|
Hi,
I have a form, with 40 controls, that change size while form is resized.
I tried to find solution for flickering, but none of them realy worked.
(like: OnPaintBackground, protected override CreateParams CreateParams, DoubleBuffered = true ...)
Is there any way to prevent this annoying flickering ?
|
|
|
|
|
Your not manually coding the resize of the controls on the form resize event are you?
You should use Anchor property of the controls, maybe with a layout grid of some kind dependign on your needs
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Hi,
Otherwise you can enclose the code that deals with resizing your controls between this.SuspendLayout() and this.ResumeLayout(true) (this is the form).
It will prevent the form from redrawing itself everytime you change a control's property. Instead, it will redraw at the end of the operation, when new values will all be computed. This should remove flickering.
Regards.
|
|
|
|
|
I didn't know that. Thanks for the info
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
You're welcome
modified on Thursday, December 2, 2010 10:52 AM
|
|
|
|
|
this is my answer to "does it really work?" which now is gone...
that depends. AFAIK it stops intermediate layout operations when items get added to a bigger item, such as ListViewItems to a ListView; however I don't expect it to have much influence on flicker reduction while resizing a form, unless their is a strong correlation between size and layout, as in a TableLayoutPanel or some kind of flow-lauyout thing.
|
|
|
|
|
Sorry, I removed the question because I noticed that I was not talking with the one that opened this post a few minutes after posting ^^
I've used this trick a couple of times and it did work well for me. I was wondering if it had done the trick to this particular issue.
|
|
|
|
|
I think in this case you have 40 controls manual resized on the Form resize event - that would be 40 from re-draws per each Form Resize event fired. I was assuming that susspending the layout would reduce this to only 1 re-draw per each Form Resize event fired.
At least I hope this is the case as I may find this useful if I revisit some code from a while back (I solved in other ways but would like to try this method at some point)
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
I was just on my way from work, so I didn't responde earlier.
I was trying to create a matrix of fields, so when you click or hover over a field
some event is raised. I will probably draw the whole matrix on bitmap and use double
buffering and create events based on mouse position.
|
|
|
|
|
if a large number of controls have similar functionality and are laid out in a grid (e.g. a virtual keyboard), then that would be the right approach; it is often referred to as "lightweight controls" and I use it a lot. You can still use a little class to represent each of the light controls, then iterate over them in your overall mouse handlers and OnPaint handler.
|
|
|
|
|
I will go with "lightweight controls". I guess, I was just lazy and was looking for shortcuts.
|
|
|
|
|
You get more flickering when you have more and/or more complex controls on a WinForm. 40 is quite a lot; are some of them list controls (ListBox, DataGridView, TreeView, ...)? are they databound?
There are some precautions you can take:
- make complex controls double-buffered (works often fine for complex controls);
- make the Form double-buffered (hasn't really ever worked for me);
- make sure you don't create a lot of objects while painting controls (assuming some are user-drawn);
- avoid background images;
- avoid transparency;
- avoid slow data accesses (database, network, ...) to fill your controls.
However the main guide line is: keep your forms simple, the user will appreciate it in many ways.
|
|
|
|
|
Luc Pattyn wrote: - make sure you don't create a lot of objects while painting controls (assuming some are user-drawn);
I second that, writing efficient paint events/overrides can be critical.
Oh, and a tip while one the subject... don't forget to dispose local Pens and Brushes (thou a better tip would be to use a global instance of them in the first place )
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
yes, I normally recommend that but lacking an indication of any owner-drawing, I omitted it this time.
|
|
|
|
|
OK, I'm having a hard time trying to understand the reasoning behind classes and I think it is due to a lack of an example that really helps me relate to why a class would be helpful in my code. I typically develop using data from a database. One of the lessons I read for creating a class uses a used car lot as an example. A used car lot has lots of cars with different makes, models, years, color, so you would create a "car" class with each of those properties and you can do things like: car.model = "honda", or car.color = "red". If I were to write an app for this, I would have a "car" table in the database with make, model, etc. fields. Then I would use SQL to insert, update, or query the data directly. Why would you create an instance of a class and assign data to all the properties of the class, if the data is not actually being stored. Maybe this example is just to show how a class works and not really practical? Can someone please provide a better explanation or example?
|
|
|
|
|
Few advantages of Classes :
1. Reusable.
2. Having a comparison with real world.
3. Ease of easy understanding of complex tasks.
For practical example you can see Recently posted funny class in a Lounge SEE HERE[^].
Regards,
Hiren.
"The more we give of anything, the more we shall get back." - Grace Speare
(you can consider this quote while giving vote also)
Microsoft Dynamics CRM
|
|
|
|
|
It may take a while to get used to classes and object orientation. This[^] might help. I would also suggest you buy and study an introductory book on the language of your choice; C# books tend to explain OO concepts to a reasonable degree.
|
|
|
|
|
Classes are basically a collection of functions and properties..
A class can be used to run a number of actions such as DisplayData or UpdateDatabase, but in some cases they can be used to represent an object such as a car in your example.
Although the class does not save the data to disk, it does allow for easy management of a lot of data related to a car. And makes things like passing data to other functions much easier to manage.
Its all just part of good design
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
OK, I think it might be becoming clearer. So I could mock my datatable fields into a class, then hide all of my SQL functions of updating, inserting, etc. in the class. Basically, my code for my form could look like:
<br />
dtclass dt = new dtclass(value1, value2);<br />
dt.update;<br />
|
|
|
|
|
yep, pretty much. thou if your working with SQL then I suggest you take a look at Linq[^].
Visual Studio has a great tool for creating the classes for you Linq to SQL[^]
Just to exemplify Linq.. you can end up with code as simple as this...
MyDatabase DB = new MyDatabase();
Car car = new Car();
car.Make = "Ford";
DB.Cars.InsertOnSubmit(car);
DB.SubmitChanges();
updating a record like so...
MyDatabase DB = new MyDatabase();
Car car = Db.Cars.Single(c => c.ID == 1);
car.Make = "Citreon";
DB.SubmitChanges();
BTW, Linq is not just for SQL it can work on many collections of data. Very powerful tool
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
Yes, yes you can. But does it make sense to do so in your particular application?
In my opinion (and it may be rather unpopular with the Linq-fanboys), you should only do that if you have the data hanging around for a while and interacting with other classes. In most of the applications I write, that doesn't happen. Maybe I read a line from a CSV file, parse it directly into SqlParameters and do an Insert, or query some data via a DataReader and write it out (CSV, XML, etc.) -- there is absolutely no need to store the data in a class, it would just needlessly bog things down.
But, there are times where having data in classes is useful. For instance maybe your car has an owner -- you can have separate classes for the car and its owner, with a relationship between them*. Now, I don't think Linq can do that (I could very easily be wrong about that), at most it would have separate classes for car and owner, but no relationship. In a DataSet (which I also don't use) the DataTables might have a relationship, but as far as I know, Linq won't.
I would also use a class if I'm passing data across a Web Service -- and I don't know whether or not Linq can do that.
So, when I use classes to hold data, I don't use Linq or EF or any other ORM tool -- I craft them myself.
*
class Person { ... }
class Car { ... Person Owner ... }
Person me = new Person(...) ;
Car mycar = new Car(...) ;
mycar.Owner = me ;
|
|
|
|
|
There are literally THOUSANDS of descriptions of what classes are, and how they work, and ALL of them are available on the internet. If you don't understand it after reading only a handful of these descriptions, how are we going to be able to describe it plainly enough for you to grasp the concept?
Classes allow you to design objects, which have properties and/or methods with which to manipulate its properties. You can then use the object as a parameter to a method instead of the individual properties. You can extend an object by implementing a new class that inherits from the original, adding more properties and methods. Just because you create an object in memory doesn't necessarily require you to save it anywhere - you can use it and then release it.
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Thanks for the support. Its not that I don't understand how I can create a class that inherits properties or methods from another one or I can organize objects and their properties by creating a class for them. I am just having a hard time grasping why I would want to use them. When I think of organizing a list of people that have first names, last names, phone numbers, I think of a database table. I can store all the data in a table and query it to display what I need in a datagridview or whatever. I was hoping someone could explain or point me to a more meaningful example of why to use a class. Just reading generic descriptions of what a class does, does not help me understand how I would incorporate it in real-life coding. Maybe I am thinking to hard about it.
|
|
|
|
|
I don't think you're thinking too hard about it, I think you just haven't written applications complicated enough yet to need OO. You don't need to be asking why you want classes, you need to be asking if you should switch from structured programming to OO programming. The answer is not necessarily. It's perfectly fine to write good old-fashioned structured programs, and you do not need to write OO to use C# - you can write perfectly good C# programs with no OO code in it. However keep in mind that the .NET framework gives you a lot of free stuff, and it's all OO, so if you want to exploit it you'll have to understand how to use it. As you design more complicated applications, you may come to realize benefits of OO and some of the stuff that you get in .NET. (A DataGridView is a class, after all, so you have already "incorporated" that into your code. Do you find the DataGridView easy to use? If so, you might learn something from that model.)
|
|
|
|
|
kruegs35 wrote: When I think of organizing a list of people that have first names, last names, phone numbers, I think of a database table. I can store all the data in a table and query it to display what I need in a datagridview or whatever.
Of course - and that is fine! The DataGridView (a class itself) will hold the data for you in memory. However, to be able to reuse that data it can be far easier to have a proper representation of the data by using classes.
public enum PhoneNumberType
{
Home,
Mobile,
Work
}
public class PhoneNumber
{
private string number;
private PhoneNumberType type;
public PhoneNumber(string number, PhoneNumberType type)
{
this.number = number;
this.type = type;
}
public string Number
{
get{ return number; }
}
public PhoneNumberType Type
{
get{ return type; }
}
}
public class Person
{
private string forename;
private string surname;
private List<PhoneNumber> numbers;
public Person(string forename, string surname, IEnumerable<PhoneNumber> numbers)
{
this.forename = forename;
this.surname = surname;
if(numbers != null)
this.numbers = new List<PhoneNumber>(numbers);
else
this.numbers = new List<PhoneNumber>();
}
public string Forename
{
get{ return forename; }
}
public string Surname
{
get{ return surname; }
}
public List<PhoneNumber> Numbers
{
get{ return numbers; }
}
}
public class People : List<Person>
{
}
Now by using this structure in memory it's easy to access any part of any person in your one collection - People - without having to requery or try and extract from the DataGridView. Any of these classes can have Load, Save, Update, Delete etc methods which can access your database, or better still an interface that represents a database so you can have different implementations of the interface for dfferent database types if ever required... but you should get to grips with the reasoning for classes before exploring interfaces!
BTW, the above code was just typed here and not copied from VS so is untested and may contain errors!
|
|
|
|
|