I use VueJS component provided by 3rd-party library, which has its own events. I can handle such events as usual with "v-on" directive and specifying interesting event name, like that:
<TheComponent v-on:itemchanged="handler"/>
But is it possible to run handler only when 'itemchanged' occurs with CTRL key pressed? The handler should not run when CTRL key is not pressed.
I tried to play with click.crtl and keydown.ctrl but have no success.
Is it possible to run handler only when 'itemchanged' occurs with CTRL key pressed?
Assuming itemchanged is triggered by a change event: no, not without a workaround. Unlike keyboard and mouse events, change contains no keyboard info. You'll need to track the status of ctrl keypresses independently because JavaScript has no way of testing whether a key is down outside of those events.
Plugin
One encapsulated way to accomplish it is with a plugin:
const pluginKeypresses = function(Vue) {
const keyPresses = {
Control: false
}
window.onkeyup = function(e) { keyPresses[e.key] = false; }
window.onkeydown = function(e) { keyPresses[e.key] = true; }
Vue.prototype.$keyPresses = Vue.observable(keyPresses);
}
Vue.use(pluginKeypresses);
Note: The e.key detection here is the current standard as of 11/2020, but is not yet fully supported by IE and some other browsers. If IE matters to you, change the key detection implementation to your liking.
Usage
From anywhere in the app you can test this.$keyPresses.Control (boolean)
Demo
Don't you receive an event object with this event ? By adding a parameter to handler you should be able to catch the event, and check inside which key is pressed. Then just add a if statement at the beginning of you handler function.
Related
<mat-checkbox (change)="handleProductClick(children, $event)" [(ngModel)] = "children.selected"
[name]="children.grpId" [id]="children.id"></mat-checkbox>
handleProductClick(selectedProd : Product, event: any)
{
event.stopPropagation();
}
If I use click function instead of change it works fine. Although I can't use click. I have to stick with change. Is there a way to call stopPropagation from change function? If not what else can I do to stop the event propagation?
I got it working. Had to use both click and change on the checkbox. I had tried that earlier. The only difference was I was calling a function in the click method and it never got called. If you call $event.stopPropagation on click method in the template, it works well. strange. The below answer solved my problem. Angular 2 prevent click on parent when clicked on child
<mat-checkbox (change)="handleProductClick(children, $event)"[checked]="children.selected" (click)="$event.stopPropagation()"
[name]="children.grpId" [id]="children.id"></mat-checkbox>
I have an object I want to drag around the screen with the mouse in Processing. I set acquired to true on mouse down over the object, and to false on mouse up, thus:
void mousePressed() {
if (overThing()) {
acquired = true;
}
}
void mouseReleased() {
acquired = false;
}
I then query acquired in my update(), and drag the object if it is true.
void update() {
\\ other stuff...
if (acquired) {
\\ drag thing code ...
}
}
This all works fine in Processing. mouseReleased() gets called whether I release the mouse inside or outside the active window.
However, when I move the code to Chrome, using processing.js (v1.4.8), mouseReleased() is not called if I release the mouse outside the canvas (whether the mouse is still over the web page, or outside the browser window). So when I return the (now unclicked) mouse to the canvas, the object is still getting dragged around.
I tried including a test of mousePressed in update(), but that also returns true in these circumstances.
Any help on what I need to do to make mouse state changes outside the canvas visible with processing.js?
I don't know about Processing specifically, but releasing mouse buttons outside a widget is a common issue in GUI development.
I suspect that you have no way of knowing the precise time when the mouse is released outside the widget, but you do have two options:
Set acquired = false in mouseOut(), as #Kevin suggests.
I assume there is some type of mouseEntered() method in Processing, and also some way of knowing if the mouse button is currently pressed (either a global variable, or an event object passed to mouseEntered()). You can catch the mouse entered event, check if the mouse has been released, and set acquired = false then.
Like so:
void mouseEntered() {
if (mouse button is pressed) {
acquired = false;
}
}
Edit: From your comments, #Susan, it seems like there is a bug in processing.js, where mousePressed is not set to false if the mouse button is released outside the canvas. One thing pointing to this being a bug is that the mouse movement example on the processing website also shows this behaviour.
Depending upon how much control you have over the website this is going on, and how much effort you want to go to, you could fix the bug yourself by writing some javascript (separate from your processing code):
Define a mouseUp() event on the page <body>, to catch all mouse release events on the page.
In the mouseUp() event, check if the event comes from your Processing control. (There is probably an event object passed to the mouseUp() function, and you might have to give your Processing control an ID to identify it)
If the event doesn't come from your Processing control, then fire a mouseUp event yourself, on the Processing control. This should (hopefully!) trigger a mouse event inside your Processing code.
I'm not sure what Processing will make of the mouse (x,y) position being outside its control when it handles the event you send it. You might want to set a flag on the event object (assuming you can add extra data to the event object) to say "don't use the (x,y) position of this event - it's outside the control".
Edit2: It was easier than I thought! Here is the JavaScript code to detect the mouse being released outside of the Processing canvas and send the mouseReleased event to the canvas. I've tested it on the mouse movement example from the Processing website, and it fixes the bug.
It uses jQuery (although it could be re-written to not use jQuery), and it assumes your Processing canvas has the ID "processingCanvas":
$(':not(processingCanvas)').mouseup(function(){
Processing.getInstanceById('processingCanvas').mouseReleased();
});
To use this code, include it anywhere in your page (in a JavaScript file or in <script> tags) and make sure you have the jQuery library included before this code.
The Processing object allows JavaScript to call any functions defined in your Processing code. Here I've used it to call Processing's built in mouseReleased() function, but if you wanted to call a custom function to handle the mouse-released-outside state differently, then you could.
You should use the mouseOut() function to detect when the mouse leaves the sketch:
void mouseOut() {
acquired = false;
}
More info in the reference here.
My window calls hide() when a QEvent::FocusOut is received. Simultaniously I want its visibility to be toggled if a hotkey is pressed. Now I have the following problem: Pressing the hotkey, registered with XGrabKex(...) seems to steel the focus of my app. Resulting in an unwanted behaviour. If my app is visible the hotkeyevent steels focus, which results in a QEvent::FocusOut, which hides my app, and after that the hotkey is received which toggles visibility (shows) my app. I.e. my app does not hide when pressing the hotkey.
Is there a way to tell the x window system to not steel the focus when a grabbed key is pressed? Or are there other possible solutions to this problem?
A couple of different methods.
Use XQueryKeymap to see which keys are pressed. For instance, when you get a FocusOut event, call XQueryKeymap and see if your hotkey is pressed. If it is not, hide the window; if it is, don't hide it and wait for the hotkey event.
Delay hiding on FocusOut by 100 or so milliseconds. Cancel hiding if you either get the hot key or get your focus back during this time interval.
Look also here for useful info.
Finally got it to work in a "proper" way:
bool MainWidget::nativeEvent(const QByteArray &eventType, void *message, long *)
{
#ifdef Q_OS_LINUX
if (eventType == "xcb_generic_event_t")
{
xcb_generic_event_t* event = static_cast<xcb_generic_event_t *>(message);
switch (event->response_type & 127)
{
case XCB_FOCUS_OUT: {
xcb_focus_out_event_t *fe = (xcb_focus_out_event_t *)event;
if ((fe->mode==XCB_NOTIFY_MODE_GRAB && fe->detail==XCB_NOTIFY_DETAIL_NONLINEAR)
|| (fe->mode==XCB_NOTIFY_MODE_NORMAL && fe->detail==XCB_NOTIFY_DETAIL_NONLINEAR ))
hide();
break;
}
}
}
#endif
return false;
}
In addition to the 'back' button functioning as expected, I need to asynchronously invoke a function to update some db tables and refresh the UI.
Prior to making this post, I did some research and tried the following on this...
<h1 data-dojo-type="dojox.mobile.Heading" id="hdgSettings" data-dojo-props="label:'Settings',back:'Done',moveTo:'svStart',fixed:'top'"></h1>
dojo.connect(dijit.registry.byId("hdgSettings"), "onclick",
function() {
if (gblLoggerOn) WL.Logger.debug(">> hdgSettings(onclick) fired...");
loadTopLvlStats();
});
Since my heading doesn't have any other widgets than the 'back' button, I thought that attaching this event to it would solve my problem... it did nothing. So I changed it to this...
dojo.connect(dijit.registry.byId("hdgSettings")._body, "onclick",
function() {
if (gblLoggerOn) WL.Logger.debug(">> hdgSettings(onclick) fired...");
loadTopLvlStats();
});
As it turns out, the '._body' attribute must be shared by the Accordion widget that I just happen to use as my app's main UI component, and any attempt to interact w the Accordion rendered my entire app useless.
As a last resort, I guess I could simply forgo using the built-in 'back' button, and simply place my own tabBarButton on the heading to control my app's transition and event processing.
If the community suggests that I use my own tabBarButton, then so be it, however there has to be a way to cleanly attach an event to the built-in 'back' button support.
Thoughts?
The following should do the trick:
var backButton = dijit.registry.byId("hdgSettings").backButton;
if (backButton) {
dojo.connect(backButton, "onClick", function() { ... });
}
Remarks:
The code above should be executed via a dojo/ready call, to avoid using dijit's widget registry before it gets filled. See http://dojotoolkit.org/reference-guide/1.9/dojo/ready.html.
Note the capitalization of the event name: "onClick" (not "onclick").
Not knowing what Dojo version you use (please always include the Dojo version information when asking questions), I kept your pre-AMD syntax, which is not recommended with recent Dojo versions (1.8, 1.9). See http://dojotoolkit.org/documentation/tutorials/1.9/modern_dojo/ for details.
I have to port some legacy code, that uses modal dialog boxes all over the place to Metro/WinRT (using C++/CX). Because these dialog boxes provide their own message loop (using DialogBoxParam()), the calling code will wait until the user has clicked a button on the message box.
I'm currently trying to write a replacement for the old message box class, that uses XAML and the popup control. To reproduce the same behavior, I have to wait in the calling thread, but also have to keep the UI responsive. I've found out, that CoreDispatcher::ProcessEvents() can be used in a loop, to keep processing events (yeah I realize that this isn't very beautiful, but I don't want to change all of our legacy code to a new threading model). However I'm running into an issue that keeps crashing my app.
Here is a minimal example that reproduces the issue (just create a XAML app and wire this to a button):
void CPPXamlTest::MainPage::Button_Click_1(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
bool cancel = false;
auto popup = ref new Popup();
auto button = ref new Button();
button->Content = "Boom";
auto token = (button->Click += ref new RoutedEventHandler([&cancel] (Object ^, RoutedEventArgs ^) { cancel = true; }));
popup->Child = button;
popup->IsOpen = true;
while (!cancel)
{
Window::Current->Dispatcher->ProcessEvents(CoreProcessEventsOption::ProcessOneAndAllPending);
}
popup->IsOpen = false;
button->Click -= token;
}
This seems to work well for the first one or two tries of opening and closing the popup, using the two buttons. After a few tries however, the application will instantly crash deep in Windows.UI.Xaml.dll, while trying to dereference a null pointer. I can also reproduce this in C# (with practically the same code).
Does anyone have an idea, what is going on in here? Or a suggestion for an alternative approach?
If anyone is interested: I asked the same question a few days later on the MSDN forums and got a response there from a Microsoft employee:
http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/11fa65e7-90b7-41f5-9884-80064ec6e2d8/
Apparently the problem here is the nested message loop that is caused by calling ProcessEvents inside an event handler. It seems that this is not supported by WinRT, but instead of failing in a well-defined manner, this will or may cause a crash.
Alas this was the best and only answer I could find, so I ended up working around the problem, by dispatching the event handler (and a lot of other code) into another thread. I could then emulate the waiting behavior of DialogBox()/DialogBoxParam() (outside the main thread), by waiting on an event that was signaled when the user clicked/tapped a button on my XAML "dialog" popup.
A workaround that works fine for me is to replace the line:
Window::Current->Dispatcher->ProcessEvents(CoreProcessEventsOption::ProcessOneAndAllPending);
with:
auto myDispatchedHandler = ref new DispatchedHandler([&](){
Window::Current->Dispatcher->ProcessEvents(CoreProcessEventsOption::ProcessOneAndAllPending);
});
dispatcher->RunAsync(CoreDispatcherPriority::Normal,myDispatchedHandler);
For more info see this post at MSDN.