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 9
(2,593 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 9
(2,579 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 9
(2,573 Views)

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

0 Kudos
Message 4 of 9
(2,559 Views)

Seems to me someone made a boo boo...

0 Kudos
Message 5 of 9
(2,485 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 9
(2,463 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 9
(2,460 Views)

@Niatross wrote:

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).


Is there a BUG number?

 

It's popped up again: Modifying more than one element from a map with the in-place element structure 

0 Kudos
Message 8 of 9
(2,343 Views)

I reported it to NI and they said that they were aware and it was in their queue. I wasn't given a bug number

Message 9 of 9
(2,330 Views)