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

FYI, I just had to create an executable in LabVIEW 8.2 and it has a built-in icon editor for executables. (Don't know if 8.0 had this, I went pretty much directly from 7.1 ---> 8.2.). This was long overdue and a welcome addition for me. Don ps. I see in the prior post that this was available in LV8. I had replied to my earlier post prior to seeing this reply....Don

In the Mixed Signal Graph.vi example in LabVIEW (8.2), you have instruction number 2) as "Try dragging the plots from one Group to another Group. You can also change the grouping by dragging plots onto the Plot Areas." I'm fairly certain I have dragged tree control items previously but I don't seem to be able to do it for this example. Forgive my ignorance. On another subject, I would say I have had applications where 10% of my features have been taken advantage of. Don't feel bad. There are a lot of LabVIEW users who are very busy and just have not had a chance to upgrade to v8 and above. There were enough changes under & over the hood (cursor palette display, data storing, etc.) also that it was a little intimidating if in the middle of an application with v7.1 (which seemed to me to be a very stable release). I am just now after a year starting to play with v8 (actually v8.2 --> I have pretty much totally skipped v8.0...just no time this last year).

I have not looked at the code yet for these editors. I have been toying a little with LabVIEW 8.0 this week and am going to download LabVIEW 8.2 today as I have SSP subscription. Anyhow, what would be needed is a way to programmatically make 16-color and 2-color 32 x 32 and 16 x 16 icons, and the ability to save as .ico file.

Actually I did find out is supposed to be released mid-September and is only to address compatibility w. LV8.2-- no additional capability.... Don

Are you sure it is Vision 8.20 and not Vision 8.0? An NI representative left me a message and did not know of a Vision 8.20. Don

Do the various icon editors discussed here allow one to create the icons needed for executables? I have not upgraded yet to 8.0 (going to go directly now to 8.2) but if one refers to the application builder that goes with LabVIEW 7.1, I refer to the icons shown on "Application Settings" tab. Don

Thanks for your reply. The problem becomes how do you make it work when you want to fire the same event both from the subvi and the main using an efficient user event strategy. If you want to see what we came up with, I was working with someone on ni.com and we came up with a good architecture for this type of problem that uses queuing in combination with a user event to do what I need. A producer-consumer architecture is also employed (but not really necessary to demonstrate the solution for this problem). Here is the thread and the most recent architecture. Sincerely, Don Download File:post-115-1134420948.llb

ps. I want to make one clarification. I stated: "if the user event has been triggered from the subVI, it will not trigger from the main VI. And no error is present upon 'Generate User Event', it just does not work." What I should have said instead of "it just does not work" is that a "timeout event fires rather than the user event." I see I have a number of downloads but so far no words of wisdom. I'll just assume everyone is stumped for now. I think I will submit this to ni.com to see what they have to say about this. Sincerely, Don

In this attached simple LLB, I employed Aviolaitis strategy in an example for deploying user events between VIs. To demonstrate: 1) Run VI 2) Click 'Open SubVI' button which open 'test_subvi.vi' 3) In the image on the front panel of test_subvi.vi, move the cursor to any point on the image; this will cause a user event to fire in main that inverts the waveform. 4) Similarly, if the user clicks the 'Stop' button in the test_main.vi, a user event will fire in the subVI that closes the test_subvi.vi front panel and stops the subVI Here is the issue: If I want to fire a similar event in the main that I did in the subVI, in this case 'Invert' which will invert the waveform, if the user event has been triggered from the subVI, it will not trigger from the main VI. And no error is present upon 'Generate User Event', it just does not work. My first thought was that I needed to reregister the user event in the main VI after triggered from the subVI. So I tried reregistering the event in the Invert event case in 'test_main.vi' prior to generating the event. Still did not work. I wanted to know what the explanation for the current behavior might be and how it might be rectified. I have plenty of workarounds but I wanted to know if there is any way this can be made to work with some simple steps. Code is LV 7.1. Thanks, Don Download File:post-115-1132767576.llb

[attachmentid=undefined]Wouldn't you want to do this more efficiently with event structure? .... Don Download File:post-115-1089650321.vi