Daklu

Link Good for a laugh if you're familiar with other programming languages. "1972 - Dennis Ritchie invents a powerful gun that shoots both forward and backward simultaneously. Not satisfied with the number of deaths and permanent maimings from that invention he invents C and Unix."

If I were looking I'd go with a quad-core cpu, lots of expansion slots, 2 or 3 wide screen monitors, and possibly a solid state hard drive. I primarily do applications to run on standard pcs; if you're doing real-time or something else you might have different requirements.

Yeah, I saw that but there wasn't anything new there that wasn't already in the wiki. Shortly after I posted the original message I opened task manager and found ~25 Excel processes running. I suspect some button I was mashing caused it, but I haven't pursued it at all yet.

Chris' post here mentioned an NI internal debugging tool called Heap Peek that I hadn't known about. So of course after reading the wiki I immediately enabled it and started poking around. I can't find any other useful information online about it. Is there any other tribal knowledge on this tool or are there other things you have used Heap Peek for? I also discovered Ned (Ctrl-Shift d, Ctrl-Shift n) and a combo to show buffer allocation (d, q.) One key combo (d, ,) causes some BDs to be grayed out. I don't know what purpose it serves though. Any other known gems?

No, but if you figure it out be sure to post a How To. That would be very cool!

Grats! I'll raise a rootbeer to you and your family. (When does she get the Labview logo tattoed on her belly?)

Bummer... I initially thought it was a real signal. You can see it on Google Maps here.

I want to see that intersection on Google Maps. Anyone know where it is?

In the spirit of layering, here are some diagrams of an application I'm currently working on. I like to use the MVC architecture as it does a good job of decoupling the functional code (Model) from the UI (View) and glue code (Controller.) What I'm showing here is the current design of the model. This is based largely on the document, "How to Mitigate Hardware Obsolescence in Next-Generation Test Systems" found here, though I use slightly different terminology and have added layers so I can use an MVC architecture. The first diagram shows the classes organized as layers and the dependencies between each layer. Notice I've inverted the dependency between the Application Separation Layer and the Device Separation Layer. This makes it much easier for me to swap out different kinds of hardware as the test system changes over time. If we switch from an ADU 218 relay box to something else, I don't need to break existing code to implement it--I simply derive a new child class from ButtonActivatorInt, implement an AcmeRelayBox device driver .ogp package, and code the AcmeRelayBoxDSL class. When I have those coded up and tested I can make a simple change in the Application Separation Layer that instantiates AcmeButtonActivator instead of ButtonActivator. The second diagram shows the model as a whole and the relationships between the different classes in the model. The ports (little squares) around the edge of the block show how the Model interacts with other components in the application. At the bottom I have classes that make calls into "drivers" (Labview classes or libraries) I've created for each hardware device and packaged as .ogp files. (Usually these are thin wrappers around the manufacturer's dlls.) At the top the controller is only aware of the TestScript, TestCase, and ConnectionMonitor objects. All the other classes and methods in the model are invisible to the controller, which makes the application level code *much* easier to write IMO.

I suggest you start by learning some basic problem-solving skills and applying them to your assignment. When you have a big problem that you don't know how to solve the first thing you do is break it down into smaller problems. If you still don't know what to do, go get help from your professor or TA. (Do we have a FAQ or something we can point people to when they come around asking us to do their homework?)

Are you referring to a memory leak in Labview or in your application? I haven't seen anything that indicates Labview has a memory leak when DVR's are not cleaned up properly. When the vi or application stops running the memory will be reclaimed. As for a leak in your application, my best guess is that it depends on your code. Labview generally retains data in memory as long as the vi that created the data remains active. If you create the DVR in your top level vi LV won't automatically reclaim the memory until that vi goes idle.

Ahh... I see. AQ calls the input and output "thralled" and that is what allows the class type to propogate through the sub vi at edit-time when it otherwise would not. There is a bit of discussion here and here about thralling. I think it's a convenience more than anything. It's not completely clear to me what is and isn't allowed for the terminals to be considered thralled. Some things, like putting a new object constant on the wire, break thrall. I believe object arrays are not thralled because it's much harder to guarantee all the objects in the array are able to be automatically downcasted. In your example, if inside the array sub vi you were to append a LVObject to the array, that would cause the downcast at the output terminal to fail. Rather than write mounds of type checking code and require Labview to go through the time consuming process of tracing through all the execution paths to make sure your object array output terminal is thralled, I suspect they just decided to disable thralling for arrays.

Sometimes I can get more work done at home... then my wife and kids decide that "Daddy's working from home" == "Daddy doesn't have to work today." At work a Zune and good earbuds are standard operating equipment for me. I end up not even noticing my music and it eliminates all the external noises.

For those who have joined the project, I have set up a repository location for uploading code you are willing to donate. In the submissions folder, create a folder with your user name. Create a sub folder with a descriptive name for each module and put your code there. When we start integrating a module into the LapDog api we'll copy it over to our main dev branch. Link Jon and I are working on getting a decent forum in place for LapDog developers so we don't load down the Lava forums with our stuff. Neither of us have worked with SF so there is a bit of a learning curve.

Thanks Yair. Now that you mention it I do recall some discussions about OpenG licensing and BSD. (See, you're already contributing! )

Glad to have you aboard. Licensing will almost certainly be LGPL to make it as easy as possible for anyone (students, test engineers, commercial integrators, National Instruments(?)) to include it in their own software. Nope, not yet. This project is still brand new so we have a lot of things to work out before we are able to release anything.

Felix, I don't quite understand all the issues you're talking about, but I'll answer the questions as best as I can. (They're not very good answers though...) Nope, no way to define something as abstract in LV. In Java if a class is abstract it cannot be instantiated. In LV everything you drop on the BD is instantiated, so abstract classes don't really fit into Labview's paradigm. You can do some things that give you a few of the same behaviors, but I've never run across a situation where I thought it was worth the effort. In LV'09 you can mark all the methods as Must Override in the class properties dialog. This doesn't stop someone from dropping the object itself on a BD which you obviously wouldn't be able to do with an abstract class. That means you may need to raise an error in all the abstract class methods in case someone sends an abstract class object through your algorithm. If you really want a class that cannot be instantiated by users, you can put the class in a .lvlib, make the class private, then provide wrappers at the lvlib level for each method in the class. That will prevent users from dropping objects of that class on the BD but still gives them access to the class methods. Unfortunately this also prevents users from creating subclasses of your abstract class (since it is private to the library), which kind of defeats the purpose of creating it in the first place. In general if I have a class I expect users will subclass I'll provide a simple default implementation so there's at least *some* functionality there. I think that simplifies the api a lot. There's nothing (afaik) that stops you from iterating through an array of objects and calling PRC on each of them, as long as each object in the array is an instance of or child of the target class. I'd need to better understand the context of what you're trying to do to say whether or not it would work in your specific situation. It's not clear to me why you need it in first place. Can you provide an example of how you expect users to use your code? In general no. Collections are just different ways to store objects in memory so you can easily store and retrieve them. If an upcast or downcast is required then it's required--you have to put it in there somewhere. Your only choice is in where to put it... are you going to do for the user or require them to do it themselves? The way I've implemented the Bag framework it's pretty easy to create front ends for each specific class so users don't have to do the downcasting themselves, but if there are lots of different classes it may not make sense to implement a front end for each one. Just to clarify, they are defined as abstract classes, not Interfaces, right? If you have a method that you don't want child classes to override, then you make it static dispatch. I use them on occasion but most of my public methods are dynamic dispatch.

ROFL!

I have a hard time thinking of delegation as a pattern. If someone says "bridge pattern," "facade," or "proxy" I can visualize how the various classes are related to each other. "Delegate pattern" doesn't do that for me. It seems more like a fundamental principle of OOP. Objects delegate (verb) responsibilities by passing requests on to a delegate (noun) that is designed to provide that functionality. The wikipedia articles refer to languages that implement "true" delegation but I'm not familiar with them so I'm sure I'm missing some of the finer points. Seems to me patterns define the relationships between the calling object and the delegate object. Different relationships create different dependency trees between the classes and ultimately dictate where you can split your application into different modules. If a pattern doesn't define a relationship, what good is it? Then again, it could be I've just missed the boat on this. As far as I know interfaces and multiple inheritance are different solutions for the same problem. You don't need to implement both of them. Since the language itself doesn't support either of these concepts the best we can do is implement a framework that simulates that functionality. That means we have to strike a balance between functionality and ease of use. My gut feeling is a multiple inheritance framework would be pretty heavy. I can't think of a way to get a native object to successfully wire into methods from two separate parent classes. You might be able to do it if you create a second "virtual" inheritance mechanism and make all the user's classes children of the same "real" parent class , but that adds a lot of complexity to developing a project. Interfaces are more managable, but the framework I put together is still too complicated for most people to understand and I'm not that happy with it. This isn't to say people are too stupid to understand it, just that with the level of native OO functionality currently in Labview it requires a lot of code to implement something that behaves like interfaces. (Ironically after spending a year or so getting the Interface Framework to work reasonably well, I discovered Interfaces aren't the right choice for my original use case. They can still be useful, just not for what I intended.) I'm interested in seeing what you come up with.

Looks like it might be a bug with the second RegEvents prim not registering the second event. In your vi Hover Over 2 wasn't firing a Mouse Leave event. When I placed Mouse Leave before Mouse Enter in the RegEvents prim the Mouse Leave event was firing but the Mouse Enter event was not. Breaking those two events out into two separate RegEvents prims made everything work right. (LV2009)

I was thinking about this more last night and I concluded that you have a very good point. I tend to use "layer of abstraction" and "level of abstraction" interchangably, but I think they are subtly different. A layer implies a set of methods that work together to abstract away lower level functionality. Abstraction level relates to how much of the lower layer's functionality the upper layer is discarding. Higher level abstractions provide more functionality at the cost of allowing less control over what the lower level functions are actually doing. An abstraction layer may have multiple abstraction levels. Creating a sub vi is always adding a new unit of abstraction, but isn't necessarily adding a new layer or a new level--you can only determine that in the context of the other vis in your project. My designs tend to have multiple thin layers with each layer offering a consistent abstraction level, so for me arbitrarily wrapping up some vis in another one just to save space is almost always adding a new level and may (depending on where I put that new vi in the project) add another layer. I definitely could have done a better job of explaining what I meant. I'm still not sure I've done it adequately. I have a very clear picture in my head of how I think about it but I don't know how to concisely describe it. [And in case anyone was wondering, I'm NOT the one who was suggesting adding a shift register to the stacked sequence structure. ]

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

FYI - Jon (jgcode) has graciously volunteered to help out with project administration. There seems to be a problem with SF's email in that requests to join the project are bouncing back to the sender. If you are having this problem send either Jon or I a private message with your SF user name and we can add you manually. *Phew* I almost went with that one too... I would've had to cancel the whole project.

Well, if you've replaced all the constructor nodes, controls, and indicators in all your vis and it's still not going away, I don't know what to tell you. I'm running out of good ideas. I assume you've checked to make sure you don't have anythink hidden off screen or behind the edge of a frame? Something else to try is deleting all the constructor nodes, controls, and indicators and seeing if it's still there. If it is see if it still points you to the same vi. Another thing you can try is to make a backup of the guilty vi then go back and start deleting stuff and saving until you find the part that is causing the trouble. I vaguely remember having a similar problem, though I'm not sure it was related to dlls. I ended up deleting all the vi contents and recreating them.