Hi Andreas
One thing to experiment with the -browserWindow: command line argument. Originally, it was designed to "get Squeak into a browser" but of course, as long as your .NET form has a HWND handle you can get Squeak inside it by passing the handle along with -browserWindow:.
Well, b*gger me. If I'd known this (uhh, perhaps if I'd asked this) a year ago...
Anyway - thank you. It seems to work: Squeak will happily run inside a .NET form.
Next challenge: I want to tell that .NET form (call it the substrate) to be the owner of other forms created within the application - because that way they'll be guaranteed (in theory) to stay in front of the Squeak window. But to be able to talk to the substrate at all, the Squeak VM must be in the same process as it. How do you launch Squeak in the same process as the form?
Well... remarkably enough, the following seems to work:
1. start Squeak
2. in Squeak, crank up the .NET bridge
3. use the bridge to create a free-standing, Squeak-desktop-sized .NET form
4. tell the VM to use that form as its browserWindow
...but I'm not yet confident that this approach would fly for the case of a plugin within a real browser. I'll have a go.
And meanwhile I have another question:
Is there a standard way of sending messages between the VM and Squeak code? For the time being I've hacked together a simple shared-data link using the GWL_USERDATA value of the Squeak window, as well as a one-way signal from VM to Squeak using some custom UI-event types. My next thought for talking to the VM was to try posting custom messages to the Squeak window's queue. Any other mechanisms?
Thanks again
Aran -- Aran Lunzer Hokkaido University