Bugger. As I suspected the original call from the client is blocked so
re-entrant callbacks from the service can't run on that thread.
Form.ShowDialog() seems to be the simplest option, but I'd really like it to
be hidden from the user. I understand that this means I'll have to take
care to ensure it doesn't block the native app indefinitely if something
goes wrong, and I'm confident I can handle this reliably.
Has anyone got any tips for hiding such a form? So far I've just got
this...
form.ShowInTaskbar = false;
form.StartPosition = FormStartPosition.Manual;
form.Left = -form.Width;
form.Top = -form.Height;
Seems to work quite well, but if the user is smart enough they can move it
onto the screen. Handling the Form.Move event and resetting the form's
position there seems to work but you get an annoying flickering ghost form
if you try to move it around.
Another idea is to show a little form (locked?) in front of the native app's
main window with some kind of animation or something...
On Fri, Oct 15, 2010 at 10:15 AM, Matt Siebert <[email protected]> wrote:
> Yes, I need to block the thread. Once control has returned to the native
> app my add-in can no longer talk to its API, until the native app calls it
> again.
>
> The WCF service would actually be started when the native app starts up.
> The native app gives add-ins a chance to startup and shutdown, and calls
> commands exposed by an add-in when the user initiates it. The service and
> client need to interact within the scope of a command being executed.
>
> I'm thinking I might be better off making the add-in the client and host
> the service in the other process. The client will need to implement a
> callback contract and support re-entrant calls, and these would need to be
> handled on the originating thread (not sure if that is possible). I'm about
> to give this a go...
>
>
> On Fri, Oct 15, 2010 at 9:41 AM, Bill McCarthy <[email protected]>wrote:
>
>> Hi Matt,
>>
>> Are you sure you need to block the thread ? As in what happens if in the
>> managed add-in you store the context when the method is first called then
>> spin off a new thread, and finally invoke back on the original context ?
>> If
>> you can't do that, then a modal form sounds like a good idea to me because
>> if you are blocking the native app, then you should provide a cancel
>> button
>> etc.
>>
>>
>> |-----Original Message-----
>> |From: [email protected] [mailto:ozdotnet-
>> |[email protected]] On Behalf Of Matt Siebert
>> |Sent: Friday, 15 October 2010 1:44 AM
>> |To: ozDotNet
>> |Subject: Message Loops
>> |
>> |G'day folks,
>> |
>> |Aside from Application.Run() and Form.ShowDialog(), are there any other
>> ways
>> |to run a message loop in a .NET app? I'm not keen on rolling my own
>> message
>> |loop, I'm just wondering if there are other options already available.
>> |
>> |Why do I want to do this? Well I'm developing an add-in for a native app
>> that
>> |hosts .NET (3.5). The native app calls a method exposed by the add-in
>> which is
>> |then free to do whatever it needs to do before returning control to the
>> native
>> |app. One caveat is that the add-in can only talk to the native app's API
>> on the
>> |thread that invoked it, attempting to do so on another thread is unstable
>> at
>> |best.
>> |
>> |In my add-in I want to host a WCF service for a client running in another
>> |process. The service needs to be able to talk to the API so I'd rather
>> not
>> host it
>> |on another thread. The problem is that I need to prevent my add-in from
>> |returning control to the native app before the client has finished with
>> the
>> |service. I've looked at Application.Run(Form) and
>> |Application.Run(ApplicationContext) but the native app immediately
>> resumes
>> |when these are called, then when the add-in eventually returns the native
>> app
>> |blows up.
>> |
>> |Form.ShowDialog() seems to be the only option that works, but I'm not
>> keen
>> on
>> |showing a form whose sole purpose is to block execution until the client
>> is
>> |finished with the service.
>> |
>> |Thanks,
>> |Matt.
>>
>>
>
