Good day.
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?
I attached the original testing programs copyeds from ..\Source\..\..XbpGet

Fraternally
Beling

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

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[L]:   https://www.LinkedIn.com/in/AndreasGehrsPahl
[F]:   https://www.FaceBook.com/AbsoluteSoftwareLLC

Hi Andreas:
Good day.
Many thanks again.
After to read carefully your advise I will to study if it worth to me to 
use SlePic in despite XbpGet(). But nothing is making me to think that 
the Alaska's team must to correctthis behaviour because in fact it looks 
like to be a bug.

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
>

Carlos,

>But nothing is making me to think that the Alaska's team must to 
>correct this behaviour because in fact it looks like to be a bug.

I don't think this can be categorized as a bug. At the most, one could call 
it a feature request. But we are talking about some demo/example code, not 
a part of the actual Xbase++ product. It is a starting point for developers 
to built on, not a final product or feature of the language.

And only because you don't like the (current) behavior, doesn't mean that it 
is a bug or needs to be "corrected" or modified. And even though I sincerely 
doubt it, someone else could conceivably like it this way, and would be 
similarly upset if the code would be suddenly changed after working a 
particular way for over 20 years (the xbpget.prg code hasn't actually 
changed at all since 1.90.314 in December of 2004). 

But as always, you do have the source code, and can adapt it to your needs 
as you see fit.

Just my 2 cents,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[L]:   https://www.LinkedIn.com/in/AndreasGehrsPahl
[F]:   https://www.FaceBook.com/AbsoluteSoftwareLLC

Hi Andreas.
Good afternoon.
I really don't like this operation. I was led to consider it as a bug 
because this random procedure (in certain circumstances "hilite" teh 
same get, in others not. This confused me because it occurs in a system 
presented as a solution 
(..\Documents\Xbase++\source\samples\solution\xbpget) and that requires 
a great deal of knowledge for its solution.
As I admire so much both the work developed by the Xabse++ team and its 
quality, I believe that this operation must be corrected despite this 
situation having been manifested only now, as far as I know.

Fraternally
Beling

On 29/10/2020 16:16, Andreas Gehrs-Pahl wrote:
> Carlos,
> 
>> But nothing is making me to think that the Alaska's team must to
>> correct this behaviour because in fact it looks like to be a bug.
> 
> I don't think this can be categorized as a bug. At the most, one could call
> it a feature request. But we are talking about some demo/example code, not
> a part of the actual Xbase++ product. It is a starting point for developers
> to built on, not a final product or feature of the language.
> 
> And only because you don't like the (current) behavior, doesn't mean that it
> is a bug or needs to be "corrected" or modified. And even though I sincerely
> doubt it, someone else could conceivably like it this way, and would be
> similarly upset if the code would be suddenly changed after working a
> particular way for over 20 years (the xbpget.prg code hasn't actually
> changed at all since 1.90.314 in December of 2004). 
> 
> But as always, you do have the source code, and can adapt it to your needs
> as you see fit.
> 
> Just my 2 cents,
> 
> Andreas
>

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
>

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
>

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
>>

Carlos,

>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 "//?"

Actually, because you replaced oDlg:Show() with oDlg:ShowModal() in your 
"IsModal()" function, you now always get runtime errors when you try to 
close the (main) dialog by either clicking on the red [X] or the [Ok] button 
or by pressing ALT-F4. Either remove SetAppFocus(oDlg) and the event loop 
after oDlg:ShowModal(), or simply use oDlg:Show(), as you made that dialog 
already modal, anyway. But don't have both! Also, using oDlg:ShowModal() 
will no longer allow the ESC key to close that modal dialog.

The new functionality with trying to remember the marked area of the XbpGets 
isn't quite working either, as you only remember the XbpSLE's markings, but 
don't synchronize those with the underlying (Invisible) Get object or even 
verify that the "Insert" or "Overwrite" mode is active when entering fields. 

So, the remembered highlight is initially shown (or not), no matter what the 
current "Insert" setting is. Also, the marked area is automatically set to a 
single character (the first time) and to the first editable character (the 
second time) a field is re-entered (from a different dialog). All of those 
are inconsistencies that might confuse the user, possibly even more than the 
original behavior. And because the Get:Pos isn't synchronized with the 
SetMarked() position, moving the cursor in a field that has a highlight at 
any position other than the first one, the cursor will always jump back to 
the first (editable) character after switching back from a different dialog.

For example, move the cursor to the "S" of the word "String" in the first 
field and use ALT-TAB to switch to a different dialog and then press ALT-TAB 
again to switch back. The "S" will still be high-lighted, but if you press 
the Cursor-Right key, the cursor will jump to the second character in the 
field, instead of the next character, the "r". Also, if you highlight more 
than one character, for example the word "little" and then switch dialogs 
with ALT-TAB, only the (first) "l" or the (last) "e" will be highlighted, 
depending on the direction of your original marking operation. And if you 
switch dialogs with ALT-TAB twice in a row, the highlight will move to the 
first character all by itself.

So, there is still some work to do...

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas@AbsoluteSoftwareLLC.com
web:   http://www.AbsoluteSoftwareLLC.com
[L]:   https://www.LinkedIn.com/in/AndreasGehrsPahl
[F]:   https://www.FaceBook.com/AbsoluteSoftwareLLC