Leaderboard

Daklu,You are in the ballpark on those hidden prims but I have to sadden you with the news that we never finished them. You're lucky if you don't immediately crash the second you try to run a VI with those nodes on the diagram. Sorry these aren't going to be useful nodes to play around with. I'd be shocked and fall out of my chair if you found these used in ANY vi in vi.lib.

I've packaged up a partially cleaned up version of the code as a VIPM and stuck it on the Code Repository in Uncertified. (here). I think I've found and zapped the XNode instances (unfortunately, they don't show up in the normal dependency places) and some of the vi's now have descriptions. I've also added a tip strip capability to the toolbar which has been on my todo list for about a year !

I agree with neil, with one minor caveat. Even if you don't implement code for unknown future requirements, it's good to think about them and guesstimate how much refactoring it will take to accomodate them. Minor changes to your original design can sometimes make future refactorings much easier. In your case it is very easy to replace a concrete class with an abstract parent class. (Subclass the concrete class, create empty vis for all the dynamic dispatch methods, change the inheritance hierarchy so the subclass is now the parent class.) Since this refactoring is so easy I don't see that you gain anything by implementing it now. I'll choose a developer who asks those questions over one who doesn't any day of the week. Those questions *need* to be asked. I believe the tendency to overengineer is a natural part of learning the craft of software development. It will decrease as you learn the costs and benefits of various designs. Eventually instead of asking "should I implement x to allow future flexibility" you'll be asking "how hard will it be to refactor to x to allow future flexibility."