Agreed. The thing is, in this scenario, the client in the other process will provide a very rich GUI. By passing the window handle from my form in the native app's process to my GUI in it's own process, I can set my GUI's parent window appropriately so that clicking the native app's main window activates my GUI just like any other modal dialog within the native app's process.
The result is that my GUI which is running in its own process appears as a modal dialog created by the native app, which is exactly what I want. On Fri, Oct 15, 2010 at 1:46 PM, noonie <[email protected]> wrote: > Matt, > > Go with the second option if you need to block the GUI. > > Hiding this sort of stuff from users in almost never a good idea. Most > users will accept an informed wait time over an apparently hung app. > > -- > noonie > > > On 15 October 2010 13:34, Matt Siebert <[email protected]> wrote: > >> 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... >> >>
