@mattfox

Thanks Matt :). Nice to see some familiar faces here!

@nachum37

I think the problem is that neither the re-activate nor the active-only-at-the-right-time behaviors are correct for all users in all cases. I guess they could consider providing the event raise / return behavior as an option on the schedule.

You can imagine there are other sorts of toggles that make no sense to happen outside of the exact time. For instance, if the scheduler was making a bell chime for the time of day, surely power loss leading to erroneous chiming is not desirable. Or, if it takes a snapshot of data, it may be more desirable to have a hole to manually fill than to have malformed data appearing to look good.

It's a tough problem to solve for all cases. You can always use a scripting data source to achieve arbitrary scheduling controls and handling of a power loss situation, but it'd take some programming and noodling.

Thanks Terry, that worked

@mattfox

Thanks Matt :). Nice to see some familiar faces here!

@nachum37

I think the problem is that neither the re-activate nor the active-only-at-the-right-time behaviors are correct for all users in all cases. I guess they could consider providing the event raise / return behavior as an option on the schedule.

You can imagine there are other sorts of toggles that make no sense to happen outside of the exact time. For instance, if the scheduler was making a bell chime for the time of day, surely power loss leading to erroneous chiming is not desirable. Or, if it takes a snapshot of data, it may be more desirable to have a hole to manually fill than to have malformed data appearing to look good.

It's a tough problem to solve for all cases. You can always use a scripting data source to achieve arbitrary scheduling controls and handling of a power loss situation, but it'd take some programming and noodling.

One way I kept state in my various scripting data sources was to JSON.stringify the persistent state into an alphanumeric point on the scripting data source. Then if

if ( typeof( state ) === 'undefined' )
  state = JSON.parse( state_context_point.value );

Of course, that would require doing this on any state change (or every script execution):

state_context_point.set( JSON.stringify( state ) );

But it gets the added benefit that now the state of your script is accessible to either review or fetch into other logic or dashboards or whatnot.

Perhaps you already have compiled templates on that instance, so they can populate the template field?

I see this error, using OpenJDK 11.0.8:

{"cause":null,"result":{"messages":[{"level":"ERROR","message":"???validate.requiredValue(i18n_en_US)???","property":"templateFiles"}]},"mangoStatusName":"VALIDATION_FAILED","mangoStatusCode":4002,"localizedMessage":"Validation failed"}

Hi Mango community, hope you're well!

I tried to create a data file data source in Mango 4.3 but I seem to not be able to add one without selecting a template. I need to compile templates to be able to select one, but I need to have a data source to be able to compile templates!

How does one create a new data file data source in a fresh 4.3 installation?