Ok, I think I'm going crazy because I cannot get a template propertyChange on the root container (the template itself) to fire at all.
I've got an existing template I'm trying to modify and have it initialize some parameters using the 'componentRunning' propertyChange event.
I have dumbed it down all the way to just this single line in the propertyChange event on the template (internally inside the template):
print 'Hello Property'
and nothing prints on the console at all when using this template in the designer.
I previously tried
print event.propertyName
but it didn't work so I simplified it down to just a static string.
For those interested, what I'm trying to do (the end goal) is build a tag path inside the template using a "BasePath" property on my main window and the "instanceName" property of the template when it's dropped on the screen. This way once the instance is named properly, all internal tags/bindings indirectly map to the correct tag based on this BasePath. (I'm hoping I can get some level of event.source.parent.parent... to link up to the Window parameter for the BasePath. If anyone has a better way of solving this, I'm open to suggestions, or if it's not even possible, I'll quit chasing it.
Yeah, I tried that too. In fact, it was the first thing I tried. When that didn't work, I tried print hoping maybe that would work better. I feel like I'm losing my mind here. LOL
I've even done saves, and closing and re-launching the designer. Next I'm going to upgrade from 8.1.44 to 8.1.45, but I'm not expecting that to fix it.
If that doesn't work, I'll reach out to support.
Edit: Actually, I'm going to create a new, blank template with just a label embedded and see if it works and there's something else in my existing template that could be causing an issue. The only other script at the template level is an mouseClicked to open a faceplate, so I wouldn't think it would affect it.
Edit 2: Ok, blank template didn't work either. I'll test the upgrade next week. I'm calling it for the day.
I went in and out of preview mode. The propertyChange event on a text component fired, but not the one on the template. I did not test by launching a client though.
Ahh, I'll give this a shot when I get into the office. I had the window already open and was going in/out of preview mode assuming that would trigger it.
That was it. Although my original hope was for this to work in designer mode without having to put it in preview mode prior to opening the window, so I don't think my original plan will work (or at least be more cumbersome than it's worth).
If that's all you need, add a boolean custom property to the template, and use the following expression bining:
// # True when preview mode is activated or when the client is launched
{[System]Client/System/SystemFlags} > 2
It will change the property from false to true anytime preview mode is selected or anytime the project is opened by the client. I use this on the visibility property of my overlays, so they stay hidden and out of the way when I'm editing a window.
What I was going to try to do was on dropping/renaming a template, that it would notice the property change of its name and in turn, look at a custom property on the window with a pre-defined base path of where all the tags on that screen point to. This would attempt to enforce a good naming convention of templates on the screen.
For example, if I drop a valve template on a screen with a custom BasePath parameter of "Plant/Cryo/Dehy", and name the template "XV_1234" it would pick up the tag path automatically of "Plant/Cryo/Dehy/XV_1234" rather than me passing in the tag path as a parameter. Helps with documentation (cause I've opened screens with dozens of valve templates all sequentially numbered.) It doesn't hurt anything, but I just like to keep good names on everything.