Carlos, you can see in the precarious preprocessor
definitions that I have renamed the Xbp ... classes to Jlb
...,
it can be used as XbpGet is used,
If you are still interested I will send you the
source code so that you can help me improve it
best regards
"Carlos A Beling" escribió en el mensaje de
noticias:768e7ef9$4186e25f$142ed4@news.alaska-software.com...
Hi Jorge.
Good day.
Many thanks.
Yes, I find it interesting.
Fraternally
Beling
On 05/11/2020 18:55, Jorge L. Borlando wrote:
>
> Hi Carlos, I leave you this test, I have worked a lot on
the Alaskan
> class with almost all the controls, if you find it
interesting, let me
> know,
>
> best regards
>
>
> "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
>>