Dispatching for events?
-
Hi everyone, currently I am writing a wrapper for some native library which offers a hand full of callbacks. I wrote some .net events which are called when these callbacks are triggered. So far no problems, but I cannot work with the result strings etc. from the application that uses my assembly, because the events are still called from a thread different from the UI thread. :( Is there any chance to call the events through some dispatcher within my mixed assembly? I would like to avoid that the user has to write some code on his own to dispatch the events. Since that is the expected event behavior, is it possible that I am doing something wrong at all? Sincerly, Roland
-
Hi everyone, currently I am writing a wrapper for some native library which offers a hand full of callbacks. I wrote some .net events which are called when these callbacks are triggered. So far no problems, but I cannot work with the result strings etc. from the application that uses my assembly, because the events are still called from a thread different from the UI thread. :( Is there any chance to call the events through some dispatcher within my mixed assembly? I would like to avoid that the user has to write some code on his own to dispatch the events. Since that is the expected event behavior, is it possible that I am doing something wrong at all? Sincerly, Roland
Don Rolando wrote:
from the application that uses my assembly, because the events are still called from a thread different from the UI thread.
Not sure I understand you correctly but it sounds like you are saying that your application code is registering an event handler for an event published in a class in the library. The library fires the event from a worker thread and therefore the application codes event handler is executing on the worker thread. If that is correct I would point out first that from a library design stand point, that doesn't seem like a good idea. The library should managed the thread communications such that the event fires on the main thread. However a simple solution is to have your application event handler call BeginInvoke to update the UI components. You can find much information[^] about this topic
led mike
-
Don Rolando wrote:
from the application that uses my assembly, because the events are still called from a thread different from the UI thread.
Not sure I understand you correctly but it sounds like you are saying that your application code is registering an event handler for an event published in a class in the library. The library fires the event from a worker thread and therefore the application codes event handler is executing on the worker thread. If that is correct I would point out first that from a library design stand point, that doesn't seem like a good idea. The library should managed the thread communications such that the event fires on the main thread. However a simple solution is to have your application event handler call BeginInvoke to update the UI components. You can find much information[^] about this topic
led mike
You understood it correctly; but the bad news is that I cannot modify the design of the library which is embedded in my assembly. I have these callbacks fired from the lib-file's worker thread. I have thought about BeginInvoke myself, but in this case I cannot hide the dispatching process from the user (or can I?), because it must be implemented in the app's event handler - so the user has to write that code himself. I would need that dispatching process in between the callback from the worker thread in the lib file and the event handler.
-
You understood it correctly; but the bad news is that I cannot modify the design of the library which is embedded in my assembly. I have these callbacks fired from the lib-file's worker thread. I have thought about BeginInvoke myself, but in this case I cannot hide the dispatching process from the user (or can I?), because it must be implemented in the app's event handler - so the user has to write that code himself. I would need that dispatching process in between the callback from the worker thread in the lib file and the event handler.
Have a deeper insight on BeginInvoke I realized that I could also do this on the event's delegate. So more or less I could start the invocation within my assembly; anyhow, I can't get it work in C++/CLI, because either the event is not recognized as a data member (seems to be a C++/CLI specific behavior, as I read so far) or the AsyncCallback structure will not work, grrr. Does anyone have a short code snippet how to invoke some event in C++/CLI correctly?
-
Have a deeper insight on BeginInvoke I realized that I could also do this on the event's delegate. So more or less I could start the invocation within my assembly; anyhow, I can't get it work in C++/CLI, because either the event is not recognized as a data member (seems to be a C++/CLI specific behavior, as I read so far) or the AsyncCallback structure will not work, grrr. Does anyone have a short code snippet how to invoke some event in C++/CLI correctly?
Don Rolando wrote:
Does anyone have a short code snippet how to invoke some event in C++/CLI correctly?
I never looked at the them but I bet you will find an example in the introductory CLI articles here on CodeProject. Look under the "Chapters" menu.
led mike
-
You understood it correctly; but the bad news is that I cannot modify the design of the library which is embedded in my assembly. I have these callbacks fired from the lib-file's worker thread. I have thought about BeginInvoke myself, but in this case I cannot hide the dispatching process from the user (or can I?), because it must be implemented in the app's event handler - so the user has to write that code himself. I would need that dispatching process in between the callback from the worker thread in the lib file and the event handler.
Don Rolando wrote:
I cannot modify the design of the library which is embedded in my assembly. I have these callbacks fired from the lib-file's worker thread.
Don Rolando wrote:
I cannot hide the dispatching process from the user (or can I?), because it must be implemented in the app's event handler - so the user has to write that code himself.
That information is very confusing. If it is your assembly, why can't you modify it?
led mike
-
Don Rolando wrote:
I cannot modify the design of the library which is embedded in my assembly. I have these callbacks fired from the lib-file's worker thread.
Don Rolando wrote:
I cannot hide the dispatching process from the user (or can I?), because it must be implemented in the app's event handler - so the user has to write that code himself.
That information is very confusing. If it is your assembly, why can't you modify it?
led mike
The assembly is from me, right... but not the linked lib-file which generates it's own worker threads and calls the callbacks. That's kind of a black box which's architectural design I cannot modify in any way. But I can try to start the dispatching when firing the event out of these callbacks. That's still within the assembly (but would however not beautify the general architecture), Silly thing is that I could not find examples for BeginInvoke on delegates for C++/CLI so far... only on controls or in C#; and I read that C++/CLI is different in that case and cannot be handled the same way... but I will get it work soon, I am sure. :)