JDave

Thanks for the pointer Ton, I will give it another go tonight, but it seems like the information in that thread works with tools called from the Tools Menu. I don't think it worked for the icon editor because it wasn't called from the Tools menu. But I will try some more. I seem to remember that the MenuLaunchVI property was just empty when queried in the icon editor. Maybe I will toss that property node into mballa's code, just to see if I am messing something up. That is the probable thing... Thanks again, David

I am writing an icon editor for my LV icons and I wanted to use the filename to get text for the icon. But it doesn't seem that there is a way to determine what VI called the icon editor. I tried using 'MenuLaunchVI' and 'ActiveVI' scripting properties to no avail. The frontmost property doesn't work either, since the VI isn't frontmost anymore. The 'ActiveVI' property did work in 8.0, but not 8.2 I was pretty excited when I saw mballa's icon editor (nice job BTW :thumbup: ) had an input for the VI ref, but this was his own addition and it doesn't get written when LV calls it (e.g. upon double-clicking the VI's icon). It seems that the rabbit hole stops here for now.... Anyone found otherwise? David

I have felt the same way and since it came up in my programming again since reading this post, I thought I might chime in that I DO NOT like it. I would classify it as a bug, because it does not fulfill it stated functionality.

I am looking at acquiring 48 channels, simultaneous, at roughly 3kHz. This would require six S-Series NI cards, which is doable, but... I found a card from General Standards Corporation that will do the job (64 ch @ 200kHz), and I was hoping to get feedback from people here. Specifically Has anyone had any problems/success with this or other General Standards cards? How have you liked the LabVIEW support/drivers from General Standards? Does anyone know of other options that have worked well? Thanks, David

First off, the SetTypeInfo VI is expecting a Type Descriptor as input, not a data variant as you are intending. Secondly, there is a wonderful option for what you are envisioning. It is using the Attributes of a variant. You can set a variant attribute by name and then retrieve it later by name in your program. And it is quite fast for 8.0 and up. Check it out.

I always wondered why Commander had OGC in the prefix and the suffix. I can understand the helpfulness of mangling at deployment, but what help is it to put the project name at the beginning of the filename? If I remember right (I can't check since I have VIPM installed already :worship: ) the OGC and OGPM portions were in different directories. If there is no need to organize by the prefix, and you have the files in a project directory, then what does the project prefix gain you? I like the prefix for a class/subsystem/library, no need for there. David

Another little thing I recently noticed (at least with 8.2) is that when making the Caption visible on a control for the first time, the Label is automatically made invisible. I like this!! :thumbup:

I appreciate the responses. I never did hear from anybody that uses suffixes to namespace, though the OpenG VIs support mangling and unmangling of VI filenames with suffixes. Do people just not use this any more? David

Thanks for the responses. Haven't got much sleep lately, which means I can sit up late on LAVA and But camera phones (at least the majority) don't provide enough detail to prove that it is YOU in the photo... Most times the photos are as blurry as your vision

I realized I have been posting here on LAVA for a while (and enjoying it!! :thumbup: ) without doing a proper introduction. Maybe I was worried that I couldn't post much to the Lounge since I don't :beer: . Perhaps I have already divulged too much... I graduated from Utah State Univ. a few years ago with a degree in EE but an emphasis in software. I have been programming in LabVIEW pretty much since I started working and have never looked back. I have been working mostly with instrument control and instrumentation (data acquisition). I have always enjoyed learning, however, so I can't seem to keep myself focused on finishing my task at hand. Always looking for the more general, perfect, ideal solution... "Better is the enemy of good" definitely applies to me. On the homefront, we just welcomed our third child, James, into the family. (Proud Papa syndrome probably prompted this post) Sometimes you intentionally branch those LabVOOP wires. 1 Object becomes 2 becomes 3... David

Very nice!! :thumbup: Thanks for posting the solution. Much cleaner than my workaround.

Interesting and certainly provocative. I think that an your idea of open source LabVIEW would be very interesting for the CS community and many "Power Users" of LabVIEW. It is also quite difficult to have excellent customer support for a language. Who do you call for project support when developing an application in C++ or C#? One of the things that impresses me about NI is they have wonderful customer support. You can't support something you don't have control over. Also I don't agree with the following nor do I see how it matches up with this Still I am sure that an open source G will be developed and it will be an important process. David

This seems improved from 7.1 behavior. The cursor would stay at the incorrect point even after zooming in. :thumbdown: It seems that the cursor positioning is limited by the pixel values available at the current zoom level. Workaround - First zoom in, then set cursor, then zoom out. If the flashing is unacceptable, you should be able to Defer Panel Updates and avoid the flicker. David

Perhaps I don't quite understand the desired result, but I would prefer two separate VIs running in parallel. One is dedicated to monitoring the DIO card and passing data via Queue to the other VI which processes the data. Or just separate the User Interface portion into a separate VI (I assume the Event Structure handles some other events as well). This could simplify the code and design a bit, IMHO. David

I agree that having a class before subclass is good, but it is slightly modified for me. I have tended to have some of the different functionality broken out into subdirectories, so I haven't worried about having a naming scheme to keep them straight. I don't do OOP in LabVIEW yet, but I use an architecture with several autonomous agents that are class-like. I name any subVIs belonging to these top-level VIs with a prefix describing who they belong too. I use a separate prefix to label top level (agent) VIs. So files either belong to an agent, or they belong "Top Level", or they simply belong to the project and have no prefix. This gives some sense of public and private scope. My thoughts with the toolkit were more along the lines of a reuse library used in a project. An error handling library may have a suffix of __err. If you import this library into your project (either to maintain modularity or due to some project specific VIs in the library) then the namespace would be __err__proj. I like the idea of a file type prefix. I used a TD prefix on my typedefs for a while, though I have recently just placed them in a Typedef subdirectory and left off the prefix. I still don't know which I prefer. I have tried having the project as a prefix, but I didn't like it. All the files in a directory should belong to the same project so the files aren't grouped by the prefix. It seemed to be harder to search through the directory because my brain had to continually skip over the first part of the filename. So more precisely, my current method looks like : scope - functionality__project.vi functionality__toolkit__project.vi David P.S. - Having a consistent scheme definitely allows for some nice automation and scripting options.

I feel like I have used LabVIEW just long enough "to be dangerous". I remember when I first saw filenames from the OpenG toolkit and from different example code posted here on LAVA, that I thought the namespacing at the end of the filename was interesting and quaint. I have come to appreciate the utility of such standards as I have worked on some larger projects. I have seen people use prefixes and suffixes to express certain qualities of a file - belonging to a group, private vs. public, functionality, global, etc. This makes looking through directories of files much easier and less painful. Not too mention avoiding unwanted cross-linking... I like the style I see a lot here on LAVA -- filename__toolkit__project.vi What styles do you use for naming files in your projects? Curious, David

Though sum is used as the output of the Add Array Elements block, it does technically refer to any result from addition. Going the technical route could provide us some gems of names for the inputs of the Add function: augend for the first input and addend for the second. :laugh: David

I'll have to remember that. Very nice.

This is a major annoyance for me with LabVIEW. Wonderful capabilities in the language --- woefully limited in the IDE department. I am pretty sure there is no such built-in functionality. You can do such macro replacing with scripting. I wrote a scripting tool a while back to replace currently selected items with the clipboard content. The lack of this basic functionality just bugged me. However, with 8.0 and on the scripting method for replacing was changed to something unintelligible I think it still works for block diagram nodes, but I haven't played with it for a while. David

8.2 added the autosave feature to let you recover unsaved files in the unlikely event of a LabVIEW crash. But my favorite is the new Save dialog. I can finally do what I really want to do (make additional copy, rename, etc.) and stop :headbang: David

You can draw text in a picture as stacked, clockwise, or counter-clockwise. So if you could use picture controls instead... Not sure what you mean by the cursor palette.

Yeah, we have funky error color => standard error color I just really hope that the funky right click node options don't become more and more standard.

I'll second that. Good code includes consistency but, as noted in another thread, consistency of this nature is not something to enforce across the industry. Maybe some ini setting exists to change the color? Speaking of color changes, I really like how 8.20 has error wires a different color than any other random cluster.

For a similar issue (using multiple BG colors for different comment types) to better standardize my documentation, I created a palette with Merge VIs containing my formatted comment text labels. Not a universal solution, but you could place it on the normal palette or the Favorites palette for more ready access. David