Latest Update!

[altenbach]

---

@Qizhen wrote:
The map data actually should not expose to customers.  We will finally hide it from users.  So the label in it is meaningless.

---

Thanks for your reply.

Even if we don't see the exposed data structure, the labels should be carried correctly. For example if I wire a certain data type to "initialize" and later create an indicator at the "find" node, I expect the indicator to be labeled the same as the value type. If I delete the indicator again and change one of the labels in the data type, then again create a new indicator, it should reflect the changes.

[Qizhen]

---

altenbach :
Even if we don't see the exposed data structure, the labels should be carried correctly. For example if I wire a certain data type to "initialize" and later create an indicator at the "find" node, I expect the indicator to be labeled the same as the value type. If I delete the indicator again and change one of the labels in the data type, then again create a new indicator, it should reflect the changes.

---

Yes, you are right. 
In the next update, I will fix the labels in the map data.   But if this is too hard to be fixed, I will remove the labels. 

[jdunham]

---

@Qizhen wrote:

---

tchristm 写:
Is there a reason that you implemented your Map as a tree instead of a Hash Table?  I thought those had faster lookup than Tree-backed maps.

---

It is because that our Map container is for general purpose.  The data numbers in the Map is uncertain.  It's hard to select a suitable Hash Function for it.  When the data number is huge, collision always happens.  In this case, the Hash Table is not as efficient as the binary tree.
However, we could provide a Hash Map besides the binary tree Map, just like the C# language.  And let customer chose a suitable Map for his application.

---

Thanks for working on this, Qizhen.  Our application would greatly benefit from a good container implementation.  I would prefer a hash table as well, since we do lots of lookups every second.  Because good hash functions can be problem-specific, it would be neat to provide a VI template for the hash function and then allow the user to provide a strictly typed VI reference for a replacement hash function when initializing the map. If that input were unwired, then a default hash could be used.

I think the status boolean outputs are good.  I disagree with altenbach that they should have their sense reversed or else go away.  They are similar to the "found?" outputs of the configuration file VIs, or the timed out? outputs of the queue notifier VIs. If you get a TRUE output, then your following case structure processes the result, and the FALSE case is usually empty.  I think the error cluster should only be for badly-formed inputs or other structural runtime errors, though its obvious that many vi.lib routine authors don't always agree.

Just a cosmetic issue, can the icons be reduced to normal size? Seemingly there is some xnode-type of stuff going on, but it would still be better if the VIs were like normal LabVIEW.

We'd love to see a LabVIEW 8.5 version.    Also the lack of ability to build into an EXE is a problem, but since NI Labs code isn't licensed for release , the EXE problem is not a big deal yet. 

[Mao.Li]

Thank you all for your concern about LabVIEW Generic Container Map! Now it has some changes including:
1)  Support LabVIEW 8.5(and only support LabVIEW 8.5 or later).
2)  VIs using the LabVIEW Generic Container Map can be built into EXE now.
3)  Added context help for palette.
4)  Fixed the bug in the example "List All Items.vi".
5)  Fixed the mismatched labels in example "Create Address Book.vi".
6)  Renamed the output parameter "find" of  Find to "found?"
7)  Some updates in the User Manual.

Please re-download the LabVIEW Generic Container Map and have a try. Your feedback is highly appreciated!

[Qizhen]

---

Mao.Li 写:
Thank you all for your concern about LabVIEW Generic Container Map! Now it has some changes including:
1)  Support LabVIEW 8.5(and only support LabVIEW 8.5 or later).
2)  VIs using the LabVIEW Generic Container Map can be built into EXE now.
3)  Added context help for palette.
4)  Fixed the bug in the example "List All Items.vi".
5)  Fixed the mismatched labels in example "Create Address Book.vi".
6)  Renamed the output parameter "find" of  Find to "found?"
7)  Some updates in the User Manual.

Please re-download the LabVIEW Generic Container Map and have a try. Your feedback is highly appreciated!

---

The information on Labs web page hasn't been updated.  But this version only support LabVIEW 8.5.
Anyone needs the old LV 8.2 version can email me.

[NJKirchner]

Just a quick FYI. Stephen Mercer has created a pure G Map structure within LV 8.5 using LVOOP. Fully open for modification and for use within EXE. Not as pretty as the xnodes but very functional.

-Norm

[Qizhen]

Have anyone already used this in your products?

[tst]

---

Qizhen wrote:
Have anyone already used this in your products?

---

Why would anyone try something that is clearly an experiment in their product? Also, I'm not even sure if the terms of use allow it.

If you mean whether people tried to use it, I can say from experience that people usually don't have the time to really work with a feature unless they have to use it in an actual project.

Personally, I didn't even get to look at it, but I don't remember why not.

[Qizhen]

I just made a minor update on it to support LabVIEW 8.6

[jdunham]

The Erase element function is still going into an infinite loop (as reported here).  Are you planning to release a fix?