Schedule problem with macros in object OIP fields

[Joe_Carrick]

I kind of blundered into this situation.

 

Basically what it amounts to is that when OIP fields have values assigned by macros (owner context) the macros will report a value for that object.

However, if the custom field is used as a column in a Schedule - the macro uses the schedule as the owner and reports an incorrectly calculated value. This is quite simply because schedules don't have any OIP fields the macros can't return any valid data.

 

I've reported this bug to Chief Tech Support.  Hopefully they will be able to come up with a solution. but I'm sure it will require some modification of the schedules to make custom field columns to evaluate the data based on using the row object as the owner and that the value can be the result of any macro in that field

Edited Saturday at 08:47 PM by Joe_Carrick

[SHCanada2]

ive seen this as hit or miss. I have an OIP in the room that checks properties of the room and floor number, and then assigns the area to the OIP in the room based on some logic

 

These seem to work fine in a schedule.

 

But When I was trying to do something on a window label, it sometimes worked and sometimes didn't. One schedule would work, and then I would copy the schedule and it would not work. it looked like a race condition between the schedule and the window label

 

when you say "Calculate incorreclty" do you mean return error, or something else?

 

so it should be interesting to see what they come back with

 

for example in my room I have:

 

and that macro is:

 

and the schedule is

 

The above all works fine: schedule is one line, shown below:

Edited Saturday at 09:40 PM by SHCanada2

[Joe_Carrick]

3 minutes ago, SHCanada2 said:

when you say "Calculate incorrectly" do you mean return error, or something else?

Since i prevent all my macros from returning "Error" the incorrect result is something I provide as a default.  I do this by using the:

• begin
  • result = Code that could produce an error
• rescue
  • result  = default value
• end

to trap errors

[Joe_Carrick]

I've also been told that schedule columns are evaluated "Left to Right" so if a macro in column 2 relies on one in column 5 there could be a problem.  In that case it would be necessary to either switch the positions or incorporate the value of column 5 directly into the macro in column 2.

 

IAE, Chief will need to do some evaluation of how to make the Schedule get the values from the Row Object;  

 

Maybe the macro context could have "Schedule Row Object" 

[SHCanada2]

27 minutes ago, Joe_Carrick said:

Chief will need to do some evaluation of how to make the Schedule get the values from the Row Object; 

they do get the values from the row object, for at least for the scenario I have, as shown above. Perhaps this issue of non calculation is limited to the scenario where one macro is dependent on another field's macro being evaluated first, as you suggest

 

[SHCanada2]

55 minutes ago, Joe_Carrick said:

Since i prevent all my macros from returning "Error" the incorrect result is something I provide as a default. 

how does the user know if it is working? They would have to know the default value is the error condition. If the default result (as a result of an error) is then used in another calculation, the default(error) value is then obfuscated from the user.

 

For most cases I am fine with the CA error as it catches errors (as opposed to crashing), and it is very glaring that it is not working as it spits out ERROR. That then tells me I need to fix something. I suppose if one could deduce the error and output "bad length" then that would help, but I would perceive that as a error message vs a default value

 

I perceive error conditions as different that a default value. I perceive a default value as something that is normally used, and the user can change it it they want something different, but they are conscious of that decision

 

In the ideal world, the result would be able to produce both a value and a data quality...but that would be way to much work to implement, and the data quality would have to be baked in CA somehow with a different text color or inverse video or something to show the user that something is not quite right.

 

anywho my two cents, take it for what it is worth.

 

I'm probably just overthinking the term "default"...it is a late saturday afternoon

 

 

[Joe_Carrick]

Hi Jason,

 

In most cases my "rescue" performs an alternate set of code to provide the appropriate value.  Sometimes it's just a matter of looking for a different NVP because the suspected object didn't have the NVP I was expecting.  In other cases I present a message explaining what's wrong.  IOW, an intelligent error correction hint.  The last option is just a reasonable value - such as (0 or 1) when the error is "division by zero"

[SHCanada2]

that makes more sense than a simple default value.

 

the conversation reminds me of this software I used many years ago. it could only output a number. One day it spit out something like -125. After much  investigating and calling the software vendor, the software was supposed to spit out -999 when something went wrong,  but it did unit conversion after setting the value to -999, which resulted in the very odd -125.

 

...yes kids back in the day when software was so archaic and maybe trying to save on memory, error codes were represented as special numbers in the same field that was supposed to get you your result