The usage case is that: heavy load task is usually scheduled on separate thread. And after task done, that thread will fire an event( even containing returned result), then main&other thread will capture the event and do other actions.
Question is: how to achieve this in Javafx? how to define customized event (not UI event), and fire it from one thread, capture from other thread?
I googled around, but don't find a concrete method. Can some one help? thanks.
Related
I'm currently working on a GWT application and I'm still a little fuzzy on how it all fits together (the joy of having to make changes without first coming to an understanding of the whole framework, although that might be difficult anyway).
We have a few Activities that all correspond to parts of the UI (e.g. main content, a toolbar and a list of things). I'm not really sure whether that's even how Activities are intended but I guess I can't really change that easily now. My problem now is that the list of things holds state (the current selection) that the main content also needs and in a way the toolbar too (at least the toolbar currently has it – I'm beyond asking).
But what would actually be an appropriate place to store that? I guess coupling the actual view implementations together and storing the selection only in the list isn't such a bright idea.
I see two main solutions here:
keep the state within each activity and keep them synchronized through events (on the EventBus). That is: the "list of things" has a current selection, main view has one too, so does the toolbar; and each time that value changes, the activity that's making the change fires an event on the event bus so that the other activities can update their state, so that all activities have the same value in their own state.
use a singleton object (if you're using GIN and dependency injection, simply annotate the object with #Singleton and inject it in all the activities) to keep the state at a central place. The activities register event handlers on the state holder object to be notified when it changes. That is, each time an activity calls setCurrentSelection (for example), an event is fired (for example a ValueChangeEvent), and because all activities listen for it, they can update their view or whatever depending on the new value. You can choose to either dispatch the event on the event bus (similar to the PlaceController) or have the state holder implement HasValueChangeHandlers. Just make sure to unregister the handlers when the activities stop to avoid memory leaks (dispatching on the event bus makes it easier: simply register the handlers on the bus passed as argument to the start method and they'll be unregistered automatically when the activity stops, and you don't even have to think about it).
Actually, PlaceController is a good example of such shared state (the current place).
I'm working on a plugin project in which I'm using Eclipse background processing.
What's the difference between the syncExec() and asyncExec() methods of the Display class? In which situations are they applicable? Any example could be helpful.
from Q: Why do I get the error "org.eclipse.swt.SWTException: Invalid thread access"?
To allow background threads to perform operations on objects belonging to the UI-thread, the methods syncExec(Runnable runnable) and asyncExec(Runnable runnable) of Display are used. These are the only methods in SWT that can be called from any thread. They allow a runnable to be executed by the UI-thread, either synchronously, causing the background thread to wait for the runnable to finish, or asynchronously allowing the background thread to continue execution without waiting for the result. A runnable that is executed using syncExec() most closely matches the equivalent direct call to the UI operation because a Java method call always waits for the result before proceeding, just like syncExec().
Adding to Tom Seidel's answer, here are examples of situations where you might want to use one or the other:
Use asyncExec when you want to update something in the UI without caring about the results. For example updating a label or a progress bar.
Use syncExec where the code following that method call needs to be sure that the UI is in a consistent state, or needs some data from the UI. For example getting some data from a user dialog. Or you update a widget and before doing anything else (e.g. another UI update) you want to know that the widget update has completed.
SWT implements single threaded UI model. In this model, only the UI-thread can invoke UI operations. If you try and access an SWT object from outside the UI-thread, you get the exception "org.eclipse.swt.SWTException: Invalid thread access". So to allow other threads to perform operations on objects belonging to the UI-thread, SWT provides syncExec and asyncExec methods.
This link may help you with an example
I have two widgets listening for a MouseOutEvent. Problem is that sometimes this events does not get called on both of the widgeth even if you mouse out of them.
No error is thrown and this is extremely hard to debug.
My understanding is that this event is fired by a browser, so I don't understand why this is not happening. I am registering this event to the widget itself.
Any suggestions will be a great help.
Thanks
Sounds like you might have used addHandler to register to your MouseOverHandler. Widget has two methods for adding event handlers, addDomHandler and addHandler. The first is meant to be used for DomEvents, e.g. MouseOutEvents. It sinks the event on the widget, which means that your listener will get notified (this is only necessary for DomEvents). Those events might not get fired if you do not use addDomHandler to register your handler.
I'm implementing a simple eclipse notification plugin that is supposed to change an icon in the toolbar if something of some nature happens. I made an extension to org.eclipse.ui.menus and the icon shows up nicely.
I thought of starting a poller thread in the Activator and have it poll every couple minutes and changing the icon accordingly.
The thread must have access to the ToolItem in order to call setImage(). How do I access the ToolItem to pass it on to the Thread?
Your handler must implement org.eclipse.ui.commands.IElementUpdater. It can call org.eclipse.ui.menus.UIElement.setIcon(ImageDescriptor). When you need to update the image, you call org.eclipse.ui.commands.ICommandService.refreshElements(String, Map) to trigger the refresh and the call to your handler.
I am using the following code to perform a selector after a delay with multiple passed parameters:
http://nifty-box.com/blog/2006/12/nsinvocation-cleans-code.html
It works very well, but I need to extend this to support the equivalent of:
[NSObject cancelPreviousPerformRequestsWithTarget:self]
(target in this case would not be self, but would be an instance of _UFLatePerformer I believe)
Is there any way to do this, so my view's deallocation can kill all remaining delayed performance requests?
On the mac you would be able to use objc_setAssociatedObject, but that does not exist on the iPhone.
So basically you need some kind of manager singleton that holds onto these references for you that you pass in an NSObject and it does what you want.
When I was doing something similar I wrote a singleton class that took in requests to perform an action, and started a timer that fired when the action was to be done - at that time my manager class decided if the request in question was still valid, and if so fired the action. I could thus effectively cancel a timer, and furthermore could tell the manager to reset the timer which didn't really, it just made a new timer but when the old timer fired the action it was requested to perform was invalid.
So basically the timer was calling the singleton back with just a request ID, which led to a dictionary entry containing details of the call.