Michael Aivaliotis

Booth Babes

Todd, Have you seen this thread? http://forums.lavag.org/index.php?showtopic=2165 I'm not sure if it covers your problem but there is a lot of info in there.

Here is a link to a document describing the decisions made in the current implementation of OOP released in LabVIEW version 8.20. LabVIEW Object-Oriented Programming: The Decisions Behind the Design I've also attached a PDF version. Download File:post-2-1155627547.pdf

Here's a video showing the Tribot in action. Download File:post-2-1155538350.avi

Well, Thanks all for the support and the love...

http://lavag.org/niweekcam/

Not so much a mistake. The Beta 8.20 has closed and it will be shipping soon. They are using it here at NIWeek already.

Well, I picked up my mindstorms and it's here with me at NIWeek.

Here's an interesting article on the marketing side of programmable construction toys (mindstorms). http://www.techuser.net/lego2.html

Crelf is in charge of that area and he's already been made aware of the submission. He won't be at niweek so he will get it approved.

Damn, I wish I had know earlier so I could get it and bring one to NIWeek. Oh well, it will have to wait until I return. I wonder if they'll be selling them at the show.

From my experience in developing projects, being gone for 5 days doesn't really make a difference in the long term success of a project. My guess is you're not just 5 days behind schedule. It actually might help to take a break, step back and evaluate the situation. Taking off for 5 days however might leave the client wondering if your company is taking the project seriously. It's more of a public relations issue than actually getting work done. I've been at an employer where all personal improvement activities such as conferences and seminars where cut-off because projects were behind schedule. In retrospect it turned out that all projects were always behind schedule. No matter how much you push, projects get done when they get done, no sooner.

This could be a little tricky because the enum control doesn't have an equivalent selector object. It only has an increment decrement. The selector equivalent is the entire text field. Pasting a down arrow there will replace the text field and is messy. I would suggest, instead to decouple the GUI requirements from the diagram data requirements as indicated in the image. This way you can use whatever you like as a control and still get the benefits of enum datatypes on the diagram.

I actually like flat buttons that raise when you hover over them. Only available in LV8 though.

It just has.

The dialog label in the controls palette is very special. You can use this label to label wires on the diagram instead of using your own colors. What makes the dialog label different from the default label is that the background color inherits the color properties of whatever object or background you place it on. Normaly, this label is used on front panels because it allows you to label dialog frames properly. Windows XP color themes contain various shades and textures which cannot be represented by a single color. However a nice bonus is the benefit of labeling wires without having to play with the colors. You must select this label from the controls palette to drop it since it's not available on the functions palette.

http://www.sunspotworld.com/

There seems to be a misunderstanding since we probably didn't clarify this point. Our fault not yours .You will still, as always, continue to attach code and files to your forum posts. This hasn't changed and will not change in the future. Sometimes however, a reply to a support topic may trigger you to come up with a tool or a complete set of VI's that are cleaned up for the general public. If you were to post it to the same thread then it would get buried in the noise. The LAVAcr helps organize those gems so people can find them and ask for support when they download it and have problems. Don't be afraid to submit code to the LAVAcr we aren't as strict as you might think.As far as emailing the person the code, this seems backwards. The whole point of the forums is to educate, and hiding the discussions and code exchange defeats this. So, YES attach your code to your reply AND post an image (for those that don't have LV:8.0.1)

I've moved this topic to the wish list because I think NI's integration with password protected VI's and the search function completely sucks. Actually, there is NO consideration of password protected VI's in LabVIEW's search function. I would like the following: A flag in the search options that allows you to ignore protected VI's If the flag is not set and a password dialog pops up during the search, there should be a checkbox asking if you want to: "ignore future searches in protected VI's (for this search)". #2 is important because when the password dialog pops up, you only have the option to Cancel. This only cancels the current VI. If you have hundreds of password protected VI's then you will get hundreds of pop-ups. Perhaps an ABORT of the search in this dialog is better. Otherwise you have to play a game of: escape+click, escape+click, escape+click in order to abort the search.

Double-Click of VI after "create subvi" action doesn't open VI. If you use the "Edit >> Create SubVI" function from menu's and then double-click the new VI icon that was created, the front panel doesn't open. However, if you nudge the icon 1 pixel, it now works. It seems to be related to editing the VI and saving it or changing the connector pane. You must do this before trying the double-click. I haven't had time to narow this down. Can others confirm this?

No one will be able to answer these questions on a public forum because of the NDA agreements they have signed. Your best bet is to come to NIWeek and talk to a developer.

C'mon guys, what do you think this is, the NI discussion forums?

I agree, Bastards! :thumbdown:

Well yes, if you could develop using OO A&D techniques and not worry about programming the framework code required to support it, then would you not do that? Are you arguing against OO design in general, or against OO design in LabVIEW?

I think that's the wrong way of looking at it. You either use GOOP or you don't. In this case size doesn't matter. If you are creating throw-away code, then sure, GOOP is overkill, but in any other instance it should be used. The reason people are afraid of it is because LabVIEW has never provided a good fully functional native implemetation of GOOP. Of course, the next release of LabVIEW should change all that. :thumbup: