mje

Reading through the replies got me thinking sub panel as well. I'm just not sure what the behavior would be...if a panel's updates are deferred will that property extend to the VI in the sub panel? I'm guessing no, but from an architecture stand point it would make sense that it does, so I honestly don't know what to expect. Sounds like it's experiment time.

I've handled this by globally disabling and greying all controls/indicators on the panel prior to a busy state. Then do your work, with deferred updates, and re-enable your controls. Easily done with VI server, there's a Controls[] property somewhere in there. Works good if you have some sort of state machine too, your enable method just needs to be state aware.

Also saw a slick demo at the last NI week that had a VI grey out when it displayed a modal dialog box. Pretty sure it was done with a simple image overlay using the alpha channel. Not sure if it was as simple as toggling visibility, or if it involved moving the image from an off screen location, but it looked really slick.

Interestingly. If you change something (like mechanical action or the unbundle names). The warnings disappear............until you save it

Think you may have found a feature.

I thought that behavior was odd as well. Features are fun!

Considering this code works...

...I'd be putting my money on the invoke node?

Interesting none the less, good find.

Yes! Leave PayPal. Please.

It took me many years to finally bite the bullet and support this site, solely because I didn't want to use PayPal.

Needless to say I have a bad experience with them as well, but it's nothing you won't hear a hundred times over on other sites. My only recommendation if lava sticks with Paypal is:

1. Have a completely isolated bank account which is only used for Paypal
2. Empty the Paypal account to your main account regularly
3. Have a completely isolated bank account which is only used for Paypal
4. Don't ever maintain a balance in the account Paypal has access to
5. Have a completely isolated bank account which is only used for Paypal

Also, being able to purchase rather than subscribe would be nice. Auto-renewing memberships set off certain flags if I try to expense it

I think to some extent, yes we are walled off. I'm pretty ignorant of non NI hardware. To some extent it's intentional. My time is way to valuable to spend tackling the latest low-cost, low-support, low-functionality, low-extensibility system from some other vendor. I buy and work with NI because their hardware just works (usually). For me its an investment in a platform that is proven, stable, and reliable, with good support for both hardware and software.

I have my doubts about priority as well. I was thinking it was most likely first to the line or possibly the behavior might be explicitly undefined.

Is there any priority logic that gets applied to tasks that are blocked on a DVR refnum at an in place element structure?

That is, consider two tasks which are both blocked while waiting for a refnum to become available. Is there any way to know which will be allowed to operate first? Does the priority of the containing VI affect this decision at all? Does the order in which the tasks blocked influence which will be signaled first? What about the phase of the moon?

If I look at the error list (same one that appears if you try to click on a broken run arrow, or use the Ctrl+L key), and have the "Show Warnings" box checked, you should see it. Note it's a warning, not an error.

I'm having a slight issue where I'm getting warnings appearing in some of my VIs that use event structues:

The above code appears to be fine, but once I run it, the VI generates a warning in the error list.

Block Diagram Warnings

Event Data Node: cluster has unnamed or duplicate named elements

Details: The cluster being bundled or unbundled by name has elements with no name, or elements with the same name.

So yeah...am I going crazy here? There's no custom objects or types involved, no other cases in the event structure, what you see in the snippet above is what you get.

Is the warning being misassigned, or is there really a problem with the event data that is signalled for in this case, a boolean button?

I find the warning annoying since I'm trying to clear a re-use library of all warnings, and I need to wade through several of these...

Example VI is attached (2010)...

duplicate names.vi

Ok, I'll bite. Portal?

I'm usually RSS or active content.

Also noticed a problem with my last paragraph. It seems the problem only creeps up when consecutive calls to the same clone are made. Either way, reentrancy made for some nice and random behavior depending on how the clones had previously been used.

True, that's another way to solve it. I dislike named objects though since their scope becomes global, so I pretty much treat them as global variables (I don't use them).

I had a deadlock issue that has been dogging me for almost two weeks now, and I finally understand what's been happening. I figured I'd share the experience, because it to me at least, it seems to be caused by such an esoteric detail that I'm surprised I was even able to track it down. I'm hoping that if at least one other person learns something, the time I spent on this will be somewhat redeemed. So if you will, it's story time.

Please examine this little bit of code. The only non-stock VI is a simple read accessor for an object. Everything else is DVR, notifier, or error related. It's LV2010 code.

(Ignore the breakpoint please).

This little bit of logic has proven to be the bane of my existence for some time now.

I'll explain the logic briefly: This VI is meant to stop an asynchronous task that the PumpRef DVR encapsulates. The VI obtains a notifier reference, and checks for an existing notification via a 0 ms timeout.

False case: If we don't timeout, that means a previous notification exists and the task has already stopped (this is the case shown in the screenshot), and no operation on the DVR is performed.

True case: If we do timeout, this means the asynchronous task might still be running (yes might, just trust me on this, I said it's story time, not thesis time). So we send a signal to the asynchronous task to tell it to stop. This is not shown in the screenshot, it's in the True case of the case structure.

We then release the lock on the DVR, and block on the same notifier. One of two things should happen:

1) If the false case above fired, we'll just pass right through the wait since a notification already existed.

2) If the true case fired, at this point we'll block until the asynchronous task returns, then we'll be off to the races because the last thing the task does is signal the notifier.

Now there's a huge problem with this. The logic above is sound, but there's a very important implementation caveat about using the Wait on Notification primitive:

This function does not remove the message from the notifier. Although a specific instance of the function returns a message only once, other instances of the function or to the Wait on Notification from Multiple function repeat the message until you call the Send Notification function with a new message.

Emphasis added. It's the emphasized part that bit me in the behind. The logic of the framework I'm working on is a little more complicated than the simple case I outlined here (big surprise, huh?) and it turns out that the VI will sometimes be called twice in succession. Well, guess what, in that case the logic works like this:

First call, first Wait on Notification primitive: Timeout, the asynchronous task is running. A signal is sent (not shown, True case of the structure), and it starts the shutdown sequence.

First call, second Wait: Blocks, eventually the asynchronous task returns, signalling the notifier, and the VI ultimately returns.

Second call, first Wait: Returns notification, this particular instance of the prim has never seen the notification before.

Second call, second Wait: Deadlock.

Why a deadlock? Because the second instance of the Wait prim has already received the notification in the first call to the VI. It will never return.

The solution you ask? Use a single element queue, and do queue previews.

The lesson: Be very careful when reusing notifier primitives if you're expecting to be able to receive old notifications.

Bonus points: Reentrancy does not seem to affect primitive reuse. The VI above is in fact reentrant with multiple clones flying around. If clone 1 of the VI fires first, clone 2 will still deadlock. I did not expect this (queue up another few days of debugging)...

So cheers, and thanks for paying attention if you kept reading this far.

-Michael

<edit>

Ok, I just re-read your post, you want to change the member icon not the Child Class banner.

Not in my tool, but still scriptable tho (and would complement the tool)

</edit>

Yup, therein lies the rub.

I'm aware of your tool but I've never successfully got the right click framework to work on my development systems. Haven't tried since 2010 though, might have to give it a whirl one day.

Edit: I totally misread the requirements...quick drop plugin, not RCF...I'll definitely need to take a look.

So, I'm doing really menial work right now, but the perfectionist in me demands I do it.

Might be going a little crazy while doing it though.

But I had an idea.

So I posted it.

Basically, when editing the icon of a dynamic dispatch VI, I'd like to automatically be able to apply an icon change to all child implementations. Not unlike how icon changes propagate through all objects when you edit a library icon, only you know, now for dynamic dispatch VIs.

You all agree?

Oh man, that last one I fixed is off by one pixel relative to its parent...

-m

Sweet. Thank you both for clarifying that.

-m

Still seem to be missing some dependencies. Of note, I'm getting complaints about MessageQueue.lvclass, Message.lvclass, and ErrorMessage.lvclass.

Seems neat though, can't wait to look more into this!

If I have an architecture where I have a multitude (>1) classes which could concievably be used to process a certain input data (format the same but contents different) I don't want to limit my expandability by hard-coding which class handles which data. If I then incorporate a method into the classes to tell me how well they can deal with the data and then choose the best fit, what would I call this approach?

We do exactly the same thing with one of our applications we've written, each object knows how to manipulate its data by virtue of its class, but the user of the object only cares that its some instance of a base class that can be operated on (it's in fact a base class wire that gets passed around) . However since myself and the other person I work with are both chemists by trade, neither of us know the "proper" name for what we're working on either. To me it's always just been an application of OOP-based polymorphism.

Transformations don't require a new buffer because you're telling LabVIEW to change the way it interprets an existing piece of data. The string "8243" becomes the numbers {56, 50, 52, 51} or {0x38, 0x32, 0x34, 0x33} because it is the U8 representation of the same data the string contains. Cast to a U16 and you get only a two element array {14386, 13363} or {0x3832, 0x3433}.

Now I'm a little unsure about reinterpretation. It makes sense to me that a temporary buffer would be used if the two types don't occupy the same physical number of bytes, otherwise memory would start leaking all over the place. Make our string "82437" and our U8 data is as expected since the sizes align and can be made to match, {0x38, 0x32, 0x34, 0x33, 0x37}. Cast to a U16 though and we now have alignment issues that cause size mismatches, the cast returns {0x3832, 0x3433}. We've lost our last byte of data. I'd expect this is a re-interpretation?

You will notice that most nodes that take in references also have an error out terminal. Dereferencing a DVR can definitely produce errors (not to mention the fact that the access is asynchronous potentially and this would be hidden from the user) but static methods have no error terminals. There would be no way for us to pass errors along either to the static method itself nor to the callee; instead of getting the actual class, they could get a default data instantiation of the class and be none the wiser. This is why the property nodes will auto dereference; they have error out terminals.

Yes, I suppose that if this ever were to see the light of day, some connector pane requirements would have to be enforced, not like those for the VIs in property definition folders.

I'm curious, in the case of property nodes operating on class DVR refnums, are the errors that can be produced (not counting the ones the VIs themselves might throw) the same as those that might be generated through an explicit in-place element structure? Also, I'm curious if using property nodes on simple by-value class wires (not refnums), can any errors be generated at all (other than any that are generated explicitly by the underlying methods)?

I've been working with data value references of classes quite a bit over the last few weeks. One feature I've fallen in love with is the new property definition folders for classes that the 2010 IDE allows us to use. Not sure how many of you are aware, but in addition to allowing easy access to several bits of data from a single node, they also automagically handle locking/releasing of class DVRs as well:

Which is completely awesome, by the way. Kudos for adding that feature.

Which got me thinking, it would be neat if statically dispatched methods could also do it. Currently for methods I might need to access from both a by-value and a by-reference scope, I find myself writing two methods: the by-value one which has all the logic, and a thin by-reference wrapper which simply calls the by-value method from within an IPE structure. I've love it if the NI wizards could find a way to have this happen automatically, kind of like the property nodes.

The only problem I see is how is LV to know when to be able to allow the use of this automatic dereferencing? There would likely need to be a requirement of having both an input and output for the class of interest, but other things creep up to, such as methods which have both in and outs for multiple classes. This might require a new type of connector flag separate from the four currently used (Dynamic, Required, Recommended, Optional)?

Any thoughts on this?

Yes, I'd love to see that idea implemented. Usually though, I take the situation as a hint I ought to put the loops in their own VIs. Not always convenient, but helps a lot for when you need to do stepping or execution highlighting.

Good idea, but nope, the methods still list in the override dialog. Code is attached.

To reproduce the behavior, just right click on View.lvclass, select New > VI for Override ...

The View class inherits from MessagePump, which defines the offending methods. Some of the offending methods are even privately scoped, all of them reside with property definition folders:

Note that if you then go further down the inheritance chain, and try to implement an override on ContainerView, the methods are no longer listed.

The project is for LV2010: LabVIEW.Messaging.2.0-r494.zip

There's still something funky going on with that class though. I think some of the info in the lvclass file is corrupt or something?

Look what happens when I try to create an override:

What's the problem you ask? The methods in the red boxes are not dynamic, yet the script picks them up for some reason and puts them in the box. Also the previously mentioned bit how the terminals aren't getting properly renamed when I override a method in the class.

Even weirder is the dialog appears normal if I try to do an override of a class further down the inheritance chain. For now I'm ignoring the behavior, I hope it doesn't come back to bite me in the behind...