OpenEuphoria

RE: Win32Lib 0.57.1 onChange bug (test code)

• Posted by Brian Broker <bkb at cnw.com> Apr 20, 2002
• 398 views

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.

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.

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...

Thanks,
-- Brian

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>