1. Win32Lib: setIndex not trigger onChange event?
- Posted by Dan Moyer <danielmoyer at prodigy.net> Mar 19, 2007
- 500 views
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?
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 19, 2007
- 502 views
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?
- Posted by Dan Moyer <danielmoyer at prodigy.net> Mar 19, 2007
- 499 views
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?
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Mar 19, 2007
- 492 views
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?
- Posted by Dan Moyer <danielmoyer at prodigy.net> Mar 19, 2007
- 496 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
6. Re: Win32Lib: setIndex not trigger onChange event?
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Mar 19, 2007
- 489 views
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