OpenEuphoria

RE: Win32Lib 0.57.1 onChange bug (test code)

• Posted by Derek Parnell <ddparnell at bigpond.com> Apr 22, 2002
• 391 views

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.