Replace in Files / "Directory" field scrolls right when clicked

Alan Kilborn

It’s usually a bad idea to alter the standard behavior of Windows controls unless you have a really good reason.

This might be one of those times.
It’s one of those things that has nagged at me occasionally, but never enough where it was enough of a conscious awareness about what was happening to make me pursue it.

Coises

@Alan-Kilborn said in Replace in Files / "Directory" field scrolls right when clicked:

@Coises said :

It’s usually a bad idea to alter the standard behavior of Windows controls unless you have a really good reason.

This might be one of those times.
It’s one of those things that has nagged at me occasionally, but never enough where it was enough of a conscious awareness about what was happening to make me pursue it.

It has annoyed me too. But…

Consider that there is almost always something in those fields (either the last used value, or some text from the document in the “Find what” field). To type something entirely new, users would have to first type Ctrl+A — or, less sophisticated users might not know about that and believe they had to delete the existing text character by character or select it with the mouse first.

Changing this would be replacing an annoying behavior which users are used to with a different annoying behavior which users are not used to.

fml2

Actually, I’m not against marking the text. What I don’t like is the fact that the text is shown scrolled to the left but then is scrolled to the right when it gets focus. It’s like pulling the ground off under the feet.

I was not aware that this is the standard way text controls work in Windows.

Coises

@fml2 said in Replace in Files / "Directory" field scrolls right when clicked:

Actually, I’m not against marking the text. What I don’t like is the fact that the text is shown scrolled to the left but then is scrolled to the right when it gets focus. It’s like pulling the ground off under the feet.

I was not aware that this is the standard way text controls work in Windows.

It’s not standard for text controls. It’s standard for “drop-down” controls, where there is a downward-pointing arrow at the right side which you can click to get a list of choices, any of which you can then click to fill in the box.

It is allowed, but not common, to use this kind of control when the text is often too long to fit the width of the box.

Edit to add: I think the scrolling-to-the-right behavior is somehow implicit in the select-all behavior, but I wouldn’t want to say either way whether it would be possible to change it without causing other inconsistent behaviors.

mpheath

@fml2 Seems to be the behavior of the CBS_AUTOHSCROLL style.

Constant	Description
CBS_AUTOHSCROLL	Automatically scrolls the text in an edit control to the right when the user types a character at the end of the line. If this style is not set, only text that fits within the rectangular boundary is allowed.

It’s like pulling the ground off under the feet.

At the moment you have some ground to stand on.

Removing this style means that the text width cannot exceed the edit control width. The ground may be pulled from under your feet entirely with removing this style as your long path would be too long in length.

I removed this style with Resource Hacker, tested the behavior and the result would disgust you. It is quite limiting of an experience.

fml2

@mpheath said in Replace in Files / "Directory" field scrolls right when clicked:

Automatically scrolls the text in an edit control to the right when the user types a character at the end of the line.

Hrm… I don’t think this describes adequately what happens since the scrolling is done without me typing anything. The edit field just gets focus. I surely want to see the caret at all times if I’m actually typing something, i.e. the style you named is a good thing.

Is it possible to mark the text (I can see the benefit of marking the text on focus) but preserve the scrolling position? Is there a style responsible for that behaviour?

As of now it’s like you come to a store, see a price tag and want to buy the item. But in the moment you take it the price changes (I’ve actually experienced such thing on a hotel booking site). I.e. you don’t get what is advertised.

Upd: anyway, I see that it’s somehow a standard (or not unusual) behaviour, and, since it’s just a minor annoyance for me, I won’t pursue to change anything in the current way it works. Thank you all for your replies!

fml2

@Coises said in Replace in Files / "Directory" field scrolls right when clicked:

It’s not standard for text controls. It’s standard for “drop-down” controls, where there is a downward-pointing arrow at the right side which you can click to get a list of choices, any of which you can then click to fill in the box.

Interestingly, the behaviour of the “Find what” field in the same dialog (which is also a drop down list) is different: it’s shown scrolled to the right (both in “Find” and “Find in files” tab). This is OK IMO since the scrolling position is not changed when the field gets focus. Changing displayed part on focus is my main concern.

Coises

@fml2 said in Replace in Files / "Directory" field scrolls right when clicked:

Interestingly, the behaviour of the “Find what” field in the same dialog (which is also a drop down list) is different: it’s shown scrolled to the right (both in “Find” and “Find in files” tab). This is OK IMO since the scrolling position is not changed when the field gets focus. Changing displayed part on focus is my main concern.

I don’t see this. If both the “Find what” field and the “Directory” field are longer than will fit, when I open the dialog, the "Find what” field is highlighted and scrolled right, while the “Directory” field is scrolled left. If I then focus the “Directory” field (whether by clicking in it or by typing Alt+E), it is highlighted and scrolled right, while the “Find what” field loses highlighting and scrolls left.

It’s consistent for me: whenever a drop-down control receives focus, the entire control is highlighted (whether by mouse, keyboard or because it is the control that receives focus when the dialog is first opened), the insertion point is set to the far right, and if the text won’t fit in the control, the text is scrolled to the right. If focus is given by clicking, the position of the click is ignored.

Whenever focus leaves a drop-down control, highlighting is removed and if the text does not fit within the control, it is scrolled to the left.

fml2

@Coises said in Replace in Files / "Directory" field scrolls right when clicked:

the "Find what” field is highlighted and scrolled right, while the “Directory” field is scrolled left.

My point exactly. This is the difference. To me, it would be more logical if no scrolling took place upon focus. Why should the field be scrolled on focus? This disrupts the mental user context IMO.

PeterJones

@fml2 said in Replace in Files / "Directory" field scrolls right when clicked:

My point exactly. This is the difference. To me, it would be more logical if no scrolling took place upon focus. Why should the field be scrolled on focus? This disrupts the mental user context IMO.

There is no difference. You misunderstood what @Coises was trying to say: whichever combobox field you click in, that one highlights all the text and scrolls to the right; the other fields go back to their default state.

Follow this sequence:

STATE = nothing active/selected/focused: both Find What and Directory show the beginning of the value (“scrolled left”)
STATE = click in Find What: Find What text shows the end (“scrolled right”), no change to Directory
STATE = click in Directory: Find What text deselects, and goes back to the beginning (“scrolled left”), and Directory selects all and shows the end (“scrolled right”)
STATE = click back in Find What: it goes back to the exact same thing as state 2

They behave exactly the same: whichever one you click selects all and scrolls to the far right. There is no difference. This is standard Windows GUI behavior, and has been for at least two decades. This is not Notepad++ specific.

update: for example, in Microsoft notepad.exe, using the Save As dialog, where the File name field uses a combobox (typeable box with pulldown arrow on right for accessing other values):

STATE = nothing clicked/selected: the File name box is scrolled to the left, showing the beginning of the filename
STATE = click in File name: it selects all and scrolls to the far right to show the end of the filename

This is the exact same behavior as in the Notepad++ dialog box. This is standard Windows GUI behavior.

fml2

@Coises , @PeterJones Now I see your point. So the “Find what” field is not scrolled to the right per se, but just because it happens to have focus when the dialog is opened. When I leave the field it gets scrolled back to the left (and the field receivinf focus is scrolled to the right).

I’ve tried several applications (including Editor and Excel) and found out that this last point (scrolling to the left when the field is left) is not done everywhere. Ofter, the text remains scrolled to the far right.

I don’t understand the logic begind it (when it’s done and when not), but I see that NP++'s behaviour does not differ (much) from that of other Windows applications.

Thank you for your patience.

Upd: Though it seems to be the standard behaviour with the drop dow lists, I still don’t get the rationale behind it. Why should something be shown one way when it doesn’t have focus and the other way when it does?

fml2

Upd2: I’ve played with it a little bit more. If the text is long enough the the displayed parts when scrolled to the left and to the right are completely different. It seems that the text radically changes. Very confusing.

PeterJones

@fml2 said in Replace in Files / "Directory" field scrolls right when clicked:

Upd2: I’ve played with it a little bit more. If the text is long enough the the displayed parts when scrolled to the left and to the right are completely different. It seems that the text radically changes. Very confusing.

Do you mean if you have a long piece of text in the combobox, like a23456789 b23456789 c23456789 d23456789 e23456789 f23456789 g23456789 h23456789 i23456789 j23456789 k23456789 l23456789 m23456789 n23456789 o23456789 p23456789 q23456789 r23456789 s23456789 t23456789 u23456789 v23456789 w23456789 x23456789 y23456789 z23456789, that when it’s not selected, you get something starting at a23456789, like
… and when you click, so it selects, you see the end of the string, which ends with z23456789, like ?

Why is that confusing to you? That is exactly the behavior described above, so no more “confusing” than all the previous examples. This behavior is exactly the behavior which has been used for decades in Windows. I am sorry you don’t like standard Windows behavior, but the N++ developer is not going to fix Windows for you – and changing the behavior of this combobox, just so that it matches your expectations would severely confuse anyone who is used to this scrolling in every normal combobox designed with standard win32 controls that they use

It seems that the text radically changes.

The text doesn’t change at all. What is visible changes, and that was already explained above. Still not confusing.

Earlier, you said,

I’ve tried several applications (including Editor and Excel) and found out that this last point (scrolling to the left when the field is left) is not done everywhere

I don’t have access to Excel right now. And I have no idea which “Editor” you tried. But I brought up Visual Studio, and tried the first non-Save-dialog combobox I could think of – the Ctrl+H search and replace: if I paste in the 260-character string example from this post, it does scroll to the right: …
If I hit tab to move to the Replace field, it does behave differently than was seen in Notepad++ or the notepad.exe SaveAs: when it unhighlights, it does not scroll back left. If I click in the FIND, then manually scroll to the left, then tab out of the FIND

… then tab back into it, it goes back to scrolled all the way right:

… so the select-all–then–scroll-right behavior is still identical to what we’ve already explained.

So what I just showed is that when leaving that particular combobox, there is a difference in behavior compared to a normal combobox: but that can easily be explained by the fact that the combo-box is not the standard Win32 combobox control, but some custom GUI element (which is obvious by the big X there, which isn’t available in other comboboxes) – so, claiming that some huge Microsoft application like Excel or Visual Studio has comboboxes that behave differently actually proves the point, not makes things more confusing: MS had to actually write a separate GUI element not available in the main win32 API – despite the fact that they are Microsoft, and literally are the ones who wrote the public combobox interface, and thus know everything about how it can and cannot function – for form controls to be able to get the behavior you want. If MS couldn’t make the standard combobox do what you want, and had to write a separate one, then there’s no way the Notepad++ could make a standard combobox do what you are asking for… I doubt very much that the Notepad++ developer is interested in the effort to create his own combobox code (a large undertaking), when there is an existing built-in win32 API combobox which does 100% of what he wants it to do, and 95% of what you want, except when entering/exiting the combobox.

fml2

@PeterJones I’m not proposing to change anything in Notepad++; I’m just expressing my not understanding the logics and the rationale in the standard behaviour of combo boxes in Windows.

Admitted, I’ve only clearly understood how it works from this discussion. Before, it didn’t jump to my eyes, probably because the texts I worked with were not long enough.

PeterJones

@fml2 said in Replace in Files / "Directory" field scrolls right when clicked:

I’m just expressing my not understanding the logics and the rationale in the standard behaviour of combo boxes in Windows.

To put it simply, for a standard combobox:

When you move focus into a combobox, it selects all the active text, and scrolls all the way to the right, so that you can see the last character in the combobox
- if you click again once it’s selected, it will clear the selection, and your typing caret will go to wherever you clicked in the visible section of text
When you move focus out of a combobox, it deselects all the active selection in that combobox, and scrolls all the way to the left, so you can see the first character.

As to the rationale: I have no clue what the win32 API designers were thinking when they created their standard combobox more than 20 years ago; sorry.