JackDunaway

Let's overlook the "snuffed flame" comparison - congrats on passing! And I can vouch that the FE was by far my hardest test also!

same for me... Me too! (now! )

Inspired by Fab who showed us a time-saving trick she just learned, here's a trick I stumbled upon today by noticing a tip strip from an inadvertent mouse hover in the "View New Content" section of LAVA. If you click on the bullet rather than the thread, it will jump to the first unread message in the thread, rather than the first post in the thread. My life just got better - been wanting this feature!!

Based on my own experience, it's probably not a good idea to flatten classes as binary data, and then expect to unflatten them with a more recent version of the class by relying on the mutation history. This includes persisting objects to disk, or flattening objects for inter-application communication between two executables with different versions of the class. Two reasons it's not good to rely on the mutation history: 1) The history can get wiped out pretty easily, for instance by renaming the class, and 2) The mutation history stops recursively tracking data structure changes once it encounters a Typedef (including Enums and Clusters) as a private data member. (reason 2 can actually get you into trouble while developing source code, which in my opinion is a good enough reason to never place a Typedef inside an LVClass) About the best choice I've found for interoperability or persisting arbitrary structures is XML. Although it seems tempting to rely on the "magic" of the built-in mutation, it would be pretty easy to get into a situation where you get burned unless you become a domain expert on making the mutation history behave

True, this is a valid workaround, thanks TG! (see snippet) This is a known issue, CAR 279047.

Thanks for the confirmation - crelf! I'll pass on the UI recommendation to the guy who made the UI

Attached is a bug we've run across where the data name is not properly interprete in the variant coercion process. The bug manifests itself in different ways in 2009 and 2010, but is present in both versions (see FP of attached VI for details). BugInVariantCoercion_2009.vi

It appears OS Window is deprecated - you may want to try Native Window. It outputs 64 bit handle rather than 32-bit, and the results seem to be equal (run this snippet):

That's the inverse of what I was arguing... you're saying "don't use Object if there's a more specific term that applies." I'm saying "If you do use Object, it better be because you're applying to a generic hierarchy." And for reference I'll quote my original question #3: I can understand how the tangent of terminology arose from the way I worded this question, but I was referrering to the use of a Class Control and Class Indicator (with whatever name label) wired into the top I/O ConPane terminals, and a straight wire shorting the input to the output on the class (a straight wire connecting the two, because without any private data elements, you couldn't do anything else!). The purpose of this practice would allow the dynamic dispatch ability, but this contradicts with my other constraint of no inheritance. If we bring inheritance and function overrides back in play, a DD input is required, whether it's misleading or not (there is argument whether the output should exist since the method is not able to modify an object that contains no elements). Asking #3 remains asinine, because the object input terminal is a requirement, not a matter of elegance or coherence. My bad.

This sparks an interesting idea - would anyone else see benefit in a "Convert from Class to Library" and vice-versa on the context menu of a project item? How often would you use this button? (From my experience, once, ever). Another interesting point - the burden of relinking all library items may overwhelm the benefit of a more coherent library choice (Class or Library), but in my case the relinking burden was small so I favored coherence. Again, I considered this, but with no definite or even likely plans to ever subclass, the more coherent choice is Library. I'll close by saying that with my particular case, it looks like a .lvlib, quacks like a .lvlib, and swims like a .lvlib, so by golly I'm going to make it one. But you may find compelling design reasons to use a .lvclass when a .lvlib would suffice.

No, he's not. That's the whole "stateless" part of his original post. With no data in the cluster, and no inheritance to add any (either real data or the meta data of runtime type), there's no object instantiation at all. AQ is right - no object, no state, no ref (and definitely no clusters!) passing between member VIs. To be fair, my original wording - "its objects are stateless" - is misleading. The absence of an object connotes statelessness. Today, my original questions seem pretty asinine basic (actually, let's allow #3 to remain asinine ), so maybe it would help to know where I was coming from - I had just finished revisiting an old class, hacking and slashing dozens of redundant data members and accessors, until, alas!, virtually nothing but a few stateless utility methods remained. Could I believe my eyes? Could such a substantial class structure be reduced to a wee library? Retrospectively, yep. Just needed a second set of eyes to confirm I wouldn't get snagged by some unforseen caveat (namespacing, common Icon, access scope, folder items for organizing project tree - all the goodies are still available, so .lvlib is go for launch). Thanks for all the responses!

Thanks for the quick answer, AQ. I will dutifully inform a few of my classes that, as suspected, they will be asked to abdicate all unused LVClass superpowers.

Consider a LVClass that has been reduced to the point where it has no Class Private Data - its objects are stateless. Also, consider this class is not part of a class hierarchy, so inheritance does not come into play. Should I "demote" this class to a "mere" Library? Is it inelegant or misleading to leave the class as a class? If it is to remain a class, is it inelegant or misleading to have Object In and Object Out terminals on the methods?

Just don't let Norm find out you're using Val(Sgnl). There is not currently a method to know how many unprocessed events are in the "Event Queue" of the Event Handler Structure, here's the discussion. But there are a few Ideas (Discard Stale Entries, Event Queue Size Terminal, Register New Refs, Priority, Control Event Buffer) you can vote for to make the "Event Queue" behave more like an Event Queue.

Thanks for replying! Parameters for use cases are limited to making class modifications already available on the other tabs, just with a different user interface. This is just a personal project (certainly not commercial), but would gladly be shared with any others interested.

Felix - Good ideas, I am pursuing them Yair - That lead is opening new doors, thank you! Current progress with my custom page - looks like I need to do more research with datatypes (I'll add developments as I casually work on this side-project):

Has anyone attempted to add pages to the Class Properties Dialog (..\LabVIEW 2010\resource\Framework\Providers\VILibrary\LIBUIP_Properties_Dialog.vi)? It must be possible to add new pages since when I create a copy of the Wire Appearance page (..\LabVIEW 2010\resource\Framework\Providers\LVClassLibrary\libpropPage_WireDesignEditor.vi) it's enumerated twice. I've already tried simply naming a file prepended with "libpropPage_", but the contract requires more than that. I have a hunch I'm going to need controls for "Page VI Data", "page synch rendezvous", "stop event in", and "page events in". (With a name like "page events in" I'm pretty sure reverse engineering is out of the question, perhaps a peek under the password-protected-hood? )

You know what... you're right, I can't get it to work either with 2009 or 2010. Even with the chameleon color (d16777271). Perhaps this worked in the LV8 era, or more likely, just some strange deja vu of which I happen to remember procedural details. Best I can offer after bum advice is crelf's product suggestion for 0px splitters.

Do you get your desired effect by setting the splitter colors (FG and BG) to transparent? This must be done via property node, since the recolor tool fails to work. If I recall correctly, the splitter looks black in edit mode and actually turns transparent in run mode.

That date is probably December 9, 2010, not Sept 12, 2011.

I don't know if you've seen the new Idea about a LabVIEW Issue Tracker to facilitate this very issue; perhaps it's worth checking out. The best way I know to check the status of a CAR is to email or call someone who can access NI's internal bug database (e.g., an NI employee). They will sometimes be able to help, especially if the information is not "classified". Word on the street is Alliance partners also have (partial?) access to this database.

I think it's fair. NI has limited resources, and assuming they're dutifully employed, the developers working on Distribute Wires are not working on something better. Not specifically.

I'll be the first to admit: NumVotes is often not proportional to IdeaPowerOrUsefulness. Distributed Wires=356 versus Undo after Save=67 is a great example. I'm excited Distribute Wires is making it into the 2011 release, don't get me wrong, but it comes with the opportunity cost of any one of dozens of better Ideas.

This is a cross-post from the Dark Side - I've searched for a while without finding any definitive discussion on this topic, so please post your thoughts over there.

Thanks, Philippe! After lurking for three years, I finally decide to chime in for the first time with a buzzkill.