Topic: using 'cal in a stretch grip dialogue box

[Albroswift]

Hello, All
Posted a similar question on a different forum, didn't get an answer that explained this block behavior.
Here is the situation: A lot of my blocks rely heavily on stretch parameters. Typically when activating a stretch grip, I will just type the size I want the block to be in that axis, and it stretches or shrinks TO that dimension. Example, insert a 12" X 12" block. Activate the x axis stretch, type 10, block resizes to 10" in the x direction. (still 12" in the y direction). Perfect. BUT, if I entered say 'cal 9+1, or any other routine that will return a dim, the block stretches BY that amount, the block stretches to 1' 10", not what I want. Is there a setting I am missing that would make it function as the first example? Alternately, suggest a different method of changing block dimensions that would allow for a 'cal command or lisp to change dim instead of adding to dim? Too many different sizes to use visibility state, lookup, etc.
Thanks--
AL
ACAD 2014

[CAB]

I'm using ACAD2006 & that entry is not supported so I can't test it.
What is your Units setting?

[Albroswift]

Type: Decimal
Units to scale inserted content: Inches
Primary Units: Architectural
Secondary Units: Decimal
Multiplier: 24.500

Behavior not tied to units I don't believe.
Thanks--

[mjfarrell]

Hello, All
Posted a similar question on a different forum, didn't get an answer that explained this block behavior.
Here is the situation: A lot of my blocks rely heavily on stretch parameters. Typically when activating a stretch grip, I will just type the size I want the block to be in that axis, and it stretches or shrinks TO that dimension. Example, insert a 12" X 12" block. Activate the x axis stretch, type 10, block resizes to 10" in the x direction. (still 12" in the y direction). Perfect. BUT, if I entered say 'cal 9+1, or any other routine that will return a dim, the block stretches BY that amount, the block stretches to 1' 10", not what I want. Is there a setting I am missing that would make it function as the first example? Alternately, suggest a different method of changing block dimensions that would allow for a 'cal command or lisp to change dim instead of adding to dim? Too many different sizes to use visibility state, lookup, etc.
Thanks--
AL
ACAD 2014

If one knows the value required, why would one use the [cal] function to input that value?
Seems like you are taking the hard way to input a simple value.

Or better if the block should ONLY stretch by given increments why not build that into the stretch function?
Or use a look up table for the accepted dimensions?

[Albroswift]

Your killin me, MJ...
I just used 9+1 as an example, enter 10, get =10. enter 'cal 10, get + 10
Most of my entries would be something like:
 'cal cvunits 3657,mm,in
or
 'cal 4295/24.5
or
 'cal mm2in 3650 (mm2in being a lisp routine)
Can't really do those in my head...
So, to recap---
insert dynamic block
Activate X axis stretch
Type 10
Block stretches/shrinks to 10" regardless of initial length (desired effect)
BUT
type 'cal 254/24.5
Block increases initial length by 10" (Not desired effect)
Thanks again!
Al

[Albroswift]

...and don't want a 5000 line lookup table...

[danallen]

or
 'cal 4295/24.5

try 42950/245 and it will be accepted, avoids problem with command line division by decimal (not sure if it will snap to 10 increment as you describe)

[mjfarrell]

same idea different logic....

IF

one needs to work in MM why not work in MM and NOT inches?

OR

one needs to work in inches, work in inches....

why introduce the headache and or possibility of failing to convert units properly?

personally, I don't trust [cal] function because there are instances it fails to do the math at all.

Command: CAL
>> Expression: 23414545245245*546461846949+
Error:
Integer numbers must be between 2147483647 and -2147483648

[Albroswift]

"try 42950/245 and it will be accepted"

2014 will accept decimal divisor, but either way adds.

"IF

one needs to work in MM why not work in MM and NOT inches?

OR

one needs to work in inches, work in inches....

why introduce the headache and or possibility of failing to convert units properly?"

Primary drawing is in architectural, output is in architectural, some components come dimensioned in metric. this has been discussed on several forums over the years, some of us would simply like to input metric dims in a imperial dwg.
BUT regardless of my reason for wanting to use the 'cal type input, or whether one believes the 'cal works at all,  I would just like someone to explain dimension "Change" vs dimension "Add" behavior.
Thanks
Al

[mjfarrell]

Will see if I can find and answer other than;
draw those metric components in a metric file and use INSERT UNITS function to scale those blocks to inches upon insertion to
the Imperial drawing and then use inches to control stretch functions.

[BKT]

or
 'cal 4295/24.5

try 42950/245 and it will be accepted, avoids problem with command line division by decimal (not sure if it will snap to 10 increment as you describe)

To the OP: I know that you're trying to find out why the cal function works the way it does, but did you try what danallen suggested and just enter the fraction without using 'cal?  I'm assuming there's a typo above and that you meant "25.4" and if that's the case, can you just enter the fraction in a dynamic block stretch, say, "2540/254" to get 10?

(I'm not where I can test this myself so I don't know if it works...)

[danallen]

I don't understand the OP operations "Activate the x axis stretch", thus I can't comment on his question about 'cal

[mjfarrell]

Interestingly enough...using the STRETCH command on a normal rectangle does not produce the results you describe:

Select objects:

Specify base point or [Displacement] <Displacement>:
Specify second point or <use first point as displacement>: 'CAL
>>>> Expression: 2*12

stretches the box 24 units as expected

Specify second point or <use first point as displacement>: 'cal

>>>> Expression: (10+2)*3

results as expected

this suggest something could be wrong with your stretch parameter definition inside your block.

[mjfarrell]

I don't understand the OP operations "Activate the x axis stretch", thus I can't comment on his question about 'cal

dynamic block with stretch function constrained to a(n) axis is how I am reading this

[mjfarrell]

after re-re-re-re reading post it would appear that

A) user is not using dynamic input correctly, i.e. set base point for stretch and then pushing courser in desired direction for stretch action

or

B) there is some issue in his LISP returning incorrect value

or

C) combination of the two

[Albroswift]

 I attached the drawing with a sample block, if you would like to try.

Interestingly enough...using the STRETCH command on a normal rectangle does not produce the results you describe:

Yes, a line or rectangle behaves as you say ie click a line, grab the end grip, type 10, line increases in length by 10.
But, click on the stretch grip on my block, type 10, block resizes to 10 in that axis.
I am using the word axis as I have a stretch in the x axis and the y axis, but applies to any stretch command in any dynamic block as far as I can determine.

>>>> Expression: 2*12

stretches the box 24 units as expected

Specify second point or <use first point as displacement>: 'cal

>>>> Expression: (10+2)*3

results as expected

Can't enter a formula in a dynamic block stretch without the 'cal
Try my block, see what you think.
[quote}dynamic block with stretch function constrained to a(n) axis is how I am reading this[/quote]
Correct

[mjfarrell]

WORKS FOR ME AS EXPECTED.....Command:
Specify point location or [Base point/Undo/eXit]: 'CAL

>>>> Expression: 3*(2+5)

Resuming GRIP_STRETCH command.

Specify point location or [Base point/Undo/eXit]: 21


issue is when and or where you enter your value....in the DYN box it will behave NOT as expected
@ command line it will

[Albroswift]

Where were you at just before "Specify point location or [Base point/Undo/eXit]: 'CAL"?
In a dynamic block?
I used your expression in a block that was 12", activated stretch, typed 'cal 3*(2+5)and new size was 33, not 21. Is there a setting somewhere that could explain? Screenshot attached.
Thanks for digging into this, appreciate the help

[mjfarrell]

yes, you got what you asked for a block that was already 12 units was stretched 3*(5+2)
12+21=33

where you enter the formula determines your result, in DYN window entered size is the resultant
@ command line current size PLUS the delta change of your formula is the resultant

[Albroswift]

Yes BUT if I entered 21 instead of 'cal 3*(5+2) it does not add to the size but replaces the size. This is the effect I am looking for.  Possible or not?

[mjfarrell]

yes, depending WHERE you enter the value...in dynamic box it alters to size entered
@ command line it applies formula

so it does BOTH, just know when and where to enter value to get desired result

[Albroswift]

I am seeing this exact behavior and agree 100%, BUT...I can't seem to enter at command line when dynamic stretch is active. I put cursor in command line and click, get cursor, but when I start typing it jumps right back to the dynamic dialogue. SO... It seems like this is not going to be an option for me.
Thanks again for the help.
Al

[mjfarrell]

Perhaps turning DYN input OFF when you want to use this method

[Albroswift]

Thanks, tried 0,1,2,and 3(default) for DYNMODE, didn't affect results
What I am seeing from trial and error is:
Any 'cal OR command line entry EXCEPT when directly entering value in dynamic stretch dialogue results in the value being added to the existing size, and I think remember back to 2007 or 11 version when ever I started using dynamic blocks that behavior (adding) was typical even in the dynamic dialogue, so I guess this behavior (having the stretch value replace the current size not add to) is really the odd man out, maybe unique to 2014, doesn't look like I can duplicate it with the 'cal command. I wonder if a transparent lisp routine to first set the stretch value to negative current size (resulting in the blocking stretching to 0) and then stretch to the 'cal input could be done? Way over my head...
AL

[mjfarrell]

I can get it to function either way....value is the resultant, and or value is summed to existing and that is the result....

or suggest F12 and just turn DYN off....so you are only using command line entry...If I get time I will make a screen capture video of
what and or how this is functioning for me in 2014

[Albroswift]

Thanks MJ
a step by step how you get value resultant from a 'cal would be awesome.