Topic: Stretch.lsp for dynamic blocks

[dexus]

I've been working on a program that extends the stretch function so it also works on dynamic blocks.
So if a stretch function is done and one of the grips of a dynamic block is inside of the selected area, the transformation is applied to the dynamic block as well.

The program is functional now and works for most of the dynamic blocks I use!
But it doesn't work on chained actions as of yet. This is because step 3 below doesn't calculate chained actions yet and I'm not sure how to figure out how the parameters are chained. Hope some of you can help me make it work on those too!

Here is how the program works step by step and I have added comments in the lsp file:

• Preform the stretch action using the default Autocad command.
• For all blocks, get the default parameters using getBlockParameters.
• Transform those parameters using the settings of the selected block using getAppliedParameters. This returns the WCS points of where the grips of the selected blocks are.
• Check which grips were inside of the selection and change the parameters of the block if needed.

Below a demonstration on a dynamic block and the code itself.

[Rustabout]

Impressive! It's also been download 16 (17 including me) times without anyone saying "good job"! I'll try it out quick.

[Rustabout]

I'm getting a "Error: no function definition: GETVARĀ"... I'm in ACAD 2023.

[dexus]

Impressive! It's also been download 16 (17 including me) times without anyone saying "good job"! I'll try it out quick.

Thanks Rustabout!

I'm getting a "Error: no function definition: GETVARĀ"... I'm in ACAD 2023.

I guess others tried but couldn't get it working.
There was a non-standard ascii character behind the getvar.
Not sure where it came from, but I think I fixed it and updated the download in the first post.
Could you give it another try?

[Rustabout]

It seems to be working! I tested it with a couple different blocks. In the past I was dying for something like this. For what I'm doing today... I won't be able to test it out in a production setting.

It works like it's supposed to, but might surprise some users if they have an action parameter with it's origin set to "midpoint": This function will stretch each side of the block by half the distance; unavoidable (and doesn't really take away from what the code is actually supposed to do), but one reason I would make this it's own routine and have it only affect blocks - but that's just me (and very easy to change). It's pretty awesome code!!

I don't know if you replaced the code but the code still has the weird character. What are you using for an editor? The formatting makes me think it's not VLIDE. The characters, along with some spaces, were causing the trouble. The spaces were causing VLIDE to not recognize some functions (they wouldn't turn blue as they normally would). This only occurred in two locations, one (shown in the attached image) had the weird hyphened 'A' characters next to it, and the other one was a little further down.

[dexus]

Thanks for looking, I will have to look into how the dxf codes indicate that it is a parameter with a midpoint and also figure out what would be the logical result. Thanks for the tip, I have never used midpoint in a parameter before.

I'm using vim for coding, I opened it with vlide and saw the incorrect characters.
Should be fixed in the first post now.

[Rustabout]

Think of that suggestion as just an FYI / Food for thought. With such a powerful code you'll be able to build spin-off projects. As-is the code works really well.

I'm really weak with DXF codes so I'm super impressed that you've been able to utilize them like this.

As far as using VIM: It's pretty easy to find those weird 'A's but the rogue spaces might be a bit more challenging. The only reason I noticed them was because some functions weren't turning blue. If you're aware it's happening and able to catch it then it's probably not a big deal... but trying to find bugs when it's really your compiler that put a weird character somewhere... could make for some long nights...

I haven't used anything extensively other than VLIDE, which sometimes annoys me to the point of hair loss (the window sizing issues really get you when you're debugging something)... so I don't blame people for trying out other stuff. I'll probably switch to VSCODE eventually. I'm using Visual Studio 2022 for .NET right now actually. Hard to go from that to VLIDE lol.

[dexus]

As far as using VIM: It's pretty easy to find those weird 'A's but the rogue spaces might be a bit more challenging. The only reason I noticed them was because some functions weren't turning blue. If you're aware it's happening and able to catch it then it's probably not a big deal... but trying to find bugs when it's really your compiler that put a weird character somewhere... could make for some long nights...

I haven't used anything extensively other than VLIDE, which sometimes annoys me to the point of hair loss (the window sizing issues really get you when you're debugging something)... so I don't blame people for trying out other stuff. I'll probably switch to VSCODE eventually. I'm using Visual Studio 2022 for .NET right now actually. Hard to go from that to VLIDE lol.

This is the first time I ran into these copy paste problems with hidden characters. Checking for the highlighting is a good tip, it doesn't look right so its easy to see when there is something wrong.
I'm so used to VIM now that its hard to switch to any editor that doesn't edit as well as VIM does. Even though I do miss all the debugging features of the other programs.

[dexus]

Think of that suggestion as just an FYI / Food for thought. With such a powerful code you'll be able to build spin-off projects. As-is the code works really well.

I'm really weak with DXF codes so I'm super impressed that you've been able to utilize them like this.

Thanks! And yes, I'm trying to make it robust and ubiquitous so it can be used for other purposes as well.

The version in the first post checks if the grips have the same point as the parameters. But its better to use the actual reference that is inside of the DXF codes. But what all the codes mean is not documented...
So this is what I think the different codes mean so far, if someone has a more complete list or more complete descriptions, that would be very helpfull!

Code: [Select]

; Parameter
; 90 = handle
; 91 = Grip reference or states?
; 92 = Grip reference
; 93 = Grip reference
; 94 = Grip reference
; 95 = Grip reference
; 177 = Base location
; 281 = Chain actions

; Grip
; 90 = handle
; 91 = Grip component reference
; 92 = Grip component reference

; Grip location component
; 90 = handle
; 91 = Paremeter reference

; Action
; 90 = handle
; 91 = Parameter reference unknown purpose
; 92 = Parameter reference Caller
; 93 = Parameter reference Caller
; 94 = 0, 1, 2 or 3?
; 95 = Parameter reference Chain