topic Re: 'CALL' affecting scripts even within an IF statement not in Libraries & objects

'CALL' affecting scripts even within an IF statement not met

Durval — Wed, 24 May 2023 10:35:48 GMT

Please help to solve a mystery.

This occurs with a custom window created in an old AC version (I think it was AC7). Now I'm trying to add some functionalities and update the window to AC15.
The object has the following segment in its 2D script:

 
IF condition THEN 
TEXT2 0, 0, "condition is met" 
!CALL "name_of_a_macro.gsm" 
ENDIF

This script produces the plan view in the attached image #1.
Condition is not met, so there's no string printed in the plan.

If I change the script just by removing de '!' before CALL command:

 
IF condition THEN 
TEXT2 0, 0, "condition is met" 
CALL "name_of_a_macro.gsm" 
ENDIF

The plan changes to the image #2. The condition is still not met, so there's no text printed, but, strangely, the CALL command, although inside the same IF statement (not met), is affecting the window's plan view. As you can see, the wallhole that windows usually create automatically is not working anymore. There is no WALLHOLE2 command in this script (actually there was one, but I commented it out for testing).

I'm going nuts to solve this. Any clues?

Thanks

Re: 'CALL' affecting scripts even within an IF statement not

Durval — Tue, 19 Jun 2012 17:12:28 GMT

image #2:

Re: 'CALL' affecting scripts even within an IF statement not

Erika Epstein — Tue, 19 Jun 2012 18:56:31 GMT

How does your "WALLHOLE2" command relate to the called macro? Can you post that portion of your script?

Re: 'CALL' affecting scripts even within an IF statement not

Durval — Tue, 19 Jun 2012 19:44:54 GMT

There was a WALLHOLE2 command in the script, but I removed it.
The problem still remains.
The object and the macro are attached below.
It's a simple window. The macro adds 'cavity closure/turn plaster' functions (sort of...).

Re: 'CALL' affecting scripts even within an IF statement not

Durval — Tue, 19 Jun 2012 21:21:21 GMT

I changed the macro that was CALLed, and the problem went away.
So, it was related in someway with the original macro script.
But what still puzzles me is why it is interfering (but not being fully executed) when the script should skip the CALL command...
It seems that CALL is in some way overwriting the IF condition, looks like a bug.