Network text editor - C# Discussion Boards

5-Mar-06 21:58

Hello, My first post here. I have tried to find answers both here and elsewhere but haven't found any. Perhaps I don't know what to look for, or maybe I'm just not looking good enough.

Anyhow, here we go: I am writing an application that presents various data that is updated quite frequently (right now every 200 msecs but that might change). Some data is presented using textboxes, some using graphic controls written by myself using GDI+. The interface also has standard buttons, radiobuttons, groupboxes and tab pages. Here's a couple of questions that's been bathering me...

1. Using SetStyle() I got rid of flicker in my own control(s), but some of the other controls still flicker. For instance the text in the tab pages and groupboxes flicker (but not the borders etc, only the Text-property). Does SetStyle double buffering only work on user defined controls, or have I missed something fundamental here? Most solutions that adresses flicker problems seems to assume you're only working with your own controls. Haven't found anything about the standard controls...

2. When defining my own controls, is there a rule of thumb what to inherit from? When is UserControl preffered and when is the nearest Form-based control better? For instance, one of my controls is a gauge. It has no particular functionality common with the standard controls so I chosed UserControl. How should I reason?

Thanks for any help. I can provide more info but I start with this as I'm not quite sure what I actually want to know...

Jens Olsson
-- modified at 3:59 Monday 6th March, 2006

[Marc]6-Mar-06 3:20

6-Mar-06 3:20

1) Well, SetStyle is a protected method, so you can/should only use it on your own custom controls. But there's a hack:

Public Shared Sub SetStyle(ByVal control As Control, ByVal flag As ControlStyles, ByVal value As Boolean)
    Dim flags As Reflection.BindingFlags = Reflection.BindingFlags.Instance Or Reflection.BindingFlags.NonPublic Or Reflection.BindingFlags.DeclaredOnly
    Dim method As Reflection.MethodInfo = control.GetType().GetMethod("SetStyle", flags)
    Dim params As Object() = {flag, value}
    method.Invoke(control, params)
End Sub

This VB.Net code allows you to set styles on any control you like. It doesn't work on every control though, but you can try it out.

2) I think everyone has their own ideas about this but i do it this way: Design the control as a UserControl, because of the easy designing. After the designing is done i change the base class: If i make a container like a groupbox or a panel, i inherit from panel, else i just inherit from control. In my opinion UserControl has a lot of useless properties and methods.

Just my €0,02 Smile | :)

"..Commit yourself to quality from day one..it's better to do nothing at all than to do something badly.."
-- Mark McCormick

|| Fold With Us! || Pensieve || VG.Net ||

Jens Olsson6-Mar-06 21:11

6-Mar-06 21:11

Thanks for the answer! I'll try that hack for sure, but right now I have solved it by manually keep track of all controls that needs frequent updates and I only Invalidate() those. Until my GUI is filled with such controls this helps. It's a bit overkill to Invalidate() the entire form and all its contents after all.

But I'm still curious why it isn't meant to use double buffering together with standard controls. In the end I might just end up using only my own controls anyway but I'm new to C# and I try to pick up as much info as possible along the way...

I think you're approach to UserControl makes sense. So it is very much a matter of taste isn't it?

Again, thanks for the reply, really appreciated!

kind regards,

Jens Olsson

[Marc]7-Mar-06 2:26

7-Mar-06 2:26

You're welcome!

No wonder everything flickered if you invalidate the entire form every time! Laugh | :laugh:

The way i do it: You can set properties on controls, and call functions and stuff. If a property has changed on a control, i think it's the responsability to invalidate when neccesary. Also the way a control paints should be controlled by the control itself.

Architecture-wise i think is a good design, and the whole standard framework (System.Windows.Forms) does this too. For example, if you change the Text property on a Label, the Label invalidates itself, there's no need for you ti invalidate it a second time. My custom controls do the same: if the control should be repainted, it's the responsability of the control itself to make it paint/invalidate.

Why doesn't every control have double-buffer? Well, a lot of controls in System.Windows.Forms are just .Net wrappers around Windows controls. So the painting gets done by Windows, not by .Net (think about Visual Styles). I heard they changed this in .Net 2, but in 1.0 and 1.1 this is just the way it goes. Smile | :)

- Marc

"..Commit yourself to quality from day one..it's better to do nothing at all than to do something badly.."
-- Mark McCormick

|| Fold With Us! || Pensieve || VG.Net ||

Jens Olsson7-Mar-06 5:22

7-Mar-06 5:22

Well, now I'm on track.

Invalidating the entire form was something I immediately felt was bad but I thought in a naive manner that it would work ok since I did't have that many controls.

Now I have to figure out how to adapt my program to this behaviour. There's plenty of data in an array that I obtain using an IPC call and after that I have to map all values to their respective controls. Right now the class that provides this array implements a delegate that the gui implements. From there I can easily access the array (ie the values read).

Well, that's off topic. If I change a property will it be invalidated no matter what? For instance, if I change the text property of a label, is any work done even if this control is on a tab page that is not visible? I mean, if I change values 4-5 times per sec I wouldn't want controls to be updated if they'r not visible...

[Marc]7-Mar-06 5:40

7-Mar-06 5:40

Uh, i don't know really. But what costs the most CPU is painting on the screen, running painting code that won't show on the screen doesn't really cost that much. Invalidate just tells Windows to update the control if it it shown on the screen i think. Otherwise Windows would really really suck Poke tongue | ;-P

.

But you can test it: attach an event handler to some paint event of a control that is on a tabpage that is not selected, so it is not visible. In the event handler you can write to the debug or something. Then change some property and see if the painting handler is raised.

What i do know: Refresh makes your control repaint instantly, while Invalidate tels Windows to 'repaint it if you have some time' or something like that. Multiple refreshes means multiple repaints, but multiple invalidates not per se. So always use Invalidate!

- Marc

"..Commit yourself to quality from day one..it's better to do nothing at all than to do something badly.."
-- Mark McCormick

|| Fold With Us! || Pensieve || VG.Net ||

Jens Olsson7-Mar-06 10:43

7-Mar-06 10:43

Yep, that's what I'm thinking too, the logic behind Invalidate should save work if it can and it probably does. I often tend to worry too much about things I shouldn't worry about at all... Wink | ;)

Well, I have wondered about the difference between Refresh and Invalidate and thought it would be something like that. Now I know, and that is quite useful to know.

Guess I have no excuses left, so it's just a matter of putting the pieces together now! Smile | :)

Thanks for all kind helpers!

regards

Jens

[Marc]7-Mar-06 10:50

7-Mar-06 10:50

No prob, happy coding! Big Grin | :-D

"..Commit yourself to quality from day one..it's better to do nothing at all than to do something badly.."
-- Mark McCormick

|| Fold With Us! || Pensieve || VG.Net ||

Jens Olsson7-Mar-06 10:46