Label binding not updating on other clients

I’m having trouble with a label that has it’s text property bound to a popup calendar component. The binding is pointing to the Formatted Date property of the calendar. The calendar component itself is pointing to a system (not client) memory tag. I also have the visible properties of both components bound to a 2-state toggle button. The button toggles between the calendar component being visible and the label being visible. It’s an ugly hack that I’m trying to use to work around the calendar component disable bug.

The problem I am having is that on other clients, the label isn’t being updated properly. On 1 client, the user changes the date/time in the calendar popup. The calendar popup component on other clients correctly changes to the newly selected date/time. When the user ‘locks in’ his selection by toggling the 2-state button, other clients that are watching the screen see the proper date, but a freshly launched client will not see the proper date. The label contains a bogus date. I’m not sure where it is coming from, maybe a default date of the label or calendar popup. The label continues to show the incorrect date until the user toggles to the calendar popup, changes the date/time, and toggles back to the label. Simply toggling to the popup and back to the label is not enough.

Is there any way to force the label to refresh on a window load? I would have assumed that this would have been taken care of by ignition itself, but it isn’t working how I would expect.

Quick recap: popup calendar bound to system memory tag is working properly (all clients in agreement). Label with text property bound to the Formatted Date property of the popup calendar is not working correctly. Clients have to be running and ‘watching’ the change take place to get the proper date sent to the label. Clients that are launched will report some sort of default date/time in the label component.

Consider having the label format the date itself using the dateFormat() expression function and the memory tag itself. That should bypass the funky propertyChange issue on the calendar. It does sound like a separate bug, though.

Looks like that will work, Phil. Thanks for the assist!