Page Up/Down quits working

[ron]

In a directory view. Choose a pair and compare in new view using text merge. Notice Page Up/Down behavior is as expected. Press F6 three times. Notice Page Up/Down no longer works as expected.

[Aaron]

Currently behavior

Thanks for the update. This seems to have caused a bit of confusion but it is actually intended behavior. If you have Line Details visible, then F6 will cycle between 4 'panes': Left Pane, Right Pane, and also Line Details Line 1, and Line 2. If you are in the Line Details section, and then hit Page Dn/Up, it will go down/up one line.

If you just want to hop between the left and right side, you may want to consider the Go Right and Go Left commands (default to Alt+Left Arrow/Right Arrow).

Does this help, or do you still find this feature confusing? A large part of the beta is initial reaction to the product. Why was it that you wanted to use F6 in this way (and in what way did you expect it to behave)?

[Michael Bulgrien]

A large part of the beta is initial reaction to the product. Why was it that you wanted to use F6 in this way (and in what way did you expect it to behave)?

Aaron, Ron was not complaining about the F6 functionality. He was compaining about the PgUp and PgDown functionality when in the Text Details section.

May I reverse the question: Why is it that Scooter decided that PgUp and PgDown should have the same functionality as the Up and Down arrows when the user is in the Text Details section? I would think that a user would simply use the Up and Down arrow keys if they wanted to move up or down one line.

The only reason I can think of to have the current PgUp and PgDown functionality in the Text Details section is if the arrow keys did something different (such as move up and down one line in the Text Details section instead of loading the Text Details section with the previous or next line in the source panes).

Since the Up and Down arrows move one line in the source panes, the expected functionaliy of PgUp and PgDown would be to page up and page down in the source panes...otherwise you've simply removed functionality by making PageUp and PageDn the same as the arrow keys.

[Tim]

May I reverse the question: Why is it that Scooter decided that PgUp and PgDown should have the same functionality as the Up and Down arrows when the user is in the Text Details section?

We didn't change the behavior of PageUp/Down and there was no "decision" related to this. The Line Details editors are the same control as the full panes -- they just happen to be one line high. So, PageUp/Down is working correctly in that context. The Line Details editors are not aware of the full pane editors and don't know how many lines they display.

We will take this as a suggestion to change the behavior of the Line Details editors.

[ron]

I see. I was following the green highlight and 'thought' I was in the bottom output pane when I was really on line 3 in the single line pane.

Now I understand why Page Up/Down does what it does in a single line pane. Not a big deal.

When all else fails F6 will generally move amongst views. I had forgotten about Alt <- & ->. But given that behavior, I'd expect Alt-Down to take me to the bottom pane.

[Michael Bulgrien]

The Line Details editors are the same control as the full panes -- they just happen to be one line high.

That makes sense. Thanks for the technical explanation.

[Michael Bulgrien]

I had forgotten about Alt <- & ->. But given that behavior, I'd expect Alt-Down to take me to the bottom pane.

I brought that up earlier in the Beta. Alt-Up and Alt-Down are already assigned to skip null lines in the input panes. So the behavior you're expecting was assigned to Alt+PageUp and Alt+PageDown.

[Michael Bulgrien]

The Line Details editors are not aware of the full pane editors and don't know how many lines they display...
We will take this as a suggestion to change the behavior of the Line Details editors.

Another thing to consider:

When focus is in middle of an input pane, Ctrl+Up and Ctrl+Down scroll the text up or down one line without changing the selected line. The single-line height of the Line Details causes the selection in the main panes to change lines. Like the PageUp and PageDown keys, this makes Ctrl+Up and Ctrl+Down keypresses functionally equivalent to Up and Down keypresses.

Two suggestions:

1) I suggest that "movement" keypresses in text details be aware of the associated input or output pane. In other words, execute the movement in the associated pane, then return focus to the text details. This way keypress cause and effect in the main panes will remain consistent even when initiated from the text details pane. (with one exception...see suggestion 2)

2) Although I am aware that F6 and Shift+F6 can be used to move up and down between the different sections in the text details, it feels awkward to me. Since Shift+Up and Shift+Down make no sense in the text details, would you humor me and allow them to be an alternative to F6 and Shift+F6 when in the text details section?

My rambling explanation of why: I am probably a minority in this...but I rarely use function buttons and obscure keyboard shortcuts. I always use Shift+Delete and Shift+Insert instead of Ctrl+X and Ctrl-V, for example...it feels more natural to me because the association of the key name and the functionality makes more sense. I dislike obscure keyboard definitions so much that I actually do a combination of Shift+Delete and Shift+Insert instead of a Ctrl+C because, believe it or not, thinking about what Ctrl key combination will give me the results I want just slows me down. Allowing me to Shift+Up a line and Shift+Down a line in text details would simplify things for me.