macro will return a substring for a label, but not the label in the schedule

[SHCanada2]

I was looking to convert my macro for unprotected openings on a building face (which is the sum of the windows divided by a drawn pline on the elvation) to a schedule.

 

All seemed good except when I create this new schedule my window labels, which currently have Wxx, now they have Wxx,Gyy as the windows are now on two schedules. I cant seem to be able to configure the schedule to not show the Gyy in the window label., so I wrote a macro to just look for the Wxx in the "schedule_number" and return that to the window label

 

All is perfectly fine for the window label, but the schedule will not return a substring correctly, it either returns "Wxx,Gxx" which is the full string, or it returns EVAL ERROR if I try and return more than the first 2 characters (or it still returns the full string depending on what method I try), or if I return only the first 2 characters, it then returns !! where it should return W0.

 

I tried a few different ways, from i) just using schedule_number[0..2], to ii)  assigning it a global var in the label and then returning the first 3 characters from the global, to iii) calling a macro and passing the schedule number to it, to iv) calling an owner object macro. No luck

 

Anyone tried this successfully or know a different way?

 

option ii: I put this macro in the window label:

EXAMPLE WINDOW: GLobal variable:%$gsched=schedule_number[0..2]%

resulting window label: 

 

resulting line in schedule: 

 

if I change to 

EXAMPLE WINDOW: GLobal variable:%$gsched=schedule_number[0..1]%

window label is correct (shows W0) but schedule has:

 

I tried fiddling with different types of ruby methods to get substrings, and tried .to_s first before [0..2] and sequencing the calls, but no luck. also tried OIP, no different results.

 

And if someone is wondering why I am assuming the Wxx will be the first and not Gyy, it is because when I first tried to search for a pattern match and get the string out, it would not work, so I started to check character by character and ended up with the above test, and odd results. i.e. If I just ask for $gsched[0] I get ! for the schedule line but $gsched gives W05,G06 for the schedule line, and $gsched[0..4] gives W05,G correctly for the window label, but gives W05,G06 for the schedule line. Basically it works properly for the window label, but the schedule line results do not match the window label

 

its almost like CA is storing a reference to the string somewhere..

 

[Alaskan_Son]

On 2/2/2025 at 7:34 PM, SHCanada2 said:

Anyone tried this successfully or know a different way?

Yes.  I have some tricks that I've uncovered/developed, and that I have shared through my subscription Mailer, but not that I plan to share here on the forum.  If you want to set up a consultation session, I'd be happy to walk you through some of the basics though. 

[QualicoreHomes]

I'm not being asked or paid to write this but I highly recommend the subscription Mailer of Michael.

 

[SHCanada2]

14 hours ago, Alaskan_Son said:

Yes.  I have some tricks that I've uncovered/developed, and that I have shared through my subscription Mailer, but not that I plan to share here on the forum.  If you want to set up a consultation session, I'd be happy to walk you through some of the basics though. 

thanks, I appreciate it. I'll try a couple more things and may be headed your way. I am interested in general of getting rid of globals as much as possible, and try to limit them to transient purposes

[Alaskan_Son]

6 hours ago, SHCanada2 said:

I am interested in general of getting rid of globals as much as possible, and try to limit them to transient purposes

Yeah.  Same.  I almost never use global variables for anything these days and recommend against them whenever possible as well.  For what its worth, I wouldn't be recommending global variables for this issue either. 

[SHCanada2]

turns out for this one, the answer is simpler, inline code in the label:

 

%"%schedule_number%"["%schedule_number%".index('W'), 3]%

 

 

that being said, with the advances in the schedule capability, my two cents is the schedules should not force their schedule number into the schedule_number property of the object.

 

IMHO along with the schedule label options of Use both callout and label, use callout, use label, there should be a fourth: "None"

 

and the good news is this just eliminated my macro which had a global variable which kept track of all the windows and cycled through the hash to find out which were on this elevation and then did the math