Michael Aivaliotis

You forget the big one - MOUSE WHEEL  . By far the most useful, just a shame it's the only one.

Thanks, I added it to the list.

Unfortunately, i did not get to see your presentation because it was at the same time as mine However, I will devour Mark Balla's video of it. The feedback I heard from others was that each of you (David and Staab) could have had your own dedicated sessions. So not sure how you can add more content. But I will reserve judgement until I see the video.

The new Events features is my favorite. I did a presentation on this topic at NIWeek. I started a new thread to spur discussion (i don't want to derail the current thread). I'd like to get the community's input on the new event features.

New Events Features in LabVIEW 2013

I did a presentation at NIWeek 2013 on the new user event features in LabVIEW 2013. I will post a link here when it's ready for online consumption. For now, I'd like to start a discussion on what all the LAVA members think of the changes and additions. If you have questions on how one feature or another work, please post here and we'll get it answered.

To summarize, here is what was changed, added:

• New - Event Inspector Window (you're gonna love this!)
• New - High Priority events
• New - Flush Event Queue Function
• New - VI Scripting methods and properties for events
• New - Mouse Scroll Wheel Event
• Improvements to the Edit Events Dialog:
  • It's now resizable (Finally)
  • You can filter search the list of event sources and events. For easy navigation.
  • You can limit instances of the event in the static queue (Similar to Flush Queue function)
    

  [*]Finally, there was a behaviour change: Non-handled, dynamically registered events do not reset the Event structure timeout terminal. In LabVIEW 2012 and older: Non-handled, dynamically registered events reset the Event structure timeout terminal.
  

Let's keep this positive. We all need to learn how to use these new features and how to integrate them within our frameworks. I know a lot of you are using user events as the main communication mechanism for your processes and modules. Let's figure out how to make our code better with all this new cool stuff.

I didn't see Norm's impromptu Leap Motion presentation, but I think that's what he was using with his scheduled presentation... right up until he disconnected it because it wasn't behaving. 

If anyone knows Norm, you know how much hand waving he does when he gets excited. Well, the Leap Motion got hand wave overload

fixed

Just found out about this "NIWeek tradition"

https://www.facebook.com/events/678470302167587/

http://youtu.be/ASO_zypdnsQ

I'm guessing that this will eventually be released publicly once your release cycle comes around?

Yes, correct.

A follow up to this. I've added this feature in VIPM Pro. It's not available in the public release but you can get it in our VIPM Labs section here: http://support.jki.net/entries/24071293-VIPM-Labs . Even though it's not a public release, we are fully supporting it just like any other release.

It requires the NI licensing and activation toolkit. Not going to be buying that...

Just wanted to make a correction. The licensing and activation toolkit from NI is free.

JKI will be releasing VIPM 2013 for the Mac soon.

If you want to try a preview release, you can download it here:

https://jki.box.com/s/d3ux8pknhu39znpc0re8

It supports Package configurations, building, repositories and The LabVIEW Tools Network. All the same cool stuff that the Windows version has. The power of LabVIEW allowed us to use the same code base for both Windows and Mac versions which was pretty awesome.

Let us know if you have any issues.

In order to get VIPM running again, you just need to install the LabVIEW 2011 run-time engine. You can get info about this here:

http://support.jki.net/entries/20959253-LabVIEW-RunTime-Engine-for-VIPM

If that doesn't help. Send an email to support@jki.net and JKI will open a one-on-one support ticket where we can get this resolved.

This issue is on our (JKI's) radar for VIPM 2013 and will be fixed in a way where you won't have this problem anymore.

In regards to the other comment: "I'm concerned that if I ask NI about VI Package Manager, they'll bounce me over to JKI, and the reverse if I ask JKI about it." - I want to say that both JKI and NI take customer support and problem solving very seriously and we will always do whatever we can to get problems like this resolved. So don't be afraid to ask. 

works for me

Need a solution for LabVIEW on the Mac. I'm looking for a way to list all running Mac apps. Then I want to pick one of them and issue a quit message and have it exit gracefully.

Does anyone know how to do this on the Mac?

Please do not report any of these issues to this thread anymore since the problem is already quantified by me and I am trying to address the root cause. The problem is intermittent and when it happens, I can fix it by repairing certain tables in the database.

If you notice this problem, you can Skype me at michaelaivaliotis with a short message stating that LAVA is down. I will then promptly fix it. But don't expect a response on Skype acknowledging receipt of the message. You will just see LAVA work again.

So another Mac issue. Whenever I try to use the ZLIB Store File.vi, I get an (always helpful, generic File IO) error. See the screenshot.

Can someone (Rolf?) help me with a workaround? I need to stick with the OpenG Zip library because of the low-level VI's it provides, which are very powerful.

The following VI is part of the OpenG LabVIEW Zip Library:

ZLIB Specific Path to Common Path__ogtk.vi

If you notice, the case structure supports Mac OS, but not Carbon. The App.TargetOS output is Carbon. I'm running this on Mac OSX 10. This has a ripple effect in that I cannot use some of the Zip tools to compress files on Mac.

Not sure who will be fixing this, since JGCode is on hiatus. But I'm reporting it here for the Googlers of the future.

Done

Sorry about not getting back to you all. The upload issue is fixed. So Ton, feel free to upload your new add-on tool .

Thanks Darin for the response. Ya, figures I'd run into a corner case. All is good now.

Awesome thanks. I think I figured out why Application Instance Close? wasn't working for me.

So the WM_CLOSE message requires a handle to a window name. My executable had a custom window name. I was using this as the window name. So the window was closing fine but the event was not firing and the app remained in memory.

In your example, if you set the VI title name to CloseMe, instead of the default CloseMe.vi, then it won't work. So the message gets sent to the window instead of the app, which is also called CloseMe.exe.

Now I just have to make sure that my window title doesn't match my exe name.

The simple answer is that the 'correct' way to handle this message is indeed with the Application Instance Close? event.  I can pump this message directly to a LV executable and it fires the event every time (so far).

The Application Instance Close? event doesn't work. If you can attach an example that works, that would be nice, but my tests show it not working.

You're correct in catching my bug. Nice to have a second set of eyes  . That was the problem. After I fixed that it worked as expected.

So the updated diagram for anyone else needing this:

How can my LabVIEW EXE application handle the windows WM_Close message correctly?

I have tried the Windows Messaging Queue library without any resolution to this problem.

The behavior I'm seeing is that my application window closes but the app remains running as can be seen by looking at the process list in Windows Task Manager. The images below don't show it but I've added the Quit LabVIEW function to exit the app. So far I've tried:

• Creating a loop that monitors the windows message queue:
  

• Application Instance Closed? Event:
  

• Panel Close? Event:
  

I've read this thread but it didn't seem to address the issue head-on. Or I didn't see what the resolution was.

Any help is appreciated. Thanks.