What is a handle ?

[Pat Stanford]

And don't forget ForEachMaterial that functions similarly, but only handles Material definitions. And will handle resources that are not applied to objects in the drawing unlike the others that pretty much only handle objects that are actually in the drawing.

[Juliensv]

@ge25yak

To add on, ForEachObject passes the handle of each object that matches the criteria, one at a time to a callback function, which means you have to set up a global list to extract just the handles.

 

Example:

handles = []

def callback(h):
  global handles
  handles.append(h)

vs.ForEachObject(criteria, callback)

 

[ge25yak]

Thanks a lot guys! Another question about the handle: is there a way to convert string to handle? I somehow need to temporarily store the handles in json and reload them. However I found that if I pass the handle as string to function like

handle='A77637D8'
vs.DelObject(handle)

it won't work.

Edited November 13, 2023 by ge25yak

[Pat Stanford]

Word of advice.  Don't try and store and reuse handles outside of VW.

 

If you really are not doing anything else in VW between uses you MIGHT be ok. But if you do any other operations inside VW after saving the handle it is very likely that whatever handle you have stored will no longer be correct. And if you close and reopen the file between uses you are almost guaranteed to have a handle stored that points to nothing.

 

The correct data structure to use for storing a way to retrieve an object is to use a UUID.  Take a look at the GetObjectUUID and GetObjectByUUID functions.

 

If you truly want to store handles, can you store them a LongInts instead of Strings? That is what the handle actually is, a Long Integer.

 

 

[FranAJA]

1 hour ago, ge25yak said:

Thank a lot guys! Another questions about the handle: is there a way to convert string to handle? I somehow need to temporarily store the handles in json and reload them. However I found that if I pass the handle as string to function like

handle='A77637D8'
vs.DelObject(handle)

it won't work.

 

As said before storing handles in variables as string permanentely is not really a good move as they change every single execution of the script. 
That handle that you have should be a direct return of a method which returns a handle.

like hobj = vs.LNewObj (method that return the handle of last new object

def vs.LNewObj(): return HANDLE

you can use this handle in the method which asks for, example : vs.DelObject(hobj)

another example below:

 

    p1 = (0, 0)
    p2 = (25, 25)
    vs.Rect(p1, p2) # method that does not return handle
    hrect = vs.LNewObj() # get the handle of the last new object created
    vs.DelObject(hrect) 

 

Edited November 13, 2023 by FranAJA

[JBenghiat]

Just to clarify @FranAJA‘s remarks, storing a handle into a variable is fine, but you should not store a handle into a parameter or any other kind of persistent storage. These were the warnings about handles at the top of the thread.

 

A handle is nothing more than the location of a drawing object in memory. You can only reliably depend on that block of memory referring to the object you want for the duration of the script, and as long as the script doesn’t delete or otherwise invalidate the object. 
 

If you need to store a list of objects for later use, use their UUID or assign name, which can then be used to retrieve the handle. 

[FranAJA]

38 minutes ago, JBenghiat said:

Just to clarify @FranAJA‘s remarks, storing a handle into a variable is fine, but you should not store a handle into a parameter or any other kind of persistent storage. These were the warnings about handles at the top of the thread.

 

A handle is nothing more than the location of a drawing object in memory. You can only reliably depend on that block of memory referring to the object you want for the duration of the script, and as long as the script doesn’t delete or otherwise invalidate the object. 
 

If you need to store a list of objects for later use, use their UUID or assign name, which can then be used to retrieve the handle. 

 

I spent two months to understand this concept 😄

[ge25yak]

Hi all, I took the advice to use uuid to track elements. In most cases it works fine, but I observed something strange when using vs.CreateSlab().

Here is my code:

vertices = [(1130,1570),(550,1570),(550,1280),(990,1280),(990,1130),(840,1130),(840,550),(1130,550)]
vs.ClosePoly()
vs.Poly(*vertices) # create polygone from vertices
poly_h = vs.LNewObj()
poly_uuid = vs.GetObjectUuid(poly_h)

for i in range(5):
	poly_h = vs.GetObjectByUuid(poly_uuid)
	vs.AlrtDialog(f"handle iter:{i} " + str(poly_h)) # poly_h is always 0 after 1st iteration, with the same uuid it cant find the corresponding handle

	hslab = vs.CreateSlab(poly_h)

	poly_uuid = vs.GetObjectUuid(poly_h)
	vs.AlrtDialog(f"uuid iter:{i} " + str(poly_uuid)) # the poly_uuid matches the initial one in the first iteration

It looks like after passing the polygon's handle to the CreateSlab function, the handle re-found using its corresponding uuid will always be 0 (None).

Not sure if this is a bug. Any ideas about how to track the polygon using uuid after the create slab operation?

[Pat Stanford]

I think the poly is "consumed" during the creation of the slab.

 

If you need to use the poly after the slab creation I think you need to duplicate the poly first.  I am not certain if the "copy" or the "original" will be the one retaining the UUID. I think when you make a copy in VW, the copy is the one that ends up selected and the original is unselected.  Or maybe it is the other way around.