Tech Off Thread

10 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Asynchronous Remoting in a .DLL Thread Issue

Back to Forum: Tech Off
  • User profile image
    osbornm

    Ok, here is the deal…. I am working on a project for one of my college classes and we are incorporating remoting into the project. We plan to use asynchronous remoting in a .dll.  This does not seem like a big deal however, we run into one problem thread control.  Here is an example, we want to use asynchronous calls from a dll to set the value of a textbox on a form.  If your not using a dll this problem is solved by using the Invoke method.  The invoke method tells that delegate to run on the same thread as the control contain that call.  When you but it into a dll there is no parent control to grab a thread reference from.  In .net 2.0 textboxes are programmed to not allow any other thread other than the parent thread to modify them.  There is a property in the textbox called invokerequired but it is read only.  My question is does any one know how to change that property or is there a way to tell a given piece of code to run on a given thread.   Thanks    

  • User profile image
    figuerres

    osbornm wrote:
    

    Ok, here is the deal…. I am working on a project for one of my college classes and we are incorporating remoting into the project. We plan to use asynchronous remoting in a .dll.  This does not seem like a big deal however, we run into one problem thread control.  Here is an example, we want to use asynchronous calls from a dll to set the value of a textbox on a form.  If your not using a dll this problem is solved by using the Invoke method.  The invoke method tells that delegate to run on the same thread as the control contain that call.  When you but it into a dll there is no parent control to grab a thread reference from.  In .net 2.0 textboxes are programmed to not allow any other thread other than the parent thread to modify them.  There is a property in the textbox called invokerequired but it is read only.  My question is does any one know how to change that property or is there a way to tell a given piece of code to run on a given thread.   Thanks    



    control on a form and an async update ?

    sounds like you should be useing the BackgroundWorkerProcess control.  it is built to allow an async process run and interop with a winform.  see if that helps you.

  • User profile image
    osbornm

    The problem we have is that we are doing the async calls in the .DLL file and sending the results back to the winform via an event.  We were unable to get the background worker control to hadle this.  If you have done this or know how we should impliment the background worker that would be amazing if not thanks for the help though!

  • User profile image
    rocjoe

    For your situation, you should be calling your .dll using method within your form, passing it a AsyncCallback delegate that points to another method in your form that reads the IAsyncResult from your dll and in turn sets the text property of the TextBox. Your IAsyncResult would be string that you would unboc, then copy into your text property. That's what AsyncCallbacks are there for.

    If you try to use the dll to set the TextBox control, you should expect to fail that assignment.

    Why? Because you're in a threading environment, there is no guarantee that the TextBox will still be there when your .dll is ready to put the result in its text property. Passing around object references to other threads could delay garbage collection which in turn causes memory leaks. And there's more too, but this isn't about what I know... Use AsyncCallback properly and your problems are solved.


  • User profile image
    osbornm

    In this remoting situation, we are subscribing to an event from the dll in the windows forms environment. Since we are in the method subscribed to the event, we can indeed guarentee that the textbox will exist. This will eliminate excess code in the GUI where it doesn't need to be.

  • User profile image
    rocjoe

    Because you're processing on separate threads it doesn't matter how you're passing it. That's why you're having problems in the first place. In particular, UI objects are not meant to be marshalled across threads.

    Its a simpler and faster option to pass data through an Asynchronous call, and return data in the IAsync result than to pass an object into another thread.

    If I really understand what it is you're trying to do, the solution you describe makes your .dll DEPEND on being used by a form that has a TextBox control on it. Maybe next time you want to use that .dll in a Console App or a Windows Service where you won't have access to any UI elements. Plus, passing an enitre TextBox to your .dll is overkill when all you want is to set the Text property.

    Don't let me discourage you, you're so close to a great solution, you just have to go that extra step and properly de-couple the .dll from the form.

  • User profile image
    eddwo

    If you need to transition back to the UI thread, but you don't have a reference to any controls to do BeginInvoke on, you can post a delegate to the UI thread using AsyncOperationManager.

    Its explained a little bit here.

  • User profile image
    osbornm

    The reason I am having the problem in the first place is because the dll is de-coupled from the form. I was doing it all from the async result in the form initially and having no problems. I wanted to have my remoting abstracted to a dll file (Business Layer). So I put all the remoting calls in the dll. The dll handles everything remoting related and then fires events telling what happened. i.e. Getting the date from the remote server will be done asyncronously, and when the result is sent from the server, an event is fired called GotDate. Then, any application can just make a call to the dll GetTheDate(), and they can subscribe to the GotDate event and do what they want with it when it is done. So the problem is not that I havent separated winforms from the dll, it is that I have seperated them. If I use a console client with my dll, everything works fine, but when I use a windows client, the event happens to come back apparently not on the same thread. When the event subscription method is called, I can MessageBox.Show() the result fine, but I cannot adjust an object on the form because the asyncronous operations within the dll operated on a different thread.

  • User profile image
    rocjoe

    The picture is starting to fill out.

    So your business layer would contain the event class, and your form would attach delegates that point to methods that are within the form itself (since changing properties on UI elements would be presentation logic). That way when the GotDate event fires, it will hit methods that are already within the form, meaning you will have no trouble referencing any objects on the form.

    If your events are already set up like that and you're still having threading problems, try this:

    http://msdn2.microsoft.com/en-us/library/ms171728.aspx

    I've used it before, the key part of the example is the SetText() method, and using the InvokeRequired property to prevent changing any control property until the invoke is done using the correct thread.

    Hope that helps!


  • User profile image
    osbornm

    eddwo: SOLUTION! Thank you much.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.