1. RE: Win32Lib 0.57.1 onChange bug (test code)
That is my suspicion too. I'll try to avoid getting the user to do the
subclassing and have win32lib do it instead.
Wolf wrote:
> .. 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 
>
>
2. 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.
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>
3. RE: Win32Lib 0.57.1 onChange bug (test code)
Sabal.Mike at notations.com wrote:
> 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?
>
>
Okay, what I've done is when a getText() is called inside the onChange
handler for Combo type controls, what is returned is the text that the
user would see in the editbox portion of the control, after the
selection has been made. This applies for both selecting from the list
via a mouse or up/down keys or by typing directly into the editbox.
I've also added a new routine getLastMsg() which returns the Windows
message that caused an event handle to fire off. This is for advanced
users as it returns the low-level {Sub/Wnd-proc procflag, iMsg, wParam,
lParam} data.
It allows one, for example, to differentiate between onChange getting
fired off because the user was typing stuff or selecting stuff.
----------
Derek.
