Stop AltGr From Triggering Menu Bar Items? - javafx

Introduction
The first MenuItem inside my MenuBar receives focus whenever I press down my AltGr key. This is by no means a wanted behavior—although it appears as though it’s the default behavior offered by the MenuBar itself.
This gets slightly annoying since I’m on a Swedish keyboard—meaning both the [] and the {} are called upon using the AltGr key.
Problem
I’d like to remove the functionality whereas the first MenuItem inside the MenuBar gets activated upon pressing down AltGr on a keyboard.
Research
As usual I’ve been browsing around Stackoverflow in the hope to find an answer—but in vain. It’s honestly not very surprising that no one has had this problem before due to the majority of Stackoverflow not actually using Swedish keyboard layouts.
Moreover
Perhaps someone has either seen a post like this somewhere—in that case, do mark this as a duplicate—in any other case, either point me and anyone who might come across this question in the right direction, or simply answer this question with a somewhat shallow example.

Looking at MenuBarSkin's constructor, it adds a scene event key handler which focuses the menu if any keypress involving Alt is not consumed by the time it reaches the scene:
// put focus on the first menu when the alt key is pressed
scene.addEventHandler(KeyEvent.KEY_PRESSED, e -> {
if (e.isAltDown() && !e.isConsumed()) {
firstMenuRunnable.run();
}
});
I've worked around this by putting an event handler on the main content pane of my window, that looks for the key-pressed event of ALT_GRAPH and consumes it. Since my handler goes before the scene handler, it should prevent the menu-focus behaviour from triggering. Roughly:
tabPane.addEventFilter(KeyEvent.KEY_PRESSED, e -> {
if (e.getCode() == KeyCode.ALT_GRAPH)
{
e.consume();
return;
}
});
I'm not sure if AltGr always shows up as ALT_GRAPH; I believe I have seen it show up as ALT with e.isControlDown() being true, but you could also consume that event if none of your menu shortcuts involve Ctrl+Alt (which I'm guessing they won't, as they would be triggered by AltGr since it maps to Ctrl+Alt on Windows).

I had exactly the same problem and based on above answer I was able to solve it by using below code:
mainAnchorPane.addEventFilter(KeyEvent.KEY_PRESSED, e -> {
if (e.isAltDown() || KeyCode.ALT_GRAPH == e.getCode()) {
e.consume();
}
});
On my environment when I pressed AltGr then event reported that Ctrl and AltGr buttons were pressed in this exact order. I didn't care about Ctrl but Alt was anoying so I kill both of my Alts with above code.

Related

JavaFX Combobox: handling key pressed for enter

i want to change the focus if a user press ENTER in a combobox. Firstly, i used an action-listener, but this will be also triggered when a user changes its value by pressing arrow key up or down or selecting value in the dropdown.
Therefore i thought that i could solve that by registering a key handler. But it doesn't work for the ENTER key.
Is there a way to solve my problem?
Edit:
Sorry i thought that my intro is enough.
So i have little form with some textfields and a comboBox. To increase the usability, the user only needs to press enter to switch to next field. This works great for textfields:
textfield.setOnAction(e -> {
cmbTax.requestFocus();
});
But if i register an action-listener, it would not fulfill my requirements, because it will be always triggered when value is changed:
cmbTax.setOnAction(e->textfield2.requestFocus());
So i tried a key listener, but it didn't react on ENTER, because it is handled internal before my listener would be called:
cmbTax.getEditor().setOnKeyPressed(this::handleKeyPressedForComboBox);
regards
This works for me:
setOnKeyPressed(e -> {
if (e.getCode() == KeyCode.ENTER) {
System.out.println("TEST");
}
});
In your case:
cmbTax.setOnKeyPressed(this::handleKeyPressedForComboBox);

Adobe Flex PopUpManager -- multiple instances of a TitleWindow opened

Setup: My Flex application is one consisting of several "subapps". Basically, the main application area is an ApplicationControlBar with buttons for each of the subapps. The rest of the area is a canvas where the subapps are displayed. Only one subapp is visible at a time. When switching between subapps, we do a canvas.removeAllChildren(), then canvas.addChild(subAppSwitchedTo). It's essentially a manual implementation of a ViewStack (the pros and cons of which are not the topic of this, so refrain from commenting on this).
Problem: In one of my subapps (let's say subapp "A"), I have a search function where results are displayed in a TitleWindow that gets popped up. Workflow is like enter search criteria, click search button, TitleWindow pops up with results (multiple selection datagrid), choose desired result(s), click OK, popup goes away (PopUpManager.removePopUp), and continue working. This all works fine. The problem is if I switch to a different subapp (say "B" -- where A gets removeAllChildren()'d and B gets added), then switch back to A and search again, when the results TitleWindow pops open, there will be TWO stacked on top of each other. If I continue to navigate away and back to A, every time I search, there will be an additional popup in the "stack" of popups (one for each time A gets addChild()'d).
Has anyone else experienced this? I'm not sure what to do about it and it's causing a serious usability bug in my application. Does this ring any bells to anyone? It's like I somehow need to flush the PopUpManager or something (even though I'm correctly calling removePopUp() to remove the TitleWindow). Please help!
EDIT
Flex SDK = 4.5.1
// Subapp "A"
if (!certificateSearchTitleWindow)
{
certificateSearchTitleWindow = new CertificateSearchTitleWindow;
certificateSearchTitleWindow.addEventListener("searchAccept", searchOKPopupHandler);
certificateSearchTitleWindow.addEventListener("searchCancel", searchClosePopupHandler);
}
PopUpManager.addPopUp(certificateSearchTitleWindow, this, true);
My guess is that the popup is removed from the main display list when you remove its parent (this in the PopUpManager.addPopup() method), but not from its parent display list. Why don't you listen, in your subapps, to the Event.REMOVED event, and then remove your popup ? That would be :
private var pp:CertificateSearchTitleWindow;
private function onCreationComplete():void
{
addEventListener(Event.REMOVED, onRemovede);
}
private function addPopUp():void
{
if (!pp) {
pp = new CertificateSearchTitleWindow();
PopUpManager.addPopUp(pp, this, true);
}
}
private function onRemoved(event:Event):void
{
if (pp) {
PopupManager.removePopUp(pp);
pp = null;
}
}
Thank you to those who gave suggestions. It turned out I was re-registering an eventListener over and over.
I am using a singleton to act as "shared memory" between the subapps. I was setting singleton.addEventListener(someType, listener) in subapp A's creationComplete callback. So everytime I navigated back to A, the creationComplete was running and re-adding this listener. After the search, the listener method (that opened the popup) was being called multiple times, i.e., as many times as the event had been added.
xref: http://forums.adobe.com/message/3941163

How to prevent an MFC dialog from handling the enter and escape keys and not passing it on

we have a C++ application that hosts a flex application in a MFC dialog. Everything works fine, all button pushes etc are passed directly on to flex with no problem at all, except the enter and escape keys, which immediately closes the dialog.
We can trap the enter key, by implementing PreTranslateMessage() or OnOK()
and impede the window closing behavior, but we still have the problem of passing these enter key pushes on to the hosted flex app further.
There is no "default" button on the form or anything like that, perhaps MFC is linking the enter key to the close button in the title bar behind the scenes or something.
Does anyone have any ideas how we can stop MFC from treating the enter key from being a special case.
Thanks a lot for any hints.
Edit: Here is PreTranslateMessage() that mmonem requested.
BOOL CFlexDialog::PreTranslateMessage(MSG* pMsg)
{
if ((pMsg->message == WM_KEYDOWN))
{
if (pMsg->wParam == VK_RETURN)
{
m_ctrlFlex->OnReturnKeyPressed();
return TRUE;
}
}
return __super::PreTranslateMessage(pMsg);
}
But it is not a suitable solution, calling a method in the flex app like that, as it makes life too difficult for the flex developer, it means he must write a special version implementing the return key behavior for every control.
We just want MFC to treat the return and escape keys like every other key.
Remove OnOK() and OnCancel(); PreTransateMessage is enough after considering VK_ESCAPE.
Why don't you use:
m_ctrlFlex->SendMessage(WM_KEYDOWN, VK_RETURN, 0)
instead of
m_ctrlFlex->OnReturnKeyPressed();
in your implementation of PreTranslateMessage ?
MFC command buttons can respond to events even if they do not have the focus.
Have you tried trapping the OnClicked event and OnOk to return nothing?
Example: trap OnClick...
void CMyDialog::OnClickedMyOK()
{
CDialog::OnOK();
}
Then do a no-op in the OnOk()
void CMyDialog::OnOK()
{
}
This should stop the enter key from being processed.
Another approach is "Windows Subclassing." That is, sending messages from one Window Procedure, that is a WindProc() to another WndProc(). This may provide a way without direct intervention. (This is not C++ subclassing.)
Here's a way with MFC Subclassing Edit: Provided a better link.
Search for "Windows / MFC Subclassing" if more info needed.
The flex control/window has a WndProc and your window certainly has a WndProc, Windows Subclassing should work.
New Edit: Here is perhaps a better link for subclassing an ActiveX control.
ActiveX Controls: Subclassing a Windows Control
Subclassing Windows Forms Controls - More .Net-centric.
Notice: In MFC you should see these functions.
CWnd::SubclassDlgItem
CWnd::SubclassWindow
CDialog inherits from CWnd so you will see those two functions as "dialog" functions as well. They are key to making this work. If the flash window is a true window, use SubclassWindow. If it's a control use SubclassDlgItem.
And finally, if nothing else works. A product/library that will hopefully make it easy. EasyHook looks like a product here. EasyHook at CodeProject, you can get all the source code.
If you are having issues handling tabs & enter keys I would recommend you look into using a window instead of a dialog. The dialog adds modal ( if you are using modal ), tabbing & default button handling. If you don't need/want those features, or if they are getting in your way, then don't use a dialog.
If I understand what you are doing, then you want flex to handle tabbing, enter key, and all sorts of other messages. Get the dialog code out of the way. If you still want modal style, then you may have to handle the enable/disabling of parent windows - thats all that windows does when you open a modal dialog.

Qt-Right click mouseReleaseEvents aren't caught by eventfilter,other events though are caught

My application consists of a WebView widget. A mouse click on the widget is not handled by the mousePressEvent() of my application, but by the WebView widget. So, I installed an event filter to receive the events. Now, I get notified of all events, except the mouseReleaseEvent for the right click (Everything works fine for left clicks and mousePressEvent for the right click is also getting registered). I guess it has got something to do with context events getting generated by right clicks (a pop-up menu gets generated). But since I am using a filter, the event should first be sent to me. The following is the code for the event filter
in Jambi, but I hope I can modify an answer given in Qt for Jambi.
public boolean eventFilter(QObject o,QEvent event)
{
if (event.type()==QEvent.Type.MouseButtonPress) // One can call the mousePressEvent() functions from here,which can do this work but speed
{
if (((QMouseEvent)event).button()==Qt.MouseButton.LeftButton)
{
mousebuttontype=1;
clickedorpressed=1;
}
else
if (((QMouseEvent)event).button()==Qt.MouseButton.RightButton)
{
mousebuttontype=2;
System.out.println("right");
}
t1=QTime.currentTime();
t1.start();
}
else
if (event.type()==QEvent.Type.MouseButtonRelease)
{
if (t1.elapsed()>900)
{
switch(mousebuttontype)
{
case 1: browser.back();
break;
case 2: browser.forward();
break;
}
}System.out.println("choda");
}
return false;
}
MY BASIC AIM IS GETTING THE TIME INTERVAL FOR WHICH THE RIGHT CLICK WAS PRESSED. ANY WORKAROUND ?
Some digging around certainly seems to suggest that there may be no right-mouse release event being generated if that is the trigger for a context menu on your particular system. These are conveyed as a QContextMenuEvent.
This Qt Labs post hints about this too.
A work around may be tricky if it is system dependent. Have you tried overriding event() in the QApplication class to see if the event comes through there? Some events don't necessarily get to the children but everything goes through QApplication::event().
Another option for you is, subclass Qwebview and override mouseReleaseEvent event
I've found a fix for this that I dont think will be system dependent.
My particular case was using mouseReleaseEvent in order to catch the events, and use them myself. I didn't get these events.
On all child widgets of the widget that I want to handle the event, I added to the class definition:
protected:
void mouseReleaseEvent(QMouseEvent *event) {event->ignore();}
This overrides the default implementation for context menu's, and sends the mouseReleaseEvent back up the parent chain like it would for other mousebuttons.
http://doc.qt.io/qt-5/qevent.html#ignore
This shows that it will probably propagate to the parent widget. As the link indicates, this fixed it for me at Qt 5.9, but I think it should work for virtually all version.
(I am aware this question is literally 7 years old, but it doesn't contain the fix that I think would be the best fix, and shows up as result 2 on google(qt not getting mouse release event on rightclick). So I think it deserves an up to date answer.)
Without going in to broader implementation explanations, the core problem I needed to solve related to this issue was that I needed to know if a context menu swallowed the right-click so I could ensure some custom state was handled properly. The simplest workaround I was able to find was to implement contextMenuEvent, which gets called after mousePressEvent, to detect if the event was accepted (a context menu was opened somewhere in my QGraphicsScene/Items). Here is a minimal example in Python to demonstrate how the event state might be used:
def contextMenuEvent(self, event):
event.setAccepted(False)
super(MyGraphicsView, self).contextMenuEvent(event)
self.__context_menu_used = event.isAccepted()
Note you can also skip running the the base class contextMenuEvent entirely to block the scene/items from opening a context menu. This is handy if you want to do 3D-DCC-like alt-RMB-zooming without accidentally opening a context menu, e.g.:
def contextMenuEvent(self, event):
# Block context menus if alt is held down
if event.modifiers() & QtCore.Qt.AltModifier:
return
event.setAccepted(False)
super(MyGraphicsView, self).contextMenuEvent(event)
self.__context_menu_used = event.isAccepted()

ASP.NET linkbutton raising onBeforeUnload event twice

I've posted this here, but thought it might deserve a question on its own.
What I'm trying to do is show a dialog box that asks the user if he/she wants to leave the page if there are unsaved changes. That all works fine. But the problem is described below:
Has anyone come across the problem where Internet Explorer fires the onbeforeunload event twice? While Googling around, I found it has something to do with the fact that for (among others) an ASP.NET linkbutton the HTML code is <a href="javascript: __doPostBack....
Apparently, when IE encouters a link that doesn't have a href="#", it fires the onbeforeunload event. Then, when you confirm the javascript dialog box we're showing, the page will do the 'real' unload to navigate to the other page, and raise the onbeforeunload event a second time.
A solution offered on the internet is to set a boolean variable and check on it before showing the dialog. So the second time, it wouldn't be shown. That's all well, but when the user cancels, the variable will still be set. So the next time the user wants to leave the page, the dialog won't be shown anymore.
Hope this is a little clear, and I hope someone has found a way around this?
In reaction to annakata: Yes, but you want the result of the dialog box to be used by the browser. So you might think using 'return bFlag' would do the trick (or event.returnValue = bFlag), but that gives you a second dialog box.
I've found a way around, thanks to this page. It's quite simple actually:
var onBeforeUnloadFired = false;
Use this global variable here:
if (!onBeforeUnloadFired) {
onBeforeUnloadFired = true;
event.returnValue = "You'll lose changes!";
}
window.setTimeout("ResetOnBeforeUnloadFired()", 1000);
And then implement that function:
function ResetOnBeforeUnloadFired() {
onBeforeUnloadFired = false;
}
So, in effect, use the flag, but reset it if the user clicks cancel. Not entirely what I would like, but haven't found anything better.
I haven't encountered this, but surely you could set the flag variable to be equal to the result of the dialog? If the user cancels the flag will therefore remain false.
var bFlag = window.confirm('Do you want to leave this page?');
IE supports an event on the document object called onstop. This event fires after the onbeforeunload event, but before the onunload event. This isn't exactly pertinent to your two dialogs question, but its still relevant to other people that might stumble on this thread ( as I did ).
The problem I was having, was that I needed to display a loading message upon the onbeforeunload event firing. This is all fine until the page has some sort of confirm dialog on it. The onbeforeunload event fires even if the user cancel's and remains on the page. The easiest thing for me to do was to move my "loading" display logic into a handler for document.onstop. On top of this, you have to check the readyState property of the document object, which is another IE-only field. If its "loading", it means the user is actually leaving the page. If its "complete", it means the user is staying.
If you are fine with just using IE, then you might be interested in the following.
document.onstop = function()
{
try
{
if( document.readyState != "complete" )
{
showLoadingDiv();
}
}
catch( error )
{
handleError( error );
}
}

Resources