Making Windows Forms Controls Resize (Fill Up) To Screen Resolution C#

[koeks525]

Hi everyone,

I been enjoying coding up this second year project we were handed in class... We were handed a story line where we are to build a Rental Management System for BayWest Mall in PE. The coding is really fun, I have probably written just over 2500 lines of code on my own We are using C# and Microsoft SQL Server 2014.

I would love to know how one would go and make the controls in one of their windows resize according to the form's size (resolution). I have tried using the Anchor property, which centers everything should the open form be maximized. I have also considered disabling the maximize button and setting the maximum size for a specific window. How would you make your controls resize to the window? Is there a specific layout that I should be using?? I created the Forms using Visual Studio's Form Designer.

Here is a picture of one of the screens (when maximized):



Thanks guys

 

[Hamster]

IIRC, use the Dock property. Dock whatever you want fixed size to the left/right/top/bottom and the parts you want to dynamically resize you "fill".

EDIT: For your example, dock the panel containing the "View Logged Errors" and the "This window displays..." text to the top, the panel containing the buttons to the bottom and fill the gird.

 

[werfie]

Anchor should do it. If you dock, you will fill up the form, I think.

Place your control on the form design so that it fits, then anchor the control you want to resize on all 4 sides I think.

 

[Hamster]

Anchor should do it. If you dock, you will fill up the form, I think.

Place your control on the form design so that it fits, then anchor the control you want to resize on all 4 sides I think.

Think that might have the same effect as dock->fill (anchoring all four corners)

All this is doing is reminding how long it has been since I've done winforms

 

[Fudzy]

Why would you want to do this?

 

[Hamster]

Why would you want to do this?

This is about proving that we are smarter than the OP. Reason and logic has no place here.

 

[werfie]

Think that might have the same effect as dock->fill (anchoring all four corners)

All this is doing is reminding how long it has been since I've done winforms

Well the docking would fill all the available space with the control, anchoring will keep any space between this control and the next (or the window border) the same and resize the control from the centre of the control (if that makes sense).

So docking is useful for filling a form (or section) completely with a control, such as a grid, but the anchoring will keep all sorts of smaller controls relative to their position to the form border or the next control as it was spaced at design time... my definition at least, I sometime struggle to explain myself LOL

 

[Hamster]

Well the docking would fill all the available space with the control, anchoring will keep any space between this control and the next (or the window border) the same and resize the control from the centre of the control (if that makes sense).

So docking is useful for filling a form (or section) completely with a control, such as a grid, but the anchoring will keep all sorts of smaller controls relative to their position to the form border or the next control as it was spaced at design time... my definition at least, I sometime struggle to explain myself LOL

Add margin and padding?

 

[koeks525]

Thanks guys for the tips... yeah it turned out I can do everything I need to do, just with the Anchor property. For my text labels, I had to turn off AutoSize. Ah, now my window is looking so classy

 

[Spacerat]

By the errors, it looks like you have loads of bugs in your code ...:wtf:

Ok yes and stay away from Datasets, DataTables etc. You will regret it if you dont

 

[semaphore]

Thanks guys for the tips... yeah it turned out I can do everything I need to do, just with the Anchor property. For my text labels, I had to turn off AutoSize. Ah, now my window is looking so classy

View attachment 290882

dafuq naming convention is .Memory.getTables, you're mixing java conventions in there.

 

[koeks525]

By the errors, it looks like you have loads of bugs in your code ...:wtf:

Ok yes and stay away from Datasets, DataTables etc. You will regret it if you dont

I am probably going to remove DataSet / DataTable from my project... I have only used it once. In other parts of the application where I needed to store result data, I made use of List<> collections. Just out of interest, why are DataSets / DataTables so bad?

These bugs occurred as I was building and testing parts of my application... I have not finished the application yet... The errors help me see where to look for errors

 

[Spacerat]

I am probably going to remove DataSet / DataTable from my project... I have only used it once. In other parts of the application where I needed to store result data, I made use of List<> collections. Just out of interest, why are DataSets / DataTables so bad?

Yes use IList<> and strongly typed objects. Firstly, the null-handling in DataRows are a pain. Objects will Nullable<> properies work far better with a DB.

Removing and adding DataRows to/from DataTables and Datasets are a royal PITA. WTF was MS thinking. Especially so if you move object between lists etc. Just that alone let me abandon DataTables after my first project.

Your first two errors are examples of exactly these issues. Farking pain.

Anyways, using an ORM (whch you should) makes using objects and lists far easier. You should not be touching DataAdapters or DataReaders in this day and age.

 

[Hamster]

Poor guy is a student

DataTables are useful for bulk updates, but that's about it.

 

[koeks525]

Yes use IList<> and strongly typed objects. Firstly, the null-handling in DataRows are a pain. Objects will Nullable<> properies work far better with a DB.

Removing and adding DataRows to/from DataTables and Datasets are a royal PITA. WTF was MS thinking. Especially so if you move object between lists etc. Just that alone let me abandon DataTables after my first project.

Your first two errors are examples of exactly these issues. Farking pain.

Anyways, using an ORM (whch you should) makes using objects and lists far easier. You should not be touching DataAdapters or DataReaders in this day and age.

I been using SqlDataReader and SqlCommand mostly... I'm probably going to rework my code and get rid of the DataSet in my Memory class. I thought I would really need it but it turns out I don't. What's ORM??

 

[koeks525]

SqlDataReader is really annoying... If you forget to close it in one part of your code, and you need to do a database related operation in another part of your code, the program crashes I should find an alternate to this

 

[Spacerat]

Poor guy is a student

Then this is a great opportunity to learn.

I been using SqlDataReader and SqlCommand mostly... I'm probably going to rework my code and get rid of the DataSet in my Memory class. I thought I would really need it but it turns out I don't. What's ORM??

Object Relational Mapper. Google it. There are several free ones. Entity Framework is just one of them and can be d/l easily. Most commonly used one. You simply dont need to operate at the ADO.NET level anymore, except if you want to learn how it works. But def not for any real system.

SqlDataReader is really annoying... If you forget to close it in one part of your code, and you need to do a database related operation in another part of your code, the program crashes I should find an alternate to this

You should not be forgetting about it. You need to establish a pattern and then code a class for that pattern. Then just re-use the class. Then it can never go forgotten, but at least you can then 'forget' about it because it is taken care of. Doing this also teaches you principle of object orientation and reuse.

 

[Hamster]

Then this is a great opportunity to learn.

I fear anything he picks up here will be forgotten while he tries to finish his project and write his finals

Object Relational Mapper. Google it. There are several free ones. Entity Framework is just one of them and can be d/l easily. Most commonly used one. You simply dont need to operate at the ADO.NET level anymore, except if you want to learn how it works. But def not for any real system.

Entity Framework is actually enough reason to just stick with standard ADO.NET. It is terrible.

If you are going to use an ORM just go with Dapper. It's fast, easy and not intrusive.

...and -1000 internet points for the first one of you f***ers that mention NHibernate

 

[Spacerat]

Entity Framework is actually enough reason to just stick with standard ADO.NET. It is terrible.

yes, personally I don't use it either, but if he can get to know it, i suppose it may be a plus on his CV as many potential employers might be using it.

 

[koeks525]

Thanks a lot guys for the pointers... I definitely will not forget what I have read here Will look at Entity Framework, experiment with it, see how far that goes. Not sure if I should put it in now, or I should rework my entire project to this Framework, after the submission date (09 October). Will remove that DataSet business happening, and replace it with a List<> collection.