|
From: Kevin A. <al...@se...> - 2002-02-17 20:14:48
|
I've converted dialog.py so that there is a result dictionary of all the return values for a given standard dialog. I converted all the samples to use the new form, except textRouter, which I'll convert later this week. I left all of the old methods in place, so any code expecting the old form will still work. I want to remove that support once we finalize the way we want dialog calls to work. If you look at dialogs.py, you can see examples of user code calls to each standard dialog: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp e/samples/dialogs/ Here's an excerpt for the ColorDialog: def on_buttonColor_mouseClick(self, target, event): result = dialog.ColorDialog(self).result self.components.fldResults.text = "ColorDialog result:\naccepted: %s\nColor: %s" % (result['accepted'], result['color']) Pretty simple, but I'm not as happy with the result attribute as I thought I would be. The problem is that it doesn't work for the user-defined dialogs that use the GenericDialog class. The reason is that in order to use a modal dialog, the minimum steps are: initialize the dialog, call ShowModal, get the results, destroy the dialog. The only solution I can think of is to have a function call wrapper, so that calling a dialog and getting the results is just a single line function call. I went ahead and added a prototype of the color dialog as a function call to dialog.py to show how this might work instead of the current system. def colorDialog(parent): dialog = wx.wxColourDialog(parent) dialog.GetColourData().SetChooseFull(1) returned = dialog.ShowModal() if returned == wx.wxID_OK or returned == wx.wxID_YES: accepted = 1 else: accepted = 0 colorData = dialog.GetColourData() color = colorData.GetColour().Get() dialog.Destroy() return {'accepted':accepted, 'returned':returnedString(returned), 'color':color} From the shell it looks like: >>> from PythonCardPrototype import dialog >>> dialog.colorDialog(None) {'returned': 'Ok', 'accepted': 1, 'color': (255, 128, 64)} I think this approach will work for all the standard dialogs. I haven't done a function wrapper on a user-defined dialog yet, but it will work pretty much the same way. The actual class for the user-defined dialog will work basically the same way, but there will be a wrapper that hides the steps of init, show dialog, destroy. The standard dialog type that we don't currently support, but that might break this methodology is the wxWizard class, but since that is a "managed window" more than a normal dialog we can deal with that hurdle when we come to it. On a related note, I noticed while doing this code that returned values need to have a numeric or string constant that won't be changed by localization. Luckily, there is only one sample so far that uses 'returned' but I think it will be more widespread with user dialog. ka |