In my project, how to keyboard caps lock on state. i have refer this question How can I get the Caps Lock state, and set it to on, if it isn't already?. but i am get solution in javafx. please give me solution.I am also ref for this site https://community.oracle.com/thread/2415027?tstart=0
You will want this import:
import java.awt.Toolkit;
If you are wanting it on no matter what, just turn it on with:
Toolkit.getDefaultToolkit().setLockingKeyState(KeyEvent.VK_CAPS_LOCK, true);
If you want to check first if it is off, then turn it on:
if (!Toolkit.getDefaultToolkit().getLockingKeyState(KeyEvent.VK_CAPS_LOCK)) {
Toolkit.getDefaultToolkit().setLockingKeyState(KeyEvent.VK_CAPS_LOCK, true);
}
Lastly, if you want to toggle between the two states:
if (Toolkit.getDefaultToolkit().getLockingKeyState(KeyEvent.VK_CAPS_LOCK)) {
Toolkit.getDefaultToolkit().setLockingKeyState(KeyEvent.VK_CAPS_LOCK, false);
} else {
Toolkit.getDefaultToolkit().setLockingKeyState(KeyEvent.VK_CAPS_LOCK, true);
}
I don't think it is possible to query the capslock/numlock state directly in JavaFX 8. Robert's solution uses the AWT Toolkit, which is not JavaFX, but should work for you. You might want to create a feature request in the JavaFX issue tracker for locking key state tracking.
Related
I'm relatively new to QML/QtQuick 2 and I quite enjoy it. To start mastering it I am implementing a small fullscreen game. My idea is to have the (simple) game and when the uses presses up the ESC key to pop-up a graphical menu with some settings.
Now I have all the basics running but I'm not completely sure which is the best Declarative way of managing the menu and passing keyboard focus back and forth.
Is it better to statically create the menu and make it hidden in my main file, like this:
MyMenuSystem {
visible: false
}
and then set it to "visible" when I need it? Or defer loading it and use Loader and create a new instance? I prefer to have it declared in my QML code for cleanness, but what is the best practice here? Or is there some component to switch between views that I'm completely missing? I could find very little information and examples on this topic. Thanks!
Your question is kinda broad and could lead to opinionated answers, but since it's a topic close to my heart, I thought I'd try to give some advice.
Loader
I tend to only use Loader when the item I need to load is only relevant under certain circumstances. For example, if a document is open that doesn't support a certain feature, then the UI element that represents that feature can be put into a Loader. A benefit of this (besides a (usually) very small increase in performance) is that it avoids the need to add lots of null checks for that feature. For example, if you don't use a Loader in this case, you might end up with a lot of code that looks like this:
text: optionalFeature.foo ? optionalFeature.foo.bar : ""
With a Loader, you control when the item is loaded, such that it's only loaded when the optional feature is enabled. Then the code becomes much nicer:
text: optionalFeature.foo.bar
Popup
For an in-game menu, I'd use a Popup. This is good if you want the user to be able to see the game in the background, though you can also obscure that with an overlay, if you wanted.
StackView
If you don't want to use a popup, then I'd suggest StackView. You should probably be using this for each screen in your game anyway, as it is a perfect fit for it.
Here's how I managed to do a Menu System:
I used Component to create a Component and createObject() to turn it into an instance of that component.
MyMenu.qml:
import QtQuick 2.9
Popup {
/* Menu Item 1 */
/* etc etc */
}
Game.qml:
Component {
id: myMenuId
MyMenu {
}
}
Game {
id: myGameId
property var dynamicItem
Keys.onPressed: {
if (event.key == Qt.Key_ESC) {
dynamicItem = myMenuId.createObject(myGameId);
dynamicItem.open()
}
}
}
I've been working with Quill for a short time and have been focused on getting collaborative editing working. So far it's going well and I have a fully working collaborative editor!
I want to show the selection and cursor position of other users, but I can't think how to properly approach this problem with Quill.
I essentially want to add markup to the rendered document, without adding any content to the actual document model. Is this possible? Where should I start?
You need to use "quill-cursors" package and then listen to selection-change event:
editor.on("selection-change", function (range, oldRange, source) {
console.log("Local cursor change: ", range);
});
Then broadcast this data to other remote users, and then render the remote cursor:
const cursors = editor.getModule("cursors");
cursors.createCursor(id, user.name, userColor);
cursors.moveCursor(id, cursorRange); // <== cursor data from previous step
cursors.toggleFlag(id, true);
In Quill 0.20, there was an example with multiple cursors working. The approach was a sibling absolutely positioned <div> that contained the cursors and synchronized with selection-change information from the editor. To not delay the 1.0 release this demo and feature was not updated with the new API but support is planned. You can try a similar approach in the meantime and of course the code is still available. You can also track the feature on Github Issues.
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.
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()
I may be missing something here because I thought this might be really easy but...
Using Flex, how can you tell when a ComboBox is open? I do find the open and close events that this component dispatches can be flaky so I'm looking for something a little more solid - it's probably staring me in the face.
How about checking either the existence or the visibility of the dropDown component?
The dropDown is a component of type ListBase, and can be accessed through the dropDown property. So maybe something like this (I didn't have time to test this myself):
if (myComboBox.dropDown != null && myComboBox.dropDown.visible) {
// myComboBox is open
}
The myComboBox.dropDown != null is a safety check so you will not get runtime errors trying to access the visible property of a null object.
The designers probably thought it was enough with the open and close events.
EDIT: I'll clarify that. Looking for a property that would reveal the opened/closed status of the combobox I fail to find it. And to my experience there's nothing flaky about the event system.