Thanks for the tip of using the hidden window.
The strings are well formed and don't have strange characters.
I can get it to crash by calling LogMessage("crash") many times.
The printf trick sounds like a viable alternative as well. I'll try that
out.
-Nicolas
On Fri, Jul 6, 2012 at 11:58 AM, Luc-Eric Rousseau <luceri...@gmail.com>wrote:
> The clean way to switch thread is to create a hidden window when your
> plug-in is initialized. Plug-ins are loaded and initialized in the
> main UI thread.
>
> Then, you use PostMessage() to your window in your worker thread to
> get it to do something. When you catch the message in your window's
> WindowProc, you'll be in the Main UI thread.
>
> You should not use message filter or hook into other people's message
> queues.
>
> the underlying service for LogMessage is thread safe, I'm disappointed
> if the SDK layer about it isn't. Check if maybe you're giving the
> string some weird character like % or $.
>
> If you compile you app with the same Visual C++ version as XSI, for
> example Visual C++ 2010, then printf() will output to the history log,
> from any thread. This is how mental ray's log output ends up there.
> You'll only see that happening if you compile in Release mode. If you
> compile your plug-in in debug mode or with another version of VC++,
> the stdout handle will not be redirected.
>
>
> On Fri, Jul 6, 2012 at 2:26 PM, Kamen Lilov <kamen.li...@chaosgroup.com>
> wrote:
> >
> > Hello Nicolas --
> >
> > There is no built-in way to pass a request (let alone execute a script
> > command) to the UI thread of SI. The workaround is to design a custom
> > message passing system and use a timed event on the main thread. Yes, it
> is
> > extremely nasty -- I would go so far as to call it a "design disaster" --
> > but it's the only workaround we have found. Either that, or a custom
> Windows
> > message filter relying on the fact that SI is an MFC application. You
> > probably don't want to go there ;)
> >
> > That said, I am very curious about LogMessage. We have never experienced
> a
> > crash while calling this method from foreign threads (specifically, the
> > thread on which YourRenderer_Process runs). We've had all kinds of
> lockups
> > accessing views, basic scene properties, SI preferences, etc. when
> > attempting access from the non-UI thread, but there were never any issues
> > with LogMessage
> >
> > Hope this helps.
> >
> > K.
>
