Good day.
I tested the XbpGet system and it has a problem when the first one 
XbpGet:preBlock returns .f.
Please see the attach.


Fraternally
Beling

Carlos,

>I tested the XbpGet system and it has a problem when the first one 
>XbpGet:preBlock returns .f.

I don't see any problem. Can you tell us what is wrong or not working as 
expected? You basically disable the ability of the user to access the first 
field by setting it's :PreBlock to FALSE. And that seems to work as 
advertised, as the field is skipped, ad can't be accessed.

What else did you expect to happen?

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

Hello Andreas.
Good Day.
Thanks again.
I was debuging the program and, with the mouse I could change the data 
of the invalid XbpGet (please see the attach).

Also if you type CTRL+HOME, the focus is set correctly to the first one 
pushbutton, but if you left click the cursor in the invalid XbpGet the 
focus goes back to the XbpGet that had the focus not to the first one 
XbpGet valid (as I expect).

The same occurs if you eliminate the PushButtons of the test.

Using arrows after CTRL+HOME works fine.

Fraternally
Beling



Em 15/10/2021 21:32, Andreas Gehrs-Pahl escreveu:
> Carlos,
> 
>> I tested the XbpGet system and it has a problem when the first one
>> XbpGet:preBlock returns .f.
> 
> I don't see any problem. Can you tell us what is wrong or not working as
> expected? You basically disable the ability of the user to access the first
> field by setting it's :PreBlock to FALSE. And that seems to work as
> advertised, as the field is skipped, ad can't be accessed.
> 
> What else did you expect to happen?
> 
> Andreas
>

Carlos,

>I was debuging the program and, with the mouse I could change the data 
>of the invalid XbpGet (please see the attach).

When you debug the program and stop or slow it down, you interrupt the event 
processing, so, of course, you can edit the field while it has focus and 
before the focus is moved to another object. Keep in mind that the field is 
not disabled and will receive focus, but as soon as it gets focus, will move 
focus to the next (or previous) object, if there is a :PreBlock and if it 
evaluates to FALSE. So, during that brief moment while the field has focus, 
you can modify it, even without using the debugger.

I don't think this is an error, as it works as programmed and advertised. 
If you want to prevent the user from editing this field for sure, just 
use :Disable() or make it not :Editable, using :SetEditable(.f.). This also 
has the advantage that it visually makes it obvious that the field can't be 
accessed.

>Also if you type CTRL+HOME, the focus is set correctly to the first one 
>pushbutton, but if you left click the cursor in the invalid XbpGet the 
>focus goes back to the XbpGet that had the focus not to the first one 
>XbpGet valid (as I expect).

That expectation is unwarranted. If you move the cursor (focus) forward or 
backwards with the Cursor/Arrow keys, Tab key, or Enter/Return, the focus 
will be moved forward or backward, to the next/previous (enabled) object in 
the tab list. If you click on a (random) field with the mouse, though, the 
last (currently/previously) selected object will regain focus again, as 
their is no forward or backward direction to skip to the next/previous 
object available. So that behavior, of going back to (or staying with) the 
last selected object is the correct, and in my opinion, expected behavior.

Of course, the XbpGet() and the XbpGetController() classes aren't part of 
the Xbase++ language, but part of the source code samples, which show a 
possible (but not always the only or even a good) implementation of a 
feature. You do have the source code for both and can modify them however 
you wish.

IMNSHO, skipping fields based on a :PreBlock, instead of disabling the 
object isn't a very good UI/UX design, even though it is certainly easier 
for the programmer to implement, as those objects will receive focus under 
any circumstances, but simply pass it on, so they only need to know about 
themselves.

A better and cleaner way would be to have the XbpGetController() class -- or 
a different mechanism -- disable (and enable) those objects, so that they 
never receive focus in the first place while they are disabled, and there is 
no need for any :PreBlock to move the focus away from those objects.

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

Hello Andreas.
Good day.
Many thanks again.
I will give a try to :seteditable().

Fraternallly
Beling

Em 24/10/2021 16:32, Andreas Gehrs-Pahl escreveu:
> Carlos,
> 
>> I was debuging the program and, with the mouse I could change the data
>> of the invalid XbpGet (please see the attach).
> 
> When you debug the program and stop or slow it down, you interrupt the event
> processing, so, of course, you can edit the field while it has focus and
> before the focus is moved to another object. Keep in mind that the field is
> not disabled and will receive focus, but as soon as it gets focus, will move
> focus to the next (or previous) object, if there is a :PreBlock and if it
> evaluates to FALSE. So, during that brief moment while the field has focus,
> you can modify it, even without using the debugger.
> 
> I don't think this is an error, as it works as programmed and advertised.
> If you want to prevent the user from editing this field for sure, just
> use :Disable() or make it not :Editable, using :SetEditable(.f.). This also
> has the advantage that it visually makes it obvious that the field can't be
> accessed.
> 
>> Also if you type CTRL+HOME, the focus is set correctly to the first one
>> pushbutton, but if you left click the cursor in the invalid XbpGet the
>> focus goes back to the XbpGet that had the focus not to the first one
>> XbpGet valid (as I expect).
> 
> That expectation is unwarranted. If you move the cursor (focus) forward or
> backwards with the Cursor/Arrow keys, Tab key, or Enter/Return, the focus
> will be moved forward or backward, to the next/previous (enabled) object in
> the tab list. If you click on a (random) field with the mouse, though, the
> last (currently/previously) selected object will regain focus again, as
> their is no forward or backward direction to skip to the next/previous
> object available. So that behavior, of going back to (or staying with) the
> last selected object is the correct, and in my opinion, expected behavior.
> 
> Of course, the XbpGet() and the XbpGetController() classes aren't part of
> the Xbase++ language, but part of the source code samples, which show a
> possible (but not always the only or even a good) implementation of a
> feature. You do have the source code for both and can modify them however
> you wish.
> 
> IMNSHO, skipping fields based on a :PreBlock, instead of disabling the
> object isn't a very good UI/UX design, even though it is certainly easier
> for the programmer to implement, as those objects will receive focus under
> any circumstances, but simply pass it on, so they only need to know about
> themselves.
> 
> A better and cleaner way would be to have the XbpGetController() class -- or
> a different mechanism -- disable (and enable) those objects, so that they
> never receive focus in the first place while they are disabled, and there is
> no need for any :PreBlock to move the focus away from those objects.
> 
> Hope that helps,
> 
> Andreas
>