LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Style Challenge - Error Wires

I'll play too

hunter_jki_0-1691599834993.png

 

Message 11 of 147
(1,490 Views)

_Henry_0-1691600347634.png

 

Message 12 of 147
(1,483 Views)

stlye-challenge-error-handling_BD.png

I assumed the Queue and Event were independent processes and should be generated even if one fails.  I also assumed that this doesn't need to scale up with more parameters, but that seems like a place for improvement with a for loop.

Message 13 of 147
(1,470 Views)

And here is mine. 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 14 of 147
(1,465 Views)

Hooovahh,   did you right-click the merge errors and report all?  I think there is another glyph that would be visible if you did.  I could be wrong. 

 

But, I definitely advise adopting this new feature and would be disappointed if it was overlooked at GDevCon. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 15 of 147
(1,453 Views)

Here's what I might do:

 

altenbach_0-1691604920773.png

 

Of course we don't really have all requirements, for example should an error be generated if an item is not found or should it just ignore missing values??

 

0 Kudos
Message 16 of 147
(1,406 Views)

I may make a submission later, but I see that a couple of the existing submissions have used an Error Ring.

 

The error ring is great in theory but in practice it is an Xnode, which are now recommended that you not use per Darren in his presentation "Ludicrous ways to fix broken LabVIEW code", here:

https://youtu.be/HKcEYkksW_o?t=602

 

The short version if you don't watch the whole thing is that Xnodes may work well in isolation but can and will cause incredible headaches when they start being used in classes, PPLs, and malleable VIs, but the cause will often be nearly impossible to trace back to your use of an Xnode.

Message 17 of 147
(1,394 Views)

@JÞB wrote:

Hooovahh,   did you right-click the merge errors and report all?  I think there is another glyph that would be visible if you did.  I could be wrong. 

 

But, I definitely advise adopting this new feature and would be disappointed if it was overlooked at GDevCon. 


It does not have merge errors.  I thought about it but I thought in cases you might get the same error reported twice due to the wiring.  But it probably is important for the User Event, and Queue to have unique errors tracked.  In practice it doesn't really matter because even one missing reference is bad and needs to be fixed, knowing you have two might not help debug it much.  But yeah what harm is it to just have it on?  Not much.

0 Kudos
Message 18 of 147
(1,376 Views)

Interesting, quite a bunch of impressive people on the submission list. My questions/observations:

  1. Surprised nobody specified a default value for the INI read.
  2. If the key is not found or an error, most do not send a message on the User Event or the Queue. What happens if the receiver is waiting for a message? Why not send a default value or a key not found message? Why not notify things downstream of the problem?
Message 19 of 147
(1,372 Views)

Screenshot 2023-08-09 120541.png

 

Pet peeves: stuff hidden under structures, wires going from right to left, default subVI icons.

0 Kudos
Message 20 of 147
(1,357 Views)