Michael Aivaliotis

Sounds great! Show me the code.

You can also buy them for the PCI bus!! They are made in my old home of Toronto for gods sake!!... and the company is called LAVA!! Aaaaaahhhhh!!One Port Parallel PCI card Damn, it's carma.

There are examples that ship with LabVIEW containing code to do exactly what you ask for. Did you search the built-in LabVIEW DAQ\DIO\COUNTER examples?Try that then come back for more.

As long as the code is clean, conforms to the documentation guidlines indicated, and performs something usefull, there's no reason why it can't be submitted right now. It does not have to be the "ultimate". After submission, we can suggest features or improvements and harass you with bug reports .By the way, in my opinion, a pie chart is very limited for visualization. I think, some support for "squareifying" the view is essential. Also, try to start your coding project with a state machine. It will become unmanageable pretty quickly without one.

Yes, it's always a trade-off. You need to view the file easily, but that means others can as well. One workaround is to come up with an encoding scheme that takes the text file and scrambles it just like robijn mentions. Then you should create a decoding tool\VI that you can run independantly of your main app. You can call it Dan Bookwalter's super duper general all-in-one decoder encoder tool. You can use this tool every time you need to view\edit\change these "special" files.I would suggest sticking with text instead of binary. The nice thing about text is it can be parsed and data can be extracted in a variety of smart ways. It also allows abstraction of the data file from the code that actually generates the data.This is why XML is powerfull. Don't use XML just for obfuscation or security. Use an encoding algorithm for that.

The parallel port is back with a vengance!

Nothing beats SequoiaView.

So? There is always room for a better, or different implementation. In fact, just because you said not to do it, makes me want to do it even more.

Awsome! Thanks for sharing.

Well, that sucks... I thought I read on IFLV that it was up again. Anyway, it really is comming soon. Scott emailed me a few weeks a go that he was working on it.

I consider discussions about IFLV such as: "is the server down?" or, "is it still usefull?" and such stuff as "filler". I mean, if you have nothing else to talk about then I guess it's ok. It reminds me of "virus warning" emails. Rest assured, there are hundreds and maybe thousands of people reading IFLV. There are also people working behind the scenes, monitoring the mail server and responding to technical issues. As has been stated before, IFLV is an alternate venue for discussions about LabVIEW. You don't necessarily have to pick one or the other. Heck, why not even read the NI forums if you so fancy? Searchview is also back up and running, which means archived IFLV is there if you want it. This topic is definitly one of those things that belongs as an article in the knowlege base under FAQ's...

Please upload a sample VI or image. If this is true then it's a serious bug!!

So I guess I should start a dozen or more LabVIEW websites to increase the index eh? :laugh:

Just want to raise this again as a wish list item since it seems that some work was done in LV8.20 to address certain search use cases but this one STILL is not addressed. Ignore clones, ignore vi.lib etc. Please add a checkbox to ignore password protected VI's.

I just refuse to use any type of Google Reader or Google email... Mainly because everyone is using it. There is no logic behind this choice. It's too hip. I'm using some other web based email program but I won't mention it because I don't want anyone else to use it. If this sounds ridiculous, then that's the way it's suppose to sound.

I suggest you get the latest copy of LabVIEW 8.20 (legaly) and open your existing code and start fixing the areas of concern. On the other hand, If you only have 6.1 then just program away as you always did with that version. Just because a newer version of LV has some cool new feature doesn't mean you have to incorporate it into your 6.1 code or make sure it will be compatible with 8.20. The newer versions of LV will automatically recompile and replace deperecated functions with newer equivalents, most of the time, automatically. Just beware that once you start using 8.20 features, then you cannot, in general, downgrade your code to an older version.

In my opinion, this single feature fulfills most of my use cases since I can make my own code to do what I want.

I would like to see the following features in future versions of the application installer builder. Ability to use keyword substitution in the information fields. For example, if I want to specify a subfolder where I want my shortcuts to be installed, I should be able to specify [Manufacturer]\[ProductName]. It seems that some fields support this but some don't. It's not consistent. Ability to hide the path selection field for National Instruments software installs. I prefer to hardcode this and not allow the user to change it. Ability to launch an EXE before or during the installation. This exe may be included with the installer. Also this exe may require the LV run-time which means that we need the ability to install the run-time first. The "run the executable after the installation" option should have the ability to show a checkbox to the user to selectively run this if they want. The additional NI installers must have an option to download from the web (NI site). This way we can reduce the distribution size. When selected, the installer would download the required setup then run it. In addition to this we should be allowed to overide the NI web distribution URL. This would allow companies to re-distribute the installer on an internal server if necessary. The additional NI installers only shows what's installed. It would be nice to allow selection of other versions not available on your machine. More powerful "system requirements" section. For example, only install if specific registry keys or files exist. Finally, the ability to bundle the install files into a single setup.exe.

Why not just copy the VI's to a new location via file explorer? They'll still point to the common code base. Am I missing something?

Hmm, I have not created one from scratch in 8.x. I too did the work originally in 7.x. They seemed to inherit the other states by just upgrading to 8.x. I know the process can be automated because i've seen it done. I can't recall how at the moment.

Even though your idea is also a good one, I was thinking something else. Actually, I always makes sure all my VI's are in memory. Is there any other way to code? Before the project view, I had a VI Tree vi that I used to place all my important vi's on the block diagram. I then open this single VI to make sure I have everything accounted for. There are several reasons I like this. The primary is that when you update typedefs, all VI's get updated automatically without later surprises. When you use the save as feature with rename, all refering VI's get updated without later surprises. When you do a search, all VI's get searched. There are others that I can't recall right now. I'm not saying that this should be a default feature but something that can be turned on, on a per\project basis. Perhaps there's another way to address the above uses-cases in LV8.x but right now, I don't see it.

I'm getting used to the new project view in LV8.x. A feature that I think would be neat is the ability to specify a VI or LLB that will automatically get loaded into memory when you open a project.

Congrats, you win!

Chris, as I'm the guy who created the original "master" button, I think I can help out a little... I'm not going to give away the secret just yet. I find it interesting to see everyone trying to figure it out. You are so very close with the decal concept, however, as you can see, when you click on the image, it doesn't shift down and to the right as in VIPM. Keep trying

Original Post: http://forums.ni.com/ni/board/message?boar...315#M205315 This was reported to R&D (#41DGI1R0) for further investigation.