Struggling to understand the new TabStop functionality along with new Scrolling behavior

[dasien]

Hello,

I recently converted my application Retrowarden to the v2 Terminal GUI. Many improvements so i am very excited to see v2 continue to develop.

One major area of confusion i have is tab behavior and scrolling. I removed all the old ScrollBar code i had, but i am struggling to make scrolling work in the application. It would seem that in order to be compliant with "Keyboard Required" tenet, the appropriate place for me to handle the need to scroll to the control which is about to receive focus is the AdvanceFocus method? I want to make sure that the intention is for the developer to manage this via AdvanceFocus (or some other method/event), and not have it just be default behavior of the underlying system to make sure that the control with focus is visible. If the intention is for the developer to manage making sure the control that receives focus is viewable, I would really appreciate an example if possible, as i am struggling with making this work in v2.

As a precursor to that, however, is an understanding of how the new TabStop functionality is supposed to work. I have gone through my application's Views and set TabStop appropriately for all of them (I think). I have added them in the order in which i wanted them to be tabbed, even though there is no longer a way to set tab order directly. I still do not understand how the underlying system is
determining the order of tab navigation for views. Whenever i Tab through the controls, many are skipped and the order is not Top Left to Bottom Right as you would expect. To take advantage of the fact that my application has several common controls across detail input forms, i created the following structure.

+----------------------------+
+ Common Header Controls     +
+ (part of base class)       +
+----------------------------+
+----------------------------+
+ Custom Detail View         +
+ (part of derived class)    +
+----------------------------+
+----------------------------+
+ Common Footer Controls     +
+ (part of base class)       +
+----------------------------+

At runtime, depending on which type of item the user wants to add/edit, i swap in a "Detail View" of the appropriate type in the middle of the common header and footer controls. The Views contained in this Detail View never receive focus via a Tab key press. I suppose i could just create separate views for each item type and duplicate the common controls to get rid of the hierarchy, but i would prefer not to do that. I had a similar problem in V1, and the solution was for me to sprinkle in some calls to FocusFirst along with setting the TabOrder custom after the Views had all been assigned. I cannot set TabOrder any longer (the code is currently commented out in my project), so i am not sure how to get the application to consistently tab through the controls in the order that a user would expect. Even for those that it tabs to, the order kind of bounces around and is not in an order a user would expect.

Describe the solution you'd like
I would like to either understand how to make the current v2 tabbing system work, or have fine-grained control over the order in which the controls i place on the screen are tabbed. On the surface, the v1 solution of TabOrder made sense, but the underlying view composition didn't seem to respect those when you set them before the views were added at runtime, hence the need for me to go back with a custom method and override whatever the order was. I appreciate the new TabStop style, but without any way to directly influence the order in which the controls get focus, I don't know how to make that work.

For scrolling, just an example of how it is intended to work with keyboard events would be helpful. I don't see any other method in v2 that would be the appropriate place to check to see if a control is visible based on is x/y relative to the ViewPort other than AdvanceFocus (e.g. no Enter or GotFocus). An example that shows the intended behavior for an application to check a View's position relative to the visible part of the screen and what to call to advance the scrolling so that the control is visible would be great.

Thank you for all the great work!

[tig]

As a precursor to that, however, is an understanding of how the new TabStop functionality is supposed to work. I have gone through my application's Views and set TabStop appropriately for all of them (I think). I have added them in the order in which i wanted them to be tabbed, even though there is no longer a way to set tab order directly. I still do not understand how the underlying system is determining the order of tab navigation for views. Whenever i Tab through the controls, many are skipped and the order is not Top Left to Bottom Right as you would expect. To take advantage of the fact that my application has several common controls across detail input forms, i created the following structure.

First, thank you for posting all this! I'm eager to both help you and ensure that the new design actually works and makes devs happy. It's entirely possible you've found real issues that need to be addressed!!

The tab order in v2 is very simple: The order is the order in which the Views exist in the View.Subviews list.

+----------------------------+
+ Common Header Controls     +
+ (part of base class)       +
+----------------------------+
+----------------------------+
+ Custom Detail View         +
+ (part of derived class)    +
+----------------------------+
+----------------------------+
+ Common Footer Controls     +
+ (part of base class)       +
+----------------------------+

I'm a bit confused by the base/derived stuff going on here. Perhaps your issue is you should be using composition instead of inheritance. I'd have:

• appView - The main container View. It would have n (n >= 2) subviews, Added in this order:
• header = MyHeaderVIew()
• detailview1 = SomeView()
• ...
• footer = MyFooterView()

All focusable views must have CanFocus = true and in the above if any focusable view has TabStop = TabBehavior.TabStop things should just work.

[tig]

For scrolling, just an example of how it is intended to work with keyboard events would be helpful.

Please see #3820, which will likely be merged to v2_develop today. It completely revamps ScrollBar and scrolling and the new examples (and scrolling.md) should make this all clear. If it doesn't, then I have more work to do ;-).

I don't see any other method in v2 that would be the appropriate place to check to see if a control is visible based on is x/y relative to the ViewPort other than AdvanceFocus (e.g. no Enter or GotFocus). An example that shows the intended behavior for an application to check a View's position relative to the visible part of the screen and what to call to advance the scrolling so that the control is visible would be great.

Why do you need to know if a control is visible or not?

Assuming there's actually a good reason, the algo would be something like this:

bool isVisible = Viewport.Contains(isVisibleView.Frame.Location) && Viewport.Contains(isVisibleView.Location with { X = isVisibleView.X + isVisibleView.Width, Y = isVisibleView.Y + isVisibleView.Height);

This would be true IFF the entire subview was visible. The algo for determining if just a part is visible is much tricker. I'd use the new Region class for this.

HOWEVER, there is a TON of complexity in doing something USEFUL with this info. That complexity is what has prevented me from investing in an API. It's a really hard problem to make it completely general purpose.

... which brings me back to WHY? Why do you think you need such functionality?

[dasien]

For scrolling, just an example of how it is intended to work with keyboard events would be helpful.

Please see #3820, which will likely be merged to v2_develop today. It completely revamps ScrollBar and scrolling and the new examples (and scrolling.md) should make this all clear. If it doesn't, then I have more work to do ;-).

I don't see any other method in v2 that would be the appropriate place to check to see if a control is visible based on is x/y relative to the ViewPort other than AdvanceFocus (e.g. no Enter or GotFocus). An example that shows the intended behavior for an application to check a View's position relative to the visible part of the screen and what to call to advance the scrolling so that the control is visible would be great.

Why do you need to know if a control is visible or not?

Assuming there's actually a good reason, the algo would be something like this:

bool isVisible = Viewport.Contains(isVisibleView.Frame.Location) && Viewport.Contains(isVisibleView.Location with { X = isVisibleView.X + isVisibleView.Width, Y = isVisibleView.Y + isVisibleView.Height);

This would be true IFF the entire subview was visible. The algo for determining if just a part is visible is much tricker. I'd use the new Region class for this.

HOWEVER, there is a TON of complexity in doing something USEFUL with this info. That complexity is what has prevented me from investing in an API. It's a really hard problem to make it completely general purpose.

... which brings me back to WHY? Why do you think you need such functionality?

thank you for the reply! I don't need to know if the control is visible or not if the underlying scrolling mechanism detects that a control which just received focus is not visible (because it is above/below the current visible area of the screen, and automatically scrolls to make that control visible. I do need to know that if i have to control the scrolling myself, so i know whether or not i needs to scroll the view so that the control is visible.

[tig]

Can you help me get to the point where I can run your current code such that I get real data so i can test? I've never used bitwarden....

[dasien]

As a precursor to that, however, is an understanding of how the new TabStop functionality is supposed to work. I have gone through my application's Views and set TabStop appropriately for all of them (I think). I have added them in the order in which i wanted them to be tabbed, even though there is no longer a way to set tab order directly. I still do not understand how the underlying system is determining the order of tab navigation for views. Whenever i Tab through the controls, many are skipped and the order is not Top Left to Bottom Right as you would expect. To take advantage of the fact that my application has several common controls across detail input forms, i created the following structure.

First, thank you for posting all this! I'm eager to both help you and ensure that the new design actually works and makes devs happy. It's entirely possible you've found real issues that need to be addressed!!

The tab order in v2 is very simple: The order is the order in which the Views exist in the View.Subviews list.

+----------------------------+
+ Common Header Controls     +
+ (part of base class)       +
+----------------------------+
+----------------------------+
+ Custom Detail View         +
+ (part of derived class)    +
+----------------------------+
+----------------------------+
+ Common Footer Controls     +
+ (part of base class)       +
+----------------------------+

I'm a bit confused by the base/derived stuff going on here. Perhaps your issue is you should be using composition instead of inheritance. I'd have:

* `appView` - The main container View. It would have n (n >= 2) subviews, `Add`ed in this order:

* `header = MyHeaderVIew()`

* `detailview1 = SomeView()`

* ...

* `footer = MyFooterView()`

All focusable views must have CanFocus = true and in the above if any focusable view has TabStop = TabBehavior.TabStop things should just work.

Thank you for that insight. I will think about using a composite methodology to construct the overall detail view. Basically, each detail view "inherits" some common properties from the parent. For example, every item which can be saved in the application has an "Item Name", so i have a base View with a Label and TextField for storing the item name. The base View also has the "Save" and "Cancel" buttons.

I need to think about where i might use that common view type (the base class) in other parts of the application, but a composite pattern might work.

[tig]

I just ported your code to the latest v2_develop. Would you like a PR?

Not sure everything is working because I can't get past login, but it should help.

[tig]

Before you go rearchitecting, lets get to the point where I can actually run the thing and poke around. This is a great opportunity for me to ensure I understand how a "real" dev (not one of us maintainers) does things naturally!

[dasien]

Can you help me get to the point where I can run your current code such that I get real data so i can test? I've never used bitwarden....

Hi - sure, i have some test credentials that you can use. The app is in a tricky state right now, but you should be able to see the two issues on one of the detail forms. What you should do it go to Vault - Connect and put these credentials in "rwtest@gmail.com" with password "otGZkrC7kWPd6g" (both without quotes). You should then see the vault screen loaded with some test items. The top one should be highlighted and you can press 'F3' to edit that item. Since that is a item of type "Login", the detail form that is loaded is a LoginDetailView. You will see that the first control to get focus is the combo box for "Folder". Pressing Tab will move the focus back to Item Name text field, etc. After 3-4 tabs, the cursor will disappear. That is because Focus has skipped all the middle controls and gone down past the bottom of the view port, to the button for "New Custom Field". Then it goes to "Save", then "Cancel", then back up to the "Folder" combobox. All of the controls in the middle are never given focus.

[dasien]

I just ported your code to the latest v2_develop. Would you like a PR?

Not sure everything is working because I can't get past login, but it should help.

Sure that would be great!

[tig]

Can you help me get to the point where I can run your current code such that I get real data so i can test? I've never used bitwarden....

Hi - sure, i have some test credentials that you can use. The app is in a tricky state right now, but you should be able to see the two issues on one of the detail forms. What you should do it go to Vault - Connect and put these credentials in "rwtest@gmail.com" with password "otGZkrC7kWPd6g" (both without quotes). You should then see the vault screen loaded with some test items. The top one should be highlighted and you can press 'F3' to edit that item. Since that is a item of type "Login", the detail form that is loaded is a LoginDetailView. You will see that the first control to get focus is the combo box for "Folder". Pressing Tab will move the focus back to Item Name text field, etc. After 3-4 tabs, the cursor will disappear. That is because Focus has skipped all the middle controls and gone down past the bottom of the view port, to the button for "New Custom Field". Then it goes to "Save", then "Cancel", then back up to the "Folder" combobox. All of the controls in the middle are never given focus.

I now have a bitwarden account and I've installed the Windows bitwarden client. What file do I point your app at when it first starts and shows the Open File Dialog?

[dasien]

haha sorry about that - forgot about the setup part. The file is bw.exe. you need to download the CLI application from Bitwarden Help CLI