Aristos Queue

2nd alternative: Change the output FPTerminal to just be "Recommended" instead of "Dynamic Dispatch Output (Recommended)". A dynamic dispatch VI does not *have* to have a dynamic dispatch output to match its dyn dispatch input. Making that change would free you of the requirement of maintaining object type across the diagram.

WAY MORE IMPORTANT: When I replied before, I was concentrating on the syntax of your diagram and I offered a work around. Now I'm looking at the semantics of your diagram and I'm seeing an issue. Pump is a class. View is a child of Pump. This VI is Pump.lvclass:MessageLoopStopped.vi. Why isn't all of this code on View's override of this VI? In other words, you should create an override VI of this VI on the View class. Whenever the object is a View object, you would dispatch to that version. That eliminates the To More Specific node entirely. Currently, you've got all the children of Pump that do not have their own overrides calling into this VI and they will all return an error because they are not View objects.

Do the overriding properly and your issues with the dynamic dispatch propagation vanish entirely.

Note the cast will ALWAYS be valid (otherwise the dynamic dispatch will not invoke the method).

The node might produce an error. When it produces an error, the output object is not the same type as the input object -- it is a default value of the type wired to the center terminal. Your output FPTerminal is marked as "Dynamic Dispatch Output". That means that the data from Dynamic Dispatch Input may pass through any nodes that modify value, but not through any nodes that modify type. This node can modify type.

If you are 100% certain that the downcast will always succeed (because of other logic in the rest of your code ensures this), use the "Preserve Run-Time Class" primitive. Like this:

You must wire the center terminal directly from the Dynamic Dispatch Input terminal for this to work so that the node has the original type of the class to work with. If you're not 100% certain the downcast will succeed, run your error cluster wire through the Preserve Run-Time Class prim -- that will tell you when the object couldn't maintain the contract.

I was wondering how (and if) you prevented that from happening. I take it this strict relationship is enforced even if the library isn't password protected?

No, I am pretty sure it only applies if the password is applied.

One reason: Friends are not loaded into memory when the library loads. But for the security model to work, friends that actually take advantage of the friend relationship have to be marked so that we know that the password was properly supplied when the subVI was dropped. This prevents someone from creating a new file of the same name and swapping in new functionality under the guise of friendship. Thus, if you do "Save As:Rename" on the library, all the friends of that library need to load into memory to update that mark. The path lets the project do this loading.

There may be other reasons. I flagged this thread for Trevor since he's the primary developer of friend and community scope.

There, fixed that for you

Um, no. I meant what I said.

Do you think this is doable?

Is it worth posting it to the Idea Exchange?

Probably and yes.

Have you reported this on ni.com/forums so that a bug report can be filed?

I want to link a listbox to an event structure but i don't know how to assign each item in list as a case in event-case structue. It only shows the whole list box when i want to Add an event case!! how can i define each item in my list as a case in event structure?

You don't. You put a case structure in the one frame of the event structure that handles Value Change event for the list box.

Well I did my version over 2 days...

I bet there's some use cases it doesn't handle. On MacIntosh, does it support the D and S keys?

The VI.Path property is not writable - so I will have to pull out the VIs, Save them, then put them back.

Just out of interest - is there a Private Method to do this - surely you guys at NI don't have to do it this way?

You're right, we don't, but it is all in C++ code. Never had anyone ask for it before, believe it or not.

To really push my luck - any chance of creating a wrapper for it?

Unlikely at this time.

What I am trying to do is essentially recreate the Save Class Dialog, and handle unsaved members etc...

That's a massively non-trivial task, as in, it took 4 months and four LV developers to get it working for all the various use cases when we rewrote it in LV 8.0.

Everything was going great until I got to the last bit to do the save

Funny... that's what we said about LV 8.0.

Oh well, maybe I should have taken DFGray's advice and just enforce that the Class is saved.

Yes. Your time will be better spent.

Try just setting the VI.Path property without calling Save, then call save on the Library, then call save on the VI. If that doesn't work, I think the GOOP Toolkit from Symbio does it by removing all the VIs from the library, saving the library, then adding the VIs back and saving again.

Thanks for your input here. I am running Windows XP SP3 on a laptop. I have the OpenG package installed and MGI VIs, but not much else regarding third-party addons. The problem is repeatable every time for me.

There's a program called Jing. There's a free download of the app. It allows you to capture video of your clicks, and it works in Windows XP (there's app for doing this built into Windows 7). Just to make sure everyone is on the same page, I'd suggest downloading Jing and recording the SWF file showing the bug and then posting it on ni.com/forums so that a CAR can be made and tracked as necessary. Jing has been very valuable for recording exact steps to reproduce in a couple of CARs I've worked on lately.

Out of interest I was wondering if the above Idea was ever considered to be a feature but got pulled?

Nope. The icon was included in the icon library for completeness, in case you had some method like "Set To Public" or "List All Public Methods" or somesuch for which the green key was needed.

You should change the title. This covers both New Accessors and New Overrides.

Has anybody with NI acknowledged this issue?

I have not. I just tried my LV 2009 SP1 and 2010 installs. No such bug. I am on a Mac, so that might be a difference.

Is this a good Idea - or are there reasons not to do this?

Making it a symbolic path would encourage you users to link against it. If you thought we were cavalier about changing VIs in vi.lib that aren't in the palettes, that's nothing compared to what we feel free to do to the Resources directory. ;-)

difference between engineers and journalists:

journalist: who can I blame

engineers: who can I get to fix it (otherwise I need to fix it)

I was working on a dual degree in both Journalism and Comp Sci. I didn't finish the Journalism degree -- had one year left to go and decided to focus on CS -- but I did work on the university newspaper for years. I don't think that is a fair evaluation of the journalist. Indeed, I found the two degrees most compatible.

Thanks for your hint. I agree with " Ideally, the primitive should have broken the wire...".

Unfortunately, we can't do that either. Those types were written long ago and they use the ancient "this is a datalog refnum of an enum type" trick. So, properly, this is a type that the Not A Refnum primitive can accept, and it is possible that you might actually have a datalog refnum of the type and it might actually be a valid open file.

We got rid of the CIN but we kept the API identical. All of it.

By the way, Wolfram, congratulations on being only the 6th user I've ever heard of using the Rendezvous VIs in the 10 years I've been working on LabVIEW.

This whole thread should be posted on ni.com so some AEs can dig into it and file CARs as needed. I frequently file CARs for threads I see on LAVA, but a lot of what you're discussing here is beyond my knowledge to write up.

I'm glad you brought up this concern so that we will consider it. I think the plan will be to make a copy of all the necessary VIs (less than there are now), place them in a separate lvlib and install all the code in its own location separate from any VIs used by the LV IDE.

No reason to rename the VIs. AppBuilder uses lots of things out of VI.lib. So does the Getting Started Window. If it really is something that both LV and customers use, put it in vi.lib and let LV use that copy. It means that any bug fixes we find for Tools >> Options also get fixed for users of the dialog.

Kudos!

Really? Even though I likely buddied the code that introduced this bug?

yeah me too! Notifiers just don't seem to feature at all in my bag of tricks...

You should know that under the hood, notifiers and queues are the same class. Notifiers always set a bounding of 1 and always use lossy enqueue. Wait For Notifier is almost identical to Preview Queue except that the Notifiers have the ability to ignore queue elements that the node has already previewed.

Yep. That's a bug. I'll file the CAR.

CAR 246266

Hi,

While I am working with 2010, LabVIEW had suddenly closed for 3 times then I decided to uninstall it. I guess next time I will update only after they have SP version.

A) Definitely NOT the experience we hope our customers get.

B) Please take a moment to post on forums.ni.com the bug reports on what you were doing when it closed.