[small bug] & is not recognized in a dialog text

[Flint]

I define in the LNG file the following line

Code: Select all

1152="Target &path:"

Then I call the dialog where it is used (Background transfer manager -> Add selected files for copying/moving), and I get the full WISIWIG implementation - "what you see is what you get" That is, I see not Target path with p underlined, but Target &path with & sign.

[Sheepdog]

Confirmed.

But as I understand it this is no bug because you can't access the 'target path' because it is no button.

sheepdog

[Flint]

Sheepdog
You are not completely right. Yes, static text fields are not accessible themselves, but when you are trying to use them, Windows places the focus to the next control that can take focus.

For example, open the Find Files dialog and on the General page press Alt+I - the cursor will immediately jump into the Search in edit field.

[SanskritFritz]

Windows places the focus to the next control that can take focus

Not Windows, but Delphi, and only if the text preceedes the control in the creation order.

[Lefteous]

2SanskritFritz

Not Windows, but Delphi, and only if the text preceedes the control in the creation order.

Windows

[Sheepdog]

[For example, open the Find Files dialog and on the General page press Alt+I - the cursor will immediately jump into the Search in edit field.

I don't know much about programming. But I have thought that the 'search &in' is a Label for the edit field while the 'target path' is only a common text field. But maybe I'm wrong.

sheepdog

[Flint]

Sheepdog
Of course, I don't know, how it's made in Delphi, I use Visual C++... But in VC++ all text labels are made independent, as usual text boxes, without any linking to the next edit box or smth similar. The programer then needs to arrange these items so that tabulation would jump from the text field to the next edit box, else such & signs will not work (I have had such bugs several times in my own programs, when the tabulation order was wrong and &s did not work). Then he just sets the property of the text boxes so that tabulation did not stop at them. So, when a user presses the Alt+letter hotkey (Alt+I in my previous example), Windows tries to jump to this text box. But it has "no-TAB" property, so Windows should jump over it to the next TAB position - and this is the edit box where the user wanted to jump.

The same concerns, e.g. listboxes and some other controls. But the checkboxes and radio-buttons are made as single units (both checkmark and its text are a single control).