Jump to content

Vectorworks crashes on creation and reset of child object.


Nebeor

Recommended Posts

I have linked multiple Plugin Objects with child<->parent relationships: parents are managing the shape of kids and are triggering kids resets if they got changed:

Parents can create new instances of kid objects with gSDK->CreateCustomObjectPath(...).

After creation the children gets their first reset triggered, this is where i experience problems.

 

The problem that i experience is that this process is not stable: sometimes the program crashes, sometimes the program doesn't, this seems impossible to predict, this could happen each time I add a few kids to my parent.

 

The error I recieved:

First-chance exception at 0x00007FF6A3B00708 in Vectorworks2015.exe: 0xC0000005: Access violation writing location 0x000000006C5F2840.
Unhandled exception at 0x00007FF6A3B00708 in Vectorworks2015.exe: 0xC000041D: An unhandled exception was encountered during a user callback.

 

If i break with debugger, the debugger points here, I assume there was something wrong with the reset of newly created objects?

image.thumb.png.70e2d50f4ea268896907ce14468ca2e7.png

How can i avoid this problem? What checks do i need?

Thanks beforehand for your useful feedback.

 

I'm working with VW 2015, windows 10 and visual studio 2012.  

Edited by Nebeor
Link to comment

The most common cause for crashes is a null handle or pointer. I’m not as familiar with the VS debugger, but I imagine there is a way to step through nested processes. The problem is likely in the child object’s redraw event, for example if you’re not setting the path correctly so the handle to the path, on reset, is empty. 

Link to comment

Yes, I assume you are not veryfing the path handle. When your parent creates the child, it could be that the first reset is called before your path is assigned. If you just assume its a correct handle and cast it to a nurbs or poly you'll run into this.

 

Since you talk about parent and child, can I assume you've set your plug-in not to remove it's content on reset? If not you do not need to get the handle by using a unique name.

Edited by Hippocode
Link to comment

CreateCustomObjectPath(const TXString& name, MCObjectHandle pathHand = NULL, MCObjectHandle profileGroupHand = NULL)

so, would you all agree that this function needs at least two arguments because the pathHand should not be null?

 

also, i tried to add a closed VWPolygon2DObj as pathHand but it doesn't resolve my bug.

 

Edited by Nebeor
Link to comment
48 minutes ago, Hippocode said:

Since you talk about parent and child, can I assume you've set your plug-in not to remove it's content on reset? If not you do not need to get the handle by using a unique name.

What do you mean with 'removing content on reset'?

 

 

What i find most interesting is that the SDK doesn't wait to terminate the C++ code before running the first reset of the VectorScript Plugin. In Vectorscrip this is not the case.

 

Link to comment
32 minutes ago, Nebeor said:

CreateCustomObjectPath(const TXString& name, MCObjectHandle pathHand = NULL, MCObjectHandle profileGroupHand = NULL)

so, would you all agree that this function needs at least two arguments because the pathHand should not be null?

 

also, i tried to add a closed VWPolygon2DObj as pathHand but it doesn't resolve my bug.

 

 

It only requires one argument, unless you want to specify a path/profile.

Your object will be created and reset. Only after this creation the path will be attached and reset again.

 

In any case, your object's code should be able to handle a NULL path.

Can you post a bit more of the last steps before the crash occurs ? Could also be a recursive reset.

 

Edited by Hippocode
Link to comment
1 minute ago, Nebeor said:

What do you mean with 'removing content on reset'?

 

 

What i find most interesting is that the SDK doesn't wait to terminate the C++ code before running the first reset of the VectorScript Plugin. In Vectorscrip this is not the case.

 

 

if object A is the parent and it creates object B inside of it (parent - child) there is no need of catching it with a unique name, as you have a handle when creating it.

That is, unless you have your object A set not to automatically remove all it's contents on reset, on which case your interface manages it. This is used if you don't wat to recreate all the inner objects each time the object is reset.

Link to comment
20 minutes ago, Hippocode said:

 

if object A is the parent and it creates object B inside of it (parent - child) there is no need of catching it with a unique name, as you have a handle when creating it.

That is, unless you have your object A set not to automatically remove all it's contents on reset, on which case your interface manages it. This is used if you don't wat to recreate all the inner objects each time the object is reset.

In my Case, the child is not IN the parent, but inserted next to the parent, so they are on the same level, this is why i am supposed to use UUID names instead of a kidsGroup, this way i can make one to many relationschips between objects.

The crash occurs when iterating the list of kids, kidStr is the name of a kid. this is indeed something thats happens recursive.

Edited by Nebeor
Link to comment

The path object won’t inherently fail with a null path, but if the object drawing code doesn’t check for a null path before performing some operation on it, you will have issues. 

 

You could also be having an issue with your getline() function. If kidStr.c_str isn’t an acceptable value, that could be an issue. At the very least, try defining a TXtString variable and checking for empty before passing it to GetObject()

Link to comment

I understand the issue better now: the crash must be caused by the child that's written in Vectorscript, because this script got executed immediatly.

I wonder if i could set the parameters of a new pathObject before triggering the first reset.

Link to comment

i'm using  a VWPolygon2DObj poly as pathhand: it's shaped to a closed rectangle, I suppose there is nothing wrong with that. 

        VWPolygon2DObj poly = VWPolygon2D();
        poly.AddVertex( 0, 0, false ); 
        poly.AddVertex( 0,depth, false );
        poly.AddVertex( length, depth, false );
        poly.AddVertex( length, 0, false );
        poly.SetClosed( true );

I'm thinking it should be VWPolygon2DObj all the way.

Edited by Nebeor
Link to comment
23 hours ago, Nebeor said:

i'm using  a VWPolygon2DObj poly as pathhand: it's shaped to a closed rectangle, I suppose there is nothing wrong with that. 


        VWPolygon2DObj poly = VWPolygon2D();
        poly.AddVertex( 0, 0, false ); 
        poly.AddVertex( 0,depth, false );
        poly.AddVertex( length, depth, false );
        poly.AddVertex( length, 0, false );
        poly.SetClosed( true );

I'm thinking it should be VWPolygon2DObj all the way.

 

If you debug you should be able to see on which line the error occurs?

Also, you don't need to define "poly" on declaration.

Link to comment
On 3/12/2018 at 6:10 AM, Nebeor said:

 


        VWPolygon2DObj poly = VWPolygon2D();
        poly.AddVertex( 0, 0, false ); 
        poly.AddVertex( 0,depth, false );
        poly.AddVertex( length, depth, false );
        poly.AddVertex( length, 0, false );
        poly.SetClosed( true );

 

 

If length or depth is zero, that could result in an improper path.

 

Have you looked at your getline() function?  My guess is that your problem lies there.

Link to comment

I have rewritten all my VectorScript Plug-ins to SDK Plug-ins: It doesn't crash anymore.

The treatment of 'ResetObject' in Vectorscript or in the SDK seems to follow a different logic, maybe this has something to do with it.

Maybe with implementing all the still lacking features, I will find out what might be wrong.

Edited by Nebeor
Link to comment
On 13-3-2018 at 2:30 PM, JBenghiat said:

 

If length or depth is zero, that could result in an improper path.

 

Have you looked at your getline() function?  My guess is that your problem lies there.

std::getLine has nothing to do with my problem but i do should replace it with something native to TXString.

casting TXString to std::strings is a quite awful idea.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...