We are using objects that at times need to sync up with the server via
the mx.data.DataService, The problem is in case of explicit method
invocation over the dataservice object we are able to trap the fault
events using the fault handlers.
The problem arises when dataservice is sync'ing the object in
background. In case of a fault event (such as session timeout or
server down) the error is not trapped via the fault handler added on
the dataservice using the addEventListener(FaultEvent.FAULT).
Any suggestions on how to trap the fault events generated via
background sync invocations of the DataService?
Try DataServiceFaultEvent.FAULT instead of FaultEvent.FAULT
Related
I was digging into some source code I am working on. I found a peculiar statement that someone had coded. The source code is a GUI application with a QML GUI and uses QT 4.7.x.
The snippet below belongs to core application logic.
// connect signal-slots for decoupling
QObject::connect (this, SIGNAL(setCurrentTaskSignal(int)), this,
SLOT(SetCurrentTaskSlot(int)), Qt::QueuedConnection);
It's strange that the object connects to itself via a queued connection which essentially means that the object may "live" in different threads at the same time?
At first glance It didn't made any sense to me. Can anyone think of any reason why such a connection would be plausible or needed?. Would this even work?
It will work without any problem. Maybe there was some event loop processing required before calling SetCurrentTaskSlot?
Note that QueuedConnection doesn't mean that something is in different thread. QueuedConnection means only that when signal is emitted, corresponding slot won't be called directly. It will be queued on event loop, and will be processed when control will be given back to event loop
The queued connection implies nothing about where the receiver lives. The opposite is true: to safely send signals to an object living in another thread, you must use queued connections. But you can use them for an object living in any thread!
One uses a queued connection to ensure that the signal will be delivered from within the event loop, and not immediately from the emit site as happens with direct connection. Direct connection is conceptually a set of calls to function pointers on a list. Queued connection is conceptually an event sent to a clever receiver who can execute a function call based on the contents of the event.
The event is the internal QMetaCallEvent, and it is QObject::event that acts upon this event and executes the call.
I have a custom observer class derived from CBase, MConnectionMonitorObserver, and QObject(for signals) that I use to observe events from RConnectionMonitor.
When I call the RConnectionMonitor::NotifyEventL passing the observer instance, the application crashes saying that a thread has panicked.
What I'm trying to do here is to listen to the network events asynchronously without blocking the main thread.
EDIT: Should I use an active object to hold the RConnectionMonitor object?
Best regards
The problem was, as #James commented, that I was registering for events before I established the connection to the connection monitor server.
I have a childwindow with an associated VM that gets created each time I ask the child window to open. when the childwindow opens, it registers a listener for an MVVM Light message. After I close the window, I'm pretty sure that I'm releasing all references to it, but I don't actually call dispose because it does not implement IDisposeable.
When I instanciate another child window of the same type, and send it a different context, I know that I'm receiving the message from the previous instanciation of the VM... each time I use the window, more and more VM are listening, and the code repeats.
How can I be sure that my previous VM that registered to listen to a message, has actually been released and is no longer active. Is there a deterministic way to do this?
Whenever you register a message you should make sure that you unregister the message as well. To unregister you can use Cleanup method on classes deriving from ViewModelBase. In other cases, e.g. a view, you should implement a method hat is called when the view is unloaded - e.g by trapping and handling the unloaded event on a control or view. In this method you then call Messenger.Unregister(EventTarget).
This behaviour is a quirk in the current version of the toolkit, and Laurent is aware of it.
How have you coded the handler for the message in the VM? It sounds like you're probably pointing it to a method inside the same VM which is registering for the message. This causes the Messenger class to maintain a reference to the VM and prevent it's garbage collection (see here for discussion). There are two solutions: implement IDisposable and unregister all messages for your VM instance or simply unregister all messages from the VM instance when the child dialog closes. Personally I'd do both to ensure the entire object web is released.
You can use either the Cleanup method or manually unregister the message. For more details click here.
NativeApplication.nativeApplication.exit(); - this method is used for exit the application of flex/air .
application.close(); - this method also used for exit the application of flex/air -
So what is different?
He is referring to NativeApplication.exit() vs WindowedApplication.close().
WindowedApplication.close() Closes the
application's NativeWindow (the
initial native window opened by the
application). This action is
cancelable.
Calling close() on the application window will effectively shut down the application, but using the exit() method on NativeApplication is the proper way to terminate it. See the following link for more info:
http://livedocs.adobe.com/flex/3/html/help.html?content=app_launch_1.html
I am not sure I am understanding your question entirely because I am not finding an application.close() method.
Here is the documentation on NativeApplication, an AIR only class: http://livedocs.adobe.com/flex/3/langref/flash/desktop/NativeApplication.html#exit()
It defines the exit method like this:
Terminates this application.
The call to the exit() method will
return; the shutdown sequence does not
begin until the currently executing
code (such as a current event handler)
has completed. Pending asynchronous
operations are canceled and may or may
not complete.
Note that an exiting event is not
dispatched. If an exiting event is
required by application logic, call
NativeApplication.nativeApplication.dispatchEvent(),
passing in an Event object of type
exiting. Likewise, closing and close
events are not dispatched before
application windows are closed. If
windows should be notified before your
application exits, you can dispatch
closing events for each open window.
If a window close event is required,
call the window's close() method
before exiting.
Here is the documetation on Application, a Flex class: http://livedocs.adobe.com/flex/3/langref/mx/core/Application.html#methodSummary
It does not seem to have a close() method associated with it. Are you possibly confusing the application class with a window class that you need to close before calling the NativeApplication.nativeApplication.exit() ?
I would be happy to help you research this further if you can clarify the question.
One completely exits the application, the other only closes the main window. It's important to understand the difference. On a Mac, for instance, closing all of an application's windows often leaves that application running in the dock. This is rarely the case on Windows, but if you have a dock icon, you should get similar behavior, I think.
I have an AIR app with the following EXIT handler defined:
NativeApplication.nativeApplication.addEventListener(Event.EXITING, applicationExitHandler);
applicationExitHandler makes an asynchronous logout request via an HttpService. Since this is asynchronous, it looks like the Application's exit() method returns before the logout request is actually made.
How can I make sure the request completes before exit() returns?
Override the default behavior. Cancel this event. Call the service then.Add a request handler/ fault handler to your service. On completion either the result or the fault handler is called. This is when you can safely exit the app (of course if signout fails, you may need extra processing). From the docs:
exiting
Dispatched when the application exit sequence is started.
The exiting event is dispatched when application exit is initiated by the operating system; for example, when a user issues the Cmd-Q key sequence on Mac OS X, or when the autoExit property of the NativeApplication object is true and the last application window is closed. Canceling this event prevents the application from exiting.
Note: Calling the NativeApplication exit() method does not cause an exiting event to be dispatched. To warn components of an impending exit, dispatch the exiting event before calling exit()
The Event.EXITING constant defines the value of the type property of an exiting event object.