Re: Win32Lib: setIndex not trigger onChange event?

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu