Open Wagnerp opened 5 months ago
@Smurf-IV I think this might be what we need https://github.com/JohannBlais/InformationBox/tree/master
@Wagnerp & @Smurf-IV & @tobitege
Maybe another solution to this MessageDialog.
The original KMessageBox is factually only a static wrapper for KryptonMessageBoxForm class. Which is the underlying component that displays the KMB.
A copy of KryptonMessageBoxForm could be the start for this dialog approach. Then wrap it in an instantiable class and expose the properties like suggested earlier.
Factually KryptonMessageBoxForm already does all the basic stuff needed, is already Kryptonized and from there can be extended with other options.
@Wagnerp @tobitege @giduac Actions for v90
Actions for v100
KryptonMessageDialog
that has fields that can be set "Before" the show is calledKMD
thoughts ?
@Wagnerp @tobitege @Smurf-IV Actions for v90
- [ ] Take KMB back to the Winform override (Remove Checkbox etc)
- [ ] Update docs to state restore and breaking changes
- [ ] Add
KryptonMessageDialog
that has fields that can be set "Before" the show is called- [ ] Add Existing V90 chekcbox etc functionality to
KMD
- [ ] Update Breaking change doc to state to to use KMD
- [ ] Update / Fix Examples to use KMD (restore KMB example)
- [ ] Add new functionality to replicate more of the "InformationBox" Example(s)
- [ ] Other functionality
thoughts ?
This dialog can become a handy control for all kinds of tasks.
Ideas to add to the list:
I appreciate the points you laid out, Smurf, and also concur with @giduac above.
Having 2 distinct components - even though causing breaking changes - looks easier to maintain in the mid- to long-term for both the maintainers and the users.
Admittedly, thus far I've mostly relied on a MessageBox-like behavior that is easy-to-use with little code for distinct purposes, like Confirmation, Yes/No or Error and always try to find a method where I don't have to provide 10 parameters each time.
Having methods to encapsule above "types" as "ease of use" drop-ins, I guess, could help many users.
A roadmap, as @giduac mentions, certainly would provide transparency and helps managing expectations for the reasons given.
@Smurf-IV, @giduac & @tobitege
The first item on the list has already been done last week.
Having 2 distinct components - even though causing breaking changes - looks easier to maintain in the mid- to long-term for both the maintainers and the users.
Agreed, I think I will Perform Step 1, BUT Keep the existing KMB and rename it as KMBDep
to allow interim for the
Use a transition period so devs can migrate to KMDialog.
And then mention that in the "Breaking Changes" I do not want to rename it to KMDialog as the functionality API params will be different.
KMDialog can then start as a separate entity in Ext kit first (to get all the controls etc sorted And RTL), Then can be moved into Suite once done.
@Wagnerp,
Please assign to me. Thanks.
@giduac Done
@Wagnerp @tobitege @giduac Actions for v90
* [x] [[Other Issues]: Copy `KryptonMessageBox` to `KryptonMessageBoxDep` #1432](https://github.com/Krypton-Suite/Standard-Toolkit/issues/1432) * [x] [[Other Issues]: Take KMB back to the Winform override (Remove Checkbox etc) #1435](https://github.com/Krypton-Suite/Standard-Toolkit/issues/1435) * [x] Update docs to state restore and breaking changes * [ ] Add `KryptonMessageDialog` that has fields that can be set "Before" the show is called * [ ] Add Existing V90 chekcbox etc functionality to `KMD` * [ ] Update Breaking change doc to state to to use KMD * [ ] Update / Fix Examples to use KMD (restore KMB example) * [ ] Add new functionality to replicate more of the "InformationBox" Example(s) * [ ] Other functionality
I think the "Not completed Actions" should be scheduled for V100
@Wagnerp
Yes please tag it V100
Taken from #1148 by @giduac
If I seen it correct then there's also an effort to incorporate a timer next to the checkbox. It might be a tall order to get all that working without creating breaking changes.
How about a sort of MessageDialog like in UWP that can be instantiated, configured and then shown.
Also the DialogResult enum remains intact and prevents confusion about all the additional values in there since DialogResult is not only used by KMessageBox
For example:
In that instantiated dialog you can embed all kinds of nifty stuff like timers / hyperlinks / scrollable text / etc. and as soon as the user closes it you can examine the dialog properties for the choices the user made.