Leaderboard

Well, I've tracked this down to an issue being brought on to using classes within a LabVIEW library. The two kinds of libraries (.lvlib and .lvclass) just plain do not work together. My little project's classes became plain uneditable, they were contained in an lvlib. In a fit of frustration, I dragged the entire lvlib hierarchy out of the library scope, and magically everything just works as intended. This is a shame, for lvlibs offered a lot of control and namespacing which really helps with code reuse. Please to any at NI who are reading this thread, fix this. Well, it's a good thing I got this working. I'm literally down to the last hours, about to be gone for two weeks and this code has to work by end of day. Meanwhile, I just lost two hours trying to add a simple primitive to one of my classes. Since there's no way I'm going to drop my use of .lvclass objects, I'm done with lvlibs for now.

I would like to programmatically change the alias of a couple DAQmx devices to make a program more versatile. I have found an example at ni.com that will do this; however, it is in version 8.6 and I have 8.5. Could someone please visit that page and save a screenshot? https://decibel.ni.c.../docs/DOC-15998 Thanks.

How about the actual VI saved in 8.0 ChangeAlias.vi

Most of the gaming advice has been about removing unneeded services and setting the performance options (system properties->advanced tab->performance options button) to "adjust for best performance". These did not help the acknowledge issue. I found one YouTube video at: It recommends going into the registry and adding "TcpAckFrequency" and "TCPNoDelay" to the parameters for the NIC. I'm seeing a positive change, but I was fooled a couple of times today, so I'm not ready to say it's fixed yet. The registry path is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{ .... some GUID identifying your NIC card port .... } Check the IP address to figure out which interface you should be looking at. Under the path add the values: TcpAckFrequency DWORD data=0x1 TCPNoDelay DWORD data=0x1 TCPNoDelay = 1 turns off nagling TcpAckFrequency is far more interesting per: http://support.microsoft.com/kb/328890 It seems Windows sends out a TCP acknowledge for every other segment received (per RFC 1122). Setting the ack frequency from 2 (default of every other segment) to 1 will acknowledge every segment. Tim

To me, this sounds like a problem for User Events and User Events only. All other refnums can be wrapped in classes. Why would I oppose building something more common for references generally? First of all, you only put a single checkbox in the Library Properties, but just because I have one reference that I want to restrict does not imply I want to restrict all references. Second, you're asking for restricting destroying the reference, but with queues, it is not uncommon to want to restrict either enqueue or dequeue -- any given subset of functionality might be the subset you wish to restrict (I even imagine one case where the *only* thing the outside can do is destroy the queue, which stops the internal producer/consumer loop). Third, you might want to share functionality to some people but not to others. For all these reasons, I think building a class that exposes the functionality that you want is the more desirable route. Asking for some scripting tools to create those wrappers faster would be reasonable. The restrictions for DVRs of class types do not fall in the above categories because those are restrictions that apply to the *entire type* of refnum. A type-wide restriction is different than a per-instance restriciton. If you wanted to prevent anyone from ever destroying a "User Event of Subtype X", that would be more viable as a request than the per instance restriction. As for the User Event, asking for a new node that, given a User Event, outputs a "Registration-Only User Event" gives you something that could still be connected to a Register Event node. With that small adjustment, you could build a refnum class that can register, send, etc. The *top-level* VI is tracked, but not the specific subVI, and this would need to be on the specific subVI. It would require a new tracking system. It is the language's job when the restriction is applied to the whole type (like having a private destructor in C++). It's not the language's job when we're talking specific instances of a type.

Would any of the VIs in \vi.lib\Utility\VariantDataType\VariantType.lvlib help you? You should at least be able to use the GetTypeInfo VI to see what your mystery F1 is.

Ton, How about using the following process, for controlling any third-party executable running on cmd prompt using WinAPIs: 1) Get the third party window handle by using GetWindowHandle API. 2) Use AttachConsole() API from kernel32.dll - This would make the third party console controllable through LabVIEW 3) Use GetConsoleScreenBufferInfo() from kernel32.dll, with which you can read the console information 4) Use another function (can't remember the function name) which would write to the console 5) Repeat Step 3 and read the output for the written command in step 4 (you might need to do some string parsing to get the desired output) 6) Use FreeConsole() function from kernel32 again, to free up the console at the end of the application. This way, you don't need to redevelop the third party app in labview, rather you could re-use the cmd prompt with this method with labview and have control/read data on it. I am planning to make a small example of this and post it very soon. -FraggerFox!