comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: widget_control and group_leader
items: Re: widget_control and group_leader

widget_control and group_leader
type: item
description: Lets say I have two widgets, A and B. There are two links between the two: 1) A.top and B.top are eachother's groupleaders, and 2) A uses common blocks and has a variable 'foreign_event_handler' that is set by B. So, when an event is generated by A and the 'Use Foreign Event Handler' option is set in the widget, events generated by A go to whatever B set 'foreign_event_handler' using: widget_control, id, event_pro=foreign_event_handler Things to note: 1) A can't be modified at all. Nothing added or changed. (ie. no more variables) 2) B is an object widget and needs to set its structure variables to variables in the events generated by A. 3) In B::init, B.top has a uvalue of self. The question is, how can I use foreign_event_handler to get to 'B self' from an event generated by A? My thought was: PRO foreign_event_handler, eventFromA widget_control, eventFromA.top, get_Group_Leader = BtopID widget_control, BtopID, get_Uvalue = objectReferenceToB ... END And now I would be in business. But, is there such as thing as get_group_leader? Is there another way to do this? I know that not being able to change A doesn't help, else there would be a million solutions, but its not my program. The only minor change I might be able to make is to create a generic variable in A's common block that could be set to whatever, but then I would have to define it as a string or a long, and that would restrict its use. Thanks much, -- Nidhi ----------------- Nidhi Kalra nrk5@cornell.edu Sent via Deja.com http://www.deja.com/
creator: nrk5
date: 2000-12-22T22:06:48-00:00

Re: widget_control and group_leader
type: item
description: Oh jeez. I dont know why this code came out so messy. Maybe this will look a little better. widget_control, top_menu, event_pro = 'topmenu_event' widget_control, state.draw_widget_id, event_pro = 'draw_color_event' widget_control, state.draw_base_id, event_pro = 'draw_base_event' widget_control, state.keyboard_text_id, event_pro = 'keyboard_event' widget_control, state.pan_widget_id, event_pro = 'pan_event' > -- > ----------------- > Nidhi Kalra > nrk5@cornell.edu > > Sent via Deja.com > http://www.deja.com/ > -- ----------------- Nidhi Kalra nrk5@cornell.edu Sent via Deja.com http://www.deja.com/
creator: nrk5
date: 2000-12-24T07:44:51-00:00

Re: widget_control and group_leader
type: item
description: Nidhi Kalra wrote: > Let me paste in a bit of the code from program A. In the event handler > that I am mostly concerned with, the user sets the mode. mousemode > cases 0-3 were already there, so I added 4 for uniformity. When 4 is > selected, events on the draw_widget are sent to the foreign event > handler. > > pro a_event, event > ; Main event loop for atv top-level base, and for all the buttons. > ... > widget_control, event.id, get_uvalue = uvalue > ... > case uvalue of > 'mode': case event.index of > 0: widget_control, state.draw_widget_id, $ > event_pro = 'atv_draw_color_event' > 1: widget_control, state.draw_widget_id, $ > event_pro = 'atv_draw_zoom_event' > 2: widget_control, state.draw_widget_id, $ > event_pro = 'atv_draw_blink_event' > 3: widget_control, state.draw_widget_id, $ > event_pro = 'atv_draw_phot_event' > 4: widget_control, state.draw_widget_id, $ > event_pro = state.foreign_event_handler $ > + '_event' > else: print, 'Unknown mouse mode!' > endcase This design choice of A (and A's author probably is scratching his head about now), is simply one possiblity among the zillions of ways events flow can be managed. He has decided to redirect events to different procedures, based on which "button" or mode is selected. Naturally, you added yet another mode to this. I guess I haven't looked closely enough at A to speak sensibly about its design choice. But the one point I wanted to make was that there is no need for events to be processed only in 1 place. That is, you could easily have zoom, blink, phot, or color active at the same time B is receiving these event! Wouldn't this be better functionality, unless something B is doing is really making A's default behavior non-intuitive. > > The functionality I'm going for is that the user can decide when to use > external event handlers and when to let program A run 'naturally'. At > the moment, I have tried to keep foreign_event as general as possible. > Each B can do whatever it pleases with its own partic…
creator: John-David T. Smith
date: 2000-12-24T19:48:08-00:00

Re: widget_control and group_leader
type: item
description: John-David Smith (jdsmith@astro.cornell.edu) writes: > Just because RSI publishes a manual describing standard > event processing doesn't mean you can't innovate beyond > that (especially in unusual cases like yours). As someone who has tried a great many oddball ways of processing events, I can attest to the wisdom of JD's words here. But I also note that as I've gained more experience with widgets and events, that my event processing has become more conservative (as opposed to, say, my politics). And now I often find myself a proponent of the Occum's Razor school of event handling, in which the simpler is the better. :-) Cheers, David P.S. Let's just say I have enough to worry about keeping track of those darn object methods to worry overly much about events flying around everywhere. -- 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: 2000-12-24T21:22:26-00:00

Re: widget_control and group_leader
type: item
description: In article <3A4652F8.D47410F8@astro.cornell.edu>, John-David Smith <jdsmith@astro.cornell.edu> wrote: Thanks JD. Lots of good info here. Having looked at the code, I realize that I'm unlikely to have more than one object widget behaving in the B position. So, rather than having the list revolve around objects, I thought it might be cute to have it use the event.id as the key. What I mean is that the first thing when you create the Broker is that it does a widget_control, id, event_pro = broker_event to all the widgets. Then, B registers with the broker items in the signup_list of the following type: item: Event_ID ;The ID to match Object B ;The object owning the method Method ;The method to be called Call_Before ;A boolean value indicating when to call the method So, the event handler gets changed to: 1. Find all items in the list such that item.Event_ID = event.id 2. Of these, find those where Call_Before = 1 3. Call each of these methods 4. Send the object back to where it came from (widget control, send..) 5. Find the remaining items where Call_Before = 0 6. Call each of these methods The principle is the same, the details are a bit different. I also have some technical questions about your code. Things I couldn't find in the help. > > pro Broker::signup, obj, method, REMOVE=rm > if obj_valid(obj) eq 0 then return > if ptr_valid(self.signup) then begin --> I couldn't find the keyword COMPLEMENT documented in the call to 'where.' It appears to return those items that are not in 'wh'. > wh=where((*self.signup).object eq obj,cnt,COMPLEMENT=valid) > > ;; Rid list of obj, if it's already on there > if cnt ne 0 then begin -->Assuming I'm right about what 'valid' is, does valid[0] = -1 if there are no items in the list that arent in 'wh'? > if valid[0] eq -1 then ptr_free, self.signup $ -->I am not sure what (*self.signup)[valid] does. Reissue self.signup to be valid? [valid] ? > else *self.signup=(*self.signup)[valid] > endif > endif > > ;; Add it to the list, if neces…
creator: nrk5
date: 2000-12-25T05:18:23-00:00

Re: widget_control and group_leader
type: item
description: Nidhi Kalra wrote: > > In article <3A4652F8.D47410F8@astro.cornell.edu>, > John-David Smith <jdsmith@astro.cornell.edu> wrote: > > Thanks JD. Lots of good info here. Having looked at the code, I realize > that I'm unlikely to have more than one object widget behaving in the B > position. So, rather than having the list revolve around objects, I > thought it might be cute to have it use the event.id as the key. > > What I mean is that the first thing when you create the Broker is that > it does a > > widget_control, id, event_pro = broker_event > > to all the widgets. Then, B registers with the broker items in the > signup_list of the following type: > > item: Event_ID ;The ID to match > Object B ;The object owning the method > Method ;The method to be called > Call_Before ;A boolean value indicating when to call the method > > So, the event handler gets changed to: > 1. Find all items in the list such that item.Event_ID = event.id > 2. Of these, find those where Call_Before = 1 > 3. Call each of these methods > 4. Send the object back to where it came from (widget control, send..) > 5. Find the remaining items where Call_Before = 0 > 6. Call each of these methods I presume in 4 you mean send the *event* back to where it came from? This might be more work than you need... see below. > > The principle is the same, the details are a bit different. I also have > some technical questions about your code. Things I couldn't find in the > help. > >> >> pro Broker::signup, obj, method, REMOVE=rm >> if obj_valid(obj) eq 0 then return >> if ptr_valid(self.signup) then begin > > --> I couldn't find the keyword COMPLEMENT documented in the call to > 'where.' It appears to return those items that are not in 'wh'. Sorry, that's a 5.4ism, and your guess is correct. In older days I would have used: wh=where((*self.signup).object ne obj,cnt) if cnt lt n_elements(*self.signup) then ... .... (*self.signup)=(*self.signup)[wh] before adding the new one on. > >> wh=where((*self.signup).ob…
creator: John-David T. Smith
date: 2000-12-29T18:33:38-00:00

Re: widget_control and group_leader
type: item
description: David Fanning wrote: >> Just because RSI publishes a manual describing standard >> event processing doesn't mean you can't innovate beyond >> that (especially in unusual cases like yours). > > As someone who has tried a great many oddball ways > of processing events, I can attest to the wisdom > of JD's words here. > > But I also note that as I've gained more experience > with widgets and events, that my event processing has > become more conservative (as opposed to, say, my > politics). And now I often find myself a proponent of > the Occum's Razor school of event handling, in which the > simpler is the better. :-) Indeed. All who feel that RSI consistently implements the simpler solution, say "aye".... *cough*. jd
creator: John-David T. Smith
date: 2000-12-29T18:34:10-00:00