Oddity with AddUndo()
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/10/2009 at 17:57, xxxxxxxx wrote:
That is definitely a possibility. Both Dan and I have been through this nesting issue in the past.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/10/2009 at 19:05, xxxxxxxx wrote:
A long shot maybe (I'm in COFFEE only).
Could it be related to the issue in COFFEE scripting that a
CommandCall() does not get included in an Undo
but a SendModellingCommand() does?Cheers
Lennart -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 02:19, xxxxxxxx wrote:
Quote: _It could be that somewhere you have a StartUndo()/EndUndo() nested within another StartUndo()/EndUndo().
>
> * * *
_
Thanks Dan, that's a great idea. I've now checked it and there's only one StartUndo()/EndUndo() pair in the code. I also looked to see if a recursive routine, of which I have several here, might have called them more than once, but no go. It's really odd.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 02:23, xxxxxxxx wrote:
Quote: A long shot maybe (I'm in COFFEE only).
>
> * * *
>
> Could it be related to the issue in COFFEE scripting that a
> CommandCall() does not get included in an Undo
> but a SendModellingCommand() does?
>
> * * *Thanks Lennart. I wasn't aware of that issue, so that's useful to know.
I guess it could be related, but I'm not sure what the relationship between CommandCall(), SendModellingCommand(), and sending a description command message to an object is. Do they all end up doing essentially the same thing?
It would be nice to be able to try another method of accessing this command. Anyone know if that's possible?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 04:36, xxxxxxxx wrote:
I can't confirm this. Something like this works perfectly fine:
>
\> DescriptionCommand dc; \> dc.id = DescID(DescLevel(BONEOBJECT_FIXCHILDS, DTYPE_BUTTON, op->GetType())); \> \> doc->StartUndo(); \> doc->AddUndo(UNDO_CHANGE, op); \> \> op->Message(MSG_DESCRIPTION_COMMAND, (void\* )&dc;); \> \> doc->EndUndo(); \> \> op->Message(MSG_UPDATE); \> \> EventAdd(); \>Maybe it's really an issue of nested undos.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 05:09, xxxxxxxx wrote:
Howdy,
The problem I had with nested StartUndo()/EndUndo() was because I was sending my tag a message from a command to click a button in the AM, but there was a StartUndo()/EndUndo() in the tag's message routine that handled the button click.
It could be that there is a StartUndo()/EndUndo() in the bone's routine to handle that button click.
Adios,
Cactus Dan -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 05:20, xxxxxxxx wrote:
Thanks Matthias. Good to know that AddUndo() does work the way I'm using it. There's clearly a bug in my code somewhere - I'll keep searching!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 06:28, xxxxxxxx wrote:
Thanks Dan. You're probably right, because everything my code does up until the simulated AM button click is reversed in one undo, everything after it (including the 'click' itself) is reversed by the second undo.
The thing is, the button click has to come in the middle of code which is enclosed by a StartUndo()/EndUndo() pair. So I'm not sure there's a way round this unless there's a method to fix bones without simulating the button click.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 07:46, xxxxxxxx wrote:
I was going to say before that calling a command like this (simulating a button press) will probably create an automatic undo. The same thing happens when I convert my plugin bone hierarchy into a C4D bone hierarchy - requires two undos to go back. There is nothing that I know of to avoid this.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/10/2009 at 09:31, xxxxxxxx wrote:
Fair enough. If there's nothing I can do about it, I can live with it! It's when you think that there must be some solution that it drives you mad...