Event from external library Topic is solved

This forum can be used to talk about general design strategies, new ideas and questions in general related to wxWidgets. If you feel your questions doesn't fit anywhere, put it here.
Post Reply
Elmi
Super wx Problem Solver
Super wx Problem Solver
Posts: 293
Joined: Thu Mar 12, 2009 3:23 pm
Location: Germany
Contact:

Event from external library

Post by Elmi »

Hi,

I have a general design problem and no _really good_ solution at the moment:

I have an application that uses plugins to communicate with external hardware. These plugins are nothing more than standard libraries (.dll/.so). These libraries access the hardware they are responsible for.

Now it can happen that the hardware sends new data. The time between two data transmissions is undefined so no forecast can be made when the next dataset will arrive.

The only solution I found for that is to poll the plugin regularly using a function that retrieves the data and gets an error "no data available" or the received data.

To avoid many unnecessary polling-cycles an event-driven model would be better. But how can I implement that when an external library is used? Is there a signalling mechanism available for that?

Btw.: an own TCP/IP connection for every plugin is not a solution, the related network load would not be acceptable (because of the huge amount of plugins).

Elmi
upCASE
Moderator
Moderator
Posts: 3176
Joined: Mon Aug 30, 2004 6:55 am
Location: Germany, Cologne

Post by upCASE »

Hi!
Though question.

Doesn't the plugin itself have some way of notification that you could use? Some callback function that would be called when data arrives? Or maybe a system specific event that would be fired?

If the plugins only support active polling by calling a function, I suppose there is no other way than creating a thread for monitoring the data and sending a custom event to the main application once data is present.

Can the plugins create output on the commandline? Maybe that would be an option as well: Capture the stdout output. This can be done in an asynchronous way, but I guess it is platform specific as well (we have something like that here for Windows and Linux).

Maybe your best option is to contact the original author for some insight. I suppose you're not the only one that would have such a question, so perhaps a new version is on the way supporting this.
OS: OpenSuSE, Ubuntu, Win XP Pro
wx: svn
Compiler: gcc 4.5.1, VC 2008, eVC 4

"If it was hard to write it should be hard to read..." - the unknown coder
"Try not! Do. Or do not. There is no try." - Yoda
Elmi
Super wx Problem Solver
Super wx Problem Solver
Posts: 293
Joined: Thu Mar 12, 2009 3:23 pm
Location: Germany
Contact:

Post by Elmi »

OK, to clarify that a bit: the plugins are my own and I have total control over the design. So everything that is possbile (in a portable manner) can be implemented. One requirement is that the design of the plugin itself has to be as easy as possible to give not so advanced programmers the possibility to implement own ones.

So I'm just looking for some good ideas :-)

Elmi
upCASE
Moderator
Moderator
Posts: 3176
Joined: Mon Aug 30, 2004 6:55 am
Location: Germany, Cologne

Post by upCASE »

Hi!
For simple cases I'd try a callback mechanism. Simply give the plugin a function that allows to register a callback function from some other application. Each time the plugin detects data, the callback is called. The application will have to care about proper synchronization though. Another question is if the callback receives the data, or if the callback is just a signal and the application has to poll the data once the callback was called.

If you can use system specific event, this is another good option as well. On Windows you could simply register an event type and post that. The application would need to check for these events. I'm not sure about Linux though.

Just my two cents. Maybe somebody else has a better solution.
OS: OpenSuSE, Ubuntu, Win XP Pro
wx: svn
Compiler: gcc 4.5.1, VC 2008, eVC 4

"If it was hard to write it should be hard to read..." - the unknown coder
"Try not! Do. Or do not. There is no try." - Yoda
Elmi
Super wx Problem Solver
Super wx Problem Solver
Posts: 293
Joined: Thu Mar 12, 2009 3:23 pm
Location: Germany
Contact:

Post by Elmi »

Yes, the callback would be an option but the code behind it is a painful hack: a pointer to a function of the main application that is handed over fromthe main application to the plugin so that it can call this function via its pointer when data are available...huh!

The signalling mechanism will not be an option because there is too much platform-dependent code.

But anyway, thank you for your ideas :-)
mael15
Ultimate wxWidgets Guru
Ultimate wxWidgets Guru
Posts: 539
Joined: Fri May 22, 2009 8:52 am
Location: Bremen, Germany

Post by mael15 »

Hi upCASE,

I have the exact same problem and I only work under Windows. Could you be so kind and elaborate this a bit more?
upCASE wrote:If you can use system specific event, this is another good option as well. On Windows you could simply register an event type and post that. The application would need to check for these events. I'm not sure about Linux though.
thanx!!!!
upCASE
Moderator
Moderator
Posts: 3176
Joined: Mon Aug 30, 2004 6:55 am
Location: Germany, Cologne

Post by upCASE »

Hi!
mael15 wrote:Hi upCASE,
I have the exact same problem and I only work under Windows. Could you be so kind and elaborate this a bit more?
Sure :-)

The general idea is to use the system specific message loop for communication. On Windows you could use RegisterWindowMessage() in both, plugin and Application, using the same identifier. Then the plugin could use the resulting message type with PostMessage() or SendMessage() to indicate an event. The main application would have to monitor the incoming events and check for the registered message type. If the application is a wxWidgets one, you could use overload
WXLRESULT MSWWindowProc ( WXUINT message, WXWPARAM wParam, WXLPARAM lParam ); to capture the messages.
OS: OpenSuSE, Ubuntu, Win XP Pro
wx: svn
Compiler: gcc 4.5.1, VC 2008, eVC 4

"If it was hard to write it should be hard to read..." - the unknown coder
"Try not! Do. Or do not. There is no try." - Yoda
Post Reply