On OSX, if you run ADS and open two Query Windows, then float one of the query windows and put a simple query of "select 1" on each. Then cycle through the windows with Command + ` (tilde) you can then cycle and stop on the floating window and then hit Command + E to execute and you will see that the main frame window will execute and not the floating window. This is the behavior in ADS 17.0 and 18.0. This also happens (sometimes) in the reverse behavior in that it happens if you stop the cycling on the main frame and it executes on the floating frame. This seems to be happening because of the frame menu bar which is changed in the OSX window manager as focus of the main window changes and the floating window doesn't have a menubar.
If you try the steps above, but you also use the mouse to click in the window after you cycle to it, then the Command + E works correctly.
If you try the steps above, but instead of Command + E you use Command + P, then the Command + P works correctly.
If you try the steps above, but instead of using a floating Query Window you use a ER Modeler window and using the Command + P, then Command + P works correctly.
This seems to be a bug in Java for OSX when a window doesn't have a menu bar. Did some Google searches but didn't find any related bugs. Work around might be to just create a menu bar for Floating Query Window on OSX.
|
164 KB
|
249 KB
|
122 KB
I'm able to reproduce this issue on OS X in both v17 & v18.
Work around might be to just create a menu bar for Floating Query Window on OSX.
I would recommend this & consider it an improvement over our current design. We should have a separate menu bar for a floating Query Window (regardless of OS) & the menu bar should offer the complete Edit, Query & Automate menu items and a limited set of the File menu items.
I observed similar floating editor focusing issues and I thought the main bug is that when the floating frame is activated, the containing tabbed pane is not. When cycling stops at a floating frame, you will notice that the selected tab is "grey" - just click on the tab to make it "white" and Cmd+E executes correctly. So may be we could look into this bug first.
[SP] update: Kin-Hong is looking into this bug
[KHW] I have checked in a fix where whenever the frame that contains a tabbed pane (i.e. the CommonFrame and the FloatingTabDocumentFrame) is activated, the tab pane group is also activated.
I observed similar floating editor focusing issues and I thought the main bug is that when the floating frame is activated, the containing tabbed pane is not. When cycling stops at a floating frame, you will notice that the selected tab is "grey" - just click on the tab to make it "white" and Cmd+E executes correctly. So may be we could look into this bug first.
[SP] update: Kin-Hong is looking into this bug
[KHW] I have checked in a fix where whenever the frame that contains a tabbed pane (i.e. the CommonFrame and the FloatingTabDocumentFrame) is activated, the tab pane group is also activated.
[KHW] I have checked in a fix where whenever the frame that contains a tabbed pane (i.e. the CommonFrame and the FloatingTabDocumentFrame) is activated, the tab pane group is also activated.
There is one bug I've run into w/ this fix (tested on OS X):
1) Launch ADS
2) Take an existing tabbed QA window & make it Floating. Notice that the yellow highlight caret row color is displayed in this floating window but the actual caret is not visible. Even after clicking inside the floating window, the caret is still not visible. The caret is visible in the ADS main frame. After I switch focus to the ADS main frame & then switch focus back to the floating window, then the caret is visible in the floating window.
[SP] This is now resolved
[KHW] I have checked in a fix where whenever the frame that contains a tabbed pane (i.e. the CommonFrame and the FloatingTabDocumentFrame) is activated, the tab pane group is also activated.
There is one bug I've run into w/ this fix (tested on OS X):
1) Launch ADS
2) Take an existing tabbed QA window & make it Floating. Notice that the yellow highlight caret row color is displayed in this floating window but the actual caret is not visible. Even after clicking inside the floating window, the caret is still not visible. The caret is visible in the ADS main frame. After I switch focus to the ADS main frame & then switch focus back to the floating window, then the caret is visible in the floating window.
[SP] This is now resolved
There is another scenario that is not resolved:
Create 6 text editor tabs. Float one of the six tabs & then restart ADS. Upon ADS restarting, the Floating window has the focus but the caret is in the main frame. Once Cmd + Tilde, the the issue resolves itself & doesn't appear again until the next time you restart ADS & still have a floating window.
There is another scenario that is not resolved:
Create 6 text editor tabs. Float one of the six tabs & then restart ADS. Upon ADS restarting, the Floating window has the focus but the caret is in the main frame. Once Cmd + Tilde, the the issue resolves itself & doesn't appear again until the next time you restart ADS & still have a floating window.
Verified in ADS 18.0.5-6 build on Mac OSX 10.12.3.
Query executed successfully in which focus is present.
Verified in ADS 18.0.5-6 build on Mac OSX 10.12.3.
Query executed successfully in which focus is present.
Issue #14913 |
Closed |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build 18.0.5-6,17.0.11-2 |
No time estimate |
1 issue link |
breaks #14975
Issue #14975New Vertical/Horizontal group -> Go To Line -> Cursor Focus gets shifted to first tab |
I'm able to reproduce this issue on OS X in both v17 & v18.
I would recommend this & consider it an improvement over our current design. We should have a separate menu bar for a floating Query Window (regardless of OS) & the menu bar should offer the complete Edit, Query & Automate menu items and a limited set of the File menu items.