AC11: IE Marker

[Laura Yanoviak]

I'd just like to verify something before I embark on another GDL adventure...

It doesn't look like the Marker I want (see attached) is possible with the provided IE Markers in AC11 -- true? Typically, we will want to have one common Marker for each IE group, the Drawing ID being inherited from "The first placed drawing of the viewpoint" (all elevations of a room treated as a single drawing).

With the "One common Marker..." selected, the choices are limited to "Outer Text" and "Inner Text"; only with "Individually..." selected do you have the choice of "First Row Text" and "Second Row Text" (I do realize these are two different Marker objects). Am I missing a setting somewhere, or am I going to have to create my own Marker???

[TomWaltz]

James wrote:
Not fixed in 1086.

You'd think a new tool that failed utterly in a plurality of cases would get more urgent attention.

Remind me, why should I upend my workflow every twelve months?

@#$%

Because you pay to! 😉

[Laura Yanoviak]

James wrote:
My experience is that when the top, always the top, view is turned off, the layID fails to resolve. I let them know. IEs are still very buggy IMO.

My workaround is to use multiple single-sided IEs with the markers stacked. Real convenient. I believe this is similar to the Tom Waltz pre-11 method.

Another workaround discovered:

If you need to eliminate the top viewpoint, you can rotate the entire marker (not just "Rotate Marker" via the pet palette) and readjust the limit polyline as needed. AC assumes that the left-pointing viewpoint is now West, the down-pointing viewpoint is now South, etc.

Just make sure that what was originally the top-pointing viewpoint remains.

[Rob]

James Murray wrote:
My experience is that when the top, always the top, view is turned off, the layID fails to resolve. I let them know. IEs are still very buggy IMO.

My workaround is to use multiple single-sided IEs with the markers stacked. Real convenient. I believe this is similar to the Tom Waltz pre-11 method.


Another workaround discovered:

If you need to eliminate the top viewpoint, you can rotate the entire marker (not just "Rotate Marker" via the pet palette) and readjust the limit polyline as needed. AC assumes that the left-pointing viewpoint is now West, the down-pointing viewpoint is now South, etc.

Just make sure that what was originally the top-pointing viewpoint remains.

guys, that is a fairly simple bug in library part itself (not a really clever GDL programming on GS side )...

I am attaching fixed one that works properly, so you do not have to rotate it etc

[Laura Yanoviak]

Ah -- thanks, Rob -- I'm not quite a GDL guru yet, so I wasn't able to catch that -- LJY.

[Rob]

That's fair enough Laura, I did not mean to present that like you should check the code in lib parts every morning for a fun
I have emphasised 'fairly simple' as a poor form of particular GDL programmer and/or Q/A fella especially when we are talking about fairly important AC feature.

[Laura Yanoviak]

Rob -- I would say I am at an intermediate level with GDL, but the "fix" is not readily apparent to me after reviewing the script -- you mind giving us a hint as to what you changed to fix the bug?

[James Murray]

I used BBedit to compare the scripts of the original and Rob's mod. This is the affected area, it's two similar instances:

if gs_inner_text_int = 1 then
	! Referred Drawing

	if gs_inner_text_layout_id then
		if (iNumItems = 1) then
			!! GS Fail
			!!!!!!sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_1
			!! Kalocay Fix
			if AC_DrawingGUID_1#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_1
			if AC_DrawingGUID_2#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_2
			if AC_DrawingGUID_3#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_3
			if AC_DrawingGUID_4#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_4
				

		else
			if bHaveContent2 then
				separator = stSeparator
			else
				separator = ""
			endif
			!! GS Fail
			!!!!!!!!sInnerText2 = sInnerText2 + separator + "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_1
			!! Kalocay Fix
			if AC_DrawingGUID_1#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_1
			if AC_DrawingGUID_2#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_2
			if AC_DrawingGUID_3#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_3
			if AC_DrawingGUID_4#"" then sInnerText1 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_4

		endif
	endif
else
yada  yada yada
endif

That section begins on 2D line 114. I think that's all there is to it.

Thank you Rob.

[Laura Yanoviak]

Thanks James! (I didn't know about BBedit -- I'll have to see if there's something comparable for Windows)

[Laura Yanoviak]

For anyone following my previous posts on the subject -- my fix:

if gs_inner_text_int = 1 then
	! Referred Drawing
!		GS error:
!		sInnerText1 = "<MARKERDRAWINGNUMBER_R>" + AC_DrawingGUID_1
!		sInnerText2 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_1
!		Kalocay fix (and modified by LJY for klipp):
		if AC_DrawingGUID_1#"" then sInnerText1 = "<MARKERDRAWINGNUMBER_R>" + AC_DrawingGUID_1
		if AC_DrawingGUID_2#"" then sInnerText1 = "<MARKERDRAWINGNUMBER_R>" + AC_DrawingGUID_2
		if AC_DrawingGUID_3#"" then sInnerText1 = "<MARKERDRAWINGNUMBER_R>" + AC_DrawingGUID_3
		if AC_DrawingGUID_4#"" then sInnerText1 = "<MARKERDRAWINGNUMBER_R>" + AC_DrawingGUID_4

		if AC_DrawingGUID_1#"" then sInnerText2 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_1
		if AC_DrawingGUID_2#"" then sInnerText2 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_2
		if AC_DrawingGUID_3#"" then sInnerText2 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_3
		if AC_DrawingGUID_4#"" then sInnerText2 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_4
			
else

[Rob]

Just a quick explanation if you are interested...

that is a problem indeed:

! GS error:
! sInnerText1 = "<MARKERDRAWINGNUMBER_R>" + AC_DrawingGUID_1
! sInnerText2 = "<MARKERSHEETNUMBER_R>" + AC_DrawingGUID_1

it means that if you delete view no.1 which is "AC_DrawingGUID_1" the script fails to find the sheet reference (as the view no.1 pointer points to nowhere) and does not attempt to test the rest of views. Therefore the bug was intriguing as it propagated itself in case of deleting view no.1 only.

Fix:

I have just added lines to test the rest of views like if view1 points to nothing go to next view (2) and so forth.