THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/02/2004 at 06:29, xxxxxxxx wrote:
Cinema 4D Version: 8.500
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;
It looked so easy....
User starts plugin (compiled using 8.5 sdk)
plugin copies the document and alters something
plugin calls somehow RenderDocument(.....) to get a bitmap.
O.k. that really does work. But now an additional preferable feature ..
I would like to open a dialog with a simple button
showing something like "Press Button to Stop Rendering".
The problem is, that the dialog does not react while rendering
and in MyThread::TestDBreak() a call to GetInputEvent(...)
gets always FALSE, so now way to find a workaround.
I've tried everything I could imagine. The only solution I found is
to use another buttontext, for instance "Pull Plug to Stop Rendering".
What is my mistake?
thank you for any help ;o)
On 01/02/2004 at 14:24, xxxxxxxx wrote:
when overloading TestDBreak() you will need to check for a userbreak by calling TestBreak in your Render Thread.
On 02/02/2004 at 04:09, xxxxxxxx wrote:
Hi samir ;o)
> when overloading TestDBreak() you will need to check for a userbreak by
> calling TestBreak in your Render Thread.
1. No. You can't do that. In fact it seems to be that TestBreak calls TestDBreak
I've watched some really nice crashes caused by stackoverflow.
2. Cinema must call the TestBreak - routine while rendering and Cinema does!
The point is: Under that circumstances (meaning:Cinema executes
RenderDocument(...)) the GetInputEvent(...) function is always FALSE;
Anyway, it would be a workaround. It would be nicer to have that button.
Any idea ????
thx for answering
On 02/02/2004 at 09:22, xxxxxxxx wrote:
1. Sorry, but I can. I do it in my plugins exactly like this and I never encountered any problems nor a stack overflow, nor any crashes or whatever. It works perfectly. And yes, TestDBreak is called by TestBreak(), that´s why you need to use it!
2. Cinema must do sh** ;o)
On 02/02/2004 at 09:23, xxxxxxxx wrote:
sh** means shine btw.
On 03/02/2004 at 02:02, xxxxxxxx wrote:
The problem is that TestDBreak() will be called from a non-GUI thread which means that it cannot safely access the GUI functions, like GetInputEvent(). Instead you have to let the dialog set a flag when the button is clicked, which the TestDBreak() function can check.
On 03/02/2004 at 07:54, xxxxxxxx wrote:
First - Thank you for answering ;o)
> Instead you have to let the dialog set a flag when the button is clicked,
> which the TestDBreak() function can check.
Fine. But I never watched a dialog function beeing executed
while RenderDocument(...) was running.
I must have misunderstood something important concerning the
Now I do it in the following way (coarse description, one of three or four
call RenderDocument(... ,this,...)
still getting crazy
On 09/02/2004 at 17:08, xxxxxxxx wrote:
If you have an asynchronous dialog then it shouldn't be locked up while the thread is executed. However, if MyThread.Wait() is called in the main thread then I think it will lock the GUI. Have you tried removing it?
On 06/09/2005 at 08:36, xxxxxxxx wrote:
May it not be a good idea to set a timer before calling to check every ??? ms if the caller is sending a message?
(It may be foolish! Just consider I'm not a programmer!)