No directly, but I'm pretty certain I could get it.

On Fri, Oct 15, 2010 at 7:46 AM, Mitch Denny <[email protected]>wrote:

> Does the app give you some kind of handle to the Window when it spins up
> your add-in?
>
>
>
> Regards
>
> *Mitch Denny
> *Readify | Chief Technology Officer
>
> Suite 408 Life.Lab Building | 198 Harbour Esplanade | Docklands | VIC 3008
> | Australia
>
> M: +61 414 610 141 | E: [email protected] | W: www.readify.net
>
> [image: Description: cid:[email protected]]
>
> The content of this e-mail, including any attachments is a confidential
> communication between Readify Pty Ltd and the intended addressee and is for
> the sole use of that intended addressee. If you are not the intended
> addressee, any use, interference with, disclosure or copying of this
> material is unauthorized and prohibited. If you have received this e-mail in
> error please contact the sender immediately and then delete the message and
> any attachment(s).
>
>
>
>
>
> *From:* [email protected] [mailto:
> [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.
>

<<image001.png>>

Reply via email to