rs.DeleteObject with object in locked layer?


(Vincent Shen) #1

I’ve found that rs.DeleteObject won’t delete object in locked layer. Do I always have to programmatically check whether a layer is locked? It gets quite complex when the layer is nested in another layer, since rs.LayerLocked won’t work either. Any workarounds?

Thanks!


#2

Something like this should work (try it with a layer called “LockedLayer”):

import rhinoscriptsyntax as rs
import scriptcontext as sc

objIDs=rs.ObjectsByLayer("LockedLayer")
if objIDs:
    for obj in objIDs: sc.doc.Objects.Purge(rs.coercerhinoobject(obj))
    sc.doc.Views.Redraw()

–Mitch


(Vincent Shen) #3

Hi @Helvetosaur

According to the SDK, Purge

Removes object from document and deletes the pointer. Typically you will want to call Delete instead in order to keep the object on the undo list.

However, I still want to be able to keep the object on the undo list. Is there a way I can better manage the locked status of a nested layer?

Thank you!


(Vincent Shen) #4

I’ve also noticed that rs.Add series work well on locked layers. I don’t quite get the rationale to not be able to delete objects from locked layers.


#5

For that I think you would need to unlock the layer in the script, delete the object, then lock it again… --Mitch


#6

I guess it just assumes that objects or layers are locked for a reason and that you don’t want to delete them… That being said, @dale @stevebaer it seems to me that this is a good candidate for an additional optional argument to DeleteObjects()…

rs.DeleteObjects(objs, DeleteLocked=False)

Would work like now if no argument or False was specified; if the DeleteLocked flag is set to True, then objects that are locked or on locked layers are allowed to be deleted…

–Mitch


#7

I think that keeping objects from being accidentally deleted is pretty much the main reason for having a layer locking feature. I also think that from a scripting point of view there is practically no difference between your unlock/relock scheme and the DeleteLocked option scheme, with the exception that the unlock/relock scheme is probably less programming accident-prone and easier to notice bugs.


#8

Well, I’m not sure about that… One thing I don’t like is if the user aborts somewhere in mid script, that layers that were locked are left unlocked… Adding an additional argument to DeleteObjects that you have to expressly set in order to delete objects seems to me to be a good way to deal with this.

–Mitch


#9

Hi Mitch,

This has been requested before and already added to RhinoScript WIP (both DeleteObject and DeleteObjects methods now have a blnIgnoreModes switch). Not sure if RhinoscriptSyntax / Python methods were updated yet.

–jarek


(Dale Fugier) #10

I’ve added a wish list item for this:

https://mcneel.myjetbrains.com/youtrack/issue/RH-37351

In the mean time, if you are using the Rhino WIP, you can use these:

import rhinoscriptsyntax as rs
import scriptcontext as sc

def DeleteObjectEx(object_id, ignore_modes=False):
    rc = False
    object_id = rs.coerceguid(object_id)
    if object_id:
        rhobj = rs.coercerhinoobject(object_id)
        if rhobj: rc = sc.doc.Objects.Delete(rhobj, True, ignore_modes)
        if rc: sc.doc.Views.Redraw()
    return rc

def DeleteObjectsEx(object_ids, ignore_modes=False):
    rc = 0
    object_ids = rs.coerceguidlist(object_ids)
    if object_ids:
        for id in object_ids:
            rhobj = rs.coercerhinoobject(id)
            if rhobj and sc.doc.Objects.Delete(rhobj, True, ignore_modes): rc+=1
        if rc: scriptcontext.doc.Views.Redraw()
    return rc

– Dale


(Vincent Shen) #11

Rhino WIP is Rhino 6, right? Can I replace the Rhinocommon.dll file with a higher version to get it work?


(Dale Fugier) #12

Yes.

Sorry, no.