From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-28-2018 10:54 AM
03-28-2018 09:47 PM - edited 03-28-2018 09:50 PM
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...
SpoilerComparing 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.
04-02-2018 09:09 AM
Seen in the wild
(unfortunately, in code I need to maintain now):smileysad:
04-02-2018 09:27 AM
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.
04-02-2018 09:40 AM - edited 04-02-2018 09:45 AM
@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 ......
04-04-2018 04:55 PM - edited 04-04-2018 05:06 PM
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!!!!
04-05-2018 02:29 AM
@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...
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.
04-11-2018 04:49 PM
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...
SpoilerA 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
04-11-2018 11:23 PM
@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...
SpoilerA 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...
04-12-2018 03:02 AM
@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...
SpoilerA 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).