[Feature Request]: Implementation of `MessageDialog`

[Wagnerp]

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:

MessageDialog dlg = new();
dlg.Checked = false;
dlg.CheckboxText = "Did you donate to Krypton Suite this year?";
DialogResult res = dlg.ShowDialog();

if ( res == DialogResult.OK && dlg.Checked ) {
   . . .
}

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.

[Wagnerp]

@Smurf-IV I think this might be what we need https://github.com/JohannBlais/InformationBox/tree/master

[giduac]

@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.

[Smurf-IV]

@Wagnerp @tobitege @giduac Actions for v90

• [x] #1432
• [x] #1435
• [x] Update docs to state restore and breaking changes

Actions for v100

• [ ] 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)
• [ ] Expandable/collapsible footer, see examples such as JIT
• [ ] Other functionality

thoughts ?

[giduac]

@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:

• Discuss and make a good plan before construction starts, maybe some kind of roadmap
• Start with a good base that easily and in a standard manner can be altered (add or remove controls/functionality)
• Rollback KMBox functionality when KMDialog becomes operational as the replacement for extended functionality. Use a transition period so devs can migrate to KMDialog.

[tobitege]

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.

[Wagnerp]

@Smurf-IV, @giduac & @tobitege

The first item on the list has already been done last week.

[Smurf-IV]

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.

[Smurf-IV]

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.

[giduac]

@Wagnerp,

Please assign to me. Thanks.

[Wagnerp]

@giduac Done

[Smurf-IV]

@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

[giduac]

@Wagnerp

Yes please tag it V100