I’ve encountered a systemic issue where switching between views or even tabbed containers (which I guess are actually views) creates a flash of un-styled content. I have a few views with rows and rows of buttons and the whole thing jumps and jiggles every time you swap tabs even though that style should be loaded and not be a problem. It’s not just a styling issue either, the page renders before all of my tag data is loaded too causing a bunch of jumping around as well. This is especially pronounced with flex repeaters. I tried playing with the loading parameter (loading > order: with-parent/after-parent) with no difference. I saw a previous post mentioning this, but it doesn’t seem to have been addressed. Are other folks just living with this, or am I constructing my views weird, no checking some box pertaining to “waiting” until some thing like “all resources are loaded” before rendering. Caching?
Do your jumpy styles/data depend on the evaluation of a binding ?
Yes, these are buttons where the color denotes status. They flash to the default “theme” styling before flashing to the updated styles. These elements are styled using the wysiwyg “styles” in the designer, not in a theme. I’ve created a custom theme but didn’t move these elements to that theme because I thought this would be easier for a layman to edit.
What Ignition version is this?
8.1.7 (b2021060314) I played around with history enabled/not to see if that made a difference with the missing tag data “flash” but it doesn’t
Can you post a screenshot of what you mean by this property configuration?
I would expect the configuration on initial page load to be whatever you had saved in the designer, then a few moments later for the binding to evaluate and bring in whatever new styling it had.
@PGriffith sure. Here is the way that I configured these buttons. I’ve been using a “template” view and having that repeat with a flex repeater with the parameters exposed for styling and content. They use the tag to determine the style (on/off) but even if the tag reported an error or wasn’t updating, I’m not seeing the “fallback” style (off), just the unstyled/default theme style. Even then, the style from the default theme is broken with weird heights before it snaps into place. The “flash” is best seen in a video - I’m just changing tabs. If you go frame by frame you see that the elements change height, style, the works.
The digital display has the same sort of thing going on where it displays “VALUE” for about half a second before updating to the tag value. No expression is being evaluated here, it’s just a tag value being pushed through the exposed params in the flex repeater.
Final edit, these are all one-shot buttons.
Here’s a simple thing to try - what if you right click the style.classes node and set ‘Persistent’ to true?
That will save the config that’s in the designer onto the window, so there should never be a ‘flash’ of unstyled content (you’ll just see the value in the designer before the binding evaluates to update)
Thanks, that solves the issued of un-styled content but now the buttons cycle through the different “states” as the value of the tag is evaluated, creating a moment of an “all green” board before flashing to the correct values of the buttons. Similarly, the analog display pops up with the right styling now but with no values creating a moment of blank fields for both the display value and the labels. These are just straight tags with nothing being evaluated or waited on. It creates a distracting jump between screens and looks “bad”.
So, unfortunately, for now that’s basically all you can do; you could try creating a different ‘indeterminate’ style class and setting that in the designer, but there’s no way to expose whether all the bindings have completed to the session.
The good news is that we’re actually already in the process of some internal improvements around the way bindings evaluate, with the end goal being to eliminate these partial, spurious evaluations. No actual timeline, but in the best case scenario those changes could land as soon as 8.1.9.
Ok, thanks for that info. I have to say, developing in perspective, especially coming from a mix of “old school” WYSIWYG HMI and hand coded front end work, lends a feeling that perspective is pretty much in Beta.
I honestly have a real fear that I’m “doing it wrong” and that I’ll have to re-do the work later. Honestly this might make it a harder sell to clients. I appreciate that there is a timeline but similar HTML 5/JS HMI’s don’t have these problems (mango automation comes to mind). I’m developing this system in Ignition specifically because should be well supported and that the work done is “standard” and repeatable.