Daklu

I don't think there's an elegant way to do this with by-val objects given your class hierarchy. By-ref objects would do it--they may not be the best solution for your particular situation though.

I discovered something today that makes perfect sense when you think about it but isn't immediately obvious. (Well, it wasn't obvious to me...) When using the equals prim on by-value objects LV does a value comparison. If I have two completely separate objects whose private data values are the same, the equals prim returns True. On the other hand, doing an equality check on two by-ref objects with the same values in the private DVR returns False unless they both dereference to the same private data cluster. (i.e. The DVR refnums are the same.) In other words, the equals prim is smart. It "knows" to compare values of by-val objects and to compare references of by-ref objects. ...eh, I thought it was a neat side effect.

I have the following class structure: - Grandparent -- ParentA --- ChildA1 --- ChildA2 --- Child... -- ParentB --- ChildB1 --- ChildB2 --- Child... -- Parent... I am creating an array of Child objects at runtime; however, before adding a Child to the array I want to make sure it does not have any siblings already in the array. In other words, if I'm trying to add ChildB1 to the array, I want to raise an error if ChildB2, ChildB3, etc. are already there. Given that the parent classes are unknown at design-time and not directly available at run-time, is there a way to compare two objects to see if they derive from a common parent? The Grandparent is known at design-time and can be used. I can think of solutions by adding framework methods to the class hierarchy, such as an abstract GetParent method in the Grandparent class. I'd like to do it using LV prims to avoid cluttering up the hierarchy. I don't think this is possible given the constraints, but I thought I'd throw it out there for the experts to chew on. ---------------------- This is releated to the Interface Framework. The other day I stumbled upon 'Preserve Run-Time Class Demo' in the Example Finder and realized I could eliminate the downcast after getting an Interface in my Baby Demo. Also, using type information instead of "Name" value to retrieve a specific Interface eliminates the problem of different Interfaces having the same name.

It turns out there's already a way to do what I was attempting. In the project window, select the sub VIs you want to reload then on the menu bar go to Tools -> Source Control -> Get Latest Version... Couple points: I presume you need to be configured for source control to be able to use it. You can only do a forced reload of the latest version. I don't think you can go through your scc client and get a previous version and have it reload. It has the annoying habit of asking you if you want to Revert or Cancel for every single vi that is being reloaded. A 'Revert All' option sure would be nice.

Thanks. I suspect it should work. In my case it got up to ~350 VIs before Labview sputtered and died. Merging doesn't address this particular problem. If I have the project open and the files on disk change, whether via a branch merge or via a check in when multiple developers are working on the same branch, LV doesn't always catch all the VIs that have changed. That often leads to conflicts (such as "MyVi.vi claims to be a member of MyLibrary.lvlib... etc.") and I have to close and reopen the project.

When working on a project sometimes another developer will check in code and I'll want to get the latest updates. Or I might be futzing around with previous versions of certain VIs. Usually LV will catch it and tell me the VI on disk has changed and offer to load the disk version. Sometimes it doesn't and continues to show the copy in memory rather than the version on disk. When that happens (or if another devoper has updated the project file) I end up having to close and reopen the project, which takes ~8-10 minutes. I'd like to have some tool that forces LV to reload the project file and any VIs, controls, libraries, etc. that are in memory from disk. The Revert method combined with getting a list of all loaded VIs might work. Rereading the project file might be tougher.

Is there a way to force Labview to reload a project file and/or project VIs from disk? I scanned through property and invoke nodes but didn't see anything promising.

In my experience if you want to change your team's behavior you have to identify what issues cause them pain and show them how the new behavior will avoid that pain. If your team doesn't experience any pain with the current system they're not likely to want to change to something new. Yes, but can you create VIPCs that link to packages at an arbitrary network location or when using that feature do they have to link to a 'real' package repository, which implies a repository client license is needed.

I appreciate the comments from everyone. I'm not the decision maker but the new use case scenarios certainly raise some questions we had not considered. Here's a tangential question Ton alluded to: How do you manage your reuse code library's souce code for multiple Labview versions? Do you do all your dev work in the earliest version of Labview the library supports? Use "Save for previous version...?" Maintain an independent branch for each Labview version? Thanks for the announcement. I hadn't realized a new version was available. Faceless corporate policy. However, since I'm building internal test tools as opposed to a shipping retail product, it might be okay. I haven't asked the question specifically. Agreed. This is very important and not obvious to new developers. I've taken to appending the major release number to the end of the library name. (MyClass__v1.lvclass) I roll the major release number if and only if I break backwards compatibility. That lets me have multiple versions of the same package installed on a single computer, should the need ever arise. Yep. Although I have found that using the "Treat read-only VIs as locked" and "Do not save automatic changes" options help minimize the frequent commits due to on-the-fly recompiles. I assume you need a VI Package Repository license for this? Slick. Very slick. Ahhh... taking a page from NI's "Sorry, can't tell you how many developers we have working on Labview" book I see. Perhaps a drink will loosen those lips. Here... have a... VIRTUAL ROOT BEER! (Cue dramatic music.) -------- It's not completely clear to me how the different VIPM versions fit together to form a complete system. I gather that you need at least one copy of Enterprise if you want to create your own repository, where clients will automatically check for updates to your packages. Does the computer hosting the repository have to be running VIPM Enterprise? Is there a limit to the number of repositories we can create? Say we have a development team here in the US and another team in China. Can we use a single Enterprise license to create a mirror repository for the China dev team? The comparison chart says you can use Enterprise to create a repository, but implies you still need to purchase a VI Package Repository Client License if you want to connect to the repository. This confuses me. Is there a use case for purchasing Enterprise without purchasing a client license? Are repository client licenses shared, computer-based, or user-based? This is how I'm seeing the pieces fitting together: Each repository administrator should have a license for VIPM Enterprise. Each reuse library developer should have a license for VIPM Pro. (Enterprise works too if the user is also the repository admin.) Each reuse library user should have VIPM Community, (or Pro/Enterprise) unless the user is also a project owner, in which case they will need a copy of Pro. Regardless of which VIPM version a developer has, each unique user should have a repository client license. (Assuming the licenses are user based.) Suppose I have a project that I've created a vipc file for and I want to load the source code onto the target computer for testing/debugging. Does the target computer also need a repository client license?

Breaking this off into another thread threw me into a loop. I thought maybe I had hit a time warp and it was last Thursday again. You could depreciate a module with a scc distribution system by simply getting a previous version instead of the latest version. Once you figure out which library components a project needs you could apply an scc label to that set of components to make it easy to switch between projects. Granted I suspect it's all easier to manage from VIPM. Questions about snapshots: How are snapshots represented and stored in VIPM? Are they treated the same as other packages? You need VIPM Pro to create snapshots, is VIPM needed to use snapshots? Do you save the snapshot with your package source code in scc? I do personally, but not for work stuff. Regardless of the licensing terms of the OpenG packages, paranoid corporate lawyers say no. How involved is your process and how many developers do you have? Congratulations to Jim and his better half! A Kringling kingling!

Actually, I'm in the early stages of redesigning the current monolithic reuse library into something that is much more modular. I fully agree monolithic libraries are generally not a good idea, having seen how well (*cough cough*) they work first hand. However, unless I'm missing something the distribution mechanism (scc or VIPM) is completely independent of the modularity of the code being distributed. Assuming the reuse library is appropriately modular there's nothing stopping us from mapping only specific library modules (or specific versions of modules) to the target computer, right?

Apologize for the late response, but yes, that is what I meant. The opacity slider too. But now that I've used the icon editor more I realize I want the layers to always be visible, similar to what you demonstrated in your mock up.

All I can say is... D'oh! Kudos for you -

Minor update: v0.9.1 I've changed the implementation for Baby:_GetInterfaceBag.vi. Previously I had created an InterfaceBag object at design time that contained the concrete interfaces the class exposes, set it as the default value, and stored it in Baby's private data. This implementation works but it can be cumbersome during development when things are changing frequently. Changes to the concrete interface tend to break the InterfaceBag. The new implementation simply creates the InterfaceBag object at runtime every time _GetInterfaceBag.vi is called. Since the concrete interfaces are stateless while in the InterfaceBag there is no need to carry them around with the class data. This simplifies the dev work for the class designer and is easier to understand. Ultimately there are lots of ways _GetInterfaceBag.vi can be implemented. The only thing that matters to the framework is that it returns an InterfaceBag object that contains all the concrete interfaces the class exposes.

This is a pretty complex project for someone brand new to Labview. Be aware that you'll likely run into all sorts of problems that don't have anything to do with the core functionality of your program. Yes, you can use non-NI hardware with Labview. If Oriental Motor supplies an api and documentation for their controllers (usually a dll) you can call into the dll from Labview.

Technologically speaking distinguishing between a "left click" and "right click" is pretty easy. I personally favor mapping a "tap and a half" to the right click functionality, but it could also be a foot switch, or a finger sock, or numerous other things. IMO the real problems are insufficient accuracy (believe it or not users can't hit what they're aiming at) and the inherent limitations of a 1:1 ratio between user-movement and on-screen-movement. Here's a link to a post where I describe the problems in more detail.

That's a good question--one I had not considered at all. My initial response is to have a branch for 8.6 and a branch for 2009 but I don't think that's a good idea. Keeping multiple code lines synched up will be a real pain. I suppose we could do all our reuse code development in the earliest version we support and let LV recompile it on test stations that use more recent versions. Not that I like that idea either... I already get frustrated in LV8.6 when Ctl-Spc, Ctl-T doesn't reposition my labels. Any suggestions? I don't understand. Our target computers will be hooked up to our scc system anyway, so isn't it simply a matter of mapping the reuse library's scc directory to the proper location on the target computer and downloading the tagged revision we want?

We had a demo unit set up in the building I used to work in. I played around with it on a few occasions and while it is very cool technology it's practical applications are limited to certain types of scenarios. For a single user nothing beats a keyboard and mouse. I know this comment was made in jest, but Labview development doesn't translate well to any current touch platform. You can do it, but you'll likely get frustrated quickly.

Shhh! Don't let the managers hear. I actually thought about that and almost made the same comment. I've mentioned before that I really like JKI's products, but earlier this week I learned we'll be using our scc platform as a distribution mechanism for our reusable code. It's a little more direct in that it eliminates the package building process (not that it's terribly difficult) and VIPM doesn't need to be installed everywhere, but we lose the flexibility of easily installing files (dll's, .net assemblies, etc.) to different locations. Any other differences I should note? Hmm... I guess I'll have to take a closer look at the NI kit.

Completely off topic, but this comment reminded of something that happened when I was a kid. We had a wood burning stove that we used to use to heat part of the house during the cold season. Our cats and dogs liked to lay on the ground near it to keep warm. One day our cat got the bright idea that being near the stove wasn't nearly as good as being on the stove. Have you ever seen a cat walk on tippy-toes? It's quite amusing.

I know "Microsoft" is a dirty word to many here so hopefully I won't be tarred and feathered for dropping this link.

Thanks for all the feedback. It sounds like NI's UTF is geared more towards regulated industries where traceability is required. I'll recommend we adopt JKI's UTF and spend the money elsewhere.

Sounds like travelling to China. Once you've done it half a dozen times you'd rather just stay home. How long are you usually out for? Meh... feelings are overrated.

Here's an updated version of the Interface Framework. Changelist: Refactored out the dependency on the Collection Framework. The Interface Framework is now self sufficient. Renamed "Interface" class to "IUnknown" to help avoid confusion. Renamed "InterfaceCollection" class to "InterfaceBag," since it no longer derives from the Collection Framework. IUnknown now contains an Interfaceable object rather than a DVR to an Interfaceable object. (Thanks kugr!) Removed friend relationship between Baby and ISleepableBaby. (Thanks SciWare!) Added several UML diagrams to the documentation. (Use Star UML to view the core document.) Still trying to figure out a better name for the Interfaceable class. I'm open to suggestions... A few other minor things, but I've forgotten what they were. A couple notes on terminology: In COM and .Net when an object supports a given Interface it is said that it implements the Interface. This makes sense in those languages; the code that executes when an Interface method is called is implemented directly in the class. That terminology doesn't make sense in this framework since each Interface is implemented in its own class rather than as part of the core code of the target class. I prefer to say an object exposes an Interface. Sometimes I'll also say an object has an Interface or supports an Interface, or an Interface is implemented for an object. I'll typically capitalize the word "Interface" when referring to the interface classes and objects described in this framework. I'll leave it lower case when using the word "interface" in the general meaning. "Interfaceable" with a capital 'I' refers to the proper noun, the Interfaceable class. When it is not capitalized, "interfaceable" is an adjective describing a class or object that derives from the Interfaceable class. These are the main diagrams I've included in the documentation. Hopefully they help explain how the framework interacts with the classes that are built on it. Other than vi context help I have not yet developed documentation on steps for class developers to take to implement classes based on the framework. In this framework any class that exposes an Interface must inherit directly or indirectly from the Interfaceable class. All Interfaces must inherit directly or indirectly from IUnknown. InterfaceBag is simply a helper object that holds all the Interfaces an interfaceable object supports. This diagram shows the relationship between the framework and the three classes (at minimum) that must be implemented when using the framework. Interfaces are designed to be reused so usually the Interface already exists, leaving the class developer with only two classes to implement. Classes that inherit from Interfaceable override the _GetInterfaces method, returning an InterfaceBag which contains all the concrete Interfaces the class exposes. How the InterfaceBag gets populated with concrete Interfaces is up to the class developer. Two common methods are by initializing the InterfaceBag in a Create method or by adding the concrete Interfaces to the InterfaceBag at design time and making those values the default. This shows the implementation of the Baby class in the attached example. It has one added complexity over the generic implementation; the Baby class has made the ISleepableBaby class a friend, which allows Baby to expose methods that are only accessable through the ISleepable Interface. This diagram shows the sequence of calls that take place when a class user calls the GetInterface method on an interfaceable object. Note that the class developer only needs to implement the _GetInterfaces method in their class. The rest of the work is handled by the framework. Here is a sequence of calls made when a class user calls a method exposed by an Interface. As expected, the class developer has slightly more work here in deciding exactly how the Interface method applies to this specific interfaceable class. ------------------------------------- What can you do with Interfaces? That's a little like asking what can you do with Play-doh. Undoubtedly there are lots of ways to use them I haven't though of. Here are a few ideas I've been bouncing around: - I really like Kurt's Active Object pattern. It might be worthwhile to create an IActiveObject interface. Still thinking about use cases on this... - I also like using the Observer pattern to separate program logic from the UI. Maybe an IObservable interface? (Though Event Refnums being strictly typed presents some difficulties.) - IPublisher? ISubscriber? - .Net documentation also provides some hints on potential uses. ISerializable? IPersistToFile? - Or getting back to what started me on this journey in the first place, IMeasureVoltage? IMeasureCurrent? [Edit Aug 3, 2010 - Removed pre-release version. Get current version from the Code Repository.]

I would be breaking things left and right. "What!? I have to go out again?"