Michael Aivaliotis

...In those cases I therefore use a Class and a MFVI for the X-Control or just use a MFVI for everything.

Really? You write Mutha Fucken VIs too?

I write VIs Mutha Fucka (VIMF)

I use methods and properties on the diagram all the time. However, I also use clusters or arrays of ctrl references passed into subVIs as well.

I don't think it's a good idea to manipulate UI objects from within a class unless the main purpose of that class is to manipulate the UI. Like a UI class.

In your example, I would create a method called Engine State. I would read that state, and if the engine was running, I would disable the button.

So I made a small tweak that should fix this issue. Moving forward. If anyone sees this again please post here so I can dig deeper (that's what she said!).

I think it is very annoying the handle these front panel items in my top level vi block diagram.

Why is it annoying? What is your goal?

I've seen it a few times too. Fairly random "feature"

Just need to up the PHP memory limit a bit (I bet it's set to 32MB)

Ya, I'm aware of this. On my radar.

Just want to give an update that we've moved this to the LAVA CR. That way, it's easier to do revision updates. And it gives better visibility.

Also, there is a new version. That was just posted.

Solving this issue is as pleasurable to me as a root canal...

What are these 2 files? Your own custom files or part of LabVIEW run-time?

Is your laptop connected to the same internet service provider your desktop is?

Am I missing something or is it some problem with the site?

How can I resolve this problem?

The issue has been resolved. Please try uploading your code again.

Thanks for letting us know. Will look into it.

I might be missing something, but those examples seem to demonstrate the Factory Pattern but do not address the messaging problem I am trying to solve.

Really? Did you open up the code?

• UI Plugin Framework Solution.zip
• UI Framework (PC-QSM).zip

They are also referenced here:

http://decibel.ni.co.../docs/DOC-12645

I don't think it's an exact match to your proposed solution but it has the right elements.

See here:

http://decibel.ni.co.../docs/DOC-15014

Specifically look at the UI Framework code.

I think it kinda does what you are asking. Each message is a child class.

This presentation was given at the CLA summit this year.

I am very interested in this design pattern as well.

I'm glad it all worked out.

Is anyone else having issues accessing LAVA?

Ok, now I have a new problem that comes under the topic heading. The file uploader is failing to upload my files... I select the file on my computer, I get the progress bar and then it comes to the end saying that the upload failed. I've tried Firefox and IE8 and also checked that it doesn't make a difference whether I access the local file via system Library or direct path (Win 7 64bit). So now I'm a bit stumped for ideas.

Please try now. It's fixed. There was a glitch due to the recent server upgrade.

I think this is what it's suppose to do since you are using a chart? You are updating the chart from inside the loop with new data. Once the chart buffer is full it will sweep from the beginning again. What is the update mode? Switch it to strip chart and see if that helps.

What version of LabVIEW did you upgrade your current LabVIEW application from? I assume it was working before (on the previous LV version) and now it's not working?

How are you testing this on older LV versions? Are you down-saving the VIs?

When you say the DLL returns all the correct info. How is that possible if it cannot communicate with the hardware? What is returned?

This issue is now resolved.

Hey folks... Sorry about the delay in responding. Looks like LAVA ran out of disk space...

We're working on it.

Just here pimpin' my idea:

Make adding label wires super easy (Step 1: Select Wire, Step 2: Start Typing, Step 3: Profits!)

Do a test to see if C:\Program Files (x86) exists using the "Check if File or Folder Exists.vi". If it does exist, it means you are running 64bit Windows.

Added a LabVIEW Wiki page that covers this. Anyone can edit and improve it if they desire:

http://labviewwiki.org/Development_Environment_Event_Callback_VIs

I think it's probably because most people only use the event case for the UI (and generally wire -1 to it).

I would think twice before generalizing like that. User events are at the top of my list and many others I've talked to, when it comes to inter-process communication. Also, using the timeout frame is a common use-case for reading other data that needs polling or other updates between events. In fact, at the CLA summit, there were many requests by other CLAs to extend the capabilities of the Event Structure even further, since handling user events is simply not enough.

Even though, at the end of the day, I'd really like NI to find a solution to this problem which allows me to register for events all willy nilly-like and only selectively create cases to handle them - my gut tells me that, If I I don't need to react on an event then I shouldn't really be registering for it in the first place, should I. For now, I would chalk it up to: "Hey, I just learned something cool and I really should spread the word about this 'best practice' to my colleagues and warn them about it." Education is important.

Maybe there should be an option to unset this should be available (like an "allow unhandled events to be registered" checkbox in the event dialog if the dynamic event handles are shown)

I really like the option of having a right-click menu toggle in the future that would allow you to enforce that you must have a case for every registered event. The default behavior should be as it is now. This way, anyone relying on the old behavior doesn't get screwed during an upgrade. However, I would also like an options switch to allow setting the default mode for event structures. Similar to the auto-grow option. At least, this way there would be a documentation entry which the user can browse to find out more.