Custom palette visible in default view

[Gérald]

Hello wireworkers !

I have a problem some of you may already have experienced...
I'm building my own Hardware and its associated driver and would like to make my palette visible in the "default" view so that my (potential) customers may start working with my HW right after running my installer, without having to mess with the "Edit>>palettes" menu.

So, let's review the potential solutions I have so far :

1/ Install my driver in "User.lib"
--> It's easy but that's not where users are used to look for drivers. Furthermore, I'd like my palette to be "directly" visible so that users can intuitively know where to look for the new stuff they just installed right after running my installer.

2/ Install my driver in "Instr.lib"
--> Once again, it's easy enough but I'm not shipping a Visa or GPIB driver and most users are expecting this kind of drivers to be installed in Instr.lib. Furthermore, NIDAQ is not installed in this directory...and I must admit this is the driver I'm competing with !

3/ Create a custom view and ask users to switch to this view using the "Edit>>palettes" menu. It's easy enough for a user already familiar with the LabVIEW basics mechanism but may be a little confusing for a new user.

4/ Install my driver in "vi.lib>>Addons"
--> This is the easiest way I found so far to make my own palette visible within the default menu but I have a philosophical problem here...Can I really consider my "driver" as a LabVIEW addon ? I don't have a definitive answer to this question...

I've been looking at the "menus" directory in the LabVIEW hierarchy and could notice that whenever you install a new NI driver, it will create a new directory that contains a "ReadOnly.txt" file as well as .mnu files.
I've made several attempts to make my own palette visible using a similar technique (be careful with names, copy the "readOnly.txt file, ...") but have not been successful so far, and I don't really want to use undocumented features in my released products.

Did anyone already run in a similar issue ? What is NI's point of view and recommendation on the subject ?
I'd like to encourage my customers to use LabVIEW...but I need to make sure I will benefit from the same "visibility" in this environment as any others NI's own brewed driver.

Does that make sense ?

Thanks a lot for your comments !

Gerald

[EdDickens]

Personally, I would use your Option 3. Create a palette the way you'd like it to look, and ship the .mnu files and install them them with the application. And I would keep your files in user.lib directory.

Then, in the LabVIEW.ini file, there is a key that specifies which palette to use. You can make a small utility that runs after installation to modify this key to load your palette. The key is "menuSetup=menuname". Just change the menuname to whatever you called your menu. Use the Config File VI to make the utility.

My second choice would be a toss up between the user.lib and instr.lib. Either would result in just about the same thing.

I would not put anything in the vi.lib directory. Although nothing that LabVIEW does "should" touch your directory because LabVIEW didn't install that particular one, I wouldn't take the chance. An update to LabVIEW or NI-DAQ could mess with it. I think NI even recommends not putting anything custom in the vi.lib.

The ReadOnly.txt files just prevent you from editing that menu in LabVIEW. If you delete that file, all that will happen is you will be able to edit that particular menu setup. So, you could include one of these to protect your menu.

Ed

Message Edited by Ed Dickens on 05-05-2005 11:17 AM

[Gérald]

Ed,

I didn't think about the LabVIEW.ini file...that was the information I missed and was not looking in the right direction !
Thanks a lot for the info, it's a great help.
Regards
Gerald