Leaderboard

I know that some work arounds have been presented, but it'd still be nice to be able to look at a method's inheritance without having to load the whole class.

My wife and I were sitting in the window seat of one of those eateries when my Wife nodded toward a group walking down the street and asked "What about them?" I looked up and saw Jim, Michael, and the JKI crew. But using the term to "geeks" to distinguish yourselves during NI week is like saying "Look for me at the prom, I'll be wearing a tuxedo." Ben

Thanks again for you reaction. I have been tuning my software and also added code to scale/sort x- and y-axis. My waveform is now almost a duplicate of the drawing. There is however a bug which I haven't found jet which screws up my x-axis scaling. I'll try to fix this myself. Thanks for all the help so far.

Next time have your speakers on. Your computer was probably saying "I'm sorry Dave. I'm afraid I can't do that".

For me, a programmatic build method refers to "automation" and therefore I don't normally stand there and watch it however, I do like to track the stages of building with messages to the UI. I used to have a timer running in a parallel thread however, running the NI Builder API locks up everything so the timer doesn't even update at slow rates. Anyways, I don't know how one would access the info from the API (if it was there) maybe by polling a resource in parallel or subscribing to an event? This would add extra complexity to your build process architecture which would be a pain IMO (and that is why I scraped the parallel timer and just get the total build time for interest). If the info is not available then maybe if the entire dialog (rather than just the info) was automated/included in the API; e.g. a parameter that was: Popup Status Window During Build = TRUE; then that would be easier to use in a custom build process? Maybe a post for the Idea Exchange??

I thought I had replied to this message. I know I typed something up--wonder what happened to it? Maybe I never submitted it... Depending on how you're planning on using your CAN classes in your applications, what you're describing is part of your reuse library, not the HAL. They belong to the Instrument Driver layer on Figure 1 of that document. The HAL is written specifically for each application. It isn't intended to be used across different projects; it's intended to make it easier for you to use different modules from your Instrument Driver layer within a single application. (Or maybe that's just my own narrow view of a HAL.) Here's a class diagram of a project I'm currently working on that illustrates how I implemented a HAL. The yellow layer on the bottom contains the reusable device driver libraries and classes. The purple layer contains the business logic and is completely independent of any specific device drivers. I can work on that code without having the device drivers even installed on the computer. (This was handy since the device drivers hadn't been written.) The blue layer in between them is the HAL. It is responsible for translating high level application requests into low level device specific commands. This diagram doesn't show it very well, so I'll explain the calling hierarchy for one set of application functionality--the Data Collector. (Note: Following Elijah's terminology the DataCollector(Sniffer) class is part of the device specific software plugin (DSSP) layer and the DataCollectorInt class is in the application separation layer (ASL.) I couldn't diagram that very well in my UML tool while keeping my classes in their correct libraries, so I use slightly different terminology. It's essentially the same thing though.) DataCollectorInt is a class that is part of the application execution layer in purple. It has only a few high level abstract methods related to collecting data: Connect, Disconnect, IsConnected, StartCapture, StopCapture, etc. Any method inputs are either native LV types or other objects within this layer. i.e. The Connect method takes a ConnectionInfo object as an input parameter. StopCapture returns a Result object and a Trace object. DataCollector(Sniffer) is a child of DataCollectorInt and implements the abstract methods of its parent. This class is an instrument specific implementation for our Crossfire and Sniffer instruments. If I change the instruments used to collect data I'll derive a new class from DataCollectorInt and implement new device specific code for each of the higher level DataCollectorInt methods. Note that this class uses composition, not inheritance, for its lower level functionality. CrossfireDSL is the device specific layer for one of our instruments. It turns out this class is only a wrapper for the Crossfire class in the device driver layer. I'm not sure there's any immediate advantage to having this class in the design. There could be a long term benefit if we ever replace our current Crossfire instrument with a new version that requires a different Crossfire device driver. I'll be able to derive a new class from CrossfireDSL that uses the new Crossfire device driver and easily plug it in. SnifferDSL is another class in the device specific layer. In this case it made a lot more sense than it did for the Crossfiire. The Sniffer library in the device driver layer contains 7 classes. (The library and classes are a simple wrapper for a third party .Net api.) I was very unfamiliar with the Sniffer api, so I used SnifferDSL to learn the api while at the same time abstracting away all the details (and 7 classes) of the Sniffer api and giving me a few higher level Sniffer control methods. Both CrossfireDSL and SnifferDSL also use composition and delegation instead of inheritance to get the functionality of the classes from the device driver layer. In fact, the only inheritance relationship is between DataCollectorInt and DataCollector(Sniffer). I did this specifically because I wanted to invert the dependency between the application execution layer and the HAL. (In fact, inverting dependencies is one of the few reasons for creating abstract classes in Labview.) If the dependencies don't matter you could skip DataCollectorInt altogether and link directly to DataCollector(Sniffer). That is simpler and more in line with what Elijah's paper describes. ---------------------------- I don't know anything about CAN or the devices you're describing, but I'd be very cautious if you're planning on making BaseCAN part of your reuse library. I tried that and abandoned it. IMO instruments change too much for this kind of hierarchy to work well over the long term. Each instruments' idiosychrocies and slightly different command sets can make it impossible to maintain a coherent generic interface while providing the low level functionality you might need for your next application. These days my reusable instrument drivers are very thin wrappers that exposes each of the instrument's commands. Higher level abstractions are application specific code built on an as-needed basis.

I always include a dummy file in the directory I want to create with the installer. That's the only way I've found to create a directory George