Auto Sizing FP Controls and Indicators

[Aristos Queue]

I suspect that you could get rid of the polling behavior by being clever about posting a user event with a timestamp but I'd have to play with it to get it right. Something about a shift register with a timestamp that the resize event updates, then posts a update UI event. As long as the current value of the shift register is before the value of the timestamp when the user event fires then the user event updates the panel sizes, otherwise it does nothing. Or something like that.

I knew it was possible to do without polling. Just took a bit to put it together...

[LAVA 1.0 Content]

I knew it was possible to do without polling. Just took a bit to put it together...

I wouldn't use notifiers for the task. This is a functionality you would like to package as subVI library or class library so that it can be reused in any of your applications or in a single application with multiple different windows. In this usage notifiers are unsafe and may freeze the application without "throwing" an error.

[Yair]

I can't look at Stephen's code, but here's my version (7.1) - simple and easy. If you get a lot of cases, just use the tunnel wiring wizard.

I see no one has responded to my previous post yet.

I will make a proper topic out of it after I've had time to examine the issue.

Download File:post-1431-1165265368.vi

[Val Brown]

You all are awesome! I'll take a look at these ideas and let you know.

Thanks for the info.

[Aristos Queue]

I wouldn't use notifiers for the task. This is a functionality you would like to package as subVI library or class library so that it can be reused in any of your applications or in a single application with multiple different windows. In this usage notifiers are unsafe and may freeze the application without "throwing" an error.

Nonsense. Don't knock a perfectly good feature just because it doesn't serve one use case. In this instance, you can't reasonably package this behavior as a subVI since the event structure is going to have to have other cases specific to whatever events are being processed for this particular dialog. The undertaking of creating a "manager" subVI -- which dynamically registers for panel resize on another VI and then uses VI server to call the "do the resize" functionality -- is overkill compared to just putting the management in whatever dialog you happen to be writing today. I'm not even sure that if you took the effort to create the manager subVI that the API you'd end up with would be less work than just adding the necessary code to each dialog. So, given that there's only going to be one Notifier running through this diagram ever, the case that you link to never arises.

[LAVA 1.0 Content]

In this instance, you can't reasonably package this behavior as a subVI since the event structure is going to have to have other cases specific to whatever events are being processed for this particular dialog.

I disagree and as a proof of concept I wrote an example which simplifies the process of resizing a front panel. EDIT: I personally do not like to pollute front panels with anything extra. It's quite ok as your VIs are simple but when your VIs get more like applications, I think one should stick with extremely simple front panel VIs. In the example the logic for the time delay is removed from the front panel VI to a separate manager VI. More complicated processes can also be given to manager VIs in a similar manner. Using LabVOOP and especially Command Design Pattern one can pass Front Panel specific functionality to be taken care of a general manager function as well.

Download the attached example and open MyFrontPanel.vi. The example is for LV 8.0.

Download File:post-4014-1165329550.zip

[Aristos Queue]

I disagree and as a proof of concept I wrote an example which simplifies the process of resizing a front panel. Download the attached example and open MyFrontPanel.vi. The example is for LV 8.0.

This doesn't fullfil the design requirements. The FPResize Manager Implementation.vi is using a timeout value on the event structure. This turns it into a 200ms polling loop, which is exactly what I was avoiding by writing the Notifier implementation. The goal was a VI that uses zero CPU time when the user isn't actively clicking on stuff.

You did manage to encapsulate the functionality better than I would've expected, but at the cost of using dynamic events, which pushes the technical difficulty of using this API beyond the knowledge of almost all users. The Notifier solution is something that I could explain to people because they've seen Notifiers and they can figure out the Event Structure. Trying to teach dynamic events has proved... difficult. There are good programming reasons why the dynamic events are set up the way they are, and they have extreme power, but they're complex beyond usability most of the time (and, yes, by "complex beyond usability" I do mean the fairly short list of steps of "enable dynamic event terminals, drop a register event node, wire everything, and configure the user event case").

I can't look at Stephen's code, but here's my version (7.1) - simple and easy. If you get a lot of cases, just use the tunnel wiring wizard.

Here it is back in LV7.1. Download File:post-5877-1165336751.vi

[Val Brown]

I hope to post a more in-depth response later tonight as I'm still knee deep (well eye brow deep) in an on-site consultation today; however, this thread is very helpful to me. The current code IS an old style polling process ESM with an idle state and various "operate" states. The problem occurs when this VI is called elsewhere (eg sending a Play command to the embedded WMP ActiveX object). It is at that point that the ActiveX container is resized by the WMP object. This has to do with default parameters of the media object being passed to/operated upon by WMP in the Play (or other) operation. So I have two possible paths, as I see it.

1. Some version of the examples given.

2. Prepare ASX files as the media input to the WMP object and embed in them commands for proper sizing etc. This solution involves making certain that ONLY such ASX objects are used by the WMP and so has other serious limitations.

Again, thanks so much for all of your help. This is ALSO assisting me in understanding Event Structures more thoroughly.

[LAVA 1.0 Content]

This doesn't fullfil the design requirements. The FPResize Manager Implementation.vi is using a timeout value on the event structure.

Fixed, no polling no more, still the same event based architecture.

This turns it into a 200ms polling loop, which is exactly what I was avoiding by writing the Notifier implementation. The goal was a VI that uses zero CPU time when the user isn't actively clicking on stuff.

Interesting, I thought notifiers and event cases internally use polling to "check for mail" but they're based on something else then, most probably CPU interrupts.

You did manage to encapsulate the functionality better than I would've expected, but at the cost of using dynamic events, which pushes the technical difficulty of using this API beyond the knowledge of almost all users.

I can see that events are hard to use if you are not familiar with handling dynamic events. So I fixed my example by adding some documentation into it so that it can function as an example of general manager design. Here it goes, only for LV 8.0 and later as LV 7.1.1 cannot handle multiple event cases very well.

EDIT: There is a bug in this version, the manager function doesn't exit properly if only stop is pressed and panel is not closed. There is no event for VI stopped running so there is no straight forward fix for this bug. The previous version I posted doesn't suffer this bug but it uses polling. The front panel VI must send some sort of message to the manager VI to exit, I just don't know yet which would be most elegant method to do this.

Download File:post-4014-1165339236.zip

[Aristos Queue]

Fixed, no polling no more, still the same event based architecture.

Interesting, I thought notifiers and event cases internally use polling to "check for mail" but they're based on something else then, most probably CPU interrupts.

I can see that events are hard to use if you are not familiar with handling dynamic events. So I fixed my example by adding some documentation into it so that it can function as an example of general manager design. Here it goes, only for LV 8.0 and later as LV 7.1.1 cannot handle multiple event cases very well.

Well done.

[LAVA 1.0 Content]

EDIT: There is a bug in this version, the manager function doesn't exit properly if only stop is pressed and panel is not closed. There is no event for VI stopped running so there is no straight forward fix for this bug. The previous version I posted doesn't suffer this bug but it uses polling. The front panel VI must send some sort of message to the manager VI to exit, I just don't know yet which would be most elegant method to do this.

Ok, I fixed the bug. The implementation now closely resembles OOP design and it can quite easily be transformed to any LabVIEW OOP alternative.

Download File:post-4014-1165357328.zip

[Ton Plomp]

Maybe a totally other idea might be an XControl?

This gets notified an exe start running and you can register for the panel resize event.

And via property nodes you can add all the controls with their resize data.

Ton

So How many ways are their to Rome?

[Val Brown]

Ok, I fixed the bug. The implementation now closely resembles OOP design and it can quite easily be transformed to any LabVIEW OOP alternative.

Download File:post-4014-1165357328.zip

I've tried this implementation but the problem is that the source code is built around the use of Picture Controls -- they have "DrawAreaSize" and ZoomFactor" as available properties. M code is built using an ActiveX container -- because I'm embedding WMP in the VI -- and the ActiveX Container does not have those properties. Or perhaps I need to set up some kind of further invoke/property node or... :headbang:

I'm still evolving from Event State Machines built around polling While loops instead of Event structures and I'm not so familiar with all of the Pane/Panel etc references.

So that means I greatly appreciate the time and effort of those who are posting on this issue.

[LAVA 1.0 Content]

I've tried this implementation but the problem is that the source code is built around the use of Picture Controls -- they have "DrawAreaSize" and ZoomFactor" as available properties. M code is built using an ActiveX container -- because I'm embedding WMP in the VI -- and the ActiveX Container does not have those properties. Or perhaps I need to set up some kind of further invoke/property node or... :headbang:

Ok. I played around for a while. Now I can resize Windows Media Player in a similar manner to the picture control. There is still a small problem, that is the container automatically resizes to the movie size when it loads the movie. I don't now have time to figure out how to avoid this. I hope this helps and you can get forward by yourself.

Download File:post-4014-1165522400.zip

[Chris Davis]

You might want to check out VideoCapX which is an ActiveX control to capture and playback video. I switched to it because you get better control over it than windows media player. Microsoft changes the ActiveX control interface for windows media player with every revision. For VB/VC++ users this is usually ok, because most of the changes are small. LabView takes a stricter approach to ActiveX controls, and can produce unwanted results when ActiveX controls change, even slightly. Anyway, VideoCapX is cheap ($79) for a single seat developer's liscense, and you can try it before you buy it. Just my 2 cents...

BTW, its window size can be resized and scale the video to match the video window size.

[Val Brown]

You might want to check out VideoCapX which is an ActiveX control to capture and playback video. I switched to it because you get better control over it than windows media player. Microsoft changes the ActiveX control interface for windows media player with every revision. For VB/VC++ users this is usually ok, because most of the changes are small. LabView takes a stricter approach to ActiveX controls, and can produce unwanted results when ActiveX controls change, even slightly. Anyway, VideoCapX is cheap ($79) for a single seat developer's liscense, and you can try it before you buy it. Just my 2 cents...

BTW, its window size can be resized and scale the video to match the video window size.

I'm really wanting to use as much of the native capabilities of WMP as possible -- that makes things far easier for my users. This is also important because I'm not just playing back video; I'm really using all of the multimedia capabilities of WMP including visualizations and need to programmatically change control settings "on the fly", with no user input. Going to another media player isn't that appealing because it isn't WMP and that will be "off putting" to some users.

Thanks for the idea though and I will look at it just to see how it might work.

[Chris Davis]

Going to another media player isn't that appealing because it isn't WMP and that will be "off putting" to some users.

Thanks for the idea though and I will look at it just to see how it might work.

I understand the need, although WMP off-puts me! Anyway, it is worth checking out, especially if you have to record video on the computer.

[Val Brown]

I understand the need, although WMP off-puts me! Anyway, it is worth checking out, especially if you have to record video on the computer.

I've downloaded the trial version VideoCapX and it looks very interesting -- and complete. Do you have any sample VIs? esp ones that support audio playback and/or playlists?

[Val Brown]

I'v also noticed that LV8.2 has an icon for the Media Player Object on the .Net/ActiveX pallete and it has the same operational characteristics. It seems like, perhaps, NI didn't really test that function very deeply.

[Chris Davis]

I've downloaded the trial version VideoCapX and it looks very interesting -- and complete. Do you have any sample VIs? esp ones that support audio playback and/or playlists?

Here is an example I loaded in the Machine Vision forum. It does video playback, but you can get some ideas for audio playback. I've never used the audio playback portion of videocapx

[Val Brown]

Thanks fpr the example.