Leaderboard

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."

Complicated to use the ZoomFactor property??????? All the heavy weight lifting is internally done by LabVIEW for you and you feel it is complicated!

Use this snippet and you can keep the same grey part by guessing what it is...

I haven't looked through the other thread, and I haven't looked at how to do this recently, but one workaround you can use is calling an internal LV function to do the same resizing which is done using the cursor. You can see a simple example here. This comes with the usual warning about calling undocumented features, etc. If you're going to use this in an EXE, change the source of the DLL to "LabVIEW". This should tell LV to go the lvrt.dll file when running as an EXE.

But since those are worn on the outside, doesn't that mean your abstraction is leaking?