JackDunaway

The regex grabs the last section in LabVIEW though. But I'd still steer away from regexes if there's any other way to do it.

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!

&x is the address of x

(type *) is a coercion to pointer to type

* is dereferencing value at x treated as type.

Thanks! That syntax was teetering just above my level of C syntax comprehension (rather, tolerance? )

There are few others descriptions of terminals understandable only for text programmers (if not for C-programmers strictly):

x-y*floor(x/y) - reminder

r*e^(i*theta) - complex number

s?t:f - select

NaN - not a number

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 still vote for symmetric calls in collections--it makes the api much easier to understand.

Cross link from the Idea Exchange: http://forums.ni.com...r/idi-p/1022833 Would the implementation of this idea make this situation less likely?

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

I have a tendency to agree that this idea could promote "seemingly safe" but actually bad practices, and after AQ's warning in 2009, I actually came to realize this is probably not a good feature to add to the language. Granted, it would be acceptable and syntactically slick to execute code in the <Not a Refnum> case, but the tendency for developers to place code in the <Valid Refnum> case makes it dangerous (even my snippet to promote this Idea makes this mistake!).

I respectfully suggest this Idea be Rejected on the grounds of potentially causing more problems than the syntactical sugar is worth (and also because it complicates the case selection of class types, a much cooler and more useful Idea)

... I'm glad I can join this extinguished group....

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

View New Content and that little dot are solely the way I browse LAVA.

same for me...

Me too! (now! )

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

Fortunately using the convert to variant function removes the possibility for the bug to happen.

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

Yes, I see the bug too, but I've got to admit that you confused me even futher by swapping the indicators on the FP (double click on your terminals on the BD to see what I mean). I note that if the representation of the numerics in the arrays are different then the bug goes away.

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

I disagree. I think of the thing on the FP and connector pane as the thing - not the type of thing. If you can use a more specific name then go for it, but if it really is an "object" in whatever field it's being applied to then I say use that name - don't avoid it just because there's a LabVIEW datatype with the same name.

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:

If it is to remain a class, is it inelegant or misleading to have Object In and Object Out terminals on the methods?

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.

You mentioned "demoting," implying you have already implemented the classes. In that case, I probably wouldn't bother converting them to a lvlib unless there are specific performance issues you are concerned about. If it's not buying you anything, don't spend time on it. Just make a mental note for future dev work.

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.

Felix raised a good point. There's no inheritance now, but what about in the future? If you can envision a scenario where you might want to override a function in the library, it may be better to leave it as a class even if there's no state data associated with it.

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.

I'm assuming that you're still going to have an object, right?

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.

1. Should I "demote" this class to a "mere" Library?
2. Is it inelegant or misleading to leave the class as a class?
3. If it is to remain a class, is it inelegant or misleading to have Object In and Object Out terminals on the methods?

So I just fixed was is probably the nastiest code bug I've ever had in my career.... Due to a programming bug on my part, sometimes the programic events would fire 100s of times more often then I'd intended.

Just don't let Norm find out you're using Val(Sgnl).

So this led me to the question, is there anyway to determine how many unprocessed events are waiting in an event queue?

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.

Can you describe your use case for wanting to add a page to the Library Properties dialog. In general we are hesitant allow additions to the development environment tools without understanding the possible applications.

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