We have a dev server running Ubuntu that I upgraded from 8.0.12 to 8.0.14 this afternoon.
After the upgrade I started seeing some odd behavior.
First thing is that we have an embedded view that essentially contains only an Icon component. The Icon is pointing to the materials IO image “material/notification_important”. It isn’t showing the Icon now. It worked before the upgrade. Other graphics from the materials library seem to work.
Second, we have “close” buttons on our popup. They are configured with an onActionPerformed event. The action is a Popup action configured to Close. This is no longer working.
Next, I’m seeing a lot of “ComponentModel” log messages that I had not seen prior to the upgrade. The associated message is “Flood limit tripped, starting 5000ms cooldown.” It’s complaining about an image component in my header. This component has the path to the image changed depending on the True/False state of a boolean tag. Both images referenced do exist. This is no longer changing the image based on the tag value. It was working before the upgrade.
These are just 3 stand out issues I’m seeing. I’m not confident in this upgrade at this point.
Are others seeing issues with this version?
Are there any known issues with .14?
Icons:
There was an unfortunate regression with regard to some icons in 8.0.14. It’s already been fixed in 8.0.15 and will be part of the stable release in the coming weeks.
Popups:
8.0.13 introduced a fix to the Popup actions. Before 8.0.13 if you specified a a Popup ID which did not exist, Perspective would find the most recently interacted with Popup and close it. In 8.0.13 and newer, if the specified Popup ID is not found, no action is taken. Please check your Popup buttons and verify they’re specifying the same Popup ID as the Popup was opened with. You have two options here:
Make the popup id match in both the open action and close action.
Supply an id which is an empty string. As of 8.0.13, if an empty string is supplied the previous behavior of closing the most recently-interacted-with Popup is invoked.
To be clear, this is not an issue with 8.0.13 or newer - it was a bug that many users built behavior on not knowing exactly what was happening. Popup actions were invoked, popups were closed, everybody was happy, but… for users who were using it correctly all along, popups would close when they shouldn’t and it made it impossible to structure their projects correctly.
Image:
I’m not familiar with this error and would need some more info to assist you here. Could I see a screenshot or stacktrace of the error you’re encountering? How exactly is the image set up/hosted? Could I see the binding?
What’s in the image I posted is all I’m seeing. It’s simply logging multiple times a second. If there’s a way to get more information on the logged message other than hovering over the magnifying glass icon, please let me know and I’ll post all information I can find.
How positive are you that the path you supplied actually resolves to something? How positive are you that the text supplied in those fields was properly applied?
Try this:
Copy the props.source value from the image you currently have.
Place a new image.
Paste the path.
Make sure you see the image you expect.
Now toggle the tag value.
Copy the props.source value AGAIN (don’t just paste again).
Paste this value into the new image and verify you see the image you expect.
The reason I’m asking this is because I didn’t see the error you are seeing until my path failed to resolve to an image. When that happens, it checks over and over again waiting for the file to be served. This check for the resource is continuously failing, which triggers the binding to re-evaluate which eventually triggers the flood warning; this is what you’re seeing.
Update: this was not actually the root cause, though it could still cause the same results.
Passing the device ID, that the popup is displaying data for, as the identifier for opening the popup, and then using it in the identifier for the close button does work. That’s going to be a little painful, but I can make it work. Thanks.
It was working fine BEFORE the upgrade, so if there is some change in the paths then I can only assume the upgrade broke something.
I’ll take the steps you’ve listed to see if they resolve anything.
It might also help if I could see the binding preview and Image.custom.path. As a last resort, try clicking into each of those value fields in the Map transform so that you can see your blinking cursor, and then press Enter. Try that for each of them, and then make sure to Apply your changes.
Okay, well, I have a workaround for now, because I can’t explain why it’s evaluating so often for you.
Instead of binding against the path of the Image and then using a tag() expression, just use a Tag Binding coupled with the Map Transform.
The moment I switched to this method my flood limit stopped tripping.
Clicking into the Map value fields and hitting enter fixed the display of the images. It not toggles back and forth between the two images if I toggle the associated tag. It is still giving me the log entries. I’ll try a direct tag binding.
Is "not" a typo and you meant "now"? Was it not switching back and forth at some point before? If it was not switching back and forth before, but you see it in the Designer now, do you have a Session open somewhere? Did you make sure to save? If you fixed the transform with my tip but didn't save, then open sessions would still be spamming your logs.
Yes, I have fat fingers! (really fat to hit “t” when I was trying to hit “w”!)
It was switching back and for BEFORE the upgrade, but not after.
I see it switching now in the designer and the client.
I did add a new image component and copied/pasted the image paths into that image and they worked fine.
BTW, it looks like using a direct tag binding worked to stop the log messages.
I will look at this more tomorrow.
Yes, it looks like something is causing that PropertyBinding->ExpressionTransform evaluation to evaluate FAR more often than it should. We’re looking into it.
Just FYI.
I did try using an Expression Transform on a Property binding. The property was the tag path that is a parameter of the view. The Transform Expression was simply "tag({value}). This caused the same errors in the log. Putting this back to a direct tag binding again caused the logging of that error to stop.
I neglected to update this thread, sorry. We opened an internal ticket yesterday because of the undesirable behavior of the chain of transforms you happened to be using. It shouldn’t be doing that, although that specific pattern was far more complicated than is necessary to do what you want.
Psssst! Mike! Don't use the tag() expression function!
While much of the history of my advice against using tag() comes from Vision, the key negative behaviors that suggest it should be avoided apply to Perspective, too. Even if this current bug is fixed.
(really fat to hit “t” when I was trying to hit “w”!)