I don’t think that the Dialog extension makes sense for these smaller dialogs just being OK, Information or Question. I think they really start to pay of if you employ them with more complex dialogs or wizards - or if you want to re-use existing parts in a dialog.
Generally you could create a whole Application without one dialog - or use dialogs a lot … design decision. Sure, Wim, for your sample the OpenHandler is overkill. I personally do not like the dialog.setToBeRendered(true); dialog.setToBeRendered(false); Is this the way you want to use it? Or just for demonstration purposes? I especially like the fact, the the dialogs are visible in the application model … so I can include them into my documentation model. In https://github.com/ecrit/pharmacy_at you find a bigger sample application we are currently building in order to development the documentation system. We have a command in there which is called when dragging data from one viewer to another, and the user has to insert some data at this point. This would be something I would like to combine with the respective command. So I’ll try to come up with a sample on this usage, resp. the way we would like to use it here. cheers, marco An 21. Jänner 2014 at 18:53:30, Wim Jongman ([email protected]) schrieb: > > The MDialog behaves now exactly like an MWindow with the same > renderer and > model structure. In this sense its programming is awkward/unexpected > because instead of having a direct class to implement we implement > children > controls (e.g. one or more MPart). > > In the feeling of the programmer, the Dialog is mostly "smaller" > than a > Part. It most of the times contains limited content (a warning, > a > confirmation, a list to select from). As it stands now, the implementation > of MDialog is "more work" than that of MPart. > > Also the activation of the MDialog (the way I programmed it) feels > a little > uneasy as you can see from my implementation [1] > > > [1] > https://github.com/E4Examples/mdialog01/blob/master/mdialog01/src/mdialog01/handlers/OpenHandler.java > > > > On Tue, Jan 21, 2014 at 4:09 PM, Eric Moffatt > wrote: > > > Beauty, this is the type of conversation we need... > > > > My recommendation would be to first start by getting the simplest > of cases > > working (i.e. just bring up a dialog and don't worry whether > or not the > > buttons are defined in the model...). This should get us some > idea of how > > the dialog interacts with the contexts which is where this is > truly > > unexplored territory. Once that pattern becomes settled we'll > be in a > > better position to evaluate what else needs to be done model-wise. > > > > Eric > > > > > > [image: Inactive hide details for Wim Jongman ---01/21/2014 > 03:03:34 > > AM---(move to a separate thread) I have made a first attempt > to im]Wim > > Jongman ---01/21/2014 03:03:34 AM---(move to a separate thread) > I have made > > a first attempt to implement MDialog [1]. It is hooked to th > > > > > > > > From: > > > > > > Wim Jongman > > > > To: > > > > > > E4 Project developer mailing list , > > > > Date: > > > > > > 01/21/2014 03:03 AM > > > > Subject: > > > > > > [e4-dev] MDialog Implementation > > > > Sent by: > > > > > > [email protected] > > ------------------------------ > > > > > > > > (move to a separate thread) > > > > I have made a first attempt to implement MDialog [1]. It is hooked > to the > > "Open" command. > > > > I Defined a MDialog with visible=false, toberendered=false > and a Part as > > control (called DialogPart). > > The part implements the JFace Dialog class and I have made a small > impl in > > the createDialogArea > > The @postconstruct is hooked to the open() method > > > > Then in the openhandler I lookup the MDialog from the model and > flip > > toberendered "on" to open the dialog and then "off" after the > dialog > > returns. > > > > Please clone the repo and take a look to get some inspiration > on how this > > can be improved > > > > [1] *https://github.com/E4Examples/mdialog01* > > > > > > Cheers, > > > > Wim_______________________________________________ > > e4-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > > > > _______________________________________________ > > e4-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
