1. Win32Lib 0.57.1 onChange bug (test code)
Here is the test program I'm working with. It is interesting to note
that the 'onChange' event seems to be working OK while you are typing in
a new entry into the Combo box but is reporting the previous value when
selecting items.
------------------------------------
include win32lib_full.ew
without warning
constant
Win = create(Window,"test",0,Default,Default,200,200,0),
Cmbo = create(Combo,"",Win,10,10,100,100,0),
Stat = create(StatusBar,"",Win,0,0,0,0,0),
Btn = create(DefPushButton,"Enter",Win,130,10,40,20,0)
procedure onClick_Btn()
sequence ctxt
ctxt = getText(Cmbo)
if length(ctxt) then
addItem(Cmbo,ctxt)
end if
end procedure
onClick[Btn] = routine_id("onClick_Btn")
procedure onChange_Cmbo()
--doEvents(Win)
setText(Stat,getText(Cmbo))
end procedure
onChange[Cmbo] = routine_id("onChange_Cmbo")
procedure onOpen_Win()
addItem( Cmbo, {"Oranges", "Pears", "Bananas", "Mangoes" } )
end procedure
onOpen[Win] = routine_id("onOpen_Win")
WinMain(Win,Normal)
------------------------------------
-- Brian
Brian Broker wrote:
> Hi Mike,
>
> I don't know if anybody else is investigating this issue but I'm doing
> what I can to figure out what is going on.
>
> All I can see is that the onChange is being processed before the text is
>
> actually changed in the control. Adding a "doEvents(Win)" at the
> beginning of my onChange routine does not change the behavior.
>
> If anybody else is investigating, let us know what you have discovered.
>
> I'd rather not waste time on a known issue.
>
> Thanks,
> Brian
>
> Michael wrote:
> > Upgraded from version 0.45r
> > Control type: SortedCombo
> > Symptom:
> > When selecting an item from the dropdown, key = getText(comboControl)
> > is called to get the new value of the dropdown. However, getText
> > returns the prior value of comboControl, which is only updated after the
> > onChange routine (which contains the call to getText) is executed. I
> > cannot tell where in the new version of win32lib this behavior is being
> > applied. It works fine under 0.45r. Any suggestions?
> >
> > Michael J. Sabal
> >
> >
2. Re: Win32Lib 0.57.1 onChange bug (test code)
.. interesting, ..are we back to getting the handle of a subclassed control
?
Anyways, here's a patch to Brian's example that *might* do what Michael
wants.
procedure onChange_Cmbo()
integer index
index=getIndex(Cmbo)
setText(Stat,getItem(Cmbo,index))
end procedure
onChange[Cmbo] = routine_id("onChange_Cmbo")
.. which, of course, 'breaks' Brian's demo 
3. Re: Win32Lib 0.57.1 onChange bug (test code)
That solved it. Thanks!
>>> wolfritz at KING.IGS.NET 04/15/02 06:59PM >>>
.. interesting, ..are we back to getting the handle of a subclassed
control
?
Anyways, here's a patch to Brian's example that *might* do what
Michael
wants.
procedure onChange_Cmbo()
integer index
index=getIndex(Cmbo)
setText(Stat,getItem(Cmbo,index))
end procedure
onChange[Cmbo] = routine_id("onChange_Cmbo")
.. which, of course, 'breaks' Brian's demo
4. Re: Win32Lib 0.57.1 onChange bug (test code)
The problem here is that a sub-optimal design decision was made somewhere
along the line to have the Change event fire for both CBN_EDITCHANGE and
CBN_SELCHANGE messages. The issue is the CBN_EDITCHANGE is sent to the
program *after* the screen has been updated with the user's change to the
edit box, while CBN_SELCHANGE is send *before* the edit box is updated. Thus
getText() routine returns different things depending on which message
triggered the Change event handler. There is no easy way that the
application can know which caused the event to fire off. I'll have to think
about how to fix this issue without breaking too many programs. Any
suggestions anyone?
----- Original Message -----
From: "Brian Broker" <bkb at cnw.com>
To: "EUforum" <EUforum at topica.com>
Sent: Tuesday, April 16, 2002 5:59 AM
Subject: Win32Lib 0.57.1 onChange bug (test code)
>
> Here is the test program I'm working with. It is interesting to note
> that the 'onChange' event seems to be working OK while you are typing in
> a new entry into the Combo box but is reporting the previous value when
> selecting items.
>
> ------------------------------------
> include win32lib_full.ew
> without warning
>
> constant
> Win = create(Window,"test",0,Default,Default,200,200,0),
> Cmbo = create(Combo,"",Win,10,10,100,100,0),
> Stat = create(StatusBar,"",Win,0,0,0,0,0),
> Btn = create(DefPushButton,"Enter",Win,130,10,40,20,0)
>
> procedure onClick_Btn()
> sequence ctxt
>
> ctxt = getText(Cmbo)
> if length(ctxt) then
> addItem(Cmbo,ctxt)
> end if
> end procedure
> onClick[Btn] = routine_id("onClick_Btn")
>
> procedure onChange_Cmbo()
> --doEvents(Win)
> setText(Stat,getText(Cmbo))
> end procedure
> onChange[Cmbo] = routine_id("onChange_Cmbo")
>
> procedure onOpen_Win()
> addItem( Cmbo, {"Oranges", "Pears", "Bananas", "Mangoes" } )
> end procedure
> onOpen[Win] = routine_id("onOpen_Win")
>
> WinMain(Win,Normal)
> ------------------------------------
>
> -- Brian
>
>
> Brian Broker wrote:
> > Hi Mike,
> >
> > I don't know if anybody else is investigating this issue but I'm doing
> > what I can to figure out what is going on.
> >
> > All I can see is that the onChange is being processed before the text is
> >
> > actually changed in the control. Adding a "doEvents(Win)" at the
> > beginning of my onChange routine does not change the behavior.
> >
> > If anybody else is investigating, let us know what you have discovered.
> >
> > I'd rather not waste time on a known issue.
> >
> > Thanks,
> > Brian
> >
> > Michael wrote:
> > > Upgraded from version 0.45r
> > > Control type: SortedCombo
> > > Symptom:
> > > When selecting an item from the dropdown, key =
getText(comboControl)
> > > is called to get the new value of the dropdown. However, getText
> > > returns the prior value of comboControl, which is only updated after
the
> > > onChange routine (which contains the call to getText) is executed. I
> > > cannot tell where in the new version of win32lib this behavior is
being
> > > applied. It works fine under 0.45r. Any suggestions?
> > >
> > > Michael J. Sabal
> > >
> > >
>
>
>
5. Re: Win32Lib 0.57.1 onChange bug (test code)
----- Original Message -----
From: "Brian Broker" <bkb at cnw.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Win32Lib 0.57.1 onChange bug (test code)
>
> Hi Derek,
>
> I'm likely missing the point of your inquiry here but I suggest the
> correct (at least intuitive) behavior lies within the source of David's
> version 0.45r.
>
I haven't got a copy of that version. Can you describe its behaviour to me?
Since version 0.50 the behaviour has been:
When the onChange event fires for a Combo type control
if triggered by dropdown selection or up/down arrows,
getText() returns the data that was displayed in the edit box before
the new item was selected,
getItem() returns the new selection
if triggered by typing into the edit box,
getText() returns the data as typed in so far and displayed in the
edit box,
getItem() for the first keystroke returns the data that was selected
before typing begun and for subsequent keystrokes it returns ""
Is this what people want?
> Do people have programs that would be broken by changing the behavior
> described below? I have no such program but if I did I'd want the value
> changed to, not the value changed from. I think that makes the most
> sense.
>
I agree. I'm assuming you are talking about having getText() always return
the value of the edit box after the new selection has updated it.
> However, if you were asking how to actually make it work that way, then
> I'd have to dig deeper than I already have. I have no problems with
> that, you just need to let me know...
I know how to make it work. It's just that there may be some programs that
already exist that rely on the library's current behaviour. That was the
point of my enquiry. Not "how do I do it" but "how do I do it *WITHOUT*
breaking existing code".
Anyhow, if no one seriously objects, I'll change it so that getText() always
returns the contents of the edit box after a new selection has updated it.
>
> Derek Parnell wrote:
> > The problem here is that a sub-optimal design decision was made
> > somewhere
> > along the line to have the Change event fire for both CBN_EDITCHANGE and
> > CBN_SELCHANGE messages. The issue is the CBN_EDITCHANGE is sent to the
> > program *after* the screen has been updated with the user's change to
> > the
> > edit box, while CBN_SELCHANGE is send *before* the edit box is updated.
> > Thus
> > getText() routine returns different things depending on which message
> > triggered the Change event handler. There is no easy way that the
> > application can know which caused the event to fire off. I'll have to
> > think
> > about how to fix this issue without breaking too many programs. Any
> > suggestions anyone?
> >
> >
> > ----- Original Message -----
> > From: "Brian Broker" <bkb at cnw.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Tuesday, April 16, 2002 5:59 AM
> > Subject: Win32Lib 0.57.1 onChange bug (test code)
> >
> >
> > > Here is the test program I'm working with. It is interesting to note
> > > that the 'onChange' event seems to be working OK while you are typing
in
> > > a new entry into the Combo box but is reporting the previous value
when
> > > selecting items.
> > >
> > > ------------------------------------
> > > include win32lib_full.ew
> > > without warning
> > >
> > > constant
> > > Win = create(Window,"test",0,Default,Default,200,200,0),
> > > Cmbo = create(Combo,"",Win,10,10,100,100,0),
> > > Stat = create(StatusBar,"",Win,0,0,0,0,0),
> > > Btn = create(DefPushButton,"Enter",Win,130,10,40,20,0)
> > >
> > > procedure onClick_Btn()
> > > sequence ctxt
> > >
> > > ctxt = getText(Cmbo)
> > > if length(ctxt) then
> > > addItem(Cmbo,ctxt)
> > > end if
> > > end procedure
> > > onClick[Btn] = routine_id("onClick_Btn")
> > >
> > > procedure onChange_Cmbo()
> > > --doEvents(Win)
> > > setText(Stat,getText(Cmbo))
> > > end procedure
> > > onChange[Cmbo] = routine_id("onChange_Cmbo")
> > >
> > > procedure onOpen_Win()
> > > addItem( Cmbo, {"Oranges", "Pears", "Bananas", "Mangoes" } )
> > > end procedure
> > > onOpen[Win] = routine_id("onOpen_Win")
> > >
> > > WinMain(Win,Normal)
> > > ------------------------------------
> > >
> > > -- Brian
> > >
> > >
> > > Brian Broker wrote:
> > > > Hi Mike,
> > > >
> > > > I don't know if anybody else is investigating this issue but I'm
doing
> > > > what I can to figure out what is going on.
> > > >
> > > > All I can see is that the onChange is being processed before the
text is
> > > >
> > > > actually changed in the control. Adding a "doEvents(Win)" at the
> > > > beginning of my onChange routine does not change the behavior.
> > > >
> > > > If anybody else is investigating, let us know what you have
discovered.
> > > >
> > > > I'd rather not waste time on a known issue.
> > > >
> > > > Thanks,
> > > > Brian
> > > >
> > > > Michael wrote:
> > > > > Upgraded from version 0.45r
> > > > > Control type: SortedCombo
> > > > > Symptom:
> > > > > When selecting an item from the dropdown, key =
> > getText(comboControl)
> > > > > is called to get the new value of the dropdown. However, getText
> > > > > returns the prior value of comboControl, which is only updated
after
> > the
> > > > > onChange routine (which contains the call to getText) is executed.
I
> > > > > cannot tell where in the new version of win32lib this behavior is
> > being
> > > > > applied. It works fine under 0.45r. Any suggestions?
> > > > >
> > > > > Michael J. Sabal
> > > > >
> <snip>
>
>
>
>
6. Re: Win32Lib 0.57.1 onChange bug (test code)
It really doesn't matter to me what happens when, as long as
1) it's consistent
2) it's well-documented
3) there is at least one way of getting the data the user intends to be
acted upon
Michael J. Sabal
>>> ddparnell at bigpond.com 04/20/02 09:30AM >>>
When the onChange event fires for a Combo type control
if triggered by dropdown selection or up/down arrows,
getText() returns the data that was displayed in the edit box
before
the new item was selected,
getItem() returns the new selection
if triggered by typing into the edit box,
getText() returns the data as typed in so far and displayed in
the
edit box,
getItem() for the first keystroke returns the data that was
selected
before typing begun and for subsequent keystrokes it returns ""
Is this what people want?
