JackDunaway

Gotcha! Well, the particular example above is just a subset of what I'm *really* trying to do, (no, "foo" is not the real section header ). If you saw the full parsing requirements, we would agree that a regex with a few submatches syntactically knocks the socks off of a solution with nested token searches. ***EDIT - And after analyzing the problem a little further, the "tokens" are expressions themselves, not static, so slice-and-dicing the string could really get messy! ***

Good point - it works in LV no prob - probably just a difference in the terminal condition of the loops between my app and RegexPal highlighting. So, as far as I'm concerned, Darin's solution works just fine! And, why would you steer away from regexes?

Nice! That's getting close, but it's missing the very last section - here's a screenshot from RegexPal: By the way, this helps enough to get me past an immediate hurdle, but can the regex be refined further to match the last section?

I'm trying to use a part of input text inside a regular expression without capturing the text in the match, but can't figure out how to construct the regex. Below is a snippet that shows what I'm trying to do, and what regex I've tried. Basically, the string is composed of sections that start with "foo", and there is no terminal string that denotes the end of a section. In other words, you know the section has ended when you run into the next "foo", or if you hit the end of the string. I'm trying to divide this string into an array of sections. (Note: you can copy the below input into http://regexpal.com/ rather than firing up LabVIEW) By best-shot regex: (foo[\s\S]*?)(?:foo)? An example input: foo text foo some more text foo some lorem ipsum text foo no more And the snippet: Any ideas?? Thanks in advance!

Thanks! That syntax was teetering just above my level of C syntax comprehension (rather, tolerance? ) Another notable carry-over is the use of "[]" to signify "array". You can find this C syntax many of the primitive icons themselves, not just the terminal names. (And just for the record: generally, it makes sense to reuse these conventions in LabVIEW rather than invent new analogies. The typecast example is one of the few instances where I might consider breaking this convention, just because the syntax is confusing)

Earlier today I was showing the LabVIEW Typecast function to a Perl developer, and I got to thinking to myself: "What does the punctuation (operators?) on the output of that function mean?" Can anyone answer the question: What does "*(type *) &x" mean?

It's helpful for the API to have two separate functions. When using "Find All Instances" in the LabVIEW IDE, it's simpler to have all "Registers" in a list and all "Unregisters" in a separate list. An "Unregister" function is more self-documenting than a "Register" with a special-super-secret argument (e.g., "I forget, do I wire -1 or 0 or NaN to unregister?..."). ***Edit*** - agree with Daklu:

I'll copy my response from the LV IdEx over here:

Protohuman instantiation complete! Just cross-posting the birth announcement of our daughter on the NI Breakpoint forum! (Higher res photo at the link above)

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):