comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Object epiphany: A new way of building widget applications
items: Re: Object epiphany: A new way of building widget applications
items: A third-party example

Object epiphany: A new way of building widget applications
type: item
description: Hi all, With almost a week delay, I finally get around to release the first version of a new class of IDL objects: the MGS_GUIObject hierarchy. Don't shy away immediately! It's far easier than it sounds, and once you will have discovered how easy it now becomes to develop widget applications, you will get hooked! Ben Tupper has managed to get something running within a day. Even though the package is only 68k (mostly documentation ;-), I prefer not to attach it to this message but distribute it via anonymous ftp (I may put it on my web site tomorrow). You can get guiobjects_1-0.zip from ftp://ftp.dkrz.de/pub/Outgoing/martin_schultz/idl/ Before describing the object hierarchy a little, here is a quick runup over the major features of this new approach: (1) You can use the same object program to create blocking, non-blocking, and compound widgets (2) In general, you will not have to worry about widget event handling in great depth. Most of this is taken care of for you in the basic MGS_GUIObject already (3) If you compose a widget out of several compound widgets, you simply add them to a built-in container, and they will be managed automatically for you. You only need to overwrite 3-4 methods (with very simple code) to get very powerful widget programs. (4) Due to the hierarchical class structure, it is very easy to maintain the code. If you or I want to add a new basic feature to all widget programs, the change only needs to be made once (in MGS_GUIObject), and all programs will "see" the change immediately. Most of the programs described below contain an example procedure at the end, so if you ".run mgs_...__define" and then call "example, /block" you get to see what they do. Hierarchy: MGS_BaseObject : this is the father (or mother) of all my objects. It contains a pretty sophisticated ErrorMessage interface including traceback information and the choice to display errors as dialogs or on the log window, and including a debug level. This object can also clone itsel…
creator: Martin Schultz
date: 2001-04-04T21:05:33-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: Ben Tupper (pemaquidriver@tidewater.net) writes: > They are pretty quick to cash a check though! Really!? The last Treasurer's Report shows no receivables for the past 6 months. I'll get back to you, but this may explain Liam's absence. :-( David
creator: davidf
date: 2001-04-05T18:04:07-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: Craig Markwardt wrote: > > JD Smith <jdsmith@astro.cornell.edu> writes: > >> Martin Schultz wrote: >>> >>> Hi all, >>> >>> With almost a week delay, I finally get around to release the first >>> version of a new class of IDL objects: the MGS_GUIObject hierarchy. >> >> I think it only fair to let people know that I tend to shy away from >> distributed code with people's initials in the name. I know, it sounds >> stupid, but I'm not sure I'm the only one. It seems to be a reasonably >> common practice here (Craig, you listening?), but one which I think >> might be best to avoid, for the following reasons: >> > ... remainder deleted ... > > Hi JD-- > > I understand what you are saying, but I think you are a little too > harsh in criticizing other people for how they name their functions, > especially when Martin's code is as cool as it sounds. <snip> Please see my post below. I did not mean to criticize the quality and generosity of, or devotion to the work... not at all. I'm sorry if that's how it came across. I have appreciated Martin's code (and especially his unflagging diligence in documenting it!) as much as anyone else. I always find interesting things reading the comments in his code. And it appears, since no one has chimed in to say they too prefer more "universal" naming schemes, that I'm the only one whom this bothers. In that case, I'll just keep quiet and deal with it. And at this rate, I can claim the large unoccupied region of the IDL namespace with no initials prepended. My next program will be called "calculate". ;) JD
creator: John-David T. Smith
date: 2001-04-05T21:57:30-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: JD Smith (jdsmith@astro.cornell.edu) writes: > My next program will be called "calculate". ;) Is this JD making a joke!? That thesis must be rocking along! :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
creator: davidf
date: 2001-04-05T22:49:51-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: JD Smith wrote: > > Craig Markwardt wrote: >> >> JD Smith <jdsmith@astro.cornell.edu> writes: >> >>> Martin Schultz wrote: >>>> >>>> Hi all, >>>> >>>> With almost a week delay, I finally get around to release the first >>>> version of a new class of IDL objects: the MGS_GUIObject hierarchy. >>> >>> I think it only fair to let people know that I tend to shy away from >>> distributed code with people's initials in the name. I know, it sounds >>> stupid, but I'm not sure I'm the only one. It seems to be a reasonably >>> common practice here (Craig, you listening?), but one which I think >>> might be best to avoid, for the following reasons: >>> >> ... remainder deleted ... >> >> Hi JD-- >> >> I understand what you are saying, but I think you are a little too >> harsh in criticizing other people for how they name their functions, >> especially when Martin's code is as cool as it sounds. > > <snip> > > Please see my post below. I did not mean to criticize the quality and > generosity of, or devotion to the work... not at all. I'm sorry if > that's how it came across. I have appreciated Martin's code (and > especially his unflagging diligence in documenting it!) as much as > anyone else. I always find interesting things reading the comments in > his code. > > And it appears, since no one has chimed in to say they too prefer more > "universal" naming schemes, that I'm the only one whom this bothers. Ah, what the hell: it bugs me too, all this prefixing with initials. If this is equated (in an incorrect, and quite bizarre, manner since the utility or coolness of any particular piece of code has little to do with its name apart from its descriptive purpose) with ones attitude towards - as JD pointed out - code quality, programmer generosity and/or devotion, etc., then I have even less right to state that it bugs me since I don't put myself anywhere even *near* the league of the JD's, Schultzs, Fannings, Tuppers, Hadfields, Markwardts, Gumleys etc of the world. Still bugs me …
creator: Paul van Delst
date: 2001-04-05T22:51:53-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: From: "Paul van Delst" <paul.vandelst@noaa.gov> > I think, in my case, it's a case of being taught at an early age (in technical writing for > scientists writing papers etc.) that use of the first person, e.g. I, we, our, etc, was > discouraged. I guess the lesson carried over into other areas. Anyway.... That does it! From now on all my routine names will prefaced with the letters TOFKAMGH O = oceanographer. (I wouldn't be brave enough to call myself one when other oceanographers are present, but I reckon I can get away with it on this group.) --- Mark Hadfield m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield National Institute for Water and Atmospheric Research -- Posted from clam.niwa.cri.nz [202.36.29.1] via Mailgate.ORG Server - http://www.Mailgate.ORG
creator: m.hadfield
date: 2001-04-05T23:38:10-00:00

A third-party example
type: item
description: Hello, Liam suggested that I post the GUI object I made with Martin's GUIobject. I have pasted it below. 1. Make an instance of the object: obj = Obj_New('HBB_TwoList') (set Debug = 1 for error traceback) 2. Realize the GUI obj->GUI a. Select any item from the left hand (primary) list. b. Click the 'copy' button to move it to the right hand (secondary) list. c. Items in the secondary list may likewise be selected and removed... d. Close the dialog. 3. Add the option to move items in the secondary list up and down. obj->SetProperty, UPDOWN = 1 obj->GUI a. Note that the earlier selections you made are preserved. b. Select an item in the secondary list (add items to the list if there are less than two items to choose from). c. Click the MoveUp or MoveDown buttons. Note, the list wraps. Note that this object overrides the following methods found in MGS_GUIObject : INIT, CLEANUP, GETPROPERTY and SETPROPERTY. Martin has made a number of suggestions including: - Change the basic contruction of the lists so that each can be regarded as indivdual compound widgets... these would be stored in the 'COMPOUND' container - Permit moving items out of the primary list into the secondary list (rather than simply copying.) - Override the GUI method so that the MoveUp/MoveDown buttons can be mapped/unmapped rather than simple desensitized. (Although he now has the NOTIFY_REALIZE keyword in his future.) - A number of items pertaining to button/list sizing and button names. (Some of which I have tried to include this morning.) All other suggestions/comments gladly accepted. ;--------START HERE---------- ;+ ; NAME: ; HBB_TwoList ; ; PURPOSE: ; The purpose of this widget/object to provide the user an interactive means of ; of adjusting the contents of a list. Items from a 'primary' list may be copied to a ;'secondary' list. Items in the secondary list may be removed or 'moved up' or ;'moved down' relative to each other. ; ; REQUIREMENTS: ; INHERITS MGS_GUIObject ; ; CATEGORY: ; Widgets. ; …
creator: btt
date: 2001-04-09T13:07:52-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: From: "Martin Schultz" <martin.schultz@dkrz.de> Hi Martin (and idl-pvwave groupies) I finally got around to looking at your object widget stuff and I must say I am impressed (though I haven't yet grasped all the ins and outs). I like the idea of storing an "object reference, method name" structure in each widget's UVALUE so that events from that widget can then be translated into method calls. Now why didn't I think of that? --- Mark Hadfield m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield National Institute for Water and Atmospheric Research -- Posted from clam.niwa.cri.nz [202.36.29.1] via Mailgate.ORG Server - http://www.Mailgate.ORG
creator: m.hadfield
date: 2001-06-12T02:50:50-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: m.hadfield@niwa.cri.nz (Mark Hadfield) writes: > From: "Martin Schultz" <martin.schultz@dkrz.de> > > Hi Martin (and idl-pvwave groupies) > > I finally got around to looking at your object widget stuff and I must say I > am impressed (though I haven't yet grasped all the ins and outs). I like the > idea of storing an "object reference, method name" structure in each > widget's UVALUE so that events from that widget can then be translated into > method calls. Now why didn't I think of that? > Well, credit for this goes to David!! I merely carried his idea to the extreme ;-) Cheers, Martin -- [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[ [[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[ [[ Bundesstr. 55, 20146 Hamburg [[ [[ phone: +49 40 41173-308 [[ [[ fax: +49 40 41173-298 [[ [[ martin.schultz@dkrz.de [[ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
creator: Martin Schultz
date: 2001-06-12T08:54:44-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: Mark Hadfield wrote: > > From: "Martin Schultz" <martin.schultz@dkrz.de> > > Hi Martin (and idl-pvwave groupies) > > I finally got around to looking at your object widget stuff and I must say I > am impressed (though I haven't yet grasped all the ins and outs). I like the > idea of storing an "object reference, method name" structure in each > widget's UVALUE so that events from that widget can then be translated into > method calls. Now why didn't I think of that? Hmm... I had used something like this a few years ago, but instead I just saved the "action" in the UVALUE, and in the event handling method I used something like: widget_control, ev.id, get_uvalue=action if action eq 'bgroup' then action=ev.value case action of 'someaction': self->dosomething, /SOMETHING .... else: call_method,action,self ;all others, just call the method endcase This is actually fairly nice, since you can add new functionality to the widget program without ever visiting the event code, but you don't *require* a method for all trivial events which occur, instead just catching those which aren't specifically handled and sending them on their way to special-purpose methods. Also note how I translate "actions" on the fly... so for instance a button and a menu item could trivially perform the same function. It also pares down the even handler in size... always a good thing. JD
creator: John-David T. Smith
date: 2001-06-12T16:18:35-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: JD Smith <jdsmith@astro.cornell.edu> writes: > Mark Hadfield wrote: >> >> From: "Martin Schultz" <martin.schultz@dkrz.de> >> >> Hi Martin (and idl-pvwave groupies) >> >> I finally got around to looking at your object widget stuff and I must say I >> am impressed (though I haven't yet grasped all the ins and outs). I like the >> idea of storing an "object reference, method name" structure in each >> widget's UVALUE so that events from that widget can then be translated into >> method calls. Now why didn't I think of that? > > Hmm... I had used something like this a few years ago, but instead I > just saved the "action" in the UVALUE, and in the event handling method > I used something like: > > widget_control, ev.id, get_uvalue=action > if action eq 'bgroup' then action=ev.value > case action of > 'someaction': self->dosomething, /SOMETHING > .... > else: call_method,action,self ;all others, just call the method > endcase > > This is actually fairly nice, since you can add new functionality to the > widget program without ever visiting the event code, but you don't > *require* a method for all trivial events which occur, instead just > catching those which aren't specifically handled and sending them on > their way to special-purpose methods. Also note how I translate > "actions" on the fly... so for instance a button and a menu item could > trivially perform the same function. It also pares down the even > handler in size... always a good thing. > > JD It appears to be the same idea behind this. My MGS_BaseGUI object provides an event handler which is appropriate for many things and needs not to be touched. So far the objref field in the widget UValue always contains "self", and I admit, I am not sure why it should be something else ;-) Cheers, Martin -- [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[ [[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[ [[ Bundesstr. 55, 20146 Hamburg [[ [[ phone: +49 40 41173-308 [[ [[ fax: +49 40 411…
creator: Martin Schultz
date: 2001-06-13T09:42:53-00:00

Re: Object epiphany: A new way of building widget applications
type: item
description: From: "Martin Schultz" <martin.schultz@dkrz.de> > ... So far the objref field in the widget UValue always contains > "self", and I admit, I am not sure why it should be something else ;-) Yeah, I was wondering about that :-) --- Mark Hadfield m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield National Institute for Water and Atmospheric Research -- Posted from clam.niwa.cri.nz [202.36.29.1] via Mailgate.ORG Server - http://www.Mailgate.ORG
creator: m.hadfield
date: 2001-06-13T21:02:13-00:00