Continuously learning

[wiebe@CARYA]

---

@JÞB wrote:

The comparison to constant is not needed since you can use the case to switch on the constant.

Actually, All (that I can think of off the bat) Comparisons to constants feeding a case selector are r-g

---

Except...

Spoiler

Comparing floats to -Inf, NaN or +Inf constants!

[billko]

---

wiebe@CARYA wrote:

---

@JÞB wrote:

The comparison to constant is not needed since you can use the case to switch on the constant.

Actually, All (that I can think of off the bat) Comparisons to constants feeding a case selector are r-g

---

Except...

Spoiler

Comparing floats to -Inf, NaN or +Inf constants!

---

Actually, there is a legit case for this.  You just named three of the five IEE 754 FP exceptions.  There might be a reason to do something if these occurred.

Didn't read your spoiler closely enough.  I missed what was written immediately above it.

[JÞB]

Seen in the wild

(unfortunately, in code I need to maintain now):smileysad:

[crossrulz]

And I am guessing that is not a simple dialog.  I have done similar for dialogs to pass out what the user configured, but those typically just write the values out when the OK button is pressed.

[JÞB]

---

@crossrulz wrote:

And I am guessing that is not a simple dialog.  I have done similar for dialogs to pass out what the user configured, but those typically just write the values out when the OK button is pressed.

---

It gets worse, there is no means available to the vi where Auto Run is visible or enabled.  Therefore, the case cannot execute unless someone is messing with a vi server ref to this vi.

EDIT:  "Don't worry Jeff, That autorun feature never worked and we can't figure out why....

There is also a mouse down event on 26 clusters of string (values A-Z) that fires a user event of (string A-Z) handled by the same event case.....to sort a list ...... 

[altenbach]

So why did nobody else ever think of that??? (seen here) 😮

paraphrasing:

"To avoid memory issues we should not use an outer while loop but use the "continuous run" button instead."

Hmmm.... NO!!!!

[wiebe@CARYA]

---

@altenbach wrote:

So why did nobody else ever think of that??? (seen here) 😮

paraphrasing:

"To avoid memory issues we should not use an outer while loop but use the "continuous run" button instead."

Hmmm.... NO!!!!

---

Isn't working around a problem better then solving it? That's not what I've heard...

Spoiler

A colleague at my previous job (20 years ago) asked me if I could make a .dll to kill the current process. He had a memory leak, and in stead of asking me to solve it, he figured it was easier to simply restart the application once a day.

There and then I realized this. Everyone can learn how to program. But some people should not be allowed to. At least not without supervision.

[BowenM]

---

wiebe@CARYA wrote:

---

@altenbach wrote:

So why did nobody else ever think of that??? (seen here) 😮

paraphrasing:

"To avoid memory issues we should not use an outer while loop but use the "continuous run" button instead."

Hmmm.... NO!!!!

---

Isn't working around a problem better then solving it? That's not what I've heard...

Spoiler

A colleague at my previous job (20 years ago) asked me if I could make a .dll to kill the current process. He had a memory leak, and in stead of asking me to solve it, he figured it was easier to simply restart the application once a day.

There and then I realized this. Everyone can learn how to program. But some people should not be allowed to. At least not without supervision.

---

Reminds me of this story

[Blokk]

---

@BowenM wrote:

---

wiebe@CARYA wrote:

---

@altenbach wrote:

So why did nobody else ever think of that??? (seen here) 😮

paraphrasing:

"To avoid memory issues we should not use an outer while loop but use the "continuous run" button instead."

Hmmm.... NO!!!!

---

Isn't working around a problem better then solving it? That's not what I've heard...

Spoiler

A colleague at my previous job (20 years ago) asked me if I could make a .dll to kill the current process. He had a memory leak, and in stead of asking me to solve it, he figured it was easier to simply restart the application once a day.

There and then I realized this. Everyone can learn how to program. But some people should not be allowed to. At least not without supervision.

---

Reminds me of this story

---

Similar to a recent post, where the OP stated he should move to LV 64bit because he has memory leaks...Well, for sure you can delay memory issues, just buy more RAM...

[wiebe@CARYA]

---

@Blokk wrote:

---

@BowenM wrote:

---

wiebe@CARYA wrote:

---

@altenbach wrote:

So why did nobody else ever think of that??? (seen here) 😮

paraphrasing:

"To avoid memory issues we should not use an outer while loop but use the "continuous run" button instead."

Hmmm.... NO!!!!

---

Isn't working around a problem better then solving it? That's not what I've heard...

Spoiler

A colleague at my previous job (20 years ago) asked me if I could make a .dll to kill the current process. He had a memory leak, and in stead of asking me to solve it, he figured it was easier to simply restart the application once a day.

There and then I realized this. Everyone can learn how to program. But some people should not be allowed to. At least not without supervision.

---

Reminds me of this story

---

Similar to a recent post, where the OP stated he should move to LV 64bit because he has memory leaks...Well, for sure you can delay memory issues, just buy more RAM...

---

Merging LabVIEW 32 bit project into LabVIEW 64 bit will it work for all the DLLs and library's ?

In all fairness, OP mentions "memory problems", not memory leaks per s. Although leaks are very likely to be the problem, OP could just needs a lot of memory. Anyway, fixing them by optimizing the code to some degree is a better solution then simply upgrading. But he might have done that already (although very likely he didn't).