Any way to read an XControl icon from disk?

[Jim_Kring]

Any way to read an XControl icon (same one that shows up in the controls palette) from disk, without loading it into  memory?

Thanks!

[MikaelH]

Hi Jim

This is the way I did it in the past, before the normal API was provided.

I assume that the icon has a black frame and I do a string match of the file content.

Maybe not the best way, but it often works 🙂

//Mikael

[Jim_Kring]

Hey Mike,

Thanks for posting this.  Is the icon data for an XControl stored in the Facade VI?  Or, is it stored in the *.xctl file in the the "NI.Lib.Icon" property (<Property Name="NI.Lib.Icon" Type="Bin"></Property>)?

Thanks,

-Jim

[MikaelH]

In the xml file xctl, you only have the header that could be applied to all members.

But I'm not sure that the Facade VI icon is used in the palette or not, I'm just assuming that 🙂

//Mikael

[Jim_Kring]

I just did a test in LV2009 and it seems that the library icon is used for the palette.

Anyone know what is the encoding of the binary data in the NI.Lib.Icon XML property?

I created a VI (attached) that reads this data from the XCTL file, but I'm not sure of the encoding (after unescaping the XML escape codes).  It doesn't look like base64, hex, etc.

Thanks,

[MikaelH]

I'm quite sure it's a compressed binary data string.

First you have to replace the &gt; &lt; &amp; characters, then you have to figure out which compression type is used.

Maybe there is a Scripting Node for this.

//Mikael

[jgcode]

Hi Jim

The X Control Icon is the Library Icon in the palette, which is not that great, so please vote for my idea here (end shameless plug)

Here is a start.

Seems data is located in two spots.

I can construct the data from the file for the banner.

But there is some other unknown data.

The second tag is only created (I think) when the Library is opened in IE 2009.

(I had a case/issue/bug causing "corrupt data" with the IE API, so now I am thinking this was likely the reason)

Props to Vugie who initially help me with my query on LAVA

[AristosQueue (NI)]

That second tag is the layer data used by the new Icon Editor. When you edit an icon, you may have many layers of graphical information. That's only needed by the editor. All the layers are flattened out to produce the banner icon.

I'm very surprised that you're able to read the data for the icon... I tried helping Jim Kring with this last night by looking at the LV source code for where we save the library icon, and the string passes through a zip compression function before being written to the file. If your library is old enough, we don't do that -- I think that compression was added new in LV 2009, so if the library is from before then, you don't have the compression layer to deal with.

[jgcode]

Any chance of posting any of the compression code to read the first tag?

Also, given I was able to construct the banner from the last 3072 points, do you know what the first ~148 characters are in the NI_IconEditor tag?

[rolfk]

Since AristosQueue mentions ZIP compression, I would simply try it with the ZLIB Inflate function from the OpenG lvZIP package. There might be a good chance that the first 4 bytes in the stream are the actual size of the uncompressed string and need to be removed before passing to ZLIB Inflate and if you want to use that number to pass to ZLIB Inflate you would likely have to care about Endianess of that number, but I would not expect other sneaky additions to the data stream, as I doubt that the LabVIEW developers intended to make this data a big secret.