In WPF, for most UI events, we have PreviewX event as well. How come there is no such a thing in Universal Apps? Is the events system fundamentally different from that of WPF that there is no need for it?
Found the answer, the system has changed from bubbling and tunneling. Now it works with Routed Events. More information can be found here. Here is the important excerpt:
Earlier we said that setting Handled to true prevents most handlers from being called. But the AddHandler method provides a technique where you can attach a handler that is always invoked for the route, even if some other handler earlier in the route has set Handled to true in the shared event data.
So instead of adding the event handler as usual, you'll need to call AddHandler to add your "Preview" handler.
Something to note: the documentation does not say that these special handlers are executed before the regular ones, so it is not exactly the same as the PreviewX method.
Related
I am getting the warning like "Added non-passive event listener to a scroll-blocking 'mousewheel' event." and suggesting me to "Consider marking event handler as 'passive' to make the page more responsive." It quite hard to understand for newbie like me. I am using Axios, mixins, auto-complete in element-ui. The page is working fine, but the loading time is lazy.
It just means you are handling mousewheel events. If the handlers are doing something instead of the normal event, you can ignore the message. If you're doing something in addition to the normal event, you should add the passive option to the listener so the default processing can happen without blocking.
https://developers.google.com/web/tools/lighthouse/audits/passive-event-listeners
In general, add the passive flag to every wheel, mousewheel,
touchstart, and touchmove event listener that does not call
preventDefault().
If it's a package that is doing the event handling and not your own code, just ignore it.
I am new to cesium so need some very basic help.
How can we swap the behavior of the mouse left button and right button without having to code the behavior ourselves?
Moreover, can someone give me a basic coding example to define our own mouse button event? I have tried to run the one from Sandcastle but it is not working at the moment, can't figure out the problem for now.
You don't need to use Cesium's mouse event system, you can just listen to the normal JavaScript mouse events outside of Cesium and react to them. The DOM element to listen to is the canvas, typically viewer.cesiumWidget.canvas.
Cesium's built-in event system is not easily configurable for now, that's an item on the wishlist. Part of the problem here is that the default behavior changes at runtime. For example, when the camera tracks or un-tracks an entity, the input event wiring gets rearranged on the fly, and customizations may be overwritten. Someday Cesium's event handlers will need to be rewritten to be configurable.
To extend what #emackey stated:
The general recommendation from the Cesium team is to use native JS events whenever possible. The event handlers within the Cesium library are there more for internal library use and plugin modules.
As for how to capture the mouse click/scroll/move events otherwise it would be helpful to have an example of what you tried so far. Though this is a good reference to read http://www.html5rocks.com/en/mobile/touchandmouse/
Most of the MSDN WinJS app samples I've seen call WinJS.UI.processAll() after the app's activated event. I've also seen a number of non-MSDN tutorials that call WinJS.UI.processAll() after the DOMContentLoaded event.
Is there any practical reason to use one approach over the other?
It's a question of timing; personally I call it on DOMContentLoaded:
WinJS.Utilities.ready().done(function() {
WinJS.UI.processAll();
});
One of the primary reasons is that you can return the promise to the activation handler (the setPromise call you see in the templates), so that the splash screen is held a little longer until the WinJS.UI.processAll completes. This enables a better transition from splashscreen to completed content, without seeing partially constructed UI.
However, if you have UI that changes based on the activation type, you may want to delay this until you've constructed the DOM anyway. Since you need the activation type to make those differences, you'll need to call it after the activation event is raised.
One of the stated SpineJS goals is to make the entire UI non-blocking (i.e. display the change to the user, even though it might have not been updated successfully on the server side yet).
Can it be used in a standard "blocking" manner?
Yes it can. Look here under "callbacks":
http://spinejs.com/docs/ajax
You can basically block the UI at any point, and I do it for things that just can't be deferred to the server. Note that I don't even use the ajaxSucess() event, but just custom bindings for events. Here is an example use case in meta programming:
Bind 'clickHandlerFinish' event to clickHandlerFinishWork()
Bind 'click' event on button a to clickHandler()
User clicks on button a
clickHandler() gets fired
clickHandler disables the button and blocks the UI
clickHandler makes an AJAX call to the server to do work
(Remember UI is still blocked)
AJAX call finally returns, and fires the clickHandlerFinish() callback
clickHandlerFinish() unblocks the UI, re-enables the button, and presents the new changes
I've used this successfully on a few instances. Works great for me!
I have seen others with a similar issue but not quite what I was looking for. In the backgrounderworker class dowork event I create an instance of a new class and call one of it's function. Previously, I had this code in a windows.form.timer tick event and would pass a delegate in as one of the parameters which would allow the function and other functions it calls within the class to call a method on the form to update a datagrid on the GUI. Is there a way to do this within the dowork event? I need this because the function I call from dowork calls other functions and I want each of those functions to log information in the GUI datagrid.
The BackgroundWorker.ReportProgress() method was intended to do that. You implement the ProgressChanged event to update the UI, it will run on the main thread. You're not restricted to report just a progress percentage, you can pass any object as well to pass info to the event handler by using the overload that accepts the userState argument. Beware that you have to use proper locking if you do that.
Apart from ReportProgess mentioned in Hans' answer, you can alternatively use Control.Invoke on one of the UI elements to exeute code in the UI thread.
You can send progress data back to the UI thread, you will get an event for that on the UI thread, then you can update the screen. It is highly preferred that the objects you send back to the UI thread are immutable. Besides calling the ReportProgress and handling the event you need to opt-in by setting WorkerSupportsProgress property to true.