Ronin7

Maybe This is what they mean?

I don't see a way to change the border color programatically (even with scripting).  The only way to change the border color is with the paintbrush tool in the dev environment- so maybe create a dedicated control for each of the above types with the coloring applied in the dev environment and then programatically show/hide each themed control.  Not elegant and would require some extra logic to show and hide the themed control but is doable.  If you get really desperate you might be able to do what you need with the .net versions of the controls you want to use but that is a whole new can of worms.

1 hour ago, Neon_Light said:

 

Hello Rolf,

I am afraid this time I have to disagree. 

Agree

Dont get me wrong I think it is okay to pay for Labview, I really "value" the software. I did work with other testsoftware and although it is the price was lower or even free, the time needed to get to a working test-setup without bugs etc. made it more expensive. Thats only the price and with Labview you can do so much more than other testsoftware etc etc. So Yes I see there is a price tag and I think it is justified. 

Dont agree

Now for the parts I do not agree with.  Some testmachines can be complex expensive, much much much more expensive than the Labview license. These machines need to be reliable. They are used a lot and you can not simply change your software when you want to. For machines like this I would rather use the Old Labview version thats already running on the machine and use a new version when the total machine is being replaced. The decision what version to use should be up to the company who did build the machine and did buy the license. Not up to NI. If I take a look at the Ni website they are simply making it hard for you to download an old version. They should not do this. Introducing risk in expensive equipment is not wanted. Dont get me wrong I rather build new setups but a lot of times it is not wanted. And Yes I know you could ask cash for install files etc of old versions, but would this make my manager happy when I need to spend extra time on that? Will my manager be extra willing to pay for a new license when I need to spend a lot of time on ridicule subjects like this? Think not. If you add that a lot of managers simply are not able to understand advantages of a good product as Labview. Then you can get to the sum where the manager tells to quit using Labview.  Sorry to say but what I write it is realistic. btw the last time I did install MS windows on a laptop I did not even need a license key. It was already in the EEprom of the laptop. 

 

To be clear, I understand you need to pay for capable software and support, but downloading a old version you already paid for? This time I think the sales and marketing department of Ni dont get the point of selling software. And yes I understand installing old software can be annoying but if I dont pay for it is not up to Ni. 

 

 

 

 

 

 

 

 

 

 

 

Rolf

Because some companies display sociopathic behavior toward their customers NI should do the same?  While that may be a reality that is an unconvincing argument.  The point in all of this is that the infrastructure is already there for a customer who has already paid for a lifetime product.  If they are so hard-up for money they could charge some sort of re-access fee, say $100, for the effort to keep the content available and the bandwidth used to provide the download.

As far as accusing someone of not doing all of their job if they did not predict that NI would totally shift paradigms as far as LabVIEW licensing and marketing, well then 99% of their user base is guilty of the same...

No way to enlarge anything on the LabVIEW tree controls.  Best Bet for what you need is to use a .net Treeview control.  You can have custom sized images etc. but there is a somewhat steep learning curve and using .net in labview results in messy block diagrams with all of the references that have to be opened and closed etc.  There are examples on LAVA and ni.com.

Thanks for the assistance Gents- apparently it is the cvirt.dll causing the issue (CVI Runtime cvirt.dll was deprecated in 2017)  KB article in case it helps anyone else in the future CVIRT.dll Is Missing From LabWindows™/CVI™ - NI.  Copying cvirt.dll to c:\windows\system32 AND c:\windows\sysWOW64 fixed the issue.  

2 hours ago, ShaunR said:

First point is it looks like it is a 32 bit DLL. Are you using 32 bit LabVIEW? (LabVIEW 64 bit for 64 bit DLL's)

If you are using LabVIEW 32 bit for the 32 bit DLL then check all dependencies are available using something like "Dependency Walker". It will tell you what is missing or cannot be found for LabVIEW to load the DLL.

ShaunR- thank you for your response.  I'm using LV2018 32bit to attempt to get this old stuff working so the bitness should be OK.  I used "Depenency Walker" as you suggested and while I'm sure I don't understand everything it shows it appears that there are a bunch of missing dependencies so it looks like there is an issue with the driver installer.

Appreciate the help-

All, 

I need to get a VI with some Old Tabor Drivers working.  I have installed the particular drivers from NI.com but I am getting an error stating a .dll cannot be loaded.   If I open the Call Library Function Node it is expecting the .dll to be at C:\VXIPNP\WinNT\Bin\ww257x_32.dll .   Since this location does not exist for Windows 10, I tried creating that folder and putting the .dll there and that did not work.  I tried pointing to other locations as well and still no luck.  Does anyone more familiar with how .dlls should work have an pointers (no pun intended) for how to get this garbage working?

a

Good luck Sir- you are one of the shining lights of LabVIEW and your willingness to share deep insights on this and the NI forums was of immeasurable value.  I hope that there are others at NI with a comparable understanding and skillset but that is probably unlikely.