Leaderboard

Result received this morning, I Passed Good day today

"this consideration is one that can easily take seconds and affect end-user experience of your application" is an oversimplification. For my app, there are numerous independently lazy-loaded application components. If all were to be loaded at once, it would take seconds. By ensuring loose coupling by eliminating static dependencies between these applications components, they are able to load independently. (It didn't always work this nicely) And I agree with the sentiment of your concern. You don't ever have to worry about dependencies until you do, and you will.

Okay, that lowers them a little bit, but not completely. There are a few things I'd look into to see if there are potential issues in the design. (Note I'm not claiming your design is bad. Rather these things *may* indicate future trouble spots. They are simply things to consider, not reasons to change the design. Alternatively, if I were in a design review these are the questions I'd ask.) It sounds like your functions may have a large degree of fan-out. (Fan-out in this context = the number of unique sub vis called by the vi.) High fan-out isn't inherently bad, but it may be indicative of a problem. Functions with high fanout are harder to describe and understand. Furthermore, they are more succeptable to requiring changes in the future simply by virtue of having a lot of dependencies. (A change to any of the dependencies may necessitate a change in the caller.) I take it each function in your library has a mostly unique set of static dependencies? (Otherwise the additional overhead to load the unused functions would be imperceptable.) Given that, do these functions really belong in the same library? Labview lacks good support for namespacing independent of library membership, so sometimes I bundle things in a library for the namespacing benefit, even if they would be better off in separate libraries. Still, it's worthwhile to ask the question and understand why they are in the same library. And to be crystal clear, whether or not you can answer these questions to my satisfaction is irrelevant. What's important is that you can answer them to your satisfaction.

After two years "leeching" content every now and then from the Lava community I think it's time to contribute a little bit. Right now, I'm working on a project that involves lots of data mining operations through a neurofuzzy controller to predict future values from some inputs. For this reason, the code needs to be as optimized as possible. With that idea in mind I've tried to implement the same controller using both a Formula Node structure and Standard 1D Array Operators inside an inlined SubVI. Well... the results have been impressive for me. I've thought the SubVI with the Formula Node would perform a little bit better than the other one with standard array operators. In fact, it was quite the opposite. The inlined SubVI was consistently around 26% faster. Inlined Std SubVI Formula Node SubVI evalSugenoFnode.vi evalSugenoInline.vi perfComp.vi PerfCompProject.zip

Great feedback on the example. To tweak the example, consider a base class called ProbeDisplay.lvclass whose job is to show a human-readable string for the Probe Watch Window. One could imagine there might be a lot of VIServer legwork and IDE voodoo in the base class (since it's desirable to reuse these abilities through inheritance), whereas child implementations such as ProbeDisplay.lvclass and ProbeDisplay-MyClass.lvclass would be relatively simple: serializing unique datatypes, and for the sake of illustration even sets of datatypes with multiple inputs on the ConPane if we could create some new WackassProbeExecutiveAggregator.lvclass child implementation. Now, it's clear you cannot just say "all implementations should be strings" -- now what do you do? OK, in the meantime rewriting this post, you came in with some good reference material that will take time (read, maybe days, weeks, after CLA Summits even) to chew on: In return, here's a link that has helped me, from which I recognized the name Uncle Bob (who has 3 contributions on this list): 97 Things Every Programmer Should Know And finally... It would be eternally helpful to do a post mortem on what the *right* solution would have been if you're able to share. (Or if Shaun is game, let's tackle his example in post #23) Perhaps, we decide the 'correct' solution is syntactically way too burdensome and in the architectural atmosphere, but at least we would feel less icky about the solutions as developed.

I think it's pretty clear from my post above that I think your problems stem from incorrect class design. But you asked for links, so here is one... Principles of Object Oriented Design In particular, your NotifyUser child classes seem to violate the Single Responsibility Principle (they convert data to a string AND display a message box for the user) and the Liskov Substitution Principle (child objects can replace parent objects without breaking the program's behavior.) Suppose you had a program that used the NotifyUser.DisplayMessage method, and at some point you decided to replace it with NotifyUser-Bool.DisplayMessage. What changes do you have to make? In a properly constructed class hierarchy you can simply replace the class constructor method (and arguments as needed) and everything else will work correctly. But with your NotifyUser design you'll have to go in and change the client code everywhere the DisplayMessage method is called because the message is coming from a different source. (As it must since the original message source is a string.) Now, if your intent is not to replace the NotifyUser object with a NotifyUser-Bool object at runtime, there's no reason to make NotifyUser-Bool inherit from NotifyUser and we circle around to AQ's question: Why have you established a parent-child relationship between these two classes?

I fully agree SetMessage followed by DisplayMessage is a less than optimal design path. In this particular case I think the problem is related to your class design and naming. First, NotifyUser implies gaining the user's attention somehow and optionally providing them with information to act on. Currently is has a single method, DisplayMessage, which displays a message box. Presumably a NotifyUser object could have different methods to notify the user in different ways, such as ApplyElectricShock or PlayAudioFile. These methods would have different inputs appropriate for what the method needs. Creating a child class named NotifyUser-Bool causes problems--ApplyElectricShock and PlayAudioFile have no meaning in a boolean-titled subclass created to override the DisplayMessage method. Sure, NotifyUser-Bool can simply not override those methods and use the default parent class behavior. The point is calling a PlayAudioFile method on an object named NotifyUser-Bool is incoherent. It doesn't make semantic sense. If you want to make child classes for each of the possible data types, then DisplayMessage (or other string-based notifications) is really the only method you *can* have in the class. And if that's the case then the NotifyUser class is misnamed. It's not a generalized object for notifying users; it is in fact a very specific way of notifying users. It should be called something like SingleButtonDialogBox. Now, if we have a class SingleButtonDialogBox with a single method DisplayMessage requiring a string input, it makes sense that all subclasses implementing DisplayMessage will also have a string input. After all, they are all going to be (or should be) some sort of dialog box, and dialog boxes require string inputs. Maybe you create a TimedSingleButtonDialogBox class that dismisses the dialog box after a fixed amount of time. But it's still going to require a string input to display something to the user. In short, the class name NotifyUser implies a high-level object that is able to notify an arbitrary user in an arbitrary way with an arbitrary notice. It creates the developer expectation that this object is responsible for any kind of user notification. On the other hand, the DisplayMessage method is too specific. The functionality implied by its name is too far removed from the general functionality implied by the class' name. I suspect it's this gap in functionality and unclarity in what the class is actually responsible for that is causing you difficulty. In particular, you are making NotifyUser (and it's subclasses) responsible for transforming an arbitrary data type into a string, and that responsibility is (imo) better left to someone else. (Such as giving the data object a ToString method.) (I realize NotifyUser is simply an example meant to illustrate the issue, but any example I come up with illustrating this problem leads back to questions about the design.) I fully agree with this. Many of my classes have little, if any, mutable data, and I have found it makes multi-threaded programming much easier. However, I don't think your suggested solution is the right path to take the G language. In my eyes it enables incorrect designs with no appreciable benefit for advanced users. Minimizing mutable state is entirely possible using good programming practices with existing versions of Labview. It's not clear to me how adding a Must Immplement flag on non-existing vis moves towards the goal of minimizing mutability. (As an aside, in the past I've openly wondered how closely related dataflow programming is to functional programming. It's apparent there are similarities, but I don't have enough experience with functional programming to give a fair assessment. It appears you've discovered the same similarities. ) Hmm... I guess my thought is simply the need to flag "Must Implement" is, by definition, an indication the design is flawed. I'm open to being convinced otherwise if you can show me an example of a good design that needs the Must Implement feature. (And to clarify, by "break the behavior of the class" I mean situations where a reasonable developer would have to dig into the parent's source code to discover why the child object is not behaving the way he expects given what he has implemented. I specifically do not mean that the child object will do everything "correctly" as a fully implemented child class would.) Have I ever wished I could change the conpane of overriding methods? Yep. Have I ever created child classes for a specific data type? I'm pretty sure I have. But these were driven by a desire for expediency, not because they were the correct design decisions.

Hello, you should perhaps give a try to XTab, this is a free solution that implement a subpannel based solution. Video demonstration : http://www.dailymotion.com/video/xksiht_xtab-pictureviewerdemo_tech Documentation here https://decibel.ni.com/content/docs/DOC-21668 Dowload here http://sine.ni.com/nips/cds/view/p/lang/fr/nid/210715 Olivier

I have not tried this yet, but it is something I will check out as son as I have a couple minutes

I would say, yes, you should demote it to a mere library (although, since it already is a mere library -- because a class inherits from a library and thus fulfills the "is a" relationship -- it might be better to say "only a library"). If the situation is as you describe, then the functions are just a collection of VIs. Creating a data type and then not using it is just wasting system resources, however small they might be. And, implied in that, I would not have Object In and Object Out terminals. What would be the point? If you wired them, all you would be doing is creating false data dependencies between functions. Now, having said all that ,before you actually build the new library, I'd pause a while and ask, "Am I absolutely certain that these functions belong together at all? What data *are* these functions operating on? Should they be packaged with whatever class represents that data?" Maybe they really are math operations or string utilities, but I don't see many programmers creating large libraries of those.