activating palette loses textselection?

[David Bovill]

On 02/04/2008, Richard Gaskin <ambassador at fourthworld.com> wrote:
>
> Klaus Major wrote:
>
> > OK - no answer - but it only happens when the target of the text-
> > > palette is
> > > a non-list field?
> > >
> >
> > No, ANY field.
> > Looks like the engine automatically puts the focus on the first field
> >  in the stack, palette or not.
>
>
Yes - but not the other way round - so list fields, I think all locked
fields do not loose their selections - only the open field.

In my experience, IIRC, it's not limited to fields but any controls. Once
> another control gets focus, text selection in an open field is lost.


Menus are OK - as are buttons that have the traversalOn set to false?
TraversalOn set to false for list fields does not seem to work - the
selection in an unlocked field is lost. This behaviour seems unrelated to
whether the stack is a palette or not.

I had submitted this request some time ago for a related issue:
>
> Indication of selected text not currently in focus:
> <http://quality.runrev.com/qacenter/show_bug.cgi?id=3327>
>
> Perhaps you and some of the others here might add some refinements to that
> to better clarify the scope of what's needed.


Done - not sure about this. But from where i can see according to the docs:

If the lockText is true and the traversalOn is false, the user can neither
> select nor edit the field's text.


Well I have a list field here with lockText = true, traversalOn = false,
autohilite = true and well selection is fine??? My take on this would be
that the traversalOn = false should be able to allow text palettes for
buttons, menus and fields???


Menus are OK - as are buttons that have the traversalOn set to false?
TraversalOn set to false for list fields does not seem to work - the
selection in an unlocked field is lost. This behaviour seems unrelated to
whether the stack is a palette or not.