franzdeco said:

may I rely on a compatibility of your WinForms controls with Mono platform on Mac OS in a near future?

That's not an environment we actively support, so I could not make any guarantees there. But we do work hard to make sure that all of the controls are backward compatible. So if it works right now, it's unlikely to change significantly in the future.

Thanks again Mike for your really complete reply.

1. Hard drive space is not a problem, of course. My concerns where on memory and performance side, because UltraWinGauge is a far more complex control than ProgressBar, and putting several bars on a single UltraWinGauge is not an option for me, as volume level is going to be just a single element inside each single "Microphone User Control" containing more controls for settings etc.

2. In the meantime I have built a first implementation using ProgressBar and DrawFilter (good exercise for me, btw!), and a second one using UltraWinGauge; both of them look pretty good, I will make my choice after some load tests. It seems to me that I cannot use a background image for UltraWinGauge bar, and/or cannot setup it's appearance on a multilinear gradient the way I need, but that will be a dedicated post, following.

3. Just one more information from your kindness and competence: may I rely on a compatibility of your WinForms controls with Mono platform on Mac OS in a near future? I have read about ASP.NET controls, but no real information about WinForm. Any piece of news would be very appreciated.

Thanks again, maximum score for your reply (still don't know how to give it, but I'll discover it!).

bye

Hi,

It depends what you mean by 'lighter".

Using the UltraWinGauge will mean installing some additional assemblies, so that will use up a little hard drive space.

As far as memory is concerned, I'm honestly not sure, but my guess is that the Gauge is probably a little heavier. But you can show all ten of your audio outputs in one UltraWinGauge controls, whereas you will need 10 UltraProgessBars.

In terms of performance, I doubt you will have any issues with either of these controls.

In terms of the amount of coding, I'm not sure. To be honest, I'm not all that familiar with the gauge. It's handled by a different team of developers. I do know that there's a Response property on the gauge marker (i.e. the linear gauge bar marker), which can be used for dampening the movement.  So that might give you what you want right there.

Response.RefreshRate and Response.ResponseTime can be tweaked to slow the movement of the gauge.  These can even be manipulated from the ValueChanged event to handle special cases like freezing the value only when it has peaked.

Also, multiple bar markers on a linear gauge can be used side-by-side or overlaid one on top of the other, to represent peak and current values at the same time.

On the other hand, for the UltraProgressBar, you would have to write a DrawFilter, which is not so bad in the this case. I imagine you will just want a line or something pretty simple at the peak value. So that's pretty simple to draw, but determining the location at which to draw the line could be pretty tricky.

Either way, you will need a timer so you know when to establish a new peak value - assuming that your display will be like others I have seen where the peak is only maintained for a few seconds.

Thank you Mike for your quick reply,

I was on ProgressBar instead of Gauge (even if the latter is for sure a more powerful choice) because it seemed to me a 'lighter' control: in my application I might have, only for output levels, some tens microphone controls receiving a signal update rate of 30 frames/sec.

Anyway, using Gauge too, there is some logic to implement, to mantain peak indicator for a couple of seconds and then resetting it to current value (or make it disappear as long as current value keeps decreasing).

Do you suggest to use anyway UltraGauge, without fearing any performance issues?

Thank you in advance.