Community
Participate
Working Groups
Build ID: Build id: I20090313-0100 Steps To Reproduce: 1. From the Expressions view, bring up Watch Expression Dialog 2. Type watch expression 3. Hit enter. More information: The OK button is highlighted and looks like it would be the action that happened when you hit Enter but it isn't. The dialog doesn't dismiss, rather the cursor goes to the next line. That to my mind implies that you could then enter another expression, which would be nice.
This is working as designed. Dialogs in Eclipse that contain multi-line text widgets trap the enter key to create a new line in the text widget and you use Ctrl+Enter to close the dialog.
Is there some way to enter more than one line of variable expressions in the same dialog box? If I enter variableX variableY the watch expression looks like this: "variableX variableY" and it's not valid. Why is this a multi line dialog?
(In reply to comment #2) > Is there some way to enter more than one line of variable expressions in the > same dialog box? If I enter > > variableX > variableY > > the watch expression looks like this: > "variableX variableY" and it's not valid. Why is this a multi line dialog? > For example, in Java I can use a watch expression as follows: for (int i=0; i<10; i++){ if (i < testNum){ System.out.println("Test Passed: " + i); return i; } }
This issue is one of the most common debugger complaints from Flex Builder users. I can understand the reason why it needs to support multi-line, for languages like Java that allow that; but it would be really great to do something to improve the workflow. I can think of a couple of possibilities: 1. The easiest would be a simple one-line message at the bottom of the dialog that says something like this: Shift+Return can be used to dismiss this dialog. I discovered this via experimentation -- I basically started trying every keyboard modifier key I could find, until I eventually found one that worked :-) It worked for me on Windows and Mac; I haven't tried Linux. 2. Another possibility would be a checkbox in the dialog that remembers its value (so that if you bring up the dialog again, the same value is still there): [x] Allow multi-line expressions If this box is checked (the default), it would have the behavior it has today. If the user un-checks this box, the multi-line edit box would be replaced by a single-line edit box; and the single-line box would not trap the Return key, so Return could be used to end the dialog. This would probably satisfy most keyboard-heavy users.
Created attachment 140039 [details] Proposed patch, adds hint text A small proposed patch for this issue. As mentioned in my previous comment, this is a common problem for our users, so I'm hoping this can go in. The patch adds a label near the bottom of the dialog, below the "[X] Enabled" checkbox, that says: Hint: Shift+Return can be used to close this dialog.
Created attachment 140040 [details] Screenshot with patch applied
Created attachment 140041 [details] Proposed patch, adds hint text Slight fix to patch, changes SWT.None to SWT.LEFT
We can add a hint. In order to get the proper key sequence rendered/NLS'd we should be using the IKeyFormatter support in org.eclipse.jface.bindings.keys.formatting.
Need to be careful on the wording, cause Ctrl-Enter will cancel or OK the dialog depending on which button has focus. Ctrl-Tab will move the tab order out of the text area as well. So Ctrl basically gets the keyboard to use the controls outside the text area.
Created attachment 140139 [details] Proposed patch: changes "Hint:" to "Tip:", changes Shift+Return to Ctrl+Return, and doesn't hard-code keysequence text This patch makes three changes to the previous one: 1. Changes "Hint:" to "Tip:" 2. Follows Darin's suggestion of using IKeyFormatter 3. Suggests Ctrl+Return instead of Shift+Return It does not directly address Darin's concern about "being careful about the wording." It occurred to me last night that "Tip:" would probably be a better first word than "Hint:" > We can add a hint. In order to get the proper key sequence rendered/NLS'd we > should be using the IKeyFormatter support in > org.eclipse.jface.bindings.keys.formatting. Nice, I didn't know about that interface. Although that seems like the right thing to do, I must admit I just tried coding that up, and on my Mac (see attachmen), the hint text now looks a bit odd. It uses "^" for the Ctrl key, and an arrow curving around from right to left to represent the Return key. Although these are standard Mac representations of these keys when showing accelerators in menus (where space is at a premium), they look a little funny in the middle of a sentence. But nonetheless, I agree that it's probably important to use platform-standard representations of keystrokes, so I can live with that. > Need to be careful on the wording, cause Ctrl-Enter will cancel or OK the > dialog depending on which button has focus. Ctrl-Tab will move the tab order > out of the text area as well. So Ctrl basically gets the keyboard to use the > controls outside the text area. You're right, Ctrl+Enter works as well as Shift+Enter. That's fine with me for the wording to use that instead. Doesn't make any difference to me. Ctrl+Enter does seem a little more "normal". Personally, I'd rather not have the wording talk about Ctrl+Tab, because the real point here is to tackle the 99% case, where the user can, with one quick keystroke, get out of the dialog. Ctrl+Tab is nice to know about, but is not as quick & easy as Shift+Enter or Ctrl+Enter.
Created attachment 140140 [details] Mac screenshot with ctrl-return Screenshot with Ctrl+Return instead of Shift+Return. As you can see, since I am now using IKeyFormatter, Ctrl+Return shows up as "^" followed by the standard Mac glyph representing the Return key. Looks a little confusing, even for someone like me who's been working on Macs for quite a number of years now.
Comment on attachment 140139 [details] Proposed patch: changes "Hint:" to "Tip:", changes Shift+Return to Ctrl+Return, and doesn't hard-code keysequence text Applied patch
Fixed. Verified.
Verified.
