Listening to events when Matlab GUI application is idle

Hi, I would appreciate a piece of advice. I have a GUI application. I am able to listen to events (answers from a geodetic instrument) when there is a process running in my application (e.g. measurement). But how to listen to events when the application is idle (no matlab activity currently active, no function running, no button pressed). Is there a function (to where write definition of listening to events) which is active when aplication window rises (program starts) and active until it is closed? Thanks for help Filip

[per isakson]

Why do you want that? My first answer is no, but then I am not sure what exactly you mean by "idle" and "no function running".

[Filip Dvoracek]

Why do I need that? Because I want to catch events! E.g. when an instrument throws an error or announcement, I want to know about it :-). By "idle" I mean that there is no Matlab function in process. E.g. application has just started and waits for user to press a button.

Answer 1

[per isakson]

An alternative might be to

• create a handle class, which creates the listener in the constructor

In startup.m

• create an instance
• put a copy of the handle somewhere, e.g. setappdata(0,'my_name',h)

[Filip Dvoracek]

I am not a Matlab expert. Which solution would you suggest as the easiest?

[per isakson]

"E.g. application has just started and waits for user to press a button."

Thus, there is an application "running". When was that started? Is that made with GUIDE? If so, add the listener to

    % --- Executes just before xxxx is made visible.
    function xxxx_OpeningFcn(hObject, eventdata, handles, varargin)

However, I'm a bit lost regarding your requirements and conditions. This instrument does it issue one or more types of events? When the user pushes the button what should happen then regarding the events?

[Filip Dvoracek]

Yes, the app is made with GUIDE.

When the user pushes a button, corresponding callback function starts. And in that function I have the listener to events. But when the callback function ends, also listening to events ends. That is the problem. There is only one type of event but the error number in the event differs each time according to current problem.

The opening function is finished in a very short time. After it is done, listening is stoped, isn't it? It is the same such as with any other callback function.

[per isakson]

Doc on addlistener (handle) says:

    When you use addlistener [...]. addlistener ties the listener's lifecycle 
    to the object that is the source of the event.

Thus, the listener will exist as long as your instrument object exists. I would store the handle of the listener in the handles-structure (, which is passed around).

In your button-callback do you use

    lh = event.listener( Hobj,'EventName',@CallbackFunction )

I guess you do to get the behavior you describe. The two ways differ regarding the life-cycle of the listener.

[Filip Dvoracek]

I use registerevent, not addlistener in my code... ErrorEvent is method of a library and ErrorHandler is my .m file (describing what to do when an event comes).

ltsync.registerevent({'ErrorEvent' 'ErrorHandler'})

[per isakson]

I've never used events of a COM-object, however, I find it hard to believe that the life-cycle of the listener is tied to the life-cycle of the callback-function. The doc doesn't say anything about the life-cycle(?) However, there is a function unregisterallevents. Doc says:

    Description, h.unregisterallevents unregisters all events previously 
    registered with COM object h. After calling unregisterall events, the 
    object [what object?] no longer responds to any events until you     
    register them again using the registerevent function.

I read between the lines that the life-cycle of the listener is tied to the life-cycle of the COM-object.

Questions:

• Do you keep ltsync when the callback-function finish?
• Have you verified with eventlisteners that the listener does not exist?
• Is there a "button" on the instruments to fire an events?

[Filip Dvoracek]

• No, I dont keep ltsync alive between functions. I have to define it in every single function in my application (in every function I have to call ltsync=actxserver('LTControl.LTCommandSync2')).
• Yes. In a function, where ltsync.registerevent is not stated, eventlisteners is emtpy.
• No. Istrument is connected via LAN or WiFi and throw an event whenever there is a error. No button may be pushed. But I can simulate some errors during measurement to invoke events.

[per isakson]

• I'm positive that the life-cycle of the listener is tied to the instrument object life-cycle and that the instrument object is deleted when the callback-function is finished.
• ok
• Fine, that makes testing easier.

Make a test where you keep ltsync alive, make checks with ltsync.registerevent, and simulate errors.

Proposal: Create both the instrument object and the listener in

    % --- Executes just before xxxx is made visible.
    function xxxx_OpeningFcn(hObject, eventdata, handles, varargin)

and store ltsync in the handles-structure.

[Filip Dvoracek]

Ok, my idea was the same - try to store ltsync in handles structure. I cant test it because I dont have the instrument right now. I will let you know later this week... Thank you.

[Filip Dvoracek]

I confirm that if a litener is saved into the handles structure, it is active even "between functions" when no process is currently being executed in my application. Thank you for your help. The solution is easy but without you I am not sure I I would try that.

Answer 2

[Walter Roberson]

The closest you could get would be to have your startup.m fire a timer function that periodically checked.

[Walter Roberson]

If the application has started and waiting for the user to press a button, then just have a callback on the event that data is ready. See http://www.mathworks.co.uk/matlabcentral/answers/85010-daq-process-usb-6008 for an example.

[Filip Dvoracek]

The application is not waiting (waitfor command was not used). With waitfor command I know it is possible to listen to events (some function is running). But without it (no function is running)? I do not understand your advice.

[Walter Roberson]

waitfor() is not used for all event types. timers and DAQ go through a different process.

waitfor() is not even used for the main GUI: it is really only used if you are executing something and need something else to complete before you continue. waitfor() is not needed for controls or events that are to be accessible when nothing else is running: the command line process will take notice of those kind of events.