THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/07/2008 at 08:51, xxxxxxxx wrote:
Cinema 4D Version: 10
Language(s) : C++ ;
I found out that cinema crashes at this line:
where grad is a Gradient*, but it does so only in debug mode (the extra c4d_debug.txt). Does anyone know anything about this, or experiencing similar problems?
On 16/07/2008 at 10:28, xxxxxxxx wrote:
I cannot confirm. Works fine here. Where are you calling InitRender()? Did you make sure that you correctly allocated the gradient instance? It´s most probably user error, as it´s working fine here in objects, tags, shader, volume shaders and posteffects. ;)
On 16/07/2008 at 10:35, xxxxxxxx wrote:
I've no idea why it wouldn't be working in debug mode if it works fine otherwise. Here's the code
> BaseContainer *data = op->GetDataInstance();
> Gradient* grad = (Gradient* )data->GetCustomDataType(ECHO_GENERAL_COLOR, CUSTOMDATATYPE_GRADIENT);
> if (grad) grad->InitRender();
this is called in Draw(BaseObject* op, LONG drawpass, BaseDraw* bd, BaseDrawHelp* bh)
oh, and it works just fine if i open it from a file for example (so it obviously works in some cases), but it crashes when smth is changed in the gradient in the am.
On 18/07/2008 at 01:34, xxxxxxxx wrote:
Hmm, should be just fine.
How are you initialising the gradient in your init?
It´s absolutely possible that it crashes in debug mode and not in release mode. That´s simply because the debug mode is much more sensible than release mode. The error doesn´t disappear just because it doesn´t crash in release mode. If it doesn´t crash your application then it may be a problem somewhere else in c4d at a later point. When this bad memory address is accessed from other parts in c4d this can lead to a crash and you will never know it was your crash! (may also be the case here btw. Maybe another memory problem makes it crash in draw.)
On 18/07/2008 at 10:12, xxxxxxxx wrote:
Gradient isn't initialised in init because it's an AM element, so i don't reckon there would be a problem there. As for the debug/release mode i don't think we are talking the same thing. I guess you're thinking of the debug/release mode in visual studio (or any other compiler), but i'm talking about the "debug mode" of cinema where you put an extra c4d_debug.txt in the c4d folder (and it basically tells you where all the memory leaks are).
On 18/07/2008 at 10:37, xxxxxxxx wrote:
Yep, it must be initialised anyway. It´s the same with other datatypes, like the excludelist for example. Why wouldn´t you initialise the gradient anyway? Don´t you have default values in your plugin?
ah, c4d_debug.txt, I see now. In any case, the debug window will not trigger a crash on its own. :-) Maybe it crashes BECAUSE the console tries to access the gradient address at the same time or so. It´s really only catching and doesn´t do any operations on your code (though it´s a funny but also scary thought...hehe).
Try to initialise the gradient, then you know more.
On 19/07/2008 at 09:54, xxxxxxxx wrote:
Thanks katachi, it so happened that i forgot to include grad->FreeRender(). But i have found some new "bugs" with undos, is there any possibility of attaching a debugger to c4d with that debug mode on, when debugging from vs it just opens plain cinema?
On 19/07/2008 at 13:34, xxxxxxxx wrote:
Nevermind, i managed it, wrong directory :)
On 25/07/2008 at 15:35, xxxxxxxx wrote:
Just one more thing about the debug mode, i have a "changed" Bool, which is always set to either FALSE or TRUE (and yes, it is set to FALSE when instantiated), but in the debug mode somehow it gets to be 1835887981 (!?) and since if (changed) is so stupidly implemented that it continues if (changed>=1) (not only ==1 which would be the same as if (changed==TRUE)) the whole thing isn't working. Dunno if i should be concerned about this, has anyone had a similar problem? (it works ok using changed==TRUE instead of changed though, so it's no big deal)