Stagg54

That sounds like it might be easier than scripting. In general I find scripting to be a pain to write. Once written it tends to be invaluable, although I find that most of the scripting I write tends to be very narrowly focused and address one specific use-case (maybe it's just me using poor programming practices and not being general enough.)

I found it!! Double clicking on the terminal did not work. It just brought up the icon editor (perhaps that's some sort of LabVIEW options setting?) Anyway I found it by making sure I had saved all my changes in SVN. Then I just started deleting things with the Context help open. As soon as I saw it disappear from context help, then I knew I must have deleted it, so it must be inside that structure. Then i just hit ctrl+z and went down into the next nested layer. thanks everyone for the help/advice. oh and on a related note apparently the search function by default does not search for hidden items. So if the label of the control terminal is not visible searching for it by the label will not get you anywhere. You can always change this though.

I'm cleaning up some old code (not mine) and I have run into the following problem. I have an indicator that is wired to the connector to pass data out of this vi. Unfortunately I can't find the thing on the block diagram. I've tried searching for it by name and haven't really had much success. (If you think this should be simple then you haven't seen the vi I'm dealing with) Is there any way to right click on the connector pane terminal and find the terminal of the corresponding indicator/control? This would also be useful because in this particular vi there are several controls/indicators with the same label. (I know - bad practices. They are not mine. Unfortunately the responsibility to make this code work is now mine. I can't throw it all away and start from scratch. As much as I'd like to, my boss seems to think it is more productive to remove cards from the house of cards instead of building the house out of bricks.) Any ideas?

scripting is your friend.

That sounds like an idea for the Idea Exchange.

If you use SVN and VI Analyzer, you should consider voting for this idea: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Let-VI-Analyzer-ignore-paths-matching-patterns/idc-p/1251344#M7775

How about a third? Why not a tab control? One tab for indicator. One tab for control.

If you think that is bad, you should see what I have to put up with on a daily basis! Making huge messy diagrams is a great method of job security (because no one else can understand it), but it sure sucks for the guy who replaces you when you retire.

Now the real question is can anyone tell me where those templates are stored? I remember seeing that in a post before but I can't seem to find it now.

If I remember correctly there is an ini token to show hidden objects.

That makes sense. And thanks Darren. That tool will come in very handy.

When I create a new vi for my class using New-> New vi from Dynamic Dispatch Template or New vi from Static Dispatch Template, Autogrow is always enabled on the error case structure, even though my in LabVIEW options settings I disabled the place new structures with Autogrow enabled. This is in LV2009SP1. I haven't checked in other versions. Has anyone else run into this?

I have several channels worth of data. I want to be able to have a horizontal bar plot where each bar represents the RMS value of the channel. I also need to have some kind of marker to mark the peak value. Anyone have any experience with bar plots in LabVIEW? I've done a little research and I haven't found a lot. It doesn't seem like it should be this hard.

You could probably just wire it through a case structure. In one case jus pass the refnum. in the other case (ie. when you want to set it to not-a-refnum) just leave the output tunnel unwired and select "use default if unwired" that should do the trick.

The application I'm thinking of is an error logger. Within each application there should only ever be one instance of the error logger and I don't want to pass an error logger wire through every vi in my application, hence the singleton makes sense. I would have a generic error logger class that would work in 90% of my applications. Perhaps that other 10% of the time I want to do add something else to the file or do something slightly different but almost all of the basic functions are the same. It wouldn't make sense to duplicate everything. I think it would make sense to be able to make a child class for that occasion. With this implementation, there doesn't appear to be any easy way to do that. Is there a better way to go than inheritance to achieve this? That doesn't seem so ridiculous to me. What if your program uses a DMM and at any given time there is only 1 DMM in the system. It would make sense to use a singleton. Now say that DMM could be one of 3 types, it could be Keithley, NI or some other brand. But each performs the same basic functions. It would make sense to have a subclass for each meter that inherits from the generic DMM. Am I thinking about this the wrong way? I'm kind of new to using classes but to me this seems to make sense. How would you solve a similar problem?

I like it. One issue I see that doesn't really seem to have a workaround is inheritance. I don't see how it could be done with this model, at least not easily.

Thanks for your responses. I will take all of that into consideration.

I'm curious if anyone has ever run into this before and how they deal with it. Here's my problem: I have 1 program that depending on which location/setting it is used in ( currently only 3 options here) it has a different front panel appearance (ie. BGcolor, text colors, boolean colors, plot colors, line styles, etc.) My world would be much easier if everyone could just agree, but that's not going to happen (which is good in a way because it keeps me employed.) Oh and also for each of these locations, when the user prints the screen I have to change all the controls to another appearance. I'm weighing a few options: As far as actually updating the control properties 1. I could do the brute force method and have a case structure in the init stage of every VI that is displayed and use proprty nodes to set every control/indicator based on which location/setting I am in. Not elegant at all but it works. Not exactly very expandable either. Everything is pretty much hardcoded unless maybe I read it in from an .ini file. Also a lot of duplicated code. If I have a particular graph that appears on 3 screens and is handled the same way, I have to repeat the code 3 times. Maybe I make a subvi - who knows. 2. I looked at xcontrols and having a method for each xcontrol something like set color scheme, but from what I can figure replacing all of the controls with xcontrols would be a complete waste of time. 3. The most promising appears to be using vi server because we have a splash screen that loads all of the VIs so when I load each one I can set the properties of each control using property nodes and references. 4. There has to be some way to incorporate classes and dynamic dispatching into method #3. As far as managing the different schemes: 1. I could read all the info from an ini file - seems straightforward 2. If I classes perhaps I could create a child class for each location and one for the print settings for each location. If anyone has any thoughts or ideas it would be nice. This seems like a pretty overwhelming problem and I'm just trying to wrap my brain around it. I figure no matter what it's going to take a lot of effort, but I figure any planning I can do ahead of time will really pay off in the end. Of course I'd like to come up with somehting that is readable, scalable, and maintainable. Knowing the people that I'm dealing with their liable to change their minds 20 times yet today about what colors they want and what line types, etc.