Rolf Kalbermatter

This is a version I did about 15 years ago in what was then LabVIEW 3.1. I programmed it to work with 8bit color images but it seems to work well for the 1 bit images you provided too. It is by far not what I would recommend to program nowadays although I think there are some interesting ideas in there. If you look at the Decode Bitmap function you may wonder why it is programmed like it is. The reason is manyfold. First there was no inplace operations back then. Second this had to run on 486DX 33 MHz CPUs back then without requiring minutes of runtime execution. I think you could squezze out a few more optimizations but in general it was what was necessary to make a RLE Decoder performant in LabVIEW back then. As said it is not really how I would program it today both in terms of using LabVIEW features as well as overal architecture but here it is. I only upgraded it to 6.0.2 from 3.1 so it can be also read with the newest LabVIEW version. Nothing else was really changed. Download File:post-349-1237721972.llb Rolf Kalbermatter

QUOTE (Yair @ Mar 16 2009, 01:52 PM) Yair is quite right. Most of the scripting properties are NOT accessible remotely for a good reason. Think about security! And about how they build VIs in Vision Builder and Co: Quite simple by executing LabVIEW VIs that run in a special runtime environment that is part of the tool that has the scripting feature not removed. Can you create a VI executable that could make use of that runtime environment? No, not really, both because of technical limits (no tool to create a LabVIEW executable that would call this special runtime instead of the standard lvrt.dll) as well as legal (that runtime only comes with those tools and is part of their license). Even if you would have installed and licensed that tool on the target machine it would be legally questionable if you have the right to execute your own code using that runtime engine enclosed in there. Rolf Kalbermatter

QUOTE (flarn2006 @ Mar 20 2009, 07:32 PM) The answer is quite simple. If you would have the source code of LabVIEW you could! You could then easily build a "cheat engine" as you call it from that source code where the password check is disabled. However the password protection itself of LabVIEW files is fairly sound. There is encryption of parts of the (undocumented) binary file structure to create a hash key. And recent versions create multiple such hash keys over various parts and that spans even the plain text readable new style XML LabVIEW files. In addition a VI knows about the password protection of the owning library and vice versa and the same with classes. While patching an older LabVIEW executable was probably an option for a good hacker I have serious doubts that this is still possible within a reasonable amount of time. And it is the worst way as every single patch release of LabVIEW is nullifing that. Hint to NI: that would be one more reason to actually release intermediate patch fixes! Makes almost every user happy and makes the life for those trying to go around the password protection a little more difficult. In the past few versions patch fix releases were never really announced properly but only in according discussion threads. I would find it useful to consider a somewhat more proactive patch fix release announcement. Rolf Kalbermatter

QUOTE (ASTDan @ Mar 18 2009, 03:08 PM) While you can get away not using the project for simple LabVIEW host applications it sure is a very handy tool to use when you start to do multi target applications (host, RT, and FPGA, and/or PDA targets in one project). I also agree that the auto populating feature is rather disturbing than useful. My projects never contain the low level functions but only the top level functions of each target, the dynamic VIs in a seperate folder and any GUIs in another folder. Possibly I add another folder for some specific VIs etc. I still organize my files on disk too but I find it useful to have another level of organization where I can maintain a somewhat different logic of how to organize my VIs than what it looks on disk. The feature that is called autopopulating folders by NI (just copy the disk hierarchy into a seperate tree view) is not useful at all in my view, and does cause all sorts of headaches for the NI developers too to avoid cross linking in the project. That all said I still have projects that were developed in earlier LabVIEW versions and are currently maintained in LabVIEW 7.1.1. So I couldn't even throw away the traditional way of organizing VIs even if I wanted to. QUOTE (jgcode @ Mar 19 2009, 10:56 PM) neBulus and Neville D Maybe this would have helped? Real-Time Target System Replication I haven't used the code personally but I know they exist as I was investigating for a similar thing for a project that went cold last year. Now there is one for FPGA too. FPGA Target System Replication While I haven't used the latter the first one is indeed working. I didn't use it for multi target deployment but built them into the host application to have a user friendly way of updating the RT target with a new software version if that should arise. It is a bit tricky to built it into a user application in a way that it can be used by people not familiar with LabVIEW or even programming at all. I made it basically a one button click operation in the maintenance screen of the application together with another button to discover any cFP target in the local network to fill in the IP address to use. Seems trivial enough to use. Rolf Kalbermatter

QUOTE (RickAlta @ Mar 19 2009, 07:59 PM) It sure is messy and with a lot of troubles. The alternative is to create a LabVIEW DLL from that VI and export it as a C function (watch out for the function prototype to be exactly like what the callback needs to be). However that has also its own problems. Unless the LabVIEW version calling (indirectly through .Net) this DLL function is exactly the same than the LabVIEw version used to create that DLL, the VI will execute in the LabVIEW runtime version that was used to create it and hence be a seperate process. This means there is no possibility to share LabVIEW data between your caller and the DLL directly since memory pointers, refnums and just about anything else have no meaning in the other. The same would apply if your .Net component would execute out of process since it would invoke the C callback pointer in its own process that would instantiate the according LabVIEW runtime. The real question is why do you have this C .Net wrapper? If you would go directly to the .Net component and it would use .Net events for this asynchonrous notification the problem would be solved if you use LabVIEW version 8.0 or higher. There you can let LabVIEW handle .Net events directly by assigining it a callback VI that will be executed on occurrence of the event. This whole .Net C wrapper makes everything unnecessarily complicated for you. Rolf Kalbermatter PS: If you can go with something more recent than LabVIEW 8.0 because of two reasons: 1) LabVIEW 8.0 had quite a bit of quirks in many areas. I have found LabVIEW 8.2.1 to be a lot more stable and reliable but 8.5(.1) or 8.6(.1) should work just as well. 2) .Net events were new in 8.0. So I would expect them to have one or two quirks that you might run into in that version that might have gotten fixed later.

QUOTE (mesmith @ Mar 18 2009, 08:50 AM) No it is not exactly as you seem to think. Lets take your example: The proxy address is usually in the form of "myproxy.mysite.net:8080" since it seldom uses the standard HTTP port of 80. So you parse that address into the DNS name (everything up to the colon) and the port number, using 80 if there is no port number. Now pass this information to TCP Open. Then you have a HTTP Request of the form "GET /index.html HTTP/1.1". Since the Proxy must know to what server to forward the HTTP request you have to modify this by prepending the server address to the absolute path of the resource. So the command to send to the proxy will be "GET http:/www.google.com/index.html HTTP/1.1". That's all. Rolf Kalbermatter

QUOTE (neBulus @ Mar 17 2009, 02:31 PM) I do not have any exact numbers but it is probably quite a fast fix indeed. In earlier days (LabVIEW 3 and so) patch fix releases where actually a lot more frequent with the f number sometimes approaching two digits. So there might have been some that were actually released as fix before anyone extern to NI might even have noticed them. However I do think they should make it somehow possible to release such fixes more frequently and allow an easy installation. A lot of LabVIEW is nowadays not in the actual binary executable anymore but in external VI files, although mostly password protected, so it is often a matter of replacing one or two VI files in a LabVIEW installation as was with this particular bug. That could be easily made more frequent since the test scope of such a modification is rather limited. For changes that get into larger components like the LabVIEW executable itself I do understand that the testing before releasing is a major pain and they probably never will go to release such fixes in lets say a monthly interval. If those VI based tool would not be password protected we might fix them ourselves and make them available but as it stands now we have to rely on NI to do that for us. Rolf Kalbermatter

QUOTE (mesmith @ Mar 5 2009, 02:05 PM) I use SVN in several applications for some of our customers to version control Lua test scripts that they write. If they do not have a fully blown Apache server available to run the SVN repository on, I just have them install the SVN service on a regularly backed up spare machine. Usually their IT dep does the maintenance of that. This allows as many test stations as they want to be synchronized with the central repository. Each test station does a SVN Update on startup and an operator can easily force a manual Update from the application menu at any time. The application also allows to visualize the status of the local repository (modified, stale, conflict, up to date) and all individual scripts and also allows maintenance including committing changes, but most people seem to prefer SVN Tortoise to do that :-). I first intended to write an intermediate DLL to access the SVN API directly from LabVIEW, assuming this to be a cleaner solution than the command line tool. But time constraints made me opt for a System Exec approach instead for a start and it is working so smoothly I guess I won't consider going back to get the DLL interface ready. The SVN DLL API while very powerful is also quite involved (and certainly in no way suited to be interfaced directly through the Call Library Node). So I have a hard time to justify the rather big time investment since the command line tool works so good. Rolf Kalbermatter

QUOTE (mesmith @ Mar 4 2009, 03:02 PM) That is because a proxy is only meant for HTTP (and possible other similar protocols like FTP sometimes). The LabVIEW TCP/IP nodes access directly the Winsock library and the thing that does for IP what a proxy does for HTTP is called a network router . So it is not a problem of the LabVIEW TCP functions but simply a question of proper setup of your network. Basically a proxy simply acts as a web server that does hand the HTTP requests through to the end server (that could again be another proxy and so on). The way to handle such a case in LabVIEW is by making a thin layer above the TCP/IP nodes. By the way the OpenG HTTP functions do some proxy server handling. But it seems they have not been packaged yet, however they are on the OpenG Toolkit CVS server repository on sourceforge. Basically you open a connection to the proxy instead and then you have to parse every HTTP request and prepend the actual end address of the desired server to every relative URL in there. Rolf Kalbermatter

QUOTE (stevea1973 @ Mar 13 2009, 03:53 AM) No! LabVIEW has no way of guessing the padding of data structures and consequently it does not try to do that at all. LabVIEW itself always uses fully packed data (with possibly one exception on the VxWorks PPC real time targets but I haven't verified that for sure since I don't have the hardware handy and haven't really run into an issue with that yet). Another explanation why it does work without those padding bytes might be a #pragma pack(1) statement in the relevant header file before declaration of the data structures (and an according #pragma pack() after that, I would hope). Rolf Kalbermatter

QUOTE (ACS @ Mar 11 2009, 03:38 PM) When you say it returns an array pointer do you mean returning it as function return value? That would be a very ugly way for an API to return such a parameter!! And if those process identifiers are really strings that parameter is anyhow not for direct LabVIEW consumption, really! However I would assume that they contain instead 32Bit integers for all practical OSes nowadays (possibly excluding 64 Bit versions). At least under Windows and Unix, OS Process Identifiers (or PIDs) are simply 32Bit numbers that can be passed to other APIs to identify a specific process. But since it is an array you will first need to know how big it is anyhow, before you can do anything. Can you give us the function protoytpe so we can see how it looks and what direction we will have to look for? Rolf Kalbermatter

QUOTE (JustinThomas @ Mar 9 2009, 09:55 PM) 1) You could use some Install Builder like Install Shield to bundle all 3rd party libraries into one installer to be run. 2) Or you could write a small LabVIEW app that executes the various extra installers and launch that. 3) The poor mans choice would be to create a patch file that calls the multiple installers and have that executed instead. The OP of this thread however explicitly did not want to run that extra installer at all. Just bundle it on the CD so it can be installed manually if the need arises. Rolf Kalbermatter

QUOTE (Jorge Moreno @ Mar 9 2009, 05:20 PM) ActiveX components need both be installed and registered on the PC you want to run them. Your Automation Nodes most probably throw errors (in the error out cluster) that you might have forgotten to handle, so the LabVIEW application tries to tell you that it can not load, initialize, or execute the ActiveX component but your lack of error handling hides that from you. Since a VB component also needs the according VB runtime installed it would be best to create a component installer in VB for your component which will also take care about bundling the right runtime and possibly other support libraries and on installation register all the necessary components on the target system. Then run that installer along with the installer for the LabVIEW application. Rolf Kalbermatter

QUOTE (CzaroK @ Feb 24 2009, 11:10 AM) There are a few caveats with this for sure. First you can not add a System ODBC Data Source if you do not have administrator or at least power user rights. So I doubt this is what you want to do in a built executable. Also you can simply format the parameters that would otherwise be created with the ODBC Data Source Manager dialog into a string and pass that string to the Open Database function as connection string, instead of a name to an ODBC data source. To see what you would need to put in a string you can basically configure on your development machine such a datasource through the ODBC manager and then fgo into the registry and look at the keys in the section for your data source in HKEY_CURRENT_USER\Software\ODBC\ODBC.INI for user data sources and HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI for system data sources. You basically just put each value in there in a format <keyname>=<keyvalue> and separate each such expression with a semicolon and you should be fine. No need to create a Data Source and you can even format the actual path to your .mdb file no matter where you have it installed. Rolf Kalbermatter

QUOTE (Joshuatronics @ Mar 6 2009, 10:21 AM) A program not crashing is absolutely no indication that everything is alright. Calling functions that take a buffer to return some information where the buffer is not allocate large enough, can cause anything from no problem at all until you do something else, crashing on exit only, crashing at a point much later than where the actual corruption occurred to crashing at the moment the memory corruption happens, but it could also have more subtle problems such as overwriting actual data used elsewhere in your program so that some subVI suddenly seems to return wrong results. This could theoretically go as far as corrupting some non crashing information in a VI or other file in memory and then after you save the file to disk you have a corrupted file on disk, that might not even be loadable anymore. So unless you did something you can securely attribute to having caused the lack of crashes now, I would be very uneasy about the fact that the application is not crashing anymore. 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