OpenEuphoria

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