Public Folder for Icon Templates in new Icon Editor

[jgcode]

I would like a public folder to be used as the default storage for the Icon Editor

OR

At least a public folder it looks to as well as <osdatadir>:\Icon Templates.

The reason for this is I would like to install icon templates as packages using VIPM/OGPB.

The current user-specific location of <osdatadir>:\Icon Templates does not suit this framework for managing packages.

[AristosQueue (NI)]

There is an update for the LV 2009 icon editor (posted Sept 14, 2009) available here:

http://decibel.ni.com/content/docs/DOC-6301

This update incorporates many suggestions that we got right off the bat from users and fixes a number of reported bugs.

An entire discussion forum exists for discussions about improving/extending the Icon Editor. It can be found here:

http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

[jgcode]

Thanks for posting AQ. You can see from the history of the discussion forum that I was one of the first to post, and after discussing the above with NI (Th Sa), LAVA and JKI,  I decided to make this a request on the Idea Exchange forum. I also have the upgrade, as I also posted about this problem as well.

I was able to create a successful workaround and made a OGPB package that installs the icons via install scripts, as the default directory is not supported in VIPM nor OGPB.

It would still be cool (and easier) if there was a public folder that was not User/OS dependent - maybe under the LabVIEW directory structure??

Just so I could better manage the icons. 

Cheers!!

JG 

[MichaelAivaliotis]

Not sure what you mean by public folder. <osdatadir> is public.

[jgcode]

Hi Michael, thanks for posting!

To clarify, I mean that <osdatadir> is user dependent, meaning when it gets resolved it is set to that current user and not some common folder.

Sorry for the confusion, maybe common is a better term than public when discussing folders???

I am talking of common/public folder e.g. <application> or <vi.lib> whereby any user logged in is accessing the same folder. 

Anyways, this makes distributing packages tricky (altho I have the workaround):

a) As the location will be different on each PC

b) <osdatadir> is not supported by OGPB/VIPM

I hope this makes sense

Cheers!!

JG