LabVIEW Style Challenge - Error Wires

[hunter_jki]

Tom McQuillan and I are gearing up for a fierce LabVIEW style debate at GDevCon in September and wanted to reach out to the LabVIEW community to learn the your style quirks and preferences.

Style Challenge
Download the attached file, an incomplete simple subVI that reads from an ini file, and sends values to a queue and a event.
Complete this code such that it is not broken, and it shows your best coding style practices.

Once complete upload a screenshot of your block diagram below.

Bonus Questions
What are your biggest coding style pet peeves?
What, if any, style practices do you enforce militantly?

[hunter_jki]

Cross Posted on LinkedIn, so we can cast a wide net.
https://www.linkedin.com/posts/hunterwsmith_labview-style-activity-7095055470645673984-hQsj

[Gregory]

Can you upload for 2016 or older?

[santo_13]

Here you go, the VI in LV2012

[altenbach]

Could you also include a typical ini file?

I guess the main challenge is to decide on error handling because queue and event should be able to fail independently. (Removing all the duplicate code is easy 😉 )

[BertMcMahan]

Going with the assumption that Enqueueing and Generating Event need to happen one after the other:

This also assumes that you want any upstream errors to prevent any further actions from happening. For example, if I wanted to generate the user event even if the Enqueue failed, then I'd handle it differently:

Bonus questions:

1- Biggest pet peeve is when two VI's that are generally adjacent to each other have different conpanes that make the wire bend. For example, the INI file VI's have the config refnum chained between each VI. I've run across examples before where a 4-terminal output conpane goes to a 5-terminal input conpane, meaning you have to have a tiny little bend in the wire somewhere.

2- All objects that are near each other have to be justified to each other, even if they don't interact. For example:

(I guess number 2 is also a pet peeve 😁)

[Taggart]

Here is mine.

[XM43]

Here is me:

With some assumptions about the code

1) Pet Peeves: No escape from wires crossing like in the second for loop. There will be some bends and some crossing.
2) I like to group the operation and try to execute them by group if possible like shown in the snippet.

[Jim_Kring]

[JÞB]

---

@hunter_jki wrote:

Tom McQuillan and I are gearing up for a fierce LabVIEW style debate at GDevCon in September and wanted to reach out to the LabVIEW community to learn the your style quirks and preferences.

Style Challenge
Download the attached file, an incomplete simple subVI that reads from an ini file, and sends values to a queue and a event.
Complete this code such that it is not broken, and it shows your best coding style practices.

Once complete upload a screenshot of your block diagram below.

Bonus Questions
What are your biggest coding style pet peeves?
What, if any, style practices do you enforce militantly?

---

The heck I would complete that code!  I'd advise strongly against it!

I MIGHT pass that Configuration Data to a User Event where the Data itself is exposed on the Left Event Case Node for Every Event Structure registered for the Event.   A 1:n Data Process.  Then have each Responsible Event Structure pass the Data along to the Event Customer that the specific Event Structure is serving (along with some Command information to tell each Data customer what to DO with the configuration Data.)

But, I think that passing configuration Data directly to ANOTHER Queue is just a bit silly since, it is already stored in a queue internally.  Moreover, it just isn't scalable with more than one Data Customer and you will beg to find race conditions between the configuration Data Queue (a writeable object) and the NEW Queue.

Better, Fire a User Event and Operate on the configuration Data Queue (Read/Write) in the Event Case and serve the Data Client from the Event. I.e. fire User Event "Config XYZ" (Datatype config file refnum) then Do Something.  You could even get Values for the same Key for each Section that you write P-C (Events) plugin for while registering different Event Structures for each of the config parameters it is designed to use.  

Yep, an Event driven Actor.class is exactly what I mean if taken all the way to LVOOP.