Re: Win32Lib: setIndex not trigger onChange event?
Dan Moyer wrote:
>
> 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</font></i>
> > > > > 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</font></i>
> > > > > 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
Just rephrasing what Derek said: w32HChange will fire either because of
user input or use of selectItem(). In the parameter sequence for the event,
there would be a flag, say 0 for user input and 1 for selecItem()-triggered
event.
CChris
|
Not Categorized, Please Help
|
|
