Possible Bug with LabVIEW Icon API

[FireFist-Redhawk]

When saving my icons using the LabVIEW Icon API, the template layer opacity gets set to 0 and and the visibility gets set to FALSE if there is no template layer. Maybe this is kind of nitpicky since there isn't a template layer anyway, but it's something that changes without me having made the change myself. I think it's fairly easily fixable though.

I believe the case structure in this SubVI should be changed just a bit to allow the template opacity and visibility Boolean to get bundled in.:

My expectation would be that even if my opacity is at 50% and I have no template layer, it is still at 50% after I save.

So there's that. But the reason for me starting this discussion is that with the release of the new open-source icon editor, there is another bug that I believe is related. If the user launches the icon editor using the Launch Icon Editor.vi API VI, and then clicks Cancel without making any changes at all, the new confirmation dialog still gets displayed.

Attached is a project to reproduce the two issues above. Step to reproduce are in the two "Test" VIs.

Interestingly, when Get VI Icon.vi is called on Blank VI.vi, an error occurs inside the password-protected SubVI, causing the following VI to insert default values for the template parameters, which are 100 for opacity and TRUE for visibility.

When Get VI Icon.vi is called on Template Removed.vi, a blank VI where a template layer was added and then removed, the opacity and visibility are again at 0 and FALSE respectively.

As I'm finishing up making this demo project, I'm realizing that the confirmation dialog issue may have more to do with text layers. If you run Confirmation Dialog Test.vi with Blank Library VI No Text.vi, you don't get the confirmation dialog.

[FireFist-Redhawk]

Icon Editor API Test.zip

[crossrulz]

There are a few problems reported here, so I will have to break up my comments. But an oversimplified summary (correct me as needed):

1. Template Layer Visibility and Opacity are set to FALSE and 0% when there is no template in the icon. These should default to whatever the icon already had.
2. If there is icon text, the cancel confirmation dialog comes up even when no changes were done when the editor is launched through Launch Icon Editor.vi
3. Read Icon Data From VI.vi is throwing an error with Blank.vi.

[crossrulz]

In regards to problem 2, I am not seeing this with the current development version. I am certain it is related to the undo/redo stack I refactored in April/May timeframe (#525). This fix should be in the next release.

[crossrulz]

For problem 3, I suspect the default icon is not saved in the VI. As this is dealing with the binary data of the VI and it is a password protect VI, we will need input from NI to confirm the problem.
@gregr-ni

[crossrulz]

For problem 1, I fully agree. A simple addition of a Bundle By Name in the True case would solve the problem. I would likely lean towards doing the BBN before the case structure to avoid some duplicated code.

[crossrulz]

Issue #539 has been created.

[FireFist-Redhawk]

Yes, well summarized. Good to hear about (2). I wasn't necessarily pointing out (3) as an issue, I was mainly just noting the reason (1) wasn't happening in the case of a blank VI. From the code, it looks like (3) may be by design.

[navep-NI]

@crossrulz
For (3), I checked the LabVIEW source and it looks like an issue from LabVIEW side, where the default images are returned empty and we don't handle that properly.
I think here the behavior should be that it should return the default image data. If that's the case it will be a minor fix.
FYI: @gregr-ni

[gregr-ni]

A bit late but I was on vacation. I can confirm that "Read Icon Data from VI.vi" reads the data as variant then passes that variant to "Extract Data.vi". Since the icon editor is the only thing that creates that variant and stores it in the VI, any VI that has never been had its icon edited will not have that variant.

I think that behavior makes sense. It should be up to the caller of "Read Icon Data from VI.vi" to decide what to do when that variant doesn't exist.

[FireFist-Redhawk]

Here is something else I have found: in Create Icon Layer.vi, the Relative Path from 1 to 2 isn't used to make the path to the template to be bundled into the template's class data; but in Get Data from Icon Class.vi, that class data element is needed to re-form Relative Path from 1 to 2. Effectively it means the path to the template gets lost when using the Icon API.

[crossrulz]

You are edging on one of the reasons I really want to refactor the API: a lot of things are poorly named.

I don't think the Create Icon Layer is actually creating a layer. It is used in the IE initialization and appears to only be to initialize the Icon class. I will have to flag this to possibly move into the Icon.lvclass.

I also need to find time to dig into what that "Relative Path form 1 to 2" is actually used for. It is likely just for the template path, but I need to make sure. Again, it is poorly named and its purpose is not obvious.

[FireFist-Redhawk]

From what I can tell, Relative path from 1 to 2 is used to (A) set the icon template layer name, and (B) determine whether or not that template file already exists on disk, to create it if it is not there. Sound familiar?

[crossrulz]

Yes, that is what I remember it being used for, I am just stating that I need to dig to make sure it is not used for some other reason. This is something we will want to clean up when we are able to get into the API refactoring effort.