donroth

It looks like user32.dll should work according to: 0 down vote There is no user64.dll for the exact same reason you just describe, .net program can be agnostic to cpu architecture so the same code needs to work on x86 and x64. If you take your program to x86 platform it will still run without any modifications. I guess that when they named user32.dll they didn't have those scenarios in mind. http://stackoverflow.com/questions/1540741/c-pinvoking-user32-dll-on-a-64-bit-system So I am assuming maybe I can start to fool around with this stuff by just downloading some of the above VIs?......Don

Can we still use user32.dll for 64-bit LabVIEW? It appears the VIs shown above or equivalent snippets would be a good starting point rather than reinventing the wheel if user32.dll is still valid to use in 64-bit LabVIEW.

Hi Folks - Does someone have the code to make a non-VI window called from LabVIEW always on top? I have a .chm (help) file I call that gets lost behind a background window if it is not always on top. Also it is built with 64-bit LabVIEW 2010. That said, George Zou basically created a 64-bit version of one of his previous VI utilities to do just this, and I have it and it works great (Thank you George). Problem is I need to build a 64-bit executable for another guy in the lab and since the VI is password protected, the executable builds but when we go to run we get the following error. LabVIEW: Resource not found. An error occurred loading VI 'Make Window Always on Top64.vi'. LabVIEW load error code 3: Could not load front panel. So I think the password protection on the block diagram is really what is causing this issue. In the meantime, I can't find George. We had been emailing over the years but I must have deleted some emails because the last one I can find for him is back in 2002. (George - if you are out there somewhere and can address this, let me know.) In any case, it would be best for me to be able to do this myself. If anyone has a VI that they can post that has an string input for window name (non-LabVIEW window) that will do this, it would be quite helpful. Thanks, Don

As mentioned, VI Server functions cannot replace or address all of the versatility of these functions, nor the child window handler.vi, at least as far as I can tell. Else I would have no problem using the VI server functions. Don

Hi LAVA members - I have some windows utilities that I am sure others here have used (and maybe even were responsible for developing). These include the LVWUtil32 libraries (primarily the WINUTIL.LLB). See: http://sine.ni.com/d...a/epd/p/id/4935 and a 'child window handler.vi' that have served me extremely well over the years in 32-bit applications. I have to upgrade one application to 64-bit using 64-bit LabVIEW. These utilities will not work of course without being modified and recompiled for 64-bit. VI Server functions cannot replace or address all of the versatility of these functions. See: http://forums.ni.com...ht/false/page/2 Has anyone considered upgrading these utilities for 64-bit application? Is anyone interested in doing this and iterating with me so I can validate in my application and we can supply an 'OpenG' type library to the community? Thanks, Don

I thought about contacting Rolf directly when I first started this project. It does seem like he is a master when it comes to understanding the creation and use of DLLs in LabVIEW. I was hoping he might be reading this. I started a forum thread on NI discussion forum regarding this very topic (direct use of input and output arrays when creating LabVIEW DLL) awhile back but I have not gotten sufficient resolution to this issue. Passing by value cannot be done for arrays, and in my preliminary testing early on, I was not able to resolve how to interpret the output pointer to array and the like. I'm tied up now but need to revisit this again as time permits. A simple example regarding use of arrays rather than stored disk images pertinent to our PCA DLL creation effort would be appreciated if anyone would like to contribute. Sincerely, Don

Yes, sorry for the late reply. Its operation has been validated against other language versions of PCA. I have a neater version of this code in state machine format that has separate steps in separate cases - but I think this version reading from left to right should be easy to decipher....Don One other thing I would like to figure out is how one would create the LabVIEW DLL if the inputs and outputs were arrays rather than stored images. The handling of arrays, allocations of memory, and determining interpretation of outputs that I believe have to be passed as pointers rather than by value has confused me to this point with respect to DLL creation. I would be interested if someone has some thoughts on this. Sincerely, Don Sincerely, Don Download File:post-115-1167314982.llb

Hi Irene: Thanks again. One more point regarding your results when running. The reason you got only 4 images even though you specified 5 is because the maximum number PCA images you can get is the result of the subtraction of (# of ending frame from original images - # of starting frame from original images). Since you specified 15 and 11, respectively, 4 is the maximum. The way you want to use PCA is to use pretty much all of the captured frames (I gave you 100 I think, so you'd start with 0 and end with 99; and really I had 225 to give but I just wanted to give you a subset so would take less memory). Then if you specified that you wanted 5 PCA images, you would not be limited by the start and end frame numbers in this case. You might want to try just so you see what a true set of PCA images can look like. Once again, I appreciate your help. Sincerely, Don

Hi Irene: Not exactly clear what you mean by 'function calling document' - do you mean the documentation on the inputs and their types as I described in one of my first messages above? Sincerely, Don

GREAT! Now when I hand this installer off to the c++ programmer who knows nothing about LabVIEW DLLS, what documentation do I need to provide him with other than what I originally mentioned to you (the inputs, outputs [in this case = none], and formats of such). In other words, after the installation, what do I have to tell him to do to get this working in c++? Is there anything special that he needs to do or you did? Thanks much! Don

ps. Irene: I retested your C executable after putting the original images in the correct directory in your heirarchy - it worked fine. Sorry about not doing that originall. I got 4 images, not 5, so I expect you hardcoded 4.....Don Hi Irene: I sent you a private message regarding ftp. Sincerely, Don

Hi Irene: Many thanks for testing this. Given the issue of the dialog below, it seems a good idea to follow this up by building the DLL installer to see if the LabVIEW VI searching dialog goes away. The problem is the installer is about 70 mbyte because it includes the RT engine which precludes uploading it here. I can put it on an ftp site for you to download if interested for one more round of this. Let me know. If you have run out of time, that is OK, and I appreciate this effort below. Sincerely, Don ps. I created the folder heirarchy you suggested so I could test "TestingPCA.exe." I do not see the images anywhere. I used filelocatorpro to search all of c: just in case they were placed somewhere else. The console window popped up but went away so quickly, I could not for sure tell whether it recorded an error. I think it said it finished successfully. Any thoughts here?

I think you are right. I don't know why I thought differently. I have built installers for v8.2 applications and knew they were responsible for installing the LabVIEW RTE - I have to look and see what all is involved for building an installer for DLLs. Perhaps it is close to the same procedure. I don't know why I thought one did not need the LabVIEW RTE for DLL use in different environment. I had in my head that the DLL files contained all of what was needed. Irene: If you want me to try to build the installer for this, I can. But it might be that the RTE is all you need. Maybe Rolf or someone from NI can clear this up?????... Thanks for your input. Don

Hello Irene: Thanks so much for your reply. In the project environment in LabVIEW 8.2, one can build an installer for a built application and the installer makes sure to include the run-time engine. For DLL building, the only thing that is offered is a build specification, i.e. there is no opportunity to build an installer as such for the DLL. Therefore, I am under the impression (and I may be wrong), that the only thing I need to supply are the .h files and necessary support files that are created during the DLL build process. Therefore, the only thing you should need are the support files I have in the .zip file. Can someone correct me if I am wrong on this? There is a LabVIEW application note that discusses integration - http://zone.ni.com/devzone/cda/tut/p/id/3517. But it seems somewhat out of date. It does mention the LabVIEW run-time engine, but again this becomes somewhat confusing because there is no opportunity to build an "installer" for the DLL. Sincerely, Don

Hello: I created a LabVIEW DLL in v8.2 that performs principal component analysis. I have successfully tested this within LabVIEW. Now I need to see if it will work in the C++ environment. I am asking for guinea pigs if anyone would volunteer to try this and tell me what is needed to get it working in that environment. In return, you get to keep this algorithm. I supply some sample time series of images within the .zip. Any help is greatly appreciated. "This DLL calculates Principal Components (PCA) Images and stores them as .bmp images to disk. It is fairly rapid. Specify: 1) the folder location of the I vs. t .bmp images (char string) 2) the starting frame # I vs. t .bmp image to use in the analysis (I32) 3) the ending frame # I vs. t .bmp image to use in the analysis (I32) 4) the number of principal component images to calculate (I32) I save the PCA images in the same folder as the original I vs. t bitmaps are stored. I name them *_PCA.bmp with * being equal to 1 to n where n is the number of PCA images you have chosen to calculate." Sincerely, DonDownload File:post-115-1165505846.zip