Rolf Kalbermatter

QUOTE (Bjarne Joergensen @ Mar 3 2009, 03:25 AM) Yes that can't work. The VI's inside an LLB are each compressed with an NI specific (by far not as good as zlib but at least something) algorithme into a resource and added to the LLB file. So the resource stream and therefore the LLB file does not contain intelligible ASCII characters due to that compression. This is so since the beginning of LLBs although NI added also an uncompressed LLB resource stream variant to the LLB format at around LabVIEW 8 but that seems only getting used when creating in the Application Builder the LLB that gets later turned into an executable. Rolf Kalbermatter

QUOTE (Bjarne Joergensen @ Feb 27 2009, 10:00 AM) It won't work in LabVIEW 8.6 AFAIK. They compress most of the information in a VI file. Freee text labels on the front panel for instance can not be found anymore in this way. Rolf Kalbermatter

QUOTE (torekp @ Feb 25 2009, 03:43 PM) While a path can be relative in itself the browse function does not work that way directly. You could instead use a hidden control whose browse button you make visible and then monitor the Value changing and whenever it changes make the necessary absolute to relative conversion and display it in the visible path control. There would need to be some error handling if the user decided to browse outside that directory as LabVIEWs File Select dialog can be not restricted directly to a certain subpart of the file hierarchy. Such small but rather cumbersome trivialities are probably the reason the Path control does not allow browsing relative paths. Rolf Kalbermatter

QUOTE (Joshuatronics @ Feb 25 2009, 02:20 PM) There is no obvious reason for this to crash. According to the doc the 100 character input buffer for the error string should be enough. - Maybe try to make that buffer 1000 for a trial. - Maybe the error VI is supposed to only be called when not NULL. - WINAPI calling convention if not right would certainly crash this VI every single time. - Are you sure it is the error function and not one of the other VIs that crashes? There are enough other functions that get called. While WINAPI convention would badly crash if the number of parameters was not right it might be the actual value passed to the Open or Start function. Rolf Kalbermatter

QUOTE (KiranVSutar @ Feb 25 2009, 05:04 AM) As I tried to explain to you, you can use some other more flexible MSI Builder. Not sure if the VB6-MSI is that much more flexible than the LabVIEW Application Builder, otherwise you would need to get something like Install Shield or similar. Basically you use the Application Builder to create your executable with all the necessary support files and then add them to your install build script for whatever MSI Builder you use. If you want to make sure that the installer also takes care about installing the LabVIEW runtime engine you would also add the according MSMs as mentioned earlier. This could however possibly cause troubles nevertheless if the custom MSM you want to add would rely on other modules such as the Visual C Runtime libraries that the LabVIEW modules might want to try to install too. Rolf Kalbermatter

QUOTE (Mark Yedinak @ Feb 24 2009, 04:58 PM) Make a product suggestion at the http://digital.ni.com/applications/psc.nsf/default?OpenForm' target="_blank">Product Suggestion Center. The fact that it is there for so long (I don't think 3.0 had any printing capabilities that you could call home about so not sure it was there already ) tells me however that there is probably a very fundamental problem with this that might be hard or almost impossible to remove without causing quite a bit of other problems. But I do not know the details of it, just noticed it long ago and watched my installed printers ever since if the dialog started to get slow. Rolf Kalbermatter

QUOTE (ejensen @ Feb 23 2009, 01:21 PM) Unfortunately that does not work for MSM files. They are simply MSI merge module and in fact the LabVIEW support files such as the Runtime Engine and many others that you can select in the Installer Tab are also provided as MSMs in the applibs\distkit\redist\modules (for LabVIEW 7.1). But the application Builder does not allow to add your own custom MSMs to the list of possible modules to merge into an installer. The solution is actually to use the Application Builder only to Build your executable and then use some MSI Builder (Install Shield or similar) to create your installation from there. You can add the necessary MSMs from above mentionen directory to your MSI build if you do not need to go to complicated. lvruntime.msm would be the obvious module to include into a MSI Build to add installation of the LabVIEW Runtime Engine. It does depend on other modules from that directory but that should be handled by your MSI Builder automatically if it is good for anything. You might also want to include the mkl.msm if you make use of any Advanced Analysis Library functions in your application. Note: This is only valid for LabVIEW < 8.0. The LabVIEW 8.x Project Environment/Application Builder is a lot more involved and pulls in the modules from various places including "Program Files\National Instruments\Shared\ProductCache". Rolf Kalbermatter

QUOTE (wildcatherder @ Feb 19 2009, 08:07 PM) No there isn't so far such an option. The reason is probably twofold. For one whatever format the developer would come out with to print information it would be always critizied to not contain the information in the format specific users wanted. Second the information in the project window is quite involved and you can think of a myriad of things to print from that. What you can do is going with some of the Project VI Server property Nodes and methods to do your own project information enumeration and create a text file of some sort with the specific information you are interested in. Rolf Kalbermatter

QUOTE (Shazlan @ Feb 22 2009, 04:49 AM) In order for IMAQdx to be able to see your camera you need to associate it with the IMAQ Firewire driver that comes with the Visions Acquisition Software. You can do that in the Windows Device Manager. Rolf Kalbermatter

QUOTE (SSST2009 @ Feb 21 2009, 09:13 AM) Then you should read some of the internet RFCs (Request for Comments). They are open documents that describe just about any protocol and aspect of the internet and although sometimes a bit difficult to read the authoritive source about how a protocol should be implemented. QUOTE Maybe I didn't explain in a good way my problem, in fact I will receive an e-mail in a e-mail account (like hotmail or yahoo) and from there I must save in a folder on my PC the attachment of this mail. I found how to read the e-mail but I have no idea how to save the attachement. Can you help me a little bit more? I'm surprised that you say you are using this library to read messages from hotmail or yahoo. They to the best of my knowledge will not allow clear text password logins and that is for a good reason. You should not do anything like clear word passwords over any other network than your internal and firewalled home or office network. As far as I know there is no real LabVIEW POP library out in the wild for free that does allow more than basic (clear text and possibly Base64 password authentification) which are all basically clear text. Most people having to deal with either SMTP or POP login did usually resolve to using ActiveX to use the Outlook email API to do all that. Rolf Kalbermatter

QUOTE (jzoller @ Feb 20 2009, 02:19 PM) Yes I don't think there is any way .Net could call back into LabVIEW to let it know that it has autodisposed a refnum. But then they might want to do that for their Visual Basic environment so maybe, but I doubt it would be officially documented. QUOTE My tests were very simple: create a lot of sub-refs, then attempt to orphan them by closing the top level without closing the sub-refs. Repeat a few thousand times. Monitoring memory while this happens doesn't show any particular increase. Unless .Net can call back to LabVIEW to let it know about the the disposal of the objects there would need to be some memory allocation for the LabVIEW .Net refnum, as long as the returned object is not static. So maybe you tried with something that is static, meaning it always returns the same object and does not instantiate them. I believe LabVIEW knows about if an .Net object is static and might handle it differently than normally instantiated objects. Rolf Kalbermatter

QUOTE (crelf @ Feb 20 2009, 05:49 PM) No way. They exist since before the Picture control was released. But I guess the field edit option has a redrawing problem when dealing with transparent background. Of course deep down there is C code and to enable editing of the field they probably do use the trick of creating a temporary text entry field but fail to account for the case where the table background is transparent and simply copy the table background to the edit control in all cases, which would be certainly desired behavior for non transparent backgrounds. Rolf Kalbermatter

QUOTE (hari001 @ Feb 21 2009, 01:40 AM) http://msdn.microsoft.com' rel='nofollow' target="_blank">MSDN is your friend for detailed information about specific .Net functionality. For learning how to program it I would recommend you to get a good book about it from publishers like McGrawHill, Prentice-Hall or similar. Rolf Kalbermatter

QUOTE (bmoyer @ Feb 20 2009, 08:02 AM) Well the VIs are there in the executable embedded. But they are all broken because they try to load the NI Vision DLL and that gets only installed by the NI Vision runtime (or the Development Module but that is here not of interest). Rolf Kalbermatter

QUOTE (Mark Yedinak @ Feb 20 2009, 11:24 AM) LabVIEW offers no such access for sure. You could try to use netsh command line tool available in 32 Bit Windows installations. something like this executed with System Exec should work: netsh interface ip set address "Local Area Connection" static <local address> <subnet> <gateway> 1 netsh interface ip set dns "Local Area Connection" static <dns server address> primary netsh interface ip delete dns "Local Area Connection" all netsh interface ip set address "Local Area Connection" dhcp netsh interface ip set dns "Local Area Connection" dhcp Local Area Connection is the name of your network interface as Visible in the Network Connections. Rolf Kalbermatter

QUOTE (neBulus @ Jan 22 2009, 09:35 AM) There are more than a handful of patents that cover LabVIEW. Some quite new and some quite old. One of the first patents issued for LabVIEW run out one or two years ago but NI applied for extension and it was granted. QUOTE Keeping Scripting limited NI can maintain its control over enhancements to LV and force anyone attempting to make a better version of LV (LV writtien in LV?) they will have to work for it. I think this is one valid and actual reason they do not feel like opening it up completely. Note there seem to be people with access to it outside NI, but one needs to have a very compelling reason for that. Another one is that it has still quite a few sharp edges and trap falls. Also it does often not seem to be engineered in any specific way but sometimes looks more like ad-hoc methods and properties sprinkled across the object hierarchy of LabVIEW like it got added whenever an internal tool developer found a new hook he needed to create the next LabVIEW tool feature or addon. Sometimes obvious methods are missing that seem logical in conjunction with others that do exist. Not in the sense that one requires the other but more in why implement a method for a specific object but not for others where it does make just as much sense. Also I have a few times gone into it to solve a specific problem looking and searching for the right methods and properties only to find out that the key method threw a not supported error. Yes going to the next LabVIEW version often remedies that error but at the same time things tend to break regularly when upgrading scripting code to a new LabVIEW version. QUOTE (neBulus @ Jan 23 2009, 07:13 AM) I'll add an arguement for scripting I have an app that uses SCRAMNet and maps 2 Meg of memory for up to about 50 devices. This mapping is documented in a standard form. The mapping can change when engineerings decides it needs re-mapped. It took two developers 3 days to re-map the data fields the last time there was a major change. I wrote Script that was capable of redfining the clusters associated with the mapping and it worked on machine at home. At work it gave me an insane object error while doing the demo for my boss.... I abandoned scripting. This sounds more like an argument against releasing scripting right now. But a more realistic solution would be to write a flexible driver in the ways of Tag based addressing, where you do use the Device Names/Tag Names in your LabVIEW code and on start up load that list into a Vi that can do the TagName<->MemoryAdress translation. It's a bit of work to do that in a good way but hardly more than writing a tool that can read your address list and change all the VI code using scripting. Rolf Kalbermatter

QUOTE (Ton @ Jan 22 2009, 01:58 PM) How could this work? It does not know in any way for which VI it should open the property dialog? Rolf Kalbermatter

QUOTE (Ton @ Jan 17 2009, 06:58 AM) And still no license manager making things harder Rolf Kalbermatter

QUOTE (george seifert @ Feb 19 2009, 11:07 AM) DAQmx on VirtualPC??? VirtualPC is simply a virtual machine from Microsoft much like VmWare. I can't really believe that VirtualPC does virtualize the PC Hardware to the point that DAQmx can really work on there. Well, it seems it does work , which is quite amazing if you ask me. You say DAQmx has been installed and seems to work. How did your customer check that? Can he go into Measurement & Automation Explorere inside the VM and see the boards installed and also execute the Test Panels for them? Rolf Kalbermatter

QUOTE (Ton @ Feb 19 2009, 03:39 AM) And that even works remotely. Maybe not a good idea to do that over internet with a 100 ton press controlled by LabVIEW or some heavy motion system but for some applications it can be really good. Rolf Kalbermatter

QUOTE (jzoller @ Feb 18 2009, 04:35 PM) Not sure about .Net references but if it is anything like ActiveX then yes they would need to be closed explicitly if you do not want them to linger around in memory until you stop or close the Top Level VI in whose hierarchy the reference was created. This last one is a LabVIEw specific feature since it keeps track of all its refnums and destroys them when the Top Level VI in whose hierarchy the reference was created goes idle. When it destroys its refnum it also closes the underlying ActiveX or in this case .Net handle. Otherwise the ActiveX handles would remain in memory until the process that created them is going to terminate in which case Windows process cleanup code takes care about closing anything still left open. Rolf Kalbermatter

QUOTE (JustinThomas @ Feb 18 2009, 11:38 PM) But since the VI is in a normal case structure it will be compiled into the executable. This is exactly what the OP wanted to avoid. However I do not see the real problem. I'm frequently debugging (single stepping) into VIs called with Call by Reference and that seems to work fine. Of course both the caller and callee need to be on the local system then. Rolf Kalbermatter

QUOTE (crelf @ Feb 16 2009, 11:48 AM) Well I can't say with absolute authority that there couldn't be some method to initialize the password cache somehow, but I am not aware of any other way to get the password cache filled than by applying a new password to a VI or entering a valid password for an existing VI. Nothing else seems to work and shouldn't either. It does not make sense either so why should NI add such a thing? Rolf Kalbermatter

QUOTE (vugie @ Feb 16 2009, 10:24 AM) No but in order to fill the cache you have to apply a password to a VI through VI server. At around 100ms per execution you will wait a long time to fill that cache significantly. And I believe that if the password does not match it will not be added to the cache! So you need to apply a new password to some VI, clear it and add another one, at about 100ms for each operation Shutting down LabVIEW destroys that cache too. Rolf Kalbermatter

QUOTE (torekp @ Feb 16 2009, 07:48 AM) The only problem where you should get a not file found error is in fact when trying to open a file. So I do not see how you would have to wrap all FileIO functions. Just creating your own Create File/Open File function and using them consistently in your apps would help. Rolf Kalbermatter