Design vs programatically

I was wondering if there is any advantage to do everything programatically instead of using design view to create forms, controls etc. Would there be any difference in size and/or performance after you compile it?

So far I've been doing pretty much everything programatically, specifying all the properties that aren't default for my forms controls but I am starting to wonder is there are any advantages to this, appart from making it easier (sometime) to manage and change the behaviour of my controls.

Thank you for your time

There's no advantage to writing your own code to do that stuff. It's all done in code anyway. When you add components and set properties in the designer, the appropriate code is added to the InitializeComponent method, which is called from the class constructor.

What are you doing with your Form in case of a change in Size or a change in Resolution?
If you have done all the placements and sizes by code you could adapt your form to the new setting, if everything was done in the design view nothing will happen.

Quote:

---

Originally Posted by opus

What are you doing with your Form in case of a change in Size or a change in Resolution?
If you have done all the placements and sizes by code you could adapt your form to the new setting, if everything was done in the design view nothing will happen.

---

Um, you would use the Anchor and/or Dock properties for that, which you would set in the designer. You would never write your own code to reflow your layout unless it was such a convoluted design that Dock and Anchor couldn't handle it.

Looks like I'm still only trying to get into .Net. Thanks.

Much appreciated, thank you,

I guess, the only advantage left then is for the particular case where I create and remove controls depending on the user's choice. Still it was a really good exercise to know my way around the different controls. Do the same apply to datasource, I mean binding it directly vs access it via code? I know that it is much simpler to get the data where you want it if you bind it to the project but since I don't know .net much yet, I use the old fashion connector with SQL to fetch what I need.

Quote:

---

Originally Posted by jmcilhinney

You would never write your own code to reflow your layout unless it was such a convoluted design that Dock and Anchor couldn't handle it.

---

In which case you should probably consider using WPF instead of WinForms.

Quote:

---

Originally Posted by Jomahtr

Still it was a really good exercise to know my way around the different controls.

---

That's a significant advantage, at least for the first few times.

Quote:

---

Do the same apply to datasource, I mean binding it directly vs access it via code? I know that it is much simpler to get the data where you want it if you bind it to the project but since I don't know .net much yet, I use the old fashion connector with SQL to fetch what I need

---

Frankly, I have yet to use datasources. There's a lot of functionality there, but I do wonder how much faster it really is, since writing it out isn't painful.

Quote:

---

Originally Posted by Jomahtr

Much appreciated, thank you,

I guess, the only advantage left then is for the particular case where I create and remove controls depending on the user's choice. Still it was a really good exercise to know my way around the different controls. Do the same apply to datasource, I mean binding it directly vs access it via code? I know that it is much simpler to get the data where you want it if you bind it to the project but since I don't know .net much yet, I use the old fashion connector with SQL to fetch what I need.

---

If you're going to use a DataSet at all then there's no reason not to use a typed DataSet. I would not recommend dragging items from the Data Sources window directly onto a form but that is not a requirement of using a Data Source. You can create a Data Source in a library project and use it like any other data access layer. Also note that the Data Source wizard can generate an Entity Framework model as an alternative to a typed DataSet. Now that the EF is available, I would always use it in preference to a typed DataSet.

To get back in the programming bath, I just ordered the following books:

- Murach's visual Basic 2010
- O'Reilly Programming entity framework
- Apress Pro ASP.NET in VB 2010
- WROX ADO.NET with VB.NET

for a starter, only 3/4 through the first one, which is why I ask questions here :P

We use Murach's ADO.NET 4 its a pretty good book