Weird *$&@ in LabVIEW

[John Lokanis]

With NI Week coming up, I look forward to one of the few times times a year I can discuss LabVIEW development with fellow engineers and not get a confused look and "lab-what?" as a response.

As a daily user of LabVIEW, I am always running into odd things that I cannot explain or that bug me enough that I want to discuss them with someone.  Unfortunately in the past I have not been able to recall many of these on the rare occasions that I am in the company of someone who knows what the $%$# I am talking about.  So, lately I have been accumulating these in a file on my dev machine.  I have decided to post them here in hope that one or more of these could be conversation starters when I bump into someone at NI Week this year.  Of course feel free to respond to this thread with any answers or solutions you might have for any of them.  If you can explain 5 or more of them let me know at the LAVA BBQ and I will buy you a beer!  I suppose each of these could be a thread in itself so if a long discussion gets started here I will try to fork it into a separate topic.

At the very least, I am curious if these issues are universal or I am just the lucky one who runs into this stuff all the time.  So, please let me know if you have experienced any of these.

Without further ado, in no particular order here is my current list of weird/annoying LabVIEW *issues*:

• Why does my splash screen vi (that launches my main vi) turn black for a long time when first running the application in the IDE?  And why does not do this on subsequent runs?
• Why are classes locked after running and stopping the application even though no VIs are still running?
• Why does the Installer configuration take forever to open? (on large projects)
• Why does opening a VI outside a project cause it to recompile?  All VIs are separated from their compiled code!  And why does this result in broken EXE build if we don’t dump the compiled cache?
• Why does deleting the compiled cache cause many VIs to need to be resaved after they replenish the cache? (note: all VIs are set to separate code from compiled)
• Why does the cursor not track correctly on the block diagram causing me to grab a wire I was not even close to?
• Why does one (sometime more) VI (with separated code) want to be saved after a build?
• Why does a VI that is not calling any VIs that were edited (and was not automatically checked out when the edits were made) suddenly want to be saved for no reason?  And why is it almost always the same VI regardless of the part of the project where the actual edits are?  (and all code is separated).
• Why is every VI in memory when opening a project?  DNat says that is not supposed to be the case.  And in LV2011 it is not, but in LV2015 it is.  Does make searching much easier, though.
• Really need a more unified search system.  Need to be able to search code, projects and other files all from the same dialog.
• When building, the CANCEL button is disabled and grayed out.  When it becomes available, if you press it to cancel, LV takes just as long to stop the compile as it would to just let it do the full compile in the first place.
• When finding all instances of a VI from the VI itself (RC on icon) the search window remains open as you open each location it is used.  But, if you RC on the VI in the project to find all instances, the search window is different.  And if you select something from it to view where the VI is used, the search window gets closed.
• Building EXEs can fail when writing the icon to the new EXE because the virus scanner has locked the file for scanning.  This could be averted by having the build process retry the icon update with a short delay between attempts.  Reported this as a bug and suggested they make it a CAR but it was declined since disabling the virus scanner fixed it.  That option is becoming less available in corporate environments.
• Why does LabVIEW (almost always) crash when trying to undo the Remove and Rewire and the Insert Multiple Wires QD shortcuts?
• When creating accessors, why can’t they just be saved automatically and be added to source control without a bunch of prompts?
• Why does the properties dialog take forever to open on a class in large project when in items view but if you switch to files view it opens 10x faster?
• When you open LabVIEW and the prompt appears to log into SCC, it does not appear on top of other apps.  So, if you don’t notice it quickly, LabVIEW times out and displays an error.  The SCC login prompt is still visible, however so even if you log in at this point, LabVIEW will finish loading but will not be connected to SCC.  Only way to fix this is close LabVIEW and open it again.  Sure would be nice if there was a ‘Connect to SCC’ menu option you could use to fix this without a restart.
• Installer times out when installing large web services.  Timeout is only 10 seconds.  Should be much longer or should adapt to web service size.
• Web Service contains a lot of duplicated code from EXE.  If the web service is running in the same application instance as the EXE, why does it need a copy of all the VIs as well?

Thanks for reading!

-John

Edited July 20, 2016 by John Lokanis

[smithd]

1 hour ago, John Lokanis said:

• (1)Why does deleting the compiled cache cause many VIs to need to be resaved after they replenish the cache? (note: all VIs are set to separate code from compiled)
• (2)Why is every VI in memory when opening a project?  DNat says that is not supposed to be the case.  And in LV2011 it is not, but in LV2015 it is.  Does make searching much easier, though.
• (3)Really need a more unified search system.  Need to be able to search code, projects and other files all from the same dialog.
• (4)When building, the CANCEL button is disabled and grayed out.  When it becomes available, if you press it to cancel, LV takes just as long to stop the compile as it would to just let it do the full compile in the first place.
• (5)Why does LabVIEW (almost always) crash when trying to undo the Remove and Rewire and the Insert Multiple Wires QD shortcuts?
• (6)When creating accessors, why can’t they just be saved automatically and be added to source control without a bunch of prompts?
• (7)Why does the properties dialog take forever to open on a class in large project when in items view but if you switch to files view it opens 10x fas

You have a lot of issues I've never seen, but I've experienced these at least.

(1) I read somewhere that the VIs don't necessarily have code but do have metadata (for example names of VIs, connpanes, types)...not exactly a concrete explanation but it may be the reason behind the saves.

(2) Is this outside of any libraries? Lvlibs and classes seem to have different rules, but I just tried loading a project in 2014 (not really using 2015 for much right now) and can verify that at least there, not all standalone VIs are loaded when the project loads. Could it be related to having SCC on? I never use the built in one because I found it to be terrible.

(3) And preferably one that is accurate, too (re: #2)

(4) Honestly I think you could just put "All of appbuilder" as a bullet point

(5) I've seen this on occasion, but I wouldn't say its frequent.

(6) To build fortitude. And of course, don't forget to also save the class and make sure labview doesn't crash in between, or else you get the friendly dialog about VIs not being part of the library they claim to be part of. 

(7) Thats a neat trick, although I would add, why does building the file view (the first time) take forever?

Edited July 20, 2016 by smithd

[John Lokanis]

(2) Yes, if I open a project and then open any VI (regardless of if it is in a class, library or by itself, I can RC on the icon and find all instances and it will show me where it is used in any other VI in the project.

I can also just create a new VI and drop the AllVIsInMemory property down and it will list every VI in the project.

I don't have 2014 installed anymore but I can confirm that this does not work in 2011.

Works with SCC or without.

(7) Never noticed that before but I *rarely* use files view.  Only when I want to edit the icon of a class and don't need a coffee break while I wait for the dialog to load.  Maybe it works in the background?

[drjdpowell]

8 hours ago, John Lokanis said:

Why are classes locked after running and stopping the application even though no VIs are still running?

Possibly related (if you use ACBR): https://labviewcoder.com/2016/07/06/quick-tip-asynchronously-launching-vis-the-right-way/

[ShaunR]

Most recompiling and the object cache queries you have outlined for when the "Separate Code" is set is probably because it only applies to new VIs. If you have vis that you have imported/updated from an older code base or those that were originally saved with it unchecked; the setting has no effect. You need to run a script (JGCode posted one here, if memory serves) that updates them to remove the code stored with the VI and recompile as seperate.

Edited July 20, 2016 by ShaunR

[John Lokanis]

8 hours ago, drjdpowell said:

Possibly related (if you use ACBR): https://labviewcoder.com/2016/07/06/quick-tip-asynchronously-launching-vis-the-right-way/

Nice tip.  Unfortunately I am already doing it the way you suggest.  However, I am using 0xC0 as all my dynamic VIs are reentrant in this system.  I wonder if that is also an issue?

[John Lokanis]

8 hours ago, ShaunR said:

Most recompiling and the object cache queries you have outlined for when the "Separate Code" is set is probably because it only applies to new VIs. If you have vis that you have imported/updated from an older code base or those that were originally saved with it unchecked; the setting has no effect. You need to run a script (JGCode posted one here, if memory serves) that updates them to remove the code stored with the VI and recompile as seperate.

When I say 'Separate Code' is set, I am referring to to VI properties setting, not the Options setting.  Of course the Options setting is set to separate code for new VIs, but I have also written tools to check all VIs I have ever created to ensure that they have code separation enabled.  Unfortunately that is not possible to control for NI provided code or 3rd party (OpenG, etc).  

[shoneill]

Not all of my answers are useful.....

• Splash screen going black?  Haven't seen this.
• Locked classes? I bet there IS something running in the background somewhere or a reference to a sub-VI left dangling....
• The installer configuration will actually do a "Preview" of all executables before opening the dialog.  The time taken is therefore basically equal to the amount of time taken to do a preview of all of the other builds included within.  Extremely annoying.
• VI outside a project: Context.  The VI saves information regarding to the context in which it was opened.  Same problem occurs with RT and Windows and FPGA, my VIs I reuse on multiple targets demand repeated saving event hough the code itself has NOT changed.  This kind of bookkeeping rubbish makes life hard when working across multiple targets (And project and not project are two different targets)
• compile cache leading to saves?  I don't know.  I haven't directly observed this. (maybe liked to context changes between the version saved on disk and the version in memory?)
• Cursor not tracking properly? Graphics driver.  Windows 2D graphics acceleration. Virtual machine.  Take your pick.
• Saving VIs after a build.... I think the build opens the VIs in a different context for compiling and if the VI contains any target-specific code, this will be saved as part of the annoying constant bookkeeping LabVIEW does with its binary files which are "suppposedly" separated from source code.  Why the last context needs to be saved in a VI I do not know, but it's something NI is holding on to in future if you get my point.
• VI not being edited wanting to be saved? Don't know.  Again, possible context differences between disk and memory versions of VI.
• Every VI in memory when opening a project? Because that's how NI decided it should be done.
• Search system.  There's nothing to explain here, so I claim this point towards my beer tally by default.
• Cancelling a build.  This is a PITA and I have no explanation beyond sloppy implementation.
• Finding all instances of VIs with different search windoes : Never noticed that.  Must watch out for it in future.
• EXE icon, again nothing really to explain here. 
• Crash when undoing QD. QD is buggy or is using unstable methods.  We've had several cases of QD shortcuts creating corrupt control references which ended up costing us days of debugging to find.  Random crashes and general instability ensued.
• Accessor creation.  Because if working with Classes would be too easy, the sense of achievement when actually managing to get the code working would be severely dimished.  It's for the best.
• Class prioperties dialog.  No idea and it always annoys me too.
• SCC login.  Haven't used that for years after downloading a free version of Perforce.  Here again, nothing really to explain. Beer counter = Beer counter + 1
• last two dealing with bew services.  Don't use them, no comments.

To add to this list:

• When deploying code to a RT target, we're never quite sure which version of code gets deployed.  Inlined VIs, when saved with changes, do not seem to propagate the "changed" flags to their owning VIs which then leads us to do a bottom to top forced recompile in order to properly re-sync the compiled cache with the code.  Even then we sometimes get VIs marked as running on the RT which shouldn't (have just been removed) or vise versa where a VI which definitely IS running on the RT is not marked as running int he IDE.  Frustrating as hell and a real time waster.
• FPGA compiles continuously reporting that the maximum number of messages from the compile server have been exceeded and there'll be no more feedback on the compile process until the compile is finished and even then half of the timings and resource utilisation statistics are missing...... I LOVE having to wait 2.5 hours for no useful information.
• Window juggling in the IDE.  I want to open a VI and go straight to the block diagram.  Double-click, Ctrl-E in short succession.  Window swapping ensues and after the graphical random number generator is finished, my Ctrl-E nearly always gets sent to the project window which then switches to files view.  30 seconds later I can get back to work.  Lovely.
• I also love how the Internet Toolkit is deprecated but there is no VI in any current toolkit (that we have found) to parse a CGI string.
• Icon editor has, since several versions, not been able to connect to NIs server to update the glyphs.  Also, the glyphs are seriously lacking, far too few standard LV glyphs are included.
• I also love that the project does not allow two RT targets to share the same IP address.  We have one host software with several versions of our RT system, only one of which is ever connected.  If I give two targets IP addresses of 10.0.0.15, LV cries.  If I give one 10.000.000.15 and the other 10.0.0.15, labVIEW is quite hapy (And apparently, stupid).

Shane

[hooovahh]

I entered this thread thinking I would have seen many of the issues mentioned, but honestly I haven't seen most.  But there are a few.

4 hours ago, shoneill said:

• Icon editor has, since several versions, not been able to connect to NIs server to update the glyphs.  Also, the glyphs are seriously lacking, far too few standard LV glyphs are included.
• I also love that the project does not allow two RT targets to share the same IP address.  We have one host software with several versions of our RT system, only one of which is ever connected.  If I give two targets IP addresses of 10.0.0.15, LV cries.  If I give one 10.000.000.15 and the other 10.0.0.15, labVIEW is quite hapy (And apparently, stupid).

Icon editor glyphs.  Oh it is a same for sure that this shipped feature of LabVIEW doesn't work and hasn't for so long.  You can manually sync new icons by downloading them along with a XML file on NI's site that is periodically updated.  But I add a bunch of other icons from an open source library, and so it is usually just easier to make a VIPM package with the glyphs I want and install it that way.  Then there's the other issue of having a non shared folder for the icons meaning if you log in as a different user you lose your icons all the sudden.

I never knew that about an RT project and that does sound really stupid.  Glad to hear there is some kind of work around.  It really seems like when it comes to projects that span multiple deployed targets, that NI just assumes things are static which can be a pain for something like "Find all PXI RT systems on the network and do XYZ with them."

[Neil Pate]

10 hours ago, shoneill said:

•   If I give one 10.000.000.15 and the other 10.0.0.15, labVIEW is quite hapy (And apparently, stupid).

 

Did not know about this workaround. Thanks!

[John Lokanis]

Excellent feedback guys!  I would love to run some of these theories by NI R&D and see if there is some merit to any of them.  But I should have been more clear on the free beer offer.  I need solutions, not just guesses or potential explanations.  I am looking for a 'that happens because...' and a 'to avoid it do this...' to earn that beer.  One good example is actually in my list about switching to files view before opening class properties.  Credit for that one goes to Jon McBee at the last NI Week.

As for the RT and FPGA related comments, unfortunately I only work with building Windows executables so I cannot comment on these issues happening in that realm.  But I am glad to see others airing their grievances here as well.  I hope this leads to some interesting discussions in Austin.

I'll add one more grievance to my list:

When calling .NET code, the execution thread is handed off to .NET, preventing LabVIEW from using it to execute any other parallel code.  So, if you make enough simultaneous .NET calls (say around 50+) and they take a long time to return, you can starve LabVIEW of all threads.  Not a single while loop will even be able to execute one iteration.  This is crazy.  Only solution is to customize your ini file to manually allocate threads to a different execution system and then set all your VIs that make .NET calls to run in that execution system.  I hope in the future LabVIEW will automatically run all external calls in a separate execution system by default with it's own pool of threads.  This one has bit me more that once.

[smithd]

On 7/21/2016 at 1:19 PM, John Lokanis said:

When calling .NET code, the execution thread is handed off to .NET, preventing LabVIEW from using it to execute any other parallel code.  So, if you make enough simultaneous .NET calls (say around 50+) and they take a long time to return, you can starve LabVIEW of all threads.  Not a single while loop will even be able to execute one iteration.  This is crazy.  Only solution is to customize your ini file to manually allocate threads to a different execution system and then set all your VIs that make .NET calls to run in that execution system.  I hope in the future LabVIEW will automatically run all external calls in a separate execution system by default with it's own pool of threads.  This one has bit me more that once.

Ugh yes, same with DLLs. In one particular application with a looooot of parallel DLL calls I had to wrap the functions in a different execution system (ie Other 1). I had a bunch of parallel webdav reads, each of which takes a while since the files are big, and everything stopped responding. Had no idea what was happening until I remembered I defaulted to webdav instead of FTP. Sadly, I just ended up going with the older FTP stuff because it (a) is just as fast if not faster, (b) has a timeout and webdav doesn't, and (c) doesn't block the entire execution system.

On 7/21/2016 at 1:25 AM, shoneill said:

• When deploying code to a RT target, we're never quite sure which version of code gets deployed.  Inlined VIs, when saved with changes, do not seem to propagate the "changed" flags to their owning VIs which then leads us to do a bottom to top forced recompile in order to properly re-sync the compiled cache with the code.  Even then we sometimes get VIs marked as running on the RT which shouldn't (have just been removed) or vise versa where a VI which definitely IS running on the RT is not marked as running int he IDE.  Frustrating as hell and a real time waster.
• I also love that the project does not allow two RT targets to share the same IP address.  We have one host software with several versions of our RT system, only one of which is ever connected.  If I give two targets IP addresses of 10.0.0.15, LV cries.  If I give one 10.000.000.15 and the other 10.0.0.15, labVIEW is quite hapy (And apparently, stupid).

-Inlining -- I filed a CAR on this at one point. I don't know what happened to it
-The IP address thing is awesome (and yes, quite stupid). 

On 7/21/2016 at 5:47 AM, hooovahh said:

Icon editor glyphs.  Oh it is a same for sure that this shipped feature of LabVIEW doesn't work and hasn't for so long.

The icon editor is just all around awesome. Have you guys seen the ones where:
-Using the fill tool covers up everything in the icon unless you switch tabs before using it
-Dropping a glyph into a specific layer shoves every other glyph in that layer off screen
-Changing the icon overlay for a lvlib/lvclass sometimes becomes opaque and covers up all the other layers in the icon
-Changing the icon template changes the printable area and squishes all of your text into the banner or evenly spreads text out into the banner area
 

To add one more of my own:
User event registration behavior. "Oh, you reordered the registration? You must have also wanted to reorder what code goes with what event!". Thanks labview

Edited July 23, 2016 by smithd

[ShaunR]

5 hours ago, smithd said:

Ugh yes, same with DLLs.

DLLs are not the same as .NET. The only time you will have problems is when you run in the UI thread (because you only have 1 in the root loop). They are also non-blocking (when "Run in Any Thread") so we're a couple of rings further out in hell when compared to .NET but arguably you are in hell somewhere if not using native LabVIEW . If you are using orange nodes you need to throw that code out and think of something new.

FWIW. .NET and it's older autistic sibling ActivX, are banned from all my projects because this is just the tip of the iceberg and most are show-stoppers that can sink a project - and have done so it's not rhetoric . To co-opt a saying:. "If one uses ,NET to solve a problem, one now has two problems and no portability"

[Darin]

5 hours ago, ShaunR said:

FWIW. .NET and it's older autistic sibling ActivX, are banned from all my projects....

As the parent of an autistic child I would be delighted if you could find a different pejorative to use in these situations.  Thanks.

[John Lokanis]

5 hours ago, ShaunR said:

FWIW. .NET and it's older ... sibling ActivX, are banned from all my projects

Not to go too off topic (is that even possible with this wide ranging post) but I am curious how you deal with databases, reading/writing XML, JSON or just basic OS level integration without using any .NET (et all).  Clearly you can't use the NI toolkits since that is exactly what they are doing under the hood.  Have you found some way to code a database interface to SQL Server, SQLite, MySQL or some other database in pure G code?  If so, you should consider posting it on the tools network.

[ShaunR]

31 minutes ago, John Lokanis said:

Not to go too off topic (is that even possible with this wide ranging post)

Your thread, your call.

32 minutes ago, John Lokanis said:

but I am curious how you deal with databases, reading/writing XML, JSON or just basic OS level integration without using any .NET (et all).  Clearly you can't use the NI toolkits since that is exactly what they are doing under the hood.  Have you found some way to code a database interface to SQL Server, SQLite, MySQL or some other database in pure G code?  If so, you should consider posting it on the tools network.

None of that requires ,NET. If you think about it that would be a real problem for Linux or VxWorks as .NET is a Windows only technology (I don't count Mono). The follow on from that is that most, if not all of the LabVIEW primitives don't use .NET (JSON and XML are NI parsers implemented in the run-time, I believe) and where .NET is used it is a windows only toolkit (Office, for example) so is not very attractive to me. This may be a sweeping generalisation and they may have leveraged some .NET under the hood for some things like web services but I probably don't use them or found alternatives many years ago before .NET was a twinkle in the milkman's eye. 

I avoid XML almost as much as ,NET. JSON - I have my own but drjdpowels one would be my second choice over the NI native one (which isn't .NET anyway).

For databases. I have my own cross platform SQLite one based on the [non .NET] SQLite binaries. MySQL type databases are just strings over TCPIP so that's no hardship but there is an excellent alternative to the NI toolkit which is open source and was free when you had to pay for NIs offering (which my google-fu is failing miserably at finding again). Where .NET usually comes in with databases is with the ODBC abstraction which is nice but unnecessary.

As a sort of addendum. For OS shipped features, there is very little in .NET that you cannot do with calls to the OS Win32 binaries and you are not saddled with the huge overheads and caveats.

[smithd]

15 hours ago, ShaunR said:

DLLs are not the same as .NET. The only time you will have problems is when you run in the UI thread (because you only have 1 in the root loop). They are also non-blocking (when "Run in Any Thread") so we're a couple of rings further out in hell when compared to .NET but arguably you are in hell somewhere if not using native LabVIEW . If you are using orange nodes you need to throw that code out and think of something new.

I looked through the help and couldn't find a solid statement on this, but my understanding was that the CLFN consumes whatever thread runs it, just like .NET, so if you have CPU cores*4 (or whatever the multiplier is for default execution system) long-running DLL calls the entire execution will hang, just like .net. I definitely recall someone running into this with a lot of parallel DAQ tasks, and if it isn't the case I have no clue what was happening with webdav, but again I have no documented proof.

Does anyone know if this behavior is documented (or if I'm just totally wrong)?

8 hours ago, ShaunR said:

For databases. I have my own cross platform SQLite one based on the [non .NET] SQLite binaries. MySQL type databases are just strings over TCPIP so that's no hardship but there is an excellent alternative to the NI toolkit which is open source and was free when you had to pay for NIs offering (which my google-fu is failing miserably at finding again). Where .NET usually comes in with databases is with the ODBC abstraction which is nice but unnecessary.

As a sort of addendum. For OS shipped features, there is very little in .NET that you cannot do with calls to the OS Win32 binaries and you are not saddled with the huge overheads and caveats.

While there are problems with .net (both the labview interface and the fact that .net can be really truly bizarre sometimes) I can't say I enjoy the CLFN interface any more. Rummaging through 10 header files just to find out that a myBlahType is actually just a I32, hoping you didn't configure anything wrong enough to crash labview for the Nth time, etc... (not really a complaint against labview, I'm just saying I think your argument of "I hate .net and look how easy it is to just call the dlls instead" is a bit crazy, since calling dlls is itself quite challenging) 

Edited July 23, 2016 by smithd

[ShaunR]

10 hours ago, smithd said:

Does anyone know if this behavior is documented (or if I'm just totally wrong)?

Not sure where I read it (damn my FIFO memory) I learnt a long time ago .NET blocks "run queues" and DLLs don't (notice I don't talk about threads, here). I may have dreamt it but I'm sure Rolf will come along and clear it all up for us (difference in thread mechanics, task switching, overheads etc). I'm not the only one that is anti- .NET/ActiveX and it is usually from experience rather than band-wagoning.

10 hours ago, smithd said:

I'm just saying I think your argument of "I hate .net and look how easy it is to just call the dlls instead" is a bit crazy, since calling dlls is itself quite challenging) 

I'm not sure where you got that idea from since I said in the previous post::

On 7/22/2016 at 0:14 PM, ShaunR said:

so we're a couple of rings further out in hell when compared to .NET but arguably you are in hell somewhere if not using native LabVIEW .

If you look back through my posting history I also say that DLLs are a last resort when you can't do it in LabVIEW. I see it in terms of project risk, rather than difficulty and out of 10, .NET is 9 and DLLs are about 3. As for hunting through .h files to find the type. That's just lack of documentation and a bit weak. I don't like searching the Internet to find if that green wire (they are all green) is a type, an object, needs a constructor or has a default and doesn't care. Is that different? It's really familiarity with the API that's important rather than calling mechanics.

Edited July 23, 2016 by ShaunR

[smithd]

13 hours ago, ShaunR said:

I'm not sure where you got that idea from since I said in the previous post::

fair enough

Back on the topic of whats broken in labview: What are the showstoppers that make you find .net so risky?

[ShaunR]

16 hours ago, smithd said:

fair enough

Back on the topic of whats broken in labview: What are the showstoppers that make you find .net so risky?

Well. A recent one that springs to mind is the uncontrollable JIT compiling of Windows 10. You can argue that you could specify that hardware driver suppliers only give you precompiled assemblies but it's just more crap to do with .NET that I avoid by not using it.

[Darren]

On 7/19/2016 at 7:08 PM, John Lokanis said:

Why does LabVIEW (almost always) crash when trying to undo the Remove and Rewire and the Insert Multiple Wires QD shortcuts?

 

On 7/21/2016 at 3:25 AM, shoneill said:

Crash when undoing QD. QD is buggy or is using unstable methods.  We've had several cases of QD shortcuts creating corrupt control references which ended up costing us days of debugging to find.  Random crashes and general instability ensued.

I feel confident in claiming that I use Quick Drop more than anyone on this planet. I use these shortcuts (Remove and Rewire, Insert) dozens of times a day. I've never seen the instability y'all are talking about. No crashes, no "corrupt control references". I've also never seen a CAR reported on these issues either.

I'm not discounting the fact that y'all are experiencing these issues. Believe me, I hate it as much as anyone when the car repair guy tells you that there's no way your automobile can be malfunctioning in the way you describe. But if y'all are seeing these issues as frequently as you claim, why have I not received a bug report that I can investigate? I realize that it's sometimes hard to get things into a reproducible state that can be reported. But hopefully y'all also realize there's not much I can do when the first I hear of these issues in 8 years of the feature's existence is on this LAVA thread.

[shoneill]

On 25.7.2016 at 7:59 PM, Darren said:

 

I feel confident in claiming that I use Quick Drop more than anyone on this planet. I use these shortcuts (Remove and Rewire, Insert) dozens of times a day. I've never seen the instability y'all are talking about. No crashes, no "corrupt control references". I've also never seen a CAR reported on these issues either.

I'm not discounting the fact that y'all are experiencing these issues. Believe me, I hate it as much as anyone when the car repair guy tells you that there's no way your automobile can be malfunctioning in the way you describe. But if y'all are seeing these issues as frequently as you claim, why have I not received a bug report that I can investigate? I realize that it's sometimes hard to get things into a reproducible state that can be reported. But hopefully y'all also realize there's not much I can do when the first I hear of these issues in 8 years of the feature's existence is on this LAVA thread.

Reproducibility is the problem.  As soon as we strip down things to get a format suitable to submit as a problem report, the problem invariably goes away.  This is the case with several things we observed over the years from wierd RT deploys (The RT guys had never heard of our issue at all when I asked about it at NI Week) to corrupt FP control references in typedefs created by QD.  Reduce code, problem goes away.  Great. 

How does NI propose we document these problems without sending a complete VM with LabVIEW installed AND complete source code for our project?  Sometimes these problems just get swallowed whole by the inconveneice of trying to demostrate their existence.

[Darren]

4 hours ago, shoneill said:

How does NI propose we document these problems without sending a complete VM with LabVIEW installed AND complete source code for our project?  Sometimes these problems just get swallowed whole by the inconveneice of trying to demostrate their existence.

I don't have a good answer for this. I run into the exact same issues, and I work at NI! For a while I would file CARs with a [hard to reproduce] tag on them, but I don't think anything ever came of those. I've heard of customers actually visiting NI and bringing their entire setup to get an AE to spend days troubleshooting issues like this, but I think that's overkill in almost all cases.

One thing I can say...I've heard customer sentiment that it's not worth the time to submit NIER crash reports, but that's absolutely *not* true. With each LabVIEW release since NIER's debut, we've fixed *several* crashes as a direct result of the crash reports that were sent in. So continue submitting crash reports (and attaching code where possible and appropriate), because improving stability by solving NIER-reported crashes is something we're committed to with each release.

[smithd]

45 minutes ago, Darren said:

One thing I can say...I've heard customer sentiment that it's not worth the time to submit NIER crash reports, but that's absolutely *not* true. With each LabVIEW release since NIER's debut, we've fixed *several* crashes as a direct result of the crash reports that were sent in. So continue submitting crash reports (and attaching code where possible and appropriate), because improving stability by solving NIER-reported crashes is something we're committed to with each release.

My problem is that it regularly fails to send the logs up, even when I'd like it to. (Definitely IT being annoying IT, still doesn't work though)

Edited August 16, 2016 by smithd

[hooovahh]

So on the topic of weird LabVIEW stuff I had a few today.  I noticed a couple my quick drop functions not dropping what they should be.  Now this might just be a result of my custom quick drop shortcuts, but I don't have any shortcuts for the Copy or Delete functions.  I recorded my oddness here.  Anyone seen anything like this?