AddUndo change in R10?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 11:51, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R10 
Platform:   Windows  ;   Mac OSX  ; 
Language(s) :     C++  ;

---------
Was the behaivior of Start/Add/EndUndo() changed in R10?  My plugin is now crashing the app with an access violation anytime I call AddUndo() (after previously calling StartUndo(), as required).
As far as I know, my plugin (a CommandData based plugin) is not subject to the 'threading' issues mentioned in the docs... but I've also tried putting a StopAllThreads() in front and that didn't help either.
All of this code worked fine when compiled under the R8.206 SDK, so 'something' has changed (if I bypass all the AddUndo() calls, my plugin still works fine otherwise, but I lose all the Undos).
Here's a snippet:

    
    
    
    
     BaseSelect  *m_pUserSelected = m_pPolyObj->GetPolygonS();
    
    
    
    
     m_pBaseDoc->StartUndo();
    
      // if no polys selected, select them all...  
      if( m_pUserSelected->GetCount() == 0 )  
      {  
       m_pBaseDoc->AddUndo(UNDO_CHANGE_SELECTION, m_pUserSelected);  
       m_pUserSelected->SelectAll(0, m_numFaces-1);  
      }  
     m_pBaseDoc->EndUndo();
    
    
    

...m_pPolyObj is set up to point at the active PolygonObject and of course m_pBaseDoc is previously set up to point at the active BaseDocument, etc.
Any insight would be appreciated.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 13:01, xxxxxxxx wrote:

Update: ... I've gone back to R9.6 and getting the same problem, so the change happened earlier than R10.  I'm going to try R9.1 next...
Update: ...same problem in R9.1.
As mentioned above, I had originally compiled this using the R8.206 SDK, as it was the earliest one I could use that had all the features I needed (I wanted the plugin to be compatible with as low a version as possible).
The plugin compiled with the R8.206 SDK works fine in R9.1, as well as R10 demo, but if I compile it with any later SDK, it crashes as soon as I call AddUndo().

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 14:53, xxxxxxxx wrote:

Maybe in R9+ they no longer allow you to add a BaseSelect and need to add the BaseObject or SelectionTag instead (?). I can't confirm this as I'm not adding undos for polygon/point/edge selections.

Are you positive that it is the AddUndo() (i.e.: have you commented it out and seen if the crash disappears)?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 15:26, xxxxxxxx wrote:

Yeah, it's definately the AddUndo() call itself that's crashing.  But your other tips may lead somewhere - thanks.  I think I have an R8.5 around here I can test too.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 16:59, xxxxxxxx wrote:

Hmm.. I think the problem is that I was never actually using that correctly (of course it's not documented, so I don't take any blame :) ).
Apparently, when you use the UNDO_CHANGE_SELECTION type, the data pointer needs to be a pointer to the PolygonObject, not a pointer to a BaseSelect(ion) you're about to change.
I guess it just worked by accident with the R8.206 SDK compile. ~ shrug ~
Thanks for the help!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 22:50, xxxxxxxx wrote:

Ok, next problem... any idea why the following doesn't work on Mac R10 (Xcode)?

    
    
    
    
     BaseContainer keyinput;  
     Bool input;
    
    
    
    
     input = GetInputEvent(BFM_INPUT_KEYBOARD, keyinput);
    
    
    
    
     // Check for SHIFT key  
     if( input && (keyinput.GetLong(BFM_INPUT_QUALIFIER) & QSHIFT))  
      m_shift = true;
    
    
    

...GetInputEvent() is returning a value, but the test for QSHIFT is failing (works fine on PC R10).

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 23:27, xxxxxxxx wrote:

...I see that there is also a:
Bool GetInputState(LONG askdevice, LONG askchannel, BaseContainer& res)
...which seems more appropriate, but it's unclear to me how to get the state of the SHIFT key, using that.  I'm not sure what value I'd pass in for 'askchannel'.  I guess I could just put any key value there, since the test for SHIFT will actually be on the res.GetLong(BFM_INPUT_QUALIFIER) test. Hmmm.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/07/2007 at 23:36, xxxxxxxx wrote:

Yup - GetInputEvent() works differently on PC and Mac.  It seems that on the PC, GetInputEvent() behaives as if it returns whatever the current state is (instead of just grabbing some next event), but this fails on the Mac... GetInputState() works on the Mac though.