1. Re: setFocus() Win32Lib bug
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: setFocus() Win32Lib bug
> >
> > If the cursor is on, for example, the 3rd position of a field and
> setFocus()
> > moves to another field then the cursor is on the 3rd position of the new
> > field. Is this not wrong? I would think that moving to a new field that
> the
> > cursor should be on the 1'st position of the new field. Is this a win32
> bug
> > or am I wrong...
>
> Standard Windows behavior is to move to the first character position of
the
> next
> entry field - IF the next entry field is empty.- Otherwise, it selects all
> the text in the
> next field, and places the edit cursor at the right end of that field.
>
> This is another Win32Lib bug, I'm afraid.
>
Hello Irv and George,
strictly speaking this is neither a bug nor a Windows standard. However,
this behaviour is very common with Windows apps and we should probably
follow suit. Thanks for pointing this out and I'm surprised that I didn't
notice earlier.
I've included a "fix" below but I'm not 100% satisfied with it yet. My
concerns are that if I embed this behaviour into Win32Lib in this manner,
those people who do not want their apps to do this will have problems. I
will come up with a better response to the issue in a future release.
To insert this auto-selection behaviour into Win32lib, you will need to
insert a call to setIndex in two places.
1)
In the procedure called 'tab_direction()' you need to insert a call to
SetIndex towards the end of the procedure. The new lines should look like
this ...
w32Proc( xSetFocus, { getHandle( focus ) } )
setIndex(focus, {1, 1+sendMessage( focus, WM_GETTEXTLENGTH, 0, 0 )})
window_focus[parent] = focus
2)
In the procedure called 'setFocus()', the last two lines should now look
like this...
w32Proc( xSetFocus, {getHandle(id)} )
setIndex(id, {1, 1+sendMessage( id, WM_GETTEXTLENGTH, 0, 0 )})
----
Cheers,
Derek
