GLOB_CONTEXT Label Issues

[Lachlan Green]

I have been on a label making spree. Trying to be clever I am atempting to combine 2 labels into one. One label is for walls in plan, the other is for walls in elevation. The label needs to know when it is in plan and when it is in elevation.

I have been trying to use the GLOB_CONTEXT to do this, and it works so far as showing the two different labels correctly in plan and elevation. However it prevents hotspots from moving the label. For this I was using GLOB_CONTEXT =2 & 4.

Using values 22 and 24 makes it shows the plan label correctly with movement, but it shows the plan label in elevation and without movement.

I've run through all the GLOB_CONTEXT numbers to see if any show the elevation label in elevation with movement but none do. Only 4 shows it but without movement. This gave me the idea of using IF plan ELSE do elevation would work.... howwever using the following code makes things more confusing. IF GLOB_CONTEXT = 22 THEN 'show plan' ELSE 'show elevation' ENDIF. This shows the elevation label in plan and elevation, although the hotspots do work in elevation.

Also I tried using APPLICATION_QUERY and Model View Options, however APPLICATION_QUERY seems to only apply to 3D script and labels can't access MVOs.

I'll try and simplify the code and upload an example of it. From the looks of it I doubt there's a solution as it seems I'm using the glob_context just outside what it was intended to do. Thanks in advance for any help.

[Anonymous]

Code please.

I haven't tried this with the dynamic hotspots. It seems like it should work but one never knows I guess.

[Frank Beister]

Yes, code please, better (simplified) object, because for moveable hotspots the parameter script is needed (GLOB_CONTEXT=%) and here you can't differ between floor plan and s/e. It is always 5.

I have ideas where is the problem and how to solve. You can PM directly too.

[Lachlan Green]

Thanks for the help. I’ve attached the simplified code below. Ironically by simplifying I have stumbled on a mostly complete solution which is good enough for what I need.

I was using the glob_context code in the master script, moving it to the 2D script fixed the initial problems. However there was an issue with the plan label and multiple independent hotspots. The first hotspot would work fine, the second hotspot would move as long as the first wasn't moved yet. As soon as the first is moved the second stops working.

However, if the second hotspots is related to the first (ie moves with the first) then they work. Originally I had a moveable hotspot, then DEL back to the origin and had a separate moveable hotspot. Fortunately I don't need them to be independent. I'm sure there's a better way of explaining it...

Thanks again.

All in 2D Script
unID=1

IF glob_context = 2 THEN
label_type = 1
ELSE
label_type = 2
ENDIF

ADD2 label_position[2][1]+label_position[3][1]+symb_a_size/2,label_position[2][2]+label_position[3][2]+symb_b_size/2

!!!======PLAN LABEL

IF label_type=1 THEN

!= HOTSPOT MOVEMENT
HOTSPOT2 0,offset[1][2],unID,offset[1][1],1+128 : unID=unID+1
HOTSPOT2 -1,offset[1][2],unID,offset[1][1],3 : unID=unID+1
HOTSPOT2 offset[1][1],offset[1][2],unID,offset[1][1],2 : unID=unID+1

HOTSPOT2 offset[1][1], 0, unID,offset[1][2],1+128 : unID=unID+1
HOTSPOT2 offset[1][1], -1, unID,offset[1][2],3 : unID=unID+1
HOTSPOT2 offset[1][1], offset[1][2], unID,offset[1][2],2 : unID=unID+1

ADD2 offset[1][1], offset[1][2]

LINE2 -.1, .2, .1, .2 !!==== PLACING THE TRIANGLE
LINE2 -.1, .2, 0, 0
LINE2 .1, .2, 0, 0




!DEL 1 !!========= USING THE DEL BREAKS THE HOTSPOTS





!= SECOND HOTSPOT MOVEMENT
HOTSPOT2 0, offset_e[1][2], unID,offset_e[1][1],1+128 : unID=unID+1
HOTSPOT2 -1, offset_e[1][2], unID,offset_e[1][1],3 : unID=unID+1
HOTSPOT2 offset_e[1][1], offset_e[1][2], unID,offset_e[1][1],2 : unID=unID+1

HOTSPOT2 offset_e[1][1], 0, unID,offset_e[1][2],1+128 : unID=unID+1
HOTSPOT2 offset_e[1][1], -1, unID,offset_e[1][2],3 : unID=unID+1
HOTSPOT2 offset_e[1][1], offset_e[1][2], unID,offset_e[1][2],2 : unID=unID+1

ADD2 offset_e[1][1], offset_e[1][2]

LINE2 -.1, .2, .1, .2 !!==== PLACING THE TRIANGLE
LINE2 -.1, .2, 0, 0
LINE2 .1, .2, 0, 0


ENDIF


!!!======ELEVATION LABEL

IF label_type = 2 THEN

!= HOTSPOT MOVEMENT
HOTSPOT2 0, offset[1][2], unID, offset[1][1],1+128 : unID=unID+1 !!=== HOTSPOT FOR ELE LABEL GOES HERE
HOTSPOT2 -1, offset[1][2], unID, offset[1][1],3 : unID=unID+1 !!=== DOING IT BEFORE THE GLOB_CONTEXT
HOTSPOT2 offset[1][1], offset[1][2], unID, offset[1][1],2 : unID=unID+1 !!=== MEANS IT DOESN'T BREAK!

HOTSPOT2 offset[1][1], 0, unID, offset[1][2],1+128 : unID=unID+1
HOTSPOT2 offset[1][1], -1, unID, offset[1][2],3 : unID=unID+1
HOTSPOT2 offset[1][1], offset[1][2], unID, offset[1][2],2 : unID=unID+1

ADD2 offset[1][1], offset[1][2]

!= SECOND HOTSPOT MOVEMENT
HOTSPOT2 0, offset_e[1][2], unID,offset_e[1][1],1+128 : unID=unID+1
HOTSPOT2 -1, offset_e[1][2], unID,offset_e[1][1],3 : unID=unID+1
HOTSPOT2 offset_e[1][1], offset_e[1][2], unID,offset_e[1][1],2 : unID=unID+1

HOTSPOT2 offset_e[1][1], 0, unID,offset_e[1][2],1+128 : unID=unID+1
HOTSPOT2 offset_e[1][1], -1, unID,offset_e[1][2],3 : unID=unID+1
HOTSPOT2 offset_e[1][1], offset_e[1][2], unID,offset_e[1][2],2 : unID=unID+1


RECT2 -.3,-.1,.3,.1
ENDIF

[Lachlan Green]

Ok it seems I have spoken too soon. As I was building the code back up it stopped working. Going through adding line by line I found what is breaking it. If a ADD2 or ROT2 command is placed within the same IF statement as the global_context IF statement then hotspot movement breaks down.

This includes any related IF statement. In the code below I tried to get around this by having the label_type variable equaling 1 or 2 based on the result of the global_context. However this still ends up with the hotspots breaking.

If the movement is placed between the two hotspots then the first will work, the second won't. So it seems all movement required before the hotspots must be placed outside the IF statement. This may still be doable.

[Anonymous]

LGreen

Just a guess but I'd try some sub routines in there in lieu of the value push.
Something like this
IF glob_context = 2 THEN
GOSUB 1000: !Label type 1
ELSE
GOSUB 2000: !Label type 2
ENDIF

I'm also a little hesitant to leave such a broad range of global_context in the else option.
I tend to break mine down for each context just so it will run the sub in each context.

[Lachlan Green]

Thanks Kristan,
Regarding the glob_context range in the Else section, this came about as it's the only arrangement that seems to work. Using separate statements with values 2 & 4 etc break the movement, this is also what happens if I use subroutines. I may have found the crux of the problem and it is really weird.

It seems the hotspots in the plan label rely on the existence of the hotspots in the elevation label to function properly. If I comment out the Y-axis movement of the hotspots in the plan label nothing happens. However if I do it for the elevation label, then both plan and elevation labels are constrained. I should also mention that both hotspots are using the same variable, if they use different variables it doesn't work.

In any case I've manged to get the label working good enough with only a minor annoyance in how users see the elevation hotspots.

[LiHigh]

I don't have time to try it.
I suggest you try to put those code that determine Glob_context in Master Script...