Leaderboard

I changed the hierarchy. Check out the top-level VIs in this llb saved for 8.6. I had to include the OpenG VIs in the llb to prevent breaking the links. I got wet last time I backsaved... SaveProps.llb

I had started this last time a similar question was asked, just for fun. So I finished it. It's only the "save to file". You'd have to do the same for "loading" the properties... but I think it's a good start. Scripting involved, of course. Keep both VIs in the same directory and call "Save All Properties to INI.vi" with inputs wired. No error checking and no user interface done. saveprops.zip

Hrmm... well as I'm the other developer who make the abstraction layer comment I hope y'all don't mind if I offer a contrasting viewpoint. If you don't agree that's okay, no harm no foul. *shrug* The meaning of "abstraction layer" is highly dependent on the context in which it's being discussed. From 50,000' up, Paul's four layers make sense. They're very thick layers, but typically you want to be talking about the big pieces from up there. However, when you zoom in on any one of those layers you'll find they're each made up of their own abstraction layers. Device drivers aren't written as one giant piece of monolithic code. They are built up in layers that start somewhere down in the kernel and work their way up through the OS HAL, security layers, and who knows what else. If you tell a software engineer writing kernel mode drivers that he's not using abstraction layers he'll disagree. As software developers everything we do revolves around creating abstractions. Every public vi we write is a layer of abstraction other developers working on the project need to understand. It may not a very big layer, but it's there. Good abstraction layers are highly cohesive and clearly defined. They tend to be relatively thin, but not always. They are designed so that the public methods all offer about the same level of abstraction. It's because they are well-designed and offer about the same level of abstraction that we can zoom out and think of it as one big layer. Bad abstraction layers (and I'm as guilty of writing them as anyone else) are not. They often have an unpredictable mix of high level and low level functions. I've run into several cases where I've had to bypass it and go to the layer below (you know, the one that was supposed to be abstracted away) to get the functionality I needed. Instead of focusing on one particular thing, they end up doing a little of this and a little of that. In my experience they often do not have clear boundaries and may offer overlapping functionality with other abstractions. They are too thick, too wide, soft around the edges, and incomplete. (Imagine trying to use VISA if you had to make Win32 api calls to fetch a Windows security token with every prim.) I try to follow a programming model similar to what Mikael posted. I confess I don't understand why Paul thinks that is too complicated. I think it's much, much easier to understand an application when it's layered and modularized than when there's a disorganized clump of vis all making calls to each other and offering different levels of abstraction. Maybe our brains are wired differently? Maybe you really do have cohesive abstraction layers in there but don't realize it? Anyhoo, that's my . Metaphorically speaking, yes. You're telling the rest of the world, "You don't need to know if I'm wearing Superman Underoos, WalMart Tighty-Whities, or going commando. You just need to know that everything is taken care of and none of my private methods will be exposed."