1. Win32Lib: setIndex not trigger onChange event?
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?
Dan Moyer
2. Re: Win32Lib: setIndex not trigger onChange event?
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
3. Re: Win32Lib: setIndex not trigger onChange event?
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
4. Re: Win32Lib: setIndex not trigger onChange event?
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
5. Re: Win32Lib: setIndex not trigger onChange event?
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
6. 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
