LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

IPE Map Get/Replace value extended - bug or feature

Bug, feature or me being dense

 

I want to the use an IPE to get/replace more than one element in a map.

 

I can extend the get/replace element node but all but the first one won't work.

 

There are two symptoms:

- The key data type defaults to the value data type (In my example the key of the get/replace node would be an I32). If I wire an I32 it give me a broken wire. If I wire a string instead it appears to be fine

- The extracted value node doesn't appear where I would expect and if I wire an indicator to it I get a broken wire (I have just worked out that this seems to be because the get node seems to want to accept a value, whilst the replace node wants to give a value)

 

Niatross_0-1620313921876.png

Niatross_1-1620313941364.png

I'm in LV 19.0.1f3

 

Any thoughts?

 

As an aside, is anyone else having problems with the map data type. I got really excited when it came out but I have had a few occasions where they don't seem to work, This is the first one I have been able to replicate on a small scale. A personal favourite was one where insert into map would cause re-entrant asynchronous VI's to just silently crash. Confirmed this with highlight execution and have since fixed it by returning to variant attribute based maps

 

Message 1 of 7
(239 Views)

It did change in LV20, but not for the better per se:

 

Map IPE.PNG

I can't even wire a key to the 2nd element.

 

EDIT: Turns out I can. But it's tricky. Wiring it to a string doesn't work. But I can create a constant. A numeric will be created with a broken wire. If I then replace the numeric with a string, the wire isn't broken anymore.

 

Real question is: is it a known bug?

 


@Niatross wrote:

As an aside, is anyone else having problems with the map data type.


They seem quite slow to copy.

 

So if you have a class that contains a map with data, copying the class (a lot) drags down your execution speed.

 

This might be unfair, it might be that the data is simply so much, the slow copy is justified.

 

I didn't compare this with variant attributes (or an array with LUT) either.

 

For now, I put it in a DRV (which I hate to do).

0 Kudos
Message 2 of 7
(225 Views)

Turns out you can wire the 2nd value.

 

Don't get your hopes up...

Spoiler
Map IPE 2.PNG
0 Kudos
Message 3 of 7
(219 Views)

Yeah, and you can wire a indicator to the replace value node...

0 Kudos
Message 4 of 7
(205 Views)

Seems to me someone made a boo boo...

0 Kudos
Message 5 of 7
(131 Views)

Yep, I have submitted a bug report. I was just surprised that this wasn't/hasn't been picked up (I can't find an open bug report for it).

 

I just wondered whether I was missing something obvious

 

A ctrl+F on the known issues page for 2019 doesn't show any bugs for 'map' which I struggle to believe though.

Message 6 of 7
(109 Views)

You'd only see this if you 

1) need a map;

2) actually use a map for it;

3) need to read, modify and write the key;

4) for 2 or more keys;

5) recognize it as a bug;

6) take time to post it.

 

1) filters out beginners

2) filters out map-users that have legacy code and don't want to refactor (yet)

3) and 4) are  bottlenecks, you won't need that that often.

5) doesn't filter at all, it's pretty obvious

6) might have filtered our everyone but you 😁

 

So, good catch!

Message 7 of 7
(106 Views)