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>
>
>
>
>
|
Not Categorized, Please Help
|
|
