topic Re: GDL prob with text anchor pt rot and maintain text orien in Libraries & objects

GDL prob with text anchor pt rot and maintain text orient

Erika Epstein — Fri, 14 Aug 2009 18:53:05 GMT

I am adding some graphical hotspots to some 2D symbols so I can move the text when necessary. I also have 3 options for text orientation horizontal, vertical, and 'smart' (rotates w/sym but mirrors so not seem upside down).

When I have the text orientation options the anchor point of the text no longer is the same as the graphical hotspots. I tried many ADD2 and ROT2 options for the text location textx and texty with no acceptable results.Can someone point me in the right direction?

! graphical hotspots seripting
!!!!!Text ----------------------------------------
PEN txtpen
IF tr=1 THEN !HORIZONTAL TEXT
ROT2 -symb_rotangle
ENDIF

IF tr=2 THEN ! VERTICLE TEXT
ROT2 -symb_rotangle+90
ENDIF

IF tr=3 THEN !SMART ORIENTATION
mul2 1-2*symb_mirrored,1
IF symb_rotangle>90 AND symb_rotangle<270 THEN
ROT2 180
ELSE
ROT2 0
ENDIF
ENDIF

DEFINE STYLE "symtextstyle" font, 1/(2.83464567)*fontsz, txtanchor, txtFaceCode
SET STYLE "symtextstyle"
TEXT2 textx,texty , switch_text
DEL 1

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Fri, 14 Aug 2009 19:32:49 GMT

Hi Erika,

My first impression is that you miss to DEL the MUL transformation...

Try:

ROT2 -sgn (1 - 2 * symb_mirrored) * (symb_rotangle * (tr >= 1) - 90 * (tr = 2))

DEFINE STYLE "symtextstyle" font, 1/(2.83464567)*fontsz, txtanchor, txtFaceCode
SET STYLE "symtextstyle"

TEXT2 textx,texty , switch_text

DEL 1

HTH

edit: I did a little modification on the transformation... it seems to work now.

...and I have a question... Why a 3rd status "Smart"?... Shouldn't they all be smart?...

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Fri, 14 Aug 2009 20:30:33 GMT

Hi Paulo,
I tried your code, but it isn't giving me the results I am hoping for. When we are working in AC often we place for example a light switch symbol and mirror and rotate copies of the symbol as we go about placing them. My test is to place a symple in the plan and then rotate 15 copies and then mirror this wheel of symbols to see what happens.

I am attaching two screenshots to show. When I select one of the nonvertical switches, I notice the anchor point of the text no longer matches the graphical hotspot. Moving the graphical hotspot to move the text is now bizarre. It is difficult to accurately move the actual text.
The text keeps being placed relative to the base of the switch.

As to the three text orientations, I work with a number of firms. While I use the 'smart' option, some firms have strict rules about all texts being vertical or horizontal relative to the screen. I added this drop down choices for them and also as an exercise for me with value lists .

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Fri, 14 Aug 2009 20:30:55 GMT

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Fri, 14 Aug 2009 23:28:12 GMT

Hello,

I would suggest to keep the anchor point in the middle and doing
...all the moving first
...then text rotation
...and lastly place the text at point 0, 0

Hope this helps, works nicely with my little projects.

--
Regards, Juha

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Fri, 14 Aug 2009 23:46:56 GMT

Juha,
You jumped ahead to the anchor point problem. Some symbols have two lines of text. How do you keep them from running into one another when the scale changes? Or when someone changes the font size?

thanks!

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Sat, 15 Aug 2009 07:23:33 GMT

Hello,

Could be arranged by using anchor point 5 with the
one line text. If there are two lines then the upper
has anchor point 8 and the lower line has 2.

The textblock command is a powerful solution if the
number of the lines is not known ie. the text is long
and the user is allowed to adjust the text field width.
You can request a textblock's dimensions before placing it
so centering it is not a problem.

Might be an overkill solution if only a couple of words and
lines are used.

--
Best regards, Juha

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Sat, 15 Aug 2009 10:48:39 GMT

"Erika Epstein" but it isn't giving me the results I am hoping for.[/quote wrote:

Sorry Erika... I didn't test the script...

Here is a screen shot of an object which I have created based on your script... It seems to be ok on your "crash test"...

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Sat, 15 Aug 2009 10:49:33 GMT

And here is the object...

HTH

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Mon, 17 Aug 2009 17:42:35 GMT

Thank you Paulo!

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Mon, 17 Aug 2009 21:39:22 GMT

Paulo,
When I look at the 2D script in your object their is at the end of some of the numbers E-014. What is this?

line2 -0.03182522174242, -0.04636247205929, 0.03182522174242, 0.04636247205929
line2 -0.2759849876579, -5.684341886081E-014, 0.2793487716144, -5.684341886081E-014
arc2 -0.09936532665787, -5.684341886081E-014, 0.08192157583591, 100.5325984305, 325.5325984304
arc2 0.09936532665787, -5.684341886081E-014, 0.08192157583591, 280.5325984305, 145.5325984304

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Tue, 18 Aug 2009 09:40:08 GMT

Hi Erika,

Those weird codes are produced by the ArchiCAD engine...

They appear in the code because I used 2d lines and arcs, and saved them as an object, then copy/pasted them into your object 2d script...

Its a quicker process... once it was just a "Crash test dummy"

I think... When a number like this appears with this code, it's because the ArchiCAD engine avoids coincident nodes in lines and surfaces...
So the engine creates very very small gaps between them to prevent the engine gets crazy... or something like this.

But its just a guess...

Re: GDL prob with text anchor pt rot and maintain text orien

David Maudlin — Tue, 18 Aug 2009 12:06:08 GMT

Erika:

I believe that is scientific notation that indicates that the decimal point is 14 places to the right (the number is actually decimal point, a bunch of zeros, the number before the E-14), such as -0.00000000000005684341886081.

David

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Tue, 18 Aug 2009 16:08:44 GMT

I did some testing on the four lines of code that Erika posted
and it seems that E-014 is equivalent to +5.684341886081 meters.

Here is the test code:

line2 -0.03182522174242, -0.04636247205929, 0.03182522174242, 0.04636247205929
!!!!line2 -0.2759849876579, -5.684341886081E-014, 0.2793487716144, -5.684341886081E-014
line2 -0.2759849876579, -5.684341886081+5.684341886081, 0.2793487716144, -5.684341886081+5.684341886081
!!!!arc2 -0.09936532665787, -5.684341886081E-014, 0.08192157583591, 100.5325984305, 325.5325984304
arc2 -0.09936532665787, -5.684341886081+5.684341886081, 0.08192157583591, 100.5325984305, 325.5325984304
!!!!arc2 0.09936532665787, -5.684341886081E-014, 0.08192157583591, 280.5325984305, 145.5325984304
arc2 0.09936532665787, -5.684341886081+5.684341886081, 0.08192157583591, 280.5325984305, 145.5325984304

-5.684341886081+5.684341886081 of course
equals zero which is what the autoscripted value should have been.

I believe E-014 has something to do with logarithms and exponents.
In the GDL manual under Transcendental Functions there is a function
EXP (x) that is defined as "Returns the xth power of e (e=2.7182818)"

Peter Devlin

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Tue, 18 Aug 2009 17:33:42 GMT

Perhaps the ArchiCAD code is becoming so complex that its developing some kind of artificial intelligence with a stubborn personality...

so its becoming hard for him/it to admit that zero is zero... "NO!... zero is -5.684341886081E-014"

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Tue, 18 Aug 2009 19:08:17 GMT

Thanks for everyone's help and explanations.

What still puzzles me is why AC is turning these numbers into Exponentials . Is this typical autoscripting in metric AC? I am unable to reproduce these results when I drag and drop the line-work into a 2D script window; I get just the feet and inches as drawn.

LINE2 0'-0.0000", -0'-6.0000", 0'-0.0000", 0'-6.0000"

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Tue, 18 Aug 2009 19:46:26 GMT

Hello Erika,
I just did an experiment where I set the Working Units & Levels
to Meters then drew a couple of lines one meter long. I then opened
a new library part and dragged and dropped the lines into the 2D
script. The code was in Meters. I then changed the Working Units & Levels
to Feet and Fractional Inches and dragged the same lines into the same
2D script. The code for these lines was in Feet and decimal inches.
So, it seems the units in an auto-scripted object depends on the
units used in the project.
Peter Devlin

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Tue, 18 Aug 2009 21:48:57 GMT

Peter,
I reproduced what you did, setting it on millimeters and then meters and then feet & inches. I didn't get any numbers with exponents, did you?

Re: GDL prob with text anchor pt rot and maintain text orien

Anonymous — Tue, 18 Aug 2009 23:34:19 GMT

Hello Erika,
I'm sorry. I thought you were talking about the units being used
in the script. I did not get values with exponents. I don't think
you will be able to reproduce the code that Paulo got when
he invoked the auto-script mechanism. The auto-script mechanism
gets more screwy in every AC version. I was thinking of asking
Paulo how exactly did he draw the arcs and lines thinking that
maybe he drew them some five Meters below the origin then
dragged them up to the origin before dragging and dropping them
into the 2D script but decided that that should not cause the
strange code. Maybe Paulo can tell us how he managed to get
the auto-script mechanism to write such screwy code.
Thanks,
Peter Devlin

Re: GDL prob with text anchor pt rot and maintain text orien

Erika Epstein — Tue, 18 Aug 2009 23:52:48 GMT

Peter, nothing for you to be sorry about. As always I am learning a lot more than I could have anticipated.
I tried moving the lines I drew 463 miles away from the origin to get the exponents to kick in, but perhaps not far enough.

(in millimeters)
LINE2 746274.7836314, 560996.1281125, 746275.0884134, 560996.1281125

I don't know what the period in the middle of each x and y coordinate signifies.