Re: GDI+ questions - 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

how to bind the data in datagrid using storedprocedure

7-Mar-06 10:46

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 | ;)

Thanks for all kind helpers!

regards

Jens

eswarattaluri5-Mar-06 21:56

eswarattaluri

5-Mar-06 21:56

hai,

how to bind the data in datagrid using storedprocedure.

thanks.

Re: how to bind the data in datagrid using storedprocedure

rccnh6-Mar-06 8:26

rccnh

6-Mar-06 8:26

Assuming the stored procedure is returning a result set to a DataSet, then just bind to the table returned within the DataSet. Use of a stored procedure versus a SQL Statement to retunr data has no effect on data binding.

Ron

How to show Values in CrystalReportViewer ???

Abubakarsb5-Mar-06 21:39

Abubakarsb

5-Mar-06 21:39

Hello,

I want to show Datagrid values in CrystalReportViewer by using C# can anybody send me sample code to do that? Please....

Regards,

AbuBakar

Re: How to show Values in CrystalReportViewer ???

albCode5-Mar-06 21:46

albCode

5-Mar-06 21:46

are u using WindowsApplication or WebApplication?

Re: How to show Values in CrystalReportViewer ???

Abubakarsb6-Mar-06 0:18

Abubakarsb

6-Mar-06 0:18

I am using Window Application not Web Application....

SQLDataReader Problem

Brendan Vogt5-Mar-06 21:22

Brendan Vogt

5-Mar-06 21:22

Hi all!!

I have a problem with the SQLDataReader. I don't understand it 100%. Please take a look at my code below for returning the titles to a combobox, it works fine just as it is:

public static IDataReader GetTitles()
{
SqlDataReader objDr = null;

// Create instance of connection and command object
SqlConnection objConn = new
SqlConnection(PLATTERGlobals.ConnectionString);
SqlCommand objCmd = new SqlCommand("sp_Title_GetAllTitles", objConn);

// Mark the command as a SPROC
objCmd.CommandType = CommandType.StoredProcedure;

// Add parameters to SPROC
SqlParameter[] objParamArray = new SqlParameter[] {};

// Execute the statement
try
{
objConn.Open();
objDr = objCmd.ExecuteReader();
}
catch (SqlException ex)
{
HandleError(objParamArray, ex, "sp_Title_GetAllTitles");
}
finally
{
if (objConn.State == ConnectionState.Open)
{
//objConn.Close();
}
//objConn.Dispose();
//objCmd.Dispose();
}

// Return the titles
return (objDr);

}

But I can't understand why I had to remove (//) my code in the finally block? I always like to close my connections and to dispose of them as soon as possible. But when I do it here, then it brings back a FieldCount error. Why is this? And when is the connection closed and destroyed? Do I still have to close explicitly?

Please can someone advise.

Regards

Guffa5-Mar-06 21:58

Guffa

5-Mar-06 21:58

The connection has to be open as long as you use the data reader.

You can specify CommandBehavior.CloseConnection when you create the reader to make the reader close the connection when the reader is closed, otherwise you have to close it explicitly.

Personaly I prefer to explicitly close the connection.

---
b { font-weight: normal; }

Brendan Vogt5-Mar-06 22:17

Brendan Vogt

5-Mar-06 22:17

Hey!!

All that I want to do is populate a combo box with titles, like Mr, Mrs, Miss, etc. Is this the best way to go about it? I don't like to have an open connection all the time.

Guffa5-Mar-06 22:27

Guffa

5-Mar-06 22:27

You only have to keep the connection open as long as you read from the data reader.

Open the connection, get the reader, read from it and put the data in the control, close the reader and close the connection.

---
b { font-weight: normal; }