We have found an issue with utilizing titled border type for dropdown list boxes. Our application uses a dark theme/background. When we port our app over to 8.1.x the DDLB that are of titleBorder seem to lose their dropdown arrow (it’s there, but barely visible).
To rectify the problem and to have an arrow that is feasible for factory workers to use we opted to use the default dropdown box border style (OtherBorder). However, since we have a ton of dropdown boxes that share this titleBorder style and have various types of scripting and expressions hanging off these components, we cannot just simply recreate them. We need to change the border and the colors.
To do this we opted for a programmatic solution that would take a default dropdown box (unaltered) and copy its border property to the existing window component.
Everything works just fine in 7.9.
When we port to 8.1.x we cannot open the window in the Designer or at Execution time nor can we change the template that has that control with this dropdown used as the “master”. Anywhere that template was placed at time of porting (export/import) it shows as invalid.
Yes, I know ignition does not support importing of 7.9 projects to 8.1.x, but did not want to have to reload the entire gateway to test a change.
Error when trying to open window in 8.1:
SerializationException: Unexpected parsing error during binary deserialization.
caused by IOExceptionWithCause: java.lang.ClassNotFoundException: com.incors.plaf.alloy.cz
caused by ClassNotFoundException: com.incors.plaf.alloy.cz
IA changed the "Look and Feel" java implementation, and this class doesn't exist beyond v7.9. (The old look-and-feel wasn't available in newer java, IIRC.)
If you haven't done this sort of hacking, v7.9 projects should import in v8.x, though you probably want to use full gateway backups to get full conversion effects. (It is going backwards that isn't supported.)
Blockquote In general, it's not safe to assume Ignition is "forwards compatible", meaning you should not import anything from a newer version into an older version.
What's funny is that in small tests where we create a ddlb (default OtherBorder) in 7.9. Then export that to 8.1. There isn't an issue. It's only if we programmatically "copy" a border from an existing unaltered DDLB for which the problem arises.
You're going to have to change your process on the 7.9 side to no longer use these classes, because as Phil noted, they're no longer there in 8.X, and Vision relies on explicit class hierarchies to construct components & windows.
You could add a custom module that loads the classes required into Vision, but that's a big task. Much simpler would be to shift + right click the window in the 7.9 designer and use the 'Copy XML to Clipboard' action. Compare how the borders that work vs the ones that don't work are represented. Change your scripting such that there's no difference between the two.
Wanted to let you know that we solved the issue of the invalid otherBorder on the DDLB. We took the border of another control where the border (javax.swing type) was com.incors.plaf.alloy.cu and replaced the dropdown listbox border when it was com.incors.plaf.alloy.cz with the com.incors.plaf.alloy.cu version.
newBorder is of type 'com.incors.plaf.ally.cu':
if type(myComponent.border) == 'com.incors.plaf.alloy.cz':
myComponent.border = newBorder
This allowed us to migrate the dropdown listbox from 7.9 to 8.1 w/o incident.