m3nth

Yep, you can always reverse engineer the installer it is mostly copying files and putting in registry entries or instead you could just run it

5484[/snapback]

By the way Kennon, welcome to the forums. I'm not sure that this has been discussed here, but part of the problem with running the RTE is exactly what you mentioned--that it makes registry entries, installs stuff, doesn't clean up after itself automatically, and usually requires administrator priviledges (for making registry entries, which causes it to fail if you don't have admin privs). So a lot of times it's desirable to find the files you need and copy them in an archive for easy deployment. To date, I have not needed to 'reverse engineer' the run-time engine installer since it dumps all the files in one convenient location... at least all the files that my programs use. I don't know about this whole sub-linkage lvanlys.dll bit--I've never had that issue come up--but it is a lot more convenient for me to not have to run the installer on every PC I use. This issue becomes especially important also when creating portable apps that run off of a USB drive. How portable is an app if you have to run an installer every time you use it? On top of the fact that the installer will likely fail without admin privs. So there are definite advantages to finding the files you need and being able to distribute them in one bundle.

Now if you are just trying to copy the EXE and the files in the RTE over to another machine, you could/would miss these secondary DLLs and might not copy the right one.  So it is important to run the installer for the RTE.

5476[/snapback]

I haven't had time to look at this but if they're just files that you "could/would miss" then that means you can go find them and copy them.

There's probably a way to find the external dependencies in the dll code itself but that seems somewhat complicated.

Try copying all of the files into your application directory that would normally be installed with the run-time engine and see if that fixes it. If everything is there it shouldn't be complaining.

You're right, that stuff is pretty easy--probably why it is your assignment and not ours.

You can do a lot of those things by hand, as the previous post said, or in Excel. If I were you, I would come up with a given data set that you're going to use for testing. In LabVIEW I would enter that data set into an array of numerics. After that, I would figure out how to do the processing on that array to get the desired results. That is very very basic and reasonable to expect you to learn as much on your own. Isn't that the point of school anyway? Learn how to learn. Good luck.

I'm sure there are probably better ways than this suggestion--perhaps even your occurence might work if it was modified--this is just what comes to mind though.

You can obtain an event queue with a static name const. You can also obtain the same queue by using the same name in your second VI to queue events. The queue event handler would be in the main VI to handle the case for when your second VI closes.

Or you could use notifications. I believe they are the replacement for occurences.

I do large image screen captures of a waveform graph sometimes. Since I started out with HTML reports in the first place all I needed to do was figure out how to make the images scale instead of being absolute size and having most of them cutoff during printing.

What has worked very well was to code a few routines which I'm sure you could use, but I don't have them around at the moment. I think I modified the append image to report vi. I added the HTML code to basically make the picture either 100% of the width, or 100% of the height--of the window. I looked the commands up on numerous html tutorials online. That way when you look at it it's sized correctly in the browser, and when you print it it gets sized correctly for the paper.

To handle printing the image landscape instead of portrait, I coded a routine that will just rotate the image 90 degrees. That way scaling to 100% height makes it full page!

Perhaps sometime I can find my routines for you.

...LabVIEW\vi.lib\Utility\Libraryn.llb has these files of interest for dealing with the version #.

- App Version to I32

- I32 to App Version

- App Version to String.vi

Using Jim's VI posted previously together with the I32 to App Version and App Version to String, you can format the version to a string, just like the Application Method (Get VI Version). The Application Method returns the version both as a string and as the raw U32 LabVIEW internal format.

The internal format of the U32 version (according to the documentation) is as follows:

- U8 - Major Version

- U4 - Minor Version

- U4 - Minor Minor (bugFix) Version

- U4 - Stage

.............. 0x2 = Devevelopment

.............. 0x4 = Alfa

.............. 0x6 = Beta

.............. 0x8 = Release

- U12 - Build Count

Does anyone have any suggestions or rules-of-thumb on the easiest way to transfer a file over a network? I would also be interested in any libraries that have already been made for this.

I can open a TCP/IP or UDP connection to my client but I don't have any code that will easily set up a file transfer.

Sorry... forgot to look at your version before posting... this should work in v7.0.

The example shows how the subVI may be used in a 'global' manner anywhere in your program without having to have anything connected to the reference array terminal.

Download File:post-360-1121450651.llb

So i read up a bit on LV2 globals, and i have not idea how to implement what you are suggesting.

5362[/snapback]

Either you didn't read very much or you just didn't try.

See attached example.

Download File:post-360-1121446792.llb

Sorry i didnt specifiy aobut the extent of using SubVIs. I merely ment that i wanted to retain a single front panel, rather than create a new panel for each sub portion of my program(the advantage to using tab menus/ring menus, in my opinion). Thanks for you idea.

5344[/snapback]

I think that was understood from your previous post. If you put the for loop shown in the last post into it's own subVI you can manipulate your controls that are all on one front panel by using calls to the subVI. That way the subVI can take the place of some of your current block diagram code and reduce the amount of area dedicated to manipulating the front panel.

While someone possibly may find a solution to your problem, your VI's won't run as-is because you didn't include them all. Open your main application(s) and select File > Save with Options, and select Development Distribution.

Keep in mind that not everyone has the files you do in various places for your development setup and that not everyone has OpenG.

How exactly do I import this global variable value to my vi and change it?

5312[/snapback]

Well if you browse into the subVIs like I was saying you can find the global and just Ctrl+C copy it into your program.

If you want to insert it from a file you can right click the block diagram and go to Select a VI..., then find the VI and insert. The file (on my harddrive anyway) that you would want to insert (the one that I mentioned previously) would be:

C:\Program Files\National Instruments\LabVIEW 7.1\vi.lib\express\express shared\ExFile.llb\ex_FileGlobals.vi

I'd like to be able to reset all VIs in memory to revert to a clean state like when VIs are just loaded into memory. That is to reinitialize all controls to default value and clear uninitialized shift registers. The VI method Revert VI would do that except that it erases unsaved VI changes.

5313[/snapback]

The Reinitialize All to Default won't work because it won't clear the uninitialized shift registers. Revert VI works except it erases unsaved changes. Is there any reason then that you can't just save the VI changes before reverting?

Control values are static if they are not wired to the connector pane, so you can write to them using a local variable and compare the value later.

A better implementation is to use LV2 style functional globals by creating a loop with an unitialized shift register and a case statement inside the loop to select the action that will either set the shift register or compare the last value. Since the shift register is uninitialized it will not change values between subvi calls.

In your VI there are five different places where you are performing acquisitions, two of which are the same and where the acquisition is not stopped (SystemIN).

Are you sure the part you posted in the picture is the source of the error? If an error is being displayed on the screen it could be coming from one of five different sources... have you pinpointed exactly which one is generating the error?

Is it possible to change the text on File Selection Dialog Titlebar when it is called automatically by a Write to LVM File block? If so, how exactly?

5305[/snapback]

If you're talking about the function I think you are, place it on the block diagram then open the front panel. Browse until you find the file dialog:

Write LabVIEW Measurement File.vi > exSubFileWrite.vi > ex_WriteDataAll.vi > ex_FileDialog.vi

In that VI you'll see that there's a global file that is accessed to set the title, and basically the global is just a constant, so you could change it if you want by setting it in your program. The global file is:

ex_FileGlobals.vi

Variable "LVM file save prompt" reads "Select a file to save.", so if you were to import this global into your program and set the value before calling the Write LabVIEW Measurement File, it would change the title. If you wanted to change it permanentl for all future coding you would be doing in LabVIEW you could just change the value and set it to the default and not have to worry about setting it in your program.

Alright... I'm starting a post to vet what becomes common wisdom once you've been using LabVIEW forever, but which newbies are sometimes uninformed of. The thought behind this post was that I just discovered something "new" the other day that I have never seen mentioned anywhere and have never stumbled upon before. I wound up asking myself, "How come I never knew this?"

So having found myself in the newbie category once again, hopefully people will share their favorite insights here and maybe this thread will become a quick and dirty list of tips, shortcuts and techniques that can help the newcomer quickly become a masterful LabVIEW programmer! :thumbup:

What are your favorites? I'll start with these:

- My personal favorite is probably Ctrl+Double-Clicking to go straight to the block diagram

- My second favorite technique is the LV2 functional global

- The "new" thing I stumbled across the other day was double clicking the font in the icon-editor. This brings up a dialog to set the font you want if you don't like the default.

There are a few ways to cut down on space... some recommended, some not. The #1 not recommended way would be to right click the property node and select Name Format > No Names.

Besides that though what I would recommend is creating an array or arrays of control references. Then when you need to make those items visible you can just pass the array into a for loop with a single generic property node. Another plus when using references is you can then make subVI's to operate on your controls, since they don't have to be linked to the front panel. Once you've given yourself the ability to use subVIs, you can then make your subVI an LV2 global.

So for things where I have an insane amount of controls I need to work with, I create an LV2 global and initialize it with an array of references. Thereafter I can select any other function that I program the global function to do. So the moding enum might contain the values "Init", "Set Visible" and "Set Not Visible", but the only time it would need to be wired to the array of control references would be for the "Init" call, and thereafter the VI could be called anytime to perform the visibility functions. If you are not familiar with LV2 globals (also known as functional globals) I would recommend reading up on them.

I don't know what the VIs are and the item outside the loop is the Bundle function, located at: Block Diagram > Functions Palette > Cluster > Bundle

hi

i would like to create programmatically a .< .bld > file in order to build my application installer.

Can someone give me any info about the format of this type of file or, as an alternative, give me any link about free 'installation packagers'.

My target is a installer that  install a 'main program' and prompt user to select from a checklist, a series of sub-application SWs. These application are groups of VI saved without diagram called dynamically from 'main program'.

Hope to be understood.

Bye

5286[/snapback]

First, if you don't have the application builder, you won't be able to use a .bld file, even if you generate it programmatically.

Second, you won't be able to generate it programmatically without using the application builder itself, because basically a .bld file is just all of the settings in the application builder and they're dumped to disk in whatever format the application builder uses internally.

However, if by chance you do want to be extremely ambitious, and you do have the application builder installed, you can open the Dist Save Script.vi, found in the LabVIEW\project\proddist.llb. This llb is installed when you install the Application Builder. If you were to somehow set all of the input clusters correctly and call the Dist Save Script.vi, from the looks of the front panel, you would probably wind up with a valid .bld file.

Why in the world that would benefit you (as compared to manually creating the various builds you want to create), I have no idea.

As far as free installation packages, get OpenG (www.OpenG.org) and look at the stuff that you can use with that.

Reading your post again, I would also look into other ways of possibly doing what you're trying to do using VI server or something of that nature to call sub-programs from your main VI.

Correction to my last post:

The method I use did not work because when I resized the array some elements "jumped" to the other rows.

I had to use the 2 FORs method to avoid dynamic Array Reshape and initialize with the final size already.

I also had problems with the build array, that's why I started using the Insert Into Array VI.

Thanks, everyone, again!

5285[/snapback]

I think you figured this out already (at least it sounds like you did), but Array Reshape is not the same as resizing an array (which there is no single function for--requires an Array Intialize with larger size and then Replace Array Subset).

Reshaping an array is equivalent to deleting all the carriage returns in a text file so the text is all on one line, then adding carriage returns at a different place each time to make all the lines 60 characters instead of say, 80--it comes out with all the same data, just in different places (different array dimmensions) than it started out, which is why your elements "jumped" to other rows.

What problems exactly did you have using the Build Array function? If you have rows of varying length (ie, varying # elements/columns per row), and you're appending those rows to a 2d array using the Build Array function, the 2d array will always be automatically sized correctly and you shouldn't need to initialize a new array of greater size and fill it.

No, and without wanting to sound bad, I think this would mean that nobody except a LabVIEW programmer at NI might know if it is possible at all. I personally doubt it.

Rolf Kalbermatter

5269[/snapback]

That doesn't sound bad... I came to the same conclusion:

- The icon dialog is not a VI that gets called (like some of the other functions)

- It is only available by clicking the icon in the corner

- No other NI VI's use it or access it (that I've found)

I've filed it with NI as a scripting suggestion for future implementation.

Just use the Build Array function in a loop to add rows--the array will automatically resize if an added row has more columns then the previous rows.

I finally found what you were talking about and tested it out. I put in a formula of y=x^3 and set input value x=2 -> Output = 8. Then I switched the formula to y=3^x -> Output = 9. So it looks like it works just fine to do what you want it to do, which is probably an upgrade that was included after LabVIEW version 6.1 since I'm assuming you did something identical and it doesn't work right for you.