Re: Win32Lib: setIndex not trigger onChange event?
- Posted by Dan Moyer <danielmoyer at prodigy.net> Mar 19, 2007
- 495 views
CChris wrote: > > Dan Moyer wrote: > > > > Derek Parnell wrote: > > > > > > Dan Moyer wrote: > > > > > > > > > > > > I have a list that when any item is selected fills *another* list with > > > > appropriate items; but sometimes rather than *user* selecting an item in > > > > the > > > > first list, the action of some other control intends to do so, via > > > > "setIndex". > > > > > > > > When the user selects an item, onChange event is triggered, but when > > > > "setIndex" > > > > is used, the onChange event is NOT triggered. I can call the onChange > > > > procedure > > > > myself, but it would be better if setIndex did so itself, wouldn't it? > > > > > > Triggering the Change event is the way Visual Basic does it too, and I > > > have > > > not so fond memories of adding special code to avoid running the trigger > > > every > > > time I set an index via the program's own code. > > > > > > So how about we let you decide on a per list basis. Would a method to flag > > > a > > > list as one that requires setIndex and setText to trigger an w32HChange > > > event > > > do? I could even add into the parameter data to the event handler an > > > indication > > > whether or not the event was operator or program initiated. > > > > > > -- > > > Derek Parnell > > > Melbourne, Australia > > > Skype name: derek.j.parnell > > > > Derek, > > > > I guess it could be done a number of ways, ie, > > 1. coder sets an index, and then *also* calls the w32HChange event, > > sometimes needing to use routine_id depending on where/when various > > routines are declared (and assuming the coder *knows* that this > > extra effort is required); > > 2. some kind of flag, as you said, to indicate "allow setIndex to > > trigger the w32HChange event" (would probably require re-code for IDE > > to allow setting that flag there, and coders would, again, need to > > be aware of the necessity to do so); > > 3. (I'm not sure what you mean by , "add into the parameter data to the > > event handler an indication > > whether or not the event was operator or program initiated"; isn't > > that > > what you indicate is essentially the case *now*, that if the program > > *user* clicks on a list, that *does* trigger w32HChange event, but > > if your internals act to do things to the list, perhaps add/delete, > > etc, those actions do NOT trigger w32HChange event? Isn't that, or > > something *like* that what is inhibiting *coder* asking setIndex from > > having w32HChange event triggered? Maybe I'm misunderstanding, > > and wouldn't *that* be a surprise, heh heh heh!) > > > > 4. best, I would think, would be to be able to separate *internal* list > > actions from triggering & re-triggeringw32HChange event, but something > > that I would *think* SHOULD trigger it, ie, if a *user* clicks on an > > item in the list, OR, if the coder wants something to happen AS IF > > the user clicked on an item, then both would trigger the w32HChange > > event handler. But I don't know how hard this would be, nor if > > it's as much a reasonably expected default as it seems to me. > > > > My basic feeling is that a coder would naturally assume that if *they* set > > the index, that the result should be the same as if the *user* effected the > > same by clicking on an item in the list, therefore let that happen, but I > > *know* I may be missing one or two (dozen) things. > > > > Now what do you think? :) > > > > Dan > > My take would be as follow: > > 1/ leave setIndex() alone, so as not to break anything; > > 2/ define a new procedure, say selectItem(), which would call setIndex() > and then invoke w32HChange on the control. This way, it is clear from > reading the code what the intent is: just (temporarily) set the index or > do as if the item had been selected as the result of user input. > > 3/ It would be easy then to have the event data sequence carry a flag > saying whether the selection occurred thru selectItem() or otherwise. > > The remaining task would be for the doc to emphasize that setIndex() doesn't > simulate a mouse click or keyboard arrow, while selectItem() kind of does. > > CChris CChris, Sounds good! I like it! Not sure though what you mean by: "...have the event data sequence carry a flag...", as the two actions, set the index, & trigger the event handler, are both invoked by your replacement procedure, right? & setIndex would still just act as now. But I might just replace my current two part solution with your suggested procedure! :) Dan