Rube Goldberg Code

[AeroSoul]

I mean it seems like this is an app made by him for himself, so my solution would just be "don't".

I also remove Abort buttons in my apps for customers, but not for myself.

[rolfk]

---

@AeroSoul wrote:

I mean it seems like this is an app made by him for himself, so my solution would just be "don't".

I also remove Abort buttons in my apps for customers, but not for myself.

---

Same here and I often only hide the entire toolbar without explicitly disabling the abort button. An end user application should not have a toolbar at all.

Or rather, it can of course have a toolbar if you are inclined to go through those trouble to create one, but it should not have the LabVIEW toolbar visible at all.

[JÞB]

---

@rolfk wrote:

---

@AeroSoul wrote:

I mean it seems like this is an app made by him for himself, so my solution would just be "don't".

I also remove Abort buttons in my apps for customers, but not for myself.

---

Same here and I often only hide the entire toolbar without explicitly disabling the abort button. An end user application should not have a toolbar at all.

Or rather, it can of course have a toolbar if you are inclined to go through those trouble to create one, but it should not have the LabVIEW toolbar visible at all.

---

I haven't tested this lately (if ever) but,  if anyone is near a booted Windows computer.... Does just hiding the toolbar without unchecking Show Abort Button disable "Ctrl+."?

[wiebe@CARYA]

---

@JÞB wrote:

---

@rolfk wrote:

---

@AeroSoul wrote:

I mean it seems like this is an app made by him for himself, so my solution would just be "don't".

I also remove Abort buttons in my apps for customers, but not for myself.

---

Same here and I often only hide the entire toolbar without explicitly disabling the abort button. An end user application should not have a toolbar at all.

Or rather, it can of course have a toolbar if you are inclined to go through those trouble to create one, but it should not have the LabVIEW toolbar visible at all.

---

I haven't tested this lately (if ever) but,  if anyone is near a booted Windows computer.... Does just hiding the toolbar without unchecking Show Abort Button disable "Ctrl+."?

---

No. 

[rolfk]

---

wiebe@CARYA wrote:

I haven't tested this lately (if ever) but,  if anyone is near a booted Windows computer.... Does just hiding the toolbar without unchecking Show Abort Button disable "Ctrl+."?

---

No. 

---

Partly right. It does disable that shortcut in a built application when the toolbar is not visible, and you don't add that shortcut to your custom menu.

LabVIEW 2018 SP1, Windows 10

[paul_cardinale]

---

@JÞB wrote:

---

wiebe@CARYA wrote:

---

@AeroSoul wrote:

The accepted solution equivalent of cutting your finger off to prevent a mouse button press.

---

So, how would you solve it?

---

I would also like to know.  Using an Abort button to Stop a vi is extremely dangerous.  It is precisely why no deployed apps have an abort button (unless a LabVIEW Developer forgets to rip it off)

I commonly remove the Abort button.  Removing the button also disables "CTRL+." or any hotkey otherwise assigned to Abort VI.  I started doing that shortly after joining these forums because of advice received from reading many threads.  If you have other practices I would be happy to hear your thoughts. 

---

Depends on 'deployed to whom'.  For code to be used by technicians, I always make sure to enforce a clean shutdown.

But on some of my tools for test engineers, Abort, or closing the window is the only way to stop the VI.

[JÞB]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

I haven't tested this lately (if ever) but,  if anyone is near a booted Windows computer.... Does just hiding the toolbar without unchecking Show Abort Button disable "Ctrl+."?

---

No. 

---

Partly right. It does disable that shortcut in a built application when the toolbar is not visible, and you don't add that shortcut to your custom menu.

LabVIEW 2018 SP1, Windows 10

---

That is what I seam to vaguely remember.   I never even thought to include an Abort VI RTM hotkey in a built app though.  I don't think I ever will have a good use case.

Which can only mean one thing; the law of serendipity guarantees that I'll need to do exactly that in the next week.

[altenbach]

If you ever need a random 2D array of a given size, here's one possibility:

I can think of a (very) slightly simpler solution 😄 (seen here)

[Yamaeda]

---

@altenbach wrote:

If you ever need a random 2D array of a given size, here's one possibility:

I can think of a (very) slightly simpler solution 😄 (seen here)

---

Ey! I like that one! Easy. Clear. I'd probably make it as 1 loop and reshape afterwards but i like it. 🙂

[JÞB]

---

@Yamaeda wrote:

---

@altenbach wrote:

If you ever need a random 2D array of a given size, here's one possibility:

I can think of a (very) slightly simpler solution 😄 (seen here)

---

Ey! I like that one! Easy. Clear. I'd probably make it as 1 loop and reshape afterwards but i like it. 🙂

---

I think he meant that the second 0 constant could be removed and migrate add to after the loops.

Now for the trivia fun 

Snippets do not show Constant Folding so a snip shows

BUT, what happens when we enable loop parallelization? 

The PRNG marks that the loop is no longer constant folded. Why?  Because, although the PRNG WILL generate the same numbers, they may no longer be in the same order.  UNLESS: We enable debugging forcing the loop iterations to execute sequentially!  Then we find a minor cosmetic edge-case bug TO WIT: the constant folding is not re-indicated but, of course, it should be.

Note: both loops are configured as shown above

Can someone wave a hand on another board to get NI R&D to comment?