Schedule doesn't show correct output from Ruby macro

[MarkMc]

Ran across this yesterday and played at it some this am, still can't figure it out. A very simple macro evaluates to a given number when I look in the TMM but placing that in a field to show in the schedule produces a different result. Why? I tried a few variations without luck.

Schedule Number.plan

[MarkMc]

29 minutes ago, solver said:

Look at the Manufacturer field before changing the font size and then after, then after I move the schedule.

I watched, tried it, don't get the same results. Tested a specific macro to evaluate simple_schedule_number- doesn't give the result you show in mfg field. Still don't get what is up.(no sound on video BTW)

[Alaskan_Son]

7 minutes ago, solver said:

Wonder why I'm getting this?

 

The first one is the macro that isn't working, and the next 2 are returning multiple values because you have 2 schedules...one in the plan view and one in a CAD detail.

[MarkMc]

49 minutes ago, Alaskan_Son said:

The first one is the macro that isn't working,

Figured he had two while taking brother to train. But macro still doesn't show properly any ideas? They all evaluate properly in the TMM

[Alaskan_Son]

27 minutes ago, MarkMc said:

But macro still doesn't show properly. Any ideas?

 

Why yes, I do have ideas.  I suspect its some internal limitation Chief put in place because they don't want us using the schedule number in the schedule.

[MarkMc]

16 minutes ago, Alaskan_Son said:

  I suspect its some internal limitation Chief put in place because they don't want us using the schedule number in the schedule.

Think you may be onto something there. Just tested one as a referenced and it works fine.

 

[MarkMc]

On 2/18/2019 at 1:53 PM, Alaskan_Son said:

Why yes, I do have ideas.  I suspect its some internal limitation Chief put in place because they don't want us using the schedule number in the schedule.

Talked with Jason about this and he said no that wouldn't be the reason. Sent it in. Answer returned is:

 

Quote

The problem is related to how schedule macro is processed. In order to know the schedule number we first must build the schedule in the background. In your case the macro is executing before the schedule is built so the result is you get 0 returned from the macro every time.

Not sure if it is possible to force the schedule to execute and then get the macro? not something I'm going to mess with right now though.

[Alaskan_Son]

3 hours ago, MarkMc said:

Not sure if it is possible to force the schedule to execute and then get the macro? not something I'm going to mess with right now though.

 

There's a method I often use to do this type of thing by not using the schedule number at all and instead using a global variable inside the schedule that builds its own order based on the schedule order. 

 

...and thanks for the heads up on the rest.  I find it a bit curious because I was able to use the schedule number similar to what you were trying to do above in past versions.  It just doesn't work in X11 anymore. Something changed.

 

 

[MarkMc]

48 minutes ago, Alaskan_Son said:

I find it a bit curious because I was able to use the schedule number similar to what you were trying to do above in past versions.  It just doesn't work in X11 anymore. Something changed.

Isn't it odd that it works for referenced macro though? I tried local and global to no end. Don't really need it right now so moved on to ML and symbol components.

 

Another one I just found-anything entered into a custom OIP field returns as a string (entering to decimal places doesn't change to float either) While the standard fields still return integers if entered as such.

[Joe_Carrick]

OIP fields are text automatically.  If you want to get their numerical value you need to do that in your macros.

[MarkMc]

Coulda sworn I had one of the default fields returning integers but looks like no-oops.

[Joe_Carrick]

Back to the original problem.

 

The simple_schedule_number is an "Object Specific" attribute - which works for owner as expected.

CA evidently has a special connection for it's "Object Specific" macros to force them to work within a Schedule but when we use those in user macros that connection is lost.

 

Within a Schedule a user macro finds the Schedule itself as the OWNER, not the ROW_OBJECT.  Consequently it fails to provide the correct answer.

 

We probably just need a "Object Specific" context in TMM to make it work.  I've been asking for a "Room" context for a long time - but it's still not available. 

 

Maybe if OWNER when used in a schedule just referenced the ROW OBJECT it would work properly.

[Alaskan_Son]

8 minutes ago, Joe_Carrick said:

The simple_schedule_number is an "Object Specific" attribute - which works for owner as expected.

CA evidently has a special connection for it's "Object Specific" macros to force them to work within a Schedule but when we use those in user macros that connection is lost. 

 

Within a Schedule a user macro finds the Schedule itself as the OWNER, not the ROW_OBJECT.  Consequently it fails to provide the correct answer.

 

What you described is actually only partially true.  For rooms, it works as you describe (the schedule is recognized as the owner for any macros executed inside the schedule) and I've requested they fix this in the past.  For other objects though, they do recognize the parent object when executed in the schedule as long as the macro is placed into the label or into an OIP field.  The schedule number issue Mark has been describing is actually an anomaly in this regard.

[Joe_Carrick]

26 minutes ago, Alaskan_Son said:

 

What you described is actually only partially true.  For rooms, it works as you describe (the schedule is recognized as the owner for any macros executed inside the schedule) and I've requested they fix this in the past.  For other objects though, they do recognize the parent object when executed in the schedule as long as the macro is placed into the label or into an OIP field.  The schedule number issue Mark has been describing is actually an anomaly in this regard.

The problem is with "Object Specific" macros used within user macros.  Other attributes work fine - at least in most cases.

[Joe_Carrick]

Maybe Chief's built-in macros (Global and Object):

• Are not Ruby macros at all but rather hard coded functions just returning text.
• That would explain why they don't work as we would expect.

[MarkMc]

Joe, look at Brian's explanation again -repeat from posted above

"The problem is related to how schedule macro is processed. In order to know the schedule number we first must build the schedule in the background. In your case the macro is executing before the schedule is built so the result is you get 0 returned from the macro every time."

So the only way to get it to work as is now would be if the macro execution could be delayed.

[Joe_Carrick]

Mark,

 

I'm not sure I buy Brian's explanation.  I've experimented with other "Object Specific" attributes/macros that work in TMM but not in a Schedule.  They generate errors in the Schedule when used within a user macro.  That leads me to believe the macro isn't referencing the actual object at that point at all.

 

[MarkMc]

I haven't found anything else that doesn't work yet-what have you found?

[Alaskan_Son]

21 minutes ago, Joe_Carrick said:

Mark,

 

I'm not sure I buy Brian's explanation.  I've experimented with other "Object Specific" attributes/macros that work in TMM but not in a Schedule.  They generate errors in the Schedule when used within a user macro.  That leads me to believe the macro isn't referencing the actual object at that point at all.

 

 

I think you’re doing something wrong because they work just fine for me.  I use them all the time.  I suspect you’re trying to place them as macros inside macros instead of simply using them properly as name:value pairs (object attributes).  

 

I tell it like this:  People have to look at Chief and Ruby as 2 entirely separate constructs/entities.  Whenever CHIEF sees two % signs enclosing some text, it will display any appropriate automated text.  If that text happens to match a user defined, evaluated text macro then Chief will defer to RUBY to run the code.  RUBY has no clue what anything between percentage signs means though.  Only Chief knows that.  When CHIEF “sees” the percentage signs on screen, Chief either fills it in per the defined macro, leaves it as dumb text, or defers to RUBY.  The only thing Ruby can and ever will do with the text wrapped in % signs is display it as a “%name%” string or error out.  

 

My favorite example is to write a custom evaluated macro with a value of “%layer%” into an object.  You should see the result is what you might expect...it reports the layer of the object.  Now modify the macro to “%layer%”.reverse and see what you get.  In both cases, RUBY is doing nothing more than placing the dumb text on the screen.  CHIEF is the one that replaces the text with something else when the resulting on screen text results in a defined macro (either internal or user defined).  

[Joe_Carrick]

Michael, I agree with you.

I was probably using the macro rather than the attribute.  But it's just really weird that the schedule number attributes don't work in the schedule unless you use them directly.  Placing them in a user macro in the OIP field and then adding that field to the schedule always returns zero.