"Carlos A Beling"  escribió en el mensaje de noticias:78fda112$6caa7868$140efe@news.alaska-software.com...

 

Hello Andreas.

Good day.

 

According to your advise:

<snippet>

The only way to rectify this, is to write your own XbpGet code for those

cases to make it work the way you want. Especially the

XbpGet:SetInputFocus and XbpGet:KillInputFocus methods probably need to

be modified.

</snippet>

 

I made changes to the XbpGet System and it is working as I expected.

I attached the modified files for who wants to see the changes.

All they are preceded by one line started by "//?"

 

Many thanks again.

 

Fraternally

Beling

 

On 29/10/2020 10:54, Andreas Gehrs-Pahl wrote:

> Carlos,

>

>> When you exit of the second XbpGet typing the key <UP> and you exit from

>> the first one XbpGet typing the key <DOWN> the second XbpGet ia not marked.

>> If it has a way for to do this can someone post how?

>

> Yes there is a way, but it requires some work. The Alaska XbpGet (and the

> XbpGetController) are not very sophisticated, so they don't accommodate many

> of those features that you expect.

>

> The basic issue (in this case) is, that XbpGet objects don't remember where

> in the SLE (or Get) the cursor was, before they lost focus (to a different

> get, or in your specific case, a different dialog). That's the reason why

> the cursor is always on the first (editable) character of a field if you tab

> through them. The XbpGet does remember the ::QueryMarked() positions -- so

> the highlight returns for basic text fields), but forgets them if you have a

> numeric value or a post- or pre-validation or some specific Picture values.

> And even though the highlight is still there (you can test this with the

> "Uppercase" field), the actual ::get position moves to the first character,

> so if you type cursor right, you cursor is back on the (second) character,

> rather than the one to the right of the highlight, as one would expect.

>

> The reason why the second field doesn't highlight the first character is

> simply because it is a numeric value. There are other fields that behave the

> same on that dialog, including the "Phone", "Zip", and "Bank" fields. If you

> click on a different dialog while in one of those four fields, and then

> click back on the input dialog (but not in any field or button), the cursor

> will be in the first position of the field (and not marked/highlighted),

> even if that first position isn't even editable (as in "Phone" and "Zip").

>

> The only way to rectify this, is to write your own XbpGet code for those

> cases to make it work the way you want. Especially the XbpGet:SetInputFocus

> and XbpGet:KillInputFocus methods probably need to be modified.

>

> Hope that helps,

>

> Andreas

>