Was Stretchy, Now It's Not

[Anonymous]

In an earlier version of the code shown below, you could stretch length A using one or the other of the hotspots shown in red. In the process of making a few changes, this functionality went away. I have tried everything I can think of to get it back. I didn't program this behavior in the first place, it just worked. Help!

100: !!DEFINE TEXT STYLE
DEFINE STYLE "AC_STYLE_1" pTextFont, pTextSize / 2.54, 5, 0
SET STYLE "AC_STYLE_1"

110: !!DRAW GRID LINE AND HOTSPOTS
PEN pLinePen
LINE_TYPE pLineType
HOTSPOT2 0, 0
HOTSPOT2 0, A / 2
HOTSPOT2 0, -A / 2
LINE2 0, -A / 2, 0, A / 2
HOTLINE2 0, -A / 2, 0, A / 2

120: !!ADD FIRST BUBBLE
ADD2 0, A / 2 + (pBubSize * GLOB_SCALE)
GOSUB 200
DEL 1

130: !!ADD SECOND BUBBLE IF REQUIRED
IF pBubLoc = `Both Ends` THEN
ADD2 0, -A / 2 - (pBubSize * GLOB_SCALE)
GOSUB 200
DEL 1
ENDIF

BODY -1
END


200: !!BUBBLE
LINE_TYPE pBubLineType
PEN pTextPen
ROT2 -SYMB_ROTANGLE
TEXT2 0, 0, pBubNum
DEL 1
PEN pBubPen
CIRCLE2 0, 0, pBubSize * GLOB_SCALE
HOTARC2 0, 0, pBubSize * GLOB_SCALE, 0, 360
HOTSPOT2 0,0
HOTSPOT2 0,pBubSize * GLOB_SCALE
HOTSPOT2 0,-pBubSize * GLOB_SCALE
HOTSPOT2 pBubSize * GLOB_SCALE,0
HOTSPOT2 -pBubSize * GLOB_SCALE,0
RETURN

[Anonymous]

What exactly did you change?

I put a vertical line using a in Archicad 8 & 9 and it didn't stretch, if you use 'b' it does (or use 'a' horizontally). I think if you change all your a's to b's you will be fine.

Julia

[Anonymous]

Julia wrote:
What exactly did you change?

That's a good question. I changed a lot of non-stretchy stuff before I noticed that the stretching ability had disappeared. When it was stretchy, I was still only using A's.

[Anonymous]

What was your last version where the line was stretchy? Have you looked atgraphical editing in AC 9.0?

Just a thought.

[Anonymous]

Did you put the HS before the rest?
You have to put the bounding strechable hotspot at the top of the 2d script...

PWD

[Anonymous]

Not positive this is the answer, but just something of note. The "A" value is modified (divided by 2). By using just the base "A", the point will be stretchable, but when the number is modified is when the stretchability goes.

[Anonymous]

Tom,
I think you are correct.
I believe I can verify that when the value of A or B is modified in the script arithmetically, the object is no longer stretchy along the axis
that has been modified.
Thank you,
Peter Devlin

[Anonymous]

tprokop wrote:
Not positive this is the answer, but just something of note. The "A" value is modified (divided by 2). By using just the base "A", the point will be stretchable, but when the number is modified is when the stretchability goes.

The "A" value itself is not being modified (that requires a PARAMETERS statement). The distance between the hotspots is being derived from the value of A and this generally works just fine.

The object will stretch between any two hotspots that are separated by a distance that matches the value of A or B in the associated direction(s).

It is possible that dividing by 2 has introduced some very tiny rounding error so that the sum of A/2 + A/2 is returning a value slightly different than A. Try changing to A*0.5 and see if this helps.

It is generally better to multiply by a reciprocal value than to divide by a constant. Multiplication is simple arithmetic, whereas division is handled as a transcendental function. I only use division when the divisor is a variable for this reason.

[Anonymous]

Matthew,
Just as a test, I made the simplest of objects to test whether
modifying A or B arithmetically would disable stretchiness.

One POLY2_A command with four HOTSPOT2 s at the corners.
The object stretches in both axes.
At the beginning of the script, insert the statement B=B*2 (no division).
Now the object no longer stretches along the B axis.

Does this deal with your observation about division and rounding errors ?

Thank you,
Peter Devlin

[Anonymous]

Just to verify for myself, I tried a little test:

rect2 0,0,a,b
rect2 0,0,a*.5,b*.5
hotspot2 0,0
hotspot2 a*.5,b*.5
hotspot2 a,b

The object stretches from the second (a,b) hotspot, but not the first. I think the limitation comes from "a*.5" not being equal to "a" and not from the division. By moving the "a*.5" location, it would force the value of "a" to be modified, which seems to be the restriction.