grip points

[gswifort]

Can I use grip points in PyRx? For example, to simulate the stretching operation of a dynamic block.

[CEXT-Dan]

I didn’t wrap a lot of the grip stuff Entity::moveGripPointsAt or AcDbGripOverrule. Many objects use the newer C++ signature with gripAppData, which is not trivial to use. I probably should at least create some basic wrapper for OverrulableEntity

[CEXT-Dan]

I added a basic version Db.GripOverrule, you can get the grip points, moveGripPointsAt sends indexes and the drag vector. Hopefully this is enough for what you need, it may be possible to draw custom glyphs in draw overrule.

I did not wrap AcDbGripData, which dynamic blocks use. It’s pretty advanced, I’ve only used it a couple of times over the years. I had thought it was beyond the scope of a scripting language, but if you’re finding yourself needing it, I’ll consider wrapping it at a later date

[gswifort]

Thanks for your work!

I did not wrap AcDbGripData, which dynamic blocks use. It’s pretty advanced, I’ve only used it a couple of times over the years. I had thought it was beyond the scope of a scripting language, but if you’re finding yourself needing it, I’ll consider wrapping it at a later date

I think I can handle this via dynamic properties, after adjusting the block definition.

[gswifort]

I have one problem I can't solve with dynamic parameters. I have a block with a base point parameter associated with a move operation. If I move point P1 using the grip points, everything works fine. However, if I set the P1 parameter using the properties palette and copy/paste, the block breaks.

2026-07-09_07h47_26.mp4

Drawing1.zip

[gswifort]

    print(name, len(dyn.getAnonymousBlockIds()))
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
PyDb.ErrorStatusException: Exception!(eNotImplementedYet), function getAnonymousBlockIds, Line 3237, File PyDbSymbolTableRecord.cpp:

:)

zwcad, of course

[CEXT-Dan]

'Are we talking about the same thing?'
yes

[gswifort]

and you get a different result?

[CEXT-Dan]

Actually, all editing methods add one anonymous blocks, if I use effectiveName

    db = Db.curDb()
    found = []
    for name , id in db.blockTable():
        btr = Db.BlockTableRecord(id)
        if btr.effectiveName() == 'TEST':
            found.append(id)
            print(btr.name())
    print(len(found))

Command: DOIT1
TEST
*U12
*U13
*U14
*U18
5
Command: DOIT2
Pick it:
Command: DOIT1
TEST
*U12
*U13
*U14
*U18
*U19
6`

        db = Db.curDb()
        ps, id, _ = Ed.Editor.entSel("\nPick it: ", Db.BlockReference.desc())
        ref = Db.BlockReference(id)
        if ref.isDynamicBlock():
            for prop in ref.getBlockProperties():
                name = prop.propertyName()
                var = Db.EvalVariant(3.0)
                if name == 'P1 X':
                    prop.setValue(var)
                if name == 'P1 Y':
                    prop.setValue(var)

[CEXT-Dan]

Maybe try to match the anonymous blocks with the references, I.e. also after the grip action/properties.

[CEXT-Dan]

It’s the same behavior in ActiveX, so lisp users probably face the same issue. My guess is that since the grip move is using a JIG (you can see the clone while dragging), Autodesk is doing some magic behind the scenes. It would be interesting to test on other actions, like visibility. I.e. in \tests\media\DynBlock.dwg.

Another weird thing about your block is that the palette values never change, they persist at -2.5 relative to the modified block origin

[gswifort]

Another weird thing about your block is that the palette values never change, they persist at -2.5 relative to the modified block origin

This is intentional. The action of parameter P1 moves the base point, and the coordinates of parameter P1 (like all other parameters) are relative to the base point. Therefore, their relative location remains unchanged.