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

Hi Don,

I know the way to pass in LabVIEW allocated array for C program to process, but never done the reversed way to pass in a C allocated array for LabVIEW to process, but I think there is a trick that you can use a C allocated input array (usually pass in as array pointer, the pointer can be treated like U32, so the pass in parameter maybe an integer, not an array directly) for LabVIEW to use, just I never need it, so I didn't bother to remember how, but I think Rolf has mentioned in info-labview some time, I didn't read very carefully :-(. But on the other hand, maybe there is a setting when you create LabVIEW DLL, that let you specify the input array as pointer, have you check this? Maybe then everything will be taken care of automatically.

The output array is easier, I think, because you can allocate the output array in LabVIEW, then output the array pointer to C program, C program can make use of this pointer.

I am not sure if I talked my mind clearly or not, anyway, something is better than nothing:-)

Irene

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

Don

Would it be possible for you to share the VI that is performing the actually PCA?

BR

Anders

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 Don,

That is exactly what I meant, sorry for the confusing term. It's the function description (like vi, what does this function do and the input and output parameter's type and descriptions).

Regards,

Irene

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

Yes, your right, it outputs 4 images, but I did specify 5 images, starting from image 11 to image 15, see below parameter declaration.

int numPCA=5;

int startFrame=11;

int endFrame=15;

You can just give him the full installation (including the LV8.2 runtime engine) and the function calling document (you can also put that in the PCA.h file, commenting out with //). That should be enough. You can certainly also give him my very simple example project in C if you want.

Regards,

Irene

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

Hi Don,

I got your message and I have tested it. The lvanlys.dll has to be in the Data folder, then no popup window anymore (I think LV installer puts it there automatically), but I must have moved it to different location the first time for some reason, that was my mistake . Other than that, your DLL works great.

Regards,

Irene

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

No problem, I have some time. Let me know the ftp site when you are ready. But just doubting if including the RT engine will change things than install it separately. But you never know. I can give a try.

Regards,

Irene

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?

Hi Don,

I have tested the PCA.dll. Attached is the simple console C program. Here are few points for the testing:

1.Yes, you do need to distribute the LV8.2 runtime engine to C programmer.

2.In the example I have hardcoded the image path to "C:\\Downloads\\Labview Downloads\\Ivst - with sample" if you want to run the "TestingPCA.exe" in release folder.

3.It produces many PCA images, not just one if I set "the number of principal component images to calculate" to say 5, it gives me 5 PCA images.

4. It seems there is LabVIEW vi searching dialog window poping up when runing the calculation. I thought that was because I moved the "lvanlys.dll" file to different location, but when I put under the same directory as TestingPCA.exe and PCA.dll files, it still poping up. So maybe some other dependancy files not in the same directoy as when you created the PCA.dll?

I hope this will help.

Best Regards,

Irene

Don,

I think your wrong. You can build an installer for the dll? or not?

well the 8.2 runtime is here:

LV 8.2 runtime

I think the smaller one is sufficient for dlls (lvruntimeeng.exe)

Ton

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

Hi Don,

I can help you to test by writing a C console program. Don't I need LV8.2 runtime engine to call LabVIEW created DLL? I haven't used LV8, if you have a quick link to where to download the LV8.2 runtime engine, that will help. I will test it over weekend if this is not too urgent for you.

Regards,

Irene He

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

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.

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

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

I think you left out another 8.0 feature no one talks about: The Mixed-Signal graph. Does anyone use this thing?

Sigh. My work is so un-appreciated :headbang:

J

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).

Some of you may know me from other LV venues -- info-LV, NI's DevZone. I've only recently created an account on LAVA mostly because of the discussion on the info-LV mailing list where some are claiming that forums are better than mailing lists, so I figured I'd come look around. And, being a LabVIEW R&D developer, my greatest interest, naturally, is the bug list and the comments about the newest versions. So I read through many of those over the last couple days. And I'm amazed. There's a lot of discussion about LV8.0, but there are some pretty big features that get almost zero mention. Users discussing any software are going to focus on the bugs and the things that went wrong -- that doesn't bother me. But there are some real gems in the 8.0 release. So I thought I'd list some of them here, just to see the response generated.

1) XControls : This, in my opinion, is the #1 reason to upgrade to LV8.0. I think this is the answer to many of the UI complaints made about LV. This feature is invaluable to making reusable user interfaces. It

The icon editor discussed here is not meant for executables but for VI-icons. However it can be modified to build .ico files to go with the executables!

Ton

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.

There is an upgrade to Vision (i.e. Vision 8.20) that has been released to coincide with LV8.20

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

There is an upgrade to Vision (i.e. Vision 8.20) that has been released to coincide with LV8.20

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

Here is an example VI (LV7.0) that shows how to manipulate text in a text box. The focus of this example is the Selection Start + Selection End property. This can be very powerful in performing custom live formatting of front panel text.

The trick here is to perform formatting on the text after you highlite the section of interest. The Font property is then used within the same property node.

1084[/snapback]

Download File:post-115-1089650321.vi