crelf

QUOTE (jasonw @ Mar 3 2009, 03:57 PM) IMHO, I'd replace "said" with "commanded". Although, neBulus beat me to it

QUOTE (Bjarne Joergensen @ Mar 3 2009, 03:16 PM) Putting a _ at the start of an item in those folders means that LabVIEW will skip them when it's populating it's menus (and palettes?), not when it's mass compiling.

QUOTE (Cat @ Mar 3 2009, 01:31 PM) It took 10 words?!?! I'm sure your team leader recognized the potential cost savings

QUOTE (Gary Rubin @ Mar 2 2009, 04:05 PM) We do, and we don't Some of our tools are getting a little long in the tooth these days, and they've been (at least in part) replaced by other tools from QA verified companies like National Instruments, so it makes little sense for us to continue to maintain those tools. I think what you're looking for is code verification on two levels: that the code is of good style, and that's it's functional. For the former we use the VI Analyz/ser that dannyt suggested for static code analysis, for the latter we use the Unit Test Framework for dynamic analysis.

QUOTE (Tham @ Mar 3 2009, 01:53 PM) No worries - let us know how it goes.

QUOTE (jdunham @ Mar 2 2009, 06:20 PM) I understand that, but I can't do it any other way - the attributes specific to the chesspiece objects are outside of the OO paradigm. QUOTE (MJE @ Mar 2 2009, 10:53 PM) I'd argue the opposite, doing otherwise is plain dirty. A second class, or another VI should never need knowledge of the class exposed to it at all, that's part of the reason a class has a private and public interface. Sorry - what I meant to say was that I didn't want methods in all of my classes that exposed all of the class data - that makes me feel dirty. Exposing only the things that you need, through a custom transport - I'm okay with that. QUOTE (MJE @ Mar 2 2009, 10:53 PM) Only your class should know how to rebuild it's internal structure based off data it deserializes from disk, similarly what to throw away when serializing to disk... Define an interface (preferably an actual dynamic dispatch) that is called by your chess game. I totally agree with all of your comments, but the attributes specific to the chesspiece objects are outside of the OO paradigm. There is no inheritance in this model, because there can't be. QUOTE (JCC @ Mar 3 2009, 12:37 PM) I worked on something similar. But request was: in the future we could change few attribute in child class (add or remove). Parameters for visual inspection. Very nice! But I don't think it really applies to my application. QUOTE (neBulus @ Mar 3 2009, 12:56 PM) Here are screen shots of a project I developed that had a similar (I am guessing) structure. Very nice! But I don't think it really applies to my application. QUOTE (shoneill @ Mar 3 2009, 10:24 AM) Can't you save a link to the file within the class and then have a class method to read the appropriate information on loading? Now you're talkin'! References to the chesspeices perpetuate within the chessgame - then the open/save/etc does the clean up. That I can do! Thanks - I'll let you know how it goes.

QUOTE (Tham @ Mar 2 2009, 07:17 PM) I have no idea what the problem is - I just used the profile picture ( http://amp.ece.cmu.edu/people/Qi/05101803.jpg ) in the VI and it worked fine.

QUOTE (neBulus @ Mar 3 2009, 10:46 AM) Totally! It will get you to the answer much more quickly than us shooting in the dark.

QUOTE (Cmal @ Mar 2 2009, 05:50 PM) That is, indeed, an awesome solution, but it doesn't acheive what I want. That saves everything that's in the object, and nothing that isn't. I should have tried to be more clear - this is no ordindary pattern due to some limitations in how LabVIEW controls are implemented. But that's not important right now. Let's say that the chesspieces have attributes that aren't part of their object (yes, I know, that's mind-bending) - these rogue properties are saved off into individual files that go along with the datalog file. So, I have one file that defines the chess board and some of each piece's properties, and a bunch of little files that define the additional properties for each object. OK - this is getting confusing, so I'm gonna tell you the real deal: I have an simple datalogging application where users can dynamically create workspaces, drop controls/indicators on them, change properties of those controls/indicators, etc. At the moment, I have a configuration file that holds info about each workspace and the FP nodes that are on it (like thier captions, location, shared variable bindings) but then I actually save off the ctl files for each FP node to retain things like size, background colour, scale marker placement, etc. So, at the moment, I have a bunch of files for each data logging "project" that the user creates. What I would like is a single file - say, a zip file - that has the configuration file (or datalog file as you suggested) and all the ctl files in it too. That sort of encapsulation makes sense to me.

This is one that I've had in the back of my mind for a while. Imagine that you have an object like a chess board*, and that object has objects in it, like the chess pieces. Let's say I create a chessgame object who's data has some info about the board (like the colour and size of the squares) and an array of chesspeice objects. Then I want to create a method that saves the current game state - the colours and sizes of the squares, and the locations and types of the peices. I also want a load method that recalls all of these from file as well. So, I want chessgame to have a chessgameFile as an aggregation - basically it's just another chunk of encapsulated data in the chessgame object. So, I was originally going to create a chessgameFile class that contains the file location (and formatiing info), and could get all of the data from the chessboard (and, hence, [chesspeice]) then save it all to file. Problem is, object data is private its class, so it's not like I can feed a chessboard object into a chessgameFile method and unbundle the chessgame and [chesspeice] object data. What to do? My first thought is to create methods for all the classes that have data in them that I want to save out to the file (which is, essentially, the right way to do things), but the chessgame and chesspiece classes already exist and a quite complex. I certainly don't want to make methods for each of the classes that expose the data in them, because, well, that's just plain dirty. Anyone got any pearls of wisdom to impart? * No, I'm not programming a chess program

QUOTE (hooovahh @ Mar 2 2009, 12:00 PM) It'd be a http://www.rubemachine.com/' rel='nofollow' target="_blank">Rube-Goldberg lamp.

QUOTE (Gary Rubin @ Mar 2 2009, 11:03 AM) There's an http://www.calbay.com/bxi_index.html' rel='nofollow' target="_blank">MXI/BXI link.

QUOTE (Tham @ Mar 2 2009, 10:43 AM) I can't get through to your site at the moment - it's not responding - so I can't really give you an authorative answer. Check whether the images you can't download are actually images, and not links to somewhere else, or embedded applications (like flash).

QUOTE (hooovahh @ Mar 2 2009, 10:09 AM) I'm in. Errrr, just for the lamp that is...

What does LAVA Member hooovahh do when he's bored? He builds a Heineken Mini Keg Touch Lamp!

QUOTE (jdunham @ Feb 26 2009, 05:46 PM) Well look at that... It seems like yesterday when I joined

QUOTE (jdunham @ Feb 26 2009, 03:50 PM) I'm totally with you - when talking about style, we should always use words like "guidelines" or "recommendations", and never "rules". QUOTE (jdunham @ Feb 26 2009, 03:50 PM) My examples were just off the top of my head, since I have (*gasp*) other work to do. Me too - I've spent far too much time on non-billable stuff today, so can everyone stop posting such interesting and thought-provoking stuff? crelf out.

QUOTE (jdunham @ Feb 26 2009, 01:47 PM) I was thinking "I'll post a reply agreeing with that", but by the time my browser came up I think I'd changed my mind I agree in principle that clarifying meaning is a good thing to do, but I'm not sure I agree with the examples you gave. I, of course, don't know the examples intimately, but here goes: filter coefficient(0:no filtering) <- if this is an input to a VI that filters, then you shouldn't be using this VI at all if no filtering is required. Make a decision outside of it and case it out if not required. Otherwise, all you're doing is moving that case decision to inside the subVI, which is hiding functionality, or, in this case, non-functionality overwrite?(F:Append to file) <- Either you're overwriting something or you're not - that's why it's a Boolean. I think it you want more options than that then use a datatype that allows for more than 2 selections (like an enum, since it's a choice between more than 1 textual-based things). Sorry about getting on my soapbox, but I've never found where this sort of thing couldn't have been replaced with more intuative design. QUOTE (jdunham @ Feb 26 2009, 01:47 PM) While I'm on my soapbox, making inputs "required" is a really good thing, and for the most part, required inputs don't need to have their defaults mentioned at all. I sure hope there's room on your soapbox for me too The only time I'd want a default mentioned when a connector pane element is required is when it's being run as a top level VI and it calls the "reint to default" method somewhere. We need to be mindful that it's not the control that we're making required, but the connection to it when it's used as a subVI.

QUOTE (Tomi Maila @ Feb 26 2009, 06:16 AM) Great stuff - congrats Tomi - and good luck mate!

QUOTE (jdunham @ Feb 26 2009, 01:10 PM) That's a really good point. I only use the default value in parentheses if the default value of the control isn't the default value of the datatype.

Thanks Jeff - your post was featured in today's National Instruments LabVIEW Champion meeting

QUOTE (BrokenArrow @ Feb 26 2009, 11:24 AM) I'm really hoping that's a typo tha should be 1Gb...

QUOTE (malani @ Feb 26 2009, 10:51 AM) I think it was a private method back then. Try making a VI in 8.6 with it in there and save it as an 8.2 VI.

QUOTE (bsvingen @ Feb 26 2009, 09:45 AM) My mind just doesn't get hung-up on them being there. In a sense, I just don't see them unless I'm specifically thinking about error clusters. The colour change, IMHO, was a good step forward to helping me to that. QUOTE (bsvingen @ Feb 26 2009, 09:45 AM) ...highlighting when mose over certainly would in an instance make things much clearer in a crowded diagram. I don't want to detract from the discussion at hand, but it sounds to me like the diagrams you're looking at could do with a little love. One of the reasons that CAD folks use layers is because they need to - the distance between objects is a vital part of the functionality of the design in the CAD world, but in LabVIEW it is not (unless you count the 32k pixel wire thaa AQ mentioned once ). So, while I think the idea of layers is a good one, I have a different reason for liking it than you do.

QUOTE (bsvingen @ Feb 26 2009, 06:16 AM) It'd need to have a parsing routing that was modular and easy to change, since a lot of us use different state machine transports (string, enum, queue, custom ecapsulated...)