Duplicate OpenG palette object names

[Darren]

I've been making a pass through all the LabVIEW palette content on my system, looking for duplicate names between palette objects. Since Quick Drop will only list a single object of a given name, I think it makes sense that all unique palette objects should have unique names. I have come across three OpenG VIs that have identical names to built-in LabVIEW functions (and thus, cannot currently be dropped with Quick Drop):

 

Empty Array? - user.lib_OpenG.libarrayarray.llbEmpty Array__ogtk.vi

Build Path - user.lib_OpenG.libfilefile.llbBuild Path__ogtk.vi

Strip Path - user.lib_OpenG.libfilefile.llbStrip Path__ogtk.vi

 

Currently, these VIs use window titles to define their palette entry names. Would it be possible to update the window titles of these VIs to have different names than the core LabVIEW functions, thereby allowing these three OpenG items to be droppable from Quick Drop?

[Michael Aivaliotis]

Seems like a deficiency in Quick Drop

[Darren]

Quick Drop will list multiple identically-named objects if they are namespaced differently. So one possible solution would be for OpenG to include all of their palette VIs in a library...this would cause both "Build Path" and "OpenG.lvlib:Build Path" to appear in Quick Drop as separate objects.

 

Assuming OpenG does not want to start including palette objects in libraries, I thought the renaming option was a simpler and more viable solution.

[crossrulz]

Darren, you missed the Wait (ms), Tick Count (ms), and Wait Until Next ms Multiple (all from the timing palette).

 

Personally, I think putting OpenG into libraries is a good idea.

[hooovahh]

The other alternative I noticed (thanks Darren for looking into this by the way) is to change the OpenG VI Window Title name to be "Wait (ms) OpenG".  It appears Quick Drop will find the VI name, but use the Window Title as the text to find it if one exists.  This is why "Wait (ms)" for OpenG comes up, but the primitive "Wait (ms)" (with no .vi file extension because it is a primitive)

[crossrulz]

This is why "Wait (ms)" for OpenG comes up, but the primitive "Wait (ms)" (with no .vi file extension because it is a primitive)

I think you mean Wait (ms) for OpenG DOES NOT come up, but the primitive Wait (ms) DOES.

 

Here's the conversation on the dark side that caused Darren to look into this:http://forums.ni.com/t5/LabVIEW/Duplicate-Quick-Drop-Item-Names/m-p/2521400#M766275

[Jim Kring]

Hello everyone!

 

In terms of moving OpenG VIs into libraries (LVLIBs), it could have a lot of benefits.  I wonder what the possible implications and down-sides are:

 

- How can we get existing code to link to the new LVLIB'ed versions of the libraries?

- Will it create any problems for users? Will it cause EXE builds to be larger?

 

In terms of a work-around, adding "(OpenG)" as a suffix to VIs that have the same Palette Name as NI's sounds like it could also be a good idea. Again, I wonder what the possible implications and down-sides are:

 

- Will seeing "(OpenG)" when the user hovers over it in the palettes cause confusion or look bad if none of the other OpenG VIs have "(OpenG)" in their name?

 

Anyone see other considerations or have input on those I've mentioned?

Quick Drop will list multiple identically-named objects if they are namespaced differently. So one possible solution would be for OpenG to include all of their palette VIs in a library...this would cause both "Build Path" and "OpenG.lvlib:Build Path" to appear in Quick Drop as separate objects.

 

Assuming OpenG does not want to start including palette objects in libraries, I thought the renaming option was a simpler and more viable solution.

 

How would it appear in Quick Drop? Would the user be able to visibly distinguish between the OpenG Build Path and the built-in Build Path?  For example, would (or could?) Quick Drop show "OpenG.lvlib:Build Path" or maybe "Build Path (OpenG.lvlib)" / "Build Path (OpenG)".

[Darren]

How would it appear in Quick Drop? Would the user be able to visibly distinguish between the OpenG Build Path and the built-in Build Path?  For example, would (or could?) Quick Drop show "OpenG.lvlib:Build Path" or maybe "Build Path (OpenG.lvlib)" / "Build Path (OpenG)".

 

Palette VIs that are namespaced with libraries (or classes) appear with the library name in brackets, like so:

 

[Jim Kring]

Would it create any problems (for Quick Drop) to use brackets in the VIs window title so that it looks a little more like what Quick Drop adds to LVLIB members?

For example:

"Build Path [OpenG]"

[Darren]

Would it create any problems (for Quick Drop) to use brackets in the VIs window title so that it looks a little more like what Quick Drop adds to LVLIB members?

 

Unfortunately, brackets in palette object names are treated special by Quick Drop, so suffixing with "[OpenG]" would not work. Any other delimeters (parentheses, braces, etc.) should work fine, though. I think I'd prefer if we kept brackets as a library name designation, so if you did suffix the OpenG object names, I'd prefer it be with parentheses.

[Jim Kring]

Unfortunately, brackets in palette object names are treated special by Quick Drop, so suffixing with "[OpenG]" would not work. Any other delimeters (parentheses, braces, etc.) should work fine, though. I think I'd prefer if we kept brackets as a library name designation, so if you did suffix the OpenG object names, I'd prefer it be with parentheses.

 

Would you consider this a Quick Drop bug (that brackets in a VI Window Title would cause a failure of QD)? Might want to generate a Hash of the name and use it as the UID/reference for each item that appears in the list, rather than reference by name.

[Michael Aivaliotis]

This is not just an OpenG problem. This is a general issue with anyone creating and packaging reuse libraries. I think putting OpenG items in libraries is the best approach and is also the one recommended on the palette guidelines doc here:

 

https://decibel.ni.com/content/docs/DOC-29567

[Darren]

Would you consider this a Quick Drop bug (that brackets in a VI Window Title would cause a failure of QD)? Might want to generate a Hash of the name and use it as the UID/reference for each item that appears in the list, rather than reference by name.

 

I suppose you could consider it a "bug", although this is the first time in Quick Drop's six-year history that I've heard of somebody wanting to include a bracketed suffix in a palette object name and have it *not* refer to the owning library.

 

Speaking of libraries, I just confirmed with Stephen that, if you namespace an existing VI with a library, but leave the VI's location and name on disk unchanged, then existing code that links to that VI should automatically relink to the newly-namespaced VI without issue. We've used this trick at NI on several occasions when adding library namespacing to existing APIs...I see no reason why it wouldn't work for the OpenG libraries as well.

 

So again, the very low-budget solution to this issue would be to figure out the OpenG palette objects that share names with core LabVIEW functions (it looks like there are about 6 of them from the discussion above) and add an "(OpenG)" suffix to their window titles. The more elegant solution would probably be to add libraries to namespace the OpenG VIs.

 

And looking forward, I've never particularly liked palette VIs that have different palette names than their VI filenames (the exception being Merge VIs). Hindsight is 20/20, but I probably would have just named these VIs something like "Build Path (OpenG).vi", with no custom window title/palette object name, from the start.

[Darren]

I discovered another reason, independent of Quick Drop, that these duplicate palette name issues should be fixed. When you right-click on a subVI, you don't get taken to the correct owning palette for identically named items. Right-clicking on an OpenG File VI should show the OpenG File palette, like this:

 

 

When doing this on the "Build Path" OpenG VI, it shows the File I/O palette instead:

 

[Jim Kring]

Speaking of libraries, I just confirmed with Stephen that, if you namespace an existing VI with a library, but leave the VI's location and name on disk unchanged, then existing code that links to that VI should automatically relink to the newly-namespaced VI without issue. We've used this trick at NI on several occasions when adding library namespacing to existing APIs...I see no reason why it wouldn't work for the OpenG libraries as well.

 

That's great! I didn't know about that (or learned about it so long ago I forgot about it)!  That eliminates one of the biggest technical hurdles around moving OpenG into LVLIBs. Now it just takes elbow grease

 

So again, the very low-budget solution to this issue would be to figure out the OpenG palette objects that share names with core LabVIEW functions (it looks like there are about 6 of them from the discussion above) and add an "(OpenG)" suffix to their window titles. The more elegant solution would probably be to add libraries to namespace the OpenG VIs.

 

Yeah, might do an incremental fix of adding the "(OpenG)" suffix, as a stopgap.

 

I discovered another reason, independent of Quick Drop, that these duplicate palette name issues should be fixed. When you right-click on a subVI, you don't get taken to the correct owning palette for identically named items. Right-clicking on an OpenG File VI should show the OpenG File palette, like this:

 

openggood.png

 

When doing this on the "Build Path" OpenG VI, it shows the File I/O palette instead:

 

opengbad.png

 

That's a great point, too! And, you just might have (arguably) found another LabVIEW bug ;p

 

Cheers,

[Aristos Queue]

That's a great point, too! And, you just might have (arguably) found another LabVIEW bug ;p

It's not a bug. The palettes do not have anything other than names to use as lookup keys. When I designed the shorttcut palettes, I didn't extend this out because supporting multiple items of the same name leads to severe confusion when telling people to drop something from the palettes. Rather than build a bunch of infastructure to try to resolve multiple names, I figured it was better to encourage developers to name things uniquely. And at the time I did it (LV 7.0), libraries were on the horizon to solve any namespacing issues.

[Jim Kring]

It's not a bug. The palettes do not have anything other than names to use as lookup keys. When I designed the shorttcut palettes, I didn't extend this out because supporting multiple items of the same name leads to severe confusion when telling people to drop something from the palettes. Rather than build a bunch of infastructure to try to resolve multiple names, I figured it was better to encourage developers to name things uniquely. And at the time I did it (LV 7.0), libraries were on the horizon to solve any namespacing issues.

 

Makes sense to me

[hooovahh]

Wow this thread is full of win.  So much useful information.  When I right click and do a replace I had no idea why some time it would give a useful category and some times it wouldn't.  I had no idea what methods it used to try to get the palette it came from.

[Jim Kring]

Hey Everyone,

I've rebuilt the OpenG File library (v4.0.1.22) with a fix for this -- I've added the "(OpenG)" suffix to the Window Title and palette names.

 

vipm://oglib_file?repo_url=http://www.jkisoft.com/packages

 

Please take a look and let me know if this works well. If so, I'll make the fix for the OpenG Array and Time libraries, too.

[Jim Kring]

I was on a roll and fixed/released the new OpenG Time and Array libraries too, so this issue should be resolved for now.

 

Please let me know if there are any issues once you upgrade to the new versions.

[Darren]

I just updated my OpenG libraries in LabVIEW 2013 and everything looks good. For posterity, the new palette object names I observed were:

 

OpenG Array Palette

Empty Array? (OpenG)

 

OpenG File Palette

Build Path (OpenG)

Strip Path (OpenG)

 

OpenG Time Palette

Tick Count (ms) (OpenG)

Wait (ms) (OpenG)

Wait Until Next ms Multiple (OpenG)

 

With Jim's changes, all 6 of these OpenG VIs are now droppable with Quick Drop, and they display the proper owning palette when you right-click them.

 

Thanks for implementing the fix, Jim!

[hooovahh]

Awesome now my prayers are answered.  Next step will be to update my Right Hand Quick Drop Shortcuts to use the OpenG functions that I couldn't before.

[Jim Kring]

Sweet! I'm glad this is working for everyone :-)

It was quite fun to dust off my developer hat too. And I got to use VIPM 2013 which made changing the pallet names of breeze--thanks for that, Michael Aivaliotis!