Executable has broken run arrow, development environment doesn't

[KHartley]

mtat76,

Please disregard my post earlier. I originally posted as assuming by RT just meaning run-time. Let me research your issue a little bit more and I'll see if I can find some other documentation. 

[Drew_T]

Matt,

It looks like making sure the dlls were always included fixed Greg's issue.  If it doesn't help with yours, please let us know, as it sounds like Greg may have more information.  Either way, it sounds like you may have more information after deconstructing your code as you mentioned previously.

Cheers,

[cirrusio]

Thanks, guys.  I figured out the problem - it was related to a shared variable that was connected to a type def.  Even adding the type definition as always included failed to fix the problem so I just disconnected the type-def.  Sigh...this has happened before.  Wish I didn't have to disconnect it. C'est la vie.

Cheers, Matt

[GregFreeman]

---

@mtat76 wrote:

Thanks, guys.  I figured out the problem - it was related to a shared variable that was connected to a type def.  Even adding the type definition as always included failed to fix the problem so I just disconnected the type-def.  Sigh...this has happened before.  Wish I didn't have to disconnect it. C'est la vie.

Cheers, Matt

---

Down with shared variables!!! 

[cirrusio]

Ahhhh...Greg.  I used to be of the same mind.  But, the initially spotty performance of SVs has been greatly improved.  Granted, when you have a problem, it can still be incredibly frustrating (as this thread has demonstrated).  Just wish the debugging in RT was a little better - the way I found this problem was akin to the newb way of debugging - put printf statement here and see if it is broken; put printf statement here and see if it is broken; ad infinitum.  Ugh.

[Ben]

I will not attempt a grand web-search to back me up but I believe it was Rolf Kalbermatter that wrote years ago re:Globals that they are hard to X-shoot. The first time I had trouble with a global and tried "ctrl-e" the issue became readily apparent. With no access to the code driving them, we are limited to what the power that be decide "we need".

I'd rather be responcilbe for a critter i can control than a behemoth that I do not.

As always, just my 2 cents.

Ben

[cirrusio]

Ben,

You are a grumpy old man .  I think that if you are not liberally spreading them all over the place, then they are generally easy to keep track of.  I have a generally predefined way of interacting with them so they are not proliferating all throughout the code (I set them at config time and then check them once a cycle in a single VI).  But, you have a lot of people who agree with you here (granted they had a pretty sour experience when they first came out - as did everyone else).  Now that I have been using them for a little while, I find them to be fairly straight-forward (disregard the above nonsense ) and like the fact that I can get rid of a lot of code associated with polling tcp-ip lines.  And that is just my two cents...

Matt