Leaderboard

I just discovered by accident that if you copy a primitive VI (like add) then edit the icon of a VI and paste , you get the icon of the primitive? I am sure a lot of you already knew this, but I thought I would share, because it was a nice surprise to me. Now it will be easier to create new icons. Fab

Here is our default image for our generic dialog. I smile every time I fail to wire a real image...

Thanks for the accidental discovery Fab! You'd be amazed at how many hours all of us have collectively wasted due to this ignorance! I did a whole lot of copy>Paint>Copy>Icon Editor just today (with primitives ). Tomorrow should be easier now!

Yep, this is the need-lock property. A must-have for non-merge-able files. I can't tell you off-hand how to make every new file inherit the property, but it's possible.

SVN does (can?) also set the read-only flag; we have SVN set up that way.

Daklu wrote: > I wouldn't do this. It's giving the business components (motor controller, etc.) > responsibility for deciding how the data is displayed. Totally agree. This is the basis of the separation of "model" -- the hardware/business logic/process/software simulation/whatever you're actually doing from "view" -- the UI layer or data logger system that records what's going on from "controller" -- the section of code that decides what new instructions to send to the model Model generally knows *nothing* about view or controller. Any view can connect to it. Any controller can send it orders. The model publishes a list of (events for the view to listen to OR messages sent from the model) and a list of (events for the controller to fire OR messages that can be sent to the model). The controller knows little or nothing about the view (binding these two is sometimes more acceptable). It publishes a list of events/methods for the view which tells the view what commands are available right now and lets the view command the controller.

At my previous job we had multiple developers working on projects and we used TFS. One particular project had grown out of control and it was really easy to end up with conflicts when trying to check stuff in. I've since picked up some habits that help keep everyone in their own sandbox. 1. Set the options "Treat read-only VIs as locked" and "Do not save automatic changes." This is one advantage TFS and similar systems have over SVN. Since TFS uses the read-only flag to determine whether or not a file is checked out it's very difficult to accidentally change a VI. 2. Use project libraries to separate your application into components and put all vis in a library. That will reduce the number of changes to the .lvproj file and help prevent collisions. If vis are not in a library the .lvproj file has to maintain information about its location. When a vi is in a library, the library maintains the location information for all its members, meaning the .lvproj file doesn't get changed as often. 3. Make sure only one developer is working on any given library at a time. Don't allow anyone else to make changes to that library. 4. Don't nest project libraries. Putting classes in an lvlib is good, but an lvlib in an lvlib doesn't work so well. If you have hierarchical libraries you can use dot notation naming conventions on your library names.

Here is the NI blog post introducing all champions: https://decibel.ni.com/content/groups/labview-champions/blog/2012/02/07/2012-labview-champion-inductees-nine-new-members

You can also drag and drop the icon of one vi to another vi without copy/paste. No keystrokes required... (front panel to front panel)

This thread is starting to resemble a holiday dinner at my parents' house...I do have more questions though and I'll post them later today if anybody is still paying attention. Here's some for AQ or anybody who wants to take a shot at them. I hope they are clear enough. I knew that great mind had to come from around here! However, I had to adapt from BioEngineering to Oilfield Instrumentation to stay in Tulsa so I wouldn't exactly say it's a good spot for a software guy. Without LabView we would be running instruments from a rheostat so I'm glad you're off making it modern. If you ever come through, let me know Yeah, I realized that after trying my best for a few days. After reading the paper and watching your webcast I knew that framework was the answer to all my troubles! However, when you try to mix it in to an existing project it gets messy real quick. You cannot easily follow the Actor Framework by looking at the code, I follow it by looking at the project explorer. When you try to mix the AF in with other LVOOP code & non-OOP code the project looks like alphabet soup. I would think it is desirable to have a framework that can mesh more easily, even with older, uglier code. I must need an AF-Lite...something that allows you to launch an actor, get the queue from it, and then send it messages to tell it what to do. That's it, something a Hard Drive, Air Conditioner, and Fire Suppression can all do: message = start fan, message = increase speed... I understand having a dynamic dispatch for different types of fans but why does Fan need one for different types of fan callers? I'm missing something fundamental here aren't I? Here's my problem: I want to click an .exe, some initialization routine reads a file which tells it to launch, say, a certain type of motor controller as CH1, a thermocouple input and 2 DO's as CH2, an ultrasonic pulsing PCI board as CH3, and then send their queues to a TouchscreenIdle UI, which will send and receive messages from them. The UI has no idea what they are and CH1, 2, and 3 have no idea what the other channels are or what is controlling them. The GUI sends messages asking what controls/indicators to show/hide, labels, etc...to the queues it received from the channels through the initialization routine. Then when somebody presses a button it sends that message through the right queue and the motor turns on. If they want to setup a test, the IDLE UI passes all the queues to Setup UI and so on. It seems like I should be able to use the AF for just the I/O, or for just the GUI's, or for just the Motor Controller since they are all lightly coupled. There is some coupling due to the set of POSSIBLE MESSSAGES being non-infinite but what else? How can I use the AF in this type of program incrementally? Please help a fool understand how to connect to your fool-proof machine!

Never knew this... thanks! Joe Z.

Wow I'm a little ashamed to say that I've always done a print screen, pasted my whole screen into Mspaint, then selected just the primative I wanted, copied and then pasted into the icon editor. Also I believe that Flickr allows you to search for images in the public domain, or royalty free. The site is massivly slow for me at the moment so I can't check but I think that's where I saw that feature.

You can paste just about anything into the icon editor and it'll try to bitmap it: That's a great tip - but remember to respect the copyright of the images you find

I would use OO to solve your problem and use a picture control to draw all your objects. The Top level application just keeps track of an array of objects that could be of different types but they are all inheriting a common base class. The main application calls the BaseObject.Draw method(VI) on all the objects when you need to update the screen. When you click on the picture control, the main VI goes through all Objects and calls a method(VI) to see if the Mouse coordinate is within the objects boundary. I like this approach since all object could have different state and if you right click on them and would like to display a drop down menu, all objects can decide what menu options are valid for this object.

Talk to each other. I'm serious. Team meetings are very important to minimize the risk of painful surprises. Decide who is working on which part of the code. If you have to change an interdependent module, talk to the developer who is responsible for that code.