Hi,
I am new to this newsgroup and need help in the following questions.
1. I am workin' on a GUI application. Does C# provides Layout Managers the
way Java does to design GUI? I know that it can be done using the designer
but I intentionally don't want to use that. The one reason is that you
cannot change the code generated by the designer. The other could be that
you have more free hand and control to design your GUI.
2. Any helpful link which talks about the GUI design patterns?
Thanks & Regards!
-Anoop
14  4671 
The code it generates most certainly CAN be changed, its just a text
file after all (and not locked down by the designer in any way).
You're not gaining anything by avoiding it, as it can do everything you
can do (the fact that it generates code is proof of this; there's no
reason you couldn't type in the code it generates). Both your reasons
for not using it don't have any facts to back them up.
Use the designer; it is a huge productivity boost.
When you say "GUI design patterns" are you refering to how the GUI
looks or how to design UI elements?
Anoop wrote:
Hi,
I am new to this newsgroup and need help in the following questions.
1. I am workin' on a GUI application. Does C# provides Layout Managers the
way Java does to design GUI? I know that it can be done using the designer
but I intentionally don't want to use that. The one reason is that you
cannot change the code generated by the designer. The other could be that
you have more free hand and control to design your GUI.
2. Any helpful link which talks about the GUI design patterns?
Thanks & Regards!
-Anoop
Oh, and your question about layout designers; if you're refering to
flow layout and table layout, .net 2.0 does have these. They are
container controls which you may use or not use.
Anoop wrote:
Hi,
I am new to this newsgroup and need help in the following questions.
1. I am workin' on a GUI application. Does C# provides Layout Managers the
way Java does to design GUI? I know that it can be done using the designer
but I intentionally don't want to use that. The one reason is that you
cannot change the code generated by the designer. The other could be that
you have more free hand and control to design your GUI.
2. Any helpful link which talks about the GUI design patterns?
Thanks & Regards!
-Anoop
Thanks Andy. You are right that .Net editor allows you to modify the code
but if you do so, and try to open the Form, it throws an error asking you to
revert the change (It might be a special case but I got an error 2-3 times).
The .net generated coded is in placed into one method
"InitializeComponent()". The code has location parameters and other things,
hardcoded (e.g. (100,120)). Layout Manager hides these details. Also, I am
creating wrappers arround the .Net controls so I don't want to use the
designer.
By GUI design Patterns, I mean, is the front end design e.g. Event handing,
Exception handling, Form design, logging etc on the frnt end.
Regards!
-Anoop
"Andy" <aj*****@alum.rit.eduwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...
The code it generates most certainly CAN be changed, its just a text
file after all (and not locked down by the designer in any way).
You're not gaining anything by avoiding it, as it can do everything you
can do (the fact that it generates code is proof of this; there's no
reason you couldn't type in the code it generates). Both your reasons
for not using it don't have any facts to back them up.
Use the designer; it is a huge productivity boost.
When you say "GUI design patterns" are you refering to how the GUI
looks or how to design UI elements?
Anoop wrote:
Hi,
I am new to this newsgroup and need help in the following questions.
1. I am workin' on a GUI application. Does C# provides Layout Managers
the
way Java does to design GUI? I know that it can be done using the
designer
but I intentionally don't want to use that. The one reason is that
you
cannot change the code generated by the designer. The other could be
that
you have more free hand and control to design your GUI.
2. Any helpful link which talks about the GUI design patterns?
Thanks & Regards!
-Anoop
Anoop,
After the change, you'll need to rebuild the solution. Also, close and
reopen the form. That should clear up any issues. What version of the
IDE are you using? 2003 is a bit more flakey in this regard (but its
certainly possible, just more annoying). 2005 handles this very well.
Again, if you're in .Net 2.0 (with VS2005) the container controls I
mention should provide what you want. Even if values are hardcoded,
FlowLayoutPanel should provide the functionality your looking for
(there's also TableLayoutPanel as well).
You are creating wrappers around .Net controls? Why? You can still
use the designer, as long as your wrapper (subclass?) inherits Control.
It sounds like you're setting yourself up to do alot more work than you
need to, for some fear of .net which I don't understand.
As far as design patterns go, you should be able to google for a lot of
them. Search for Windows XP design guidelines. Re: exception
handling, I imagine you'd follow the same patterns you would in Java.
Re: logging, you can use the Logging Application Block or log4net,
which is spiritually compatible with log4j.
Andy
Anoop wrote:
Thanks Andy. You are right that .Net editor allows you to modify the code
but if you do so, and try to open the Form, it throws an error asking you to
revert the change (It might be a special case but I got an error 2-3 times).
The .net generated coded is in placed into one method
"InitializeComponent()". The code has location parameters and other things,
hardcoded (e.g. (100,120)). Layout Manager hides these details. Also, I am
creating wrappers arround the .Net controls so I don't want to use the
designer.
By GUI design Patterns, I mean, is the front end design e.g. Event handing,
Exception handling, Form design, logging etc on the frnt end.
Andy <aj*****@alum.rit.eduwrote:
The code it generates most certainly CAN be changed, its just a text
file after all (and not locked down by the designer in any way).
Except that if you mess with it you may well not be able to use the
designer with it any more - that's why there are big comments saying
that effectively the designer "owns" those sections of code.
You're not gaining anything by avoiding it, as it can do everything you
can do (the fact that it generates code is proof of this; there's no
reason you couldn't type in the code it generates).
You've just proved the reverse of what you tried to prove - there's
nothing that the designer can do that can't be done manually. There are
plenty of things which can be done manually which can't be done in the
designer.
Both your reasons
for not using it don't have any facts to back them up.
Use the designer; it is a huge productivity boost.
And a killer for maintenance, unless you're *very* diligent about
naming things. Personally, I don't like having variables called things
like "label1" - but it takes longer to rename them in the designer than
it does to type code in in the first place. (In fact, the designer
often uses member variables for things which don't need to be members
at all, labels being a prime example.)
In addition, the designer doesn't have any idea of a readable code
layout. It puts the whole UI construction in one big method. When I
write GUIs, I treat that code like any other code, refactoring it and
breaking it up appropriately so that it can be easily read.
Furthermore, when you're writing actual *code* to create the UI, it's
easy to do things like keeping a running total of the horizontal or
vertical position, so that adding an extra component in the middle is
just a matter of slotting it into the right section of code, and
watching all the other components move down appropriately.
The designer's okay for prototyping, but for production code I'd rather
put a bit more time in at construction time to save maintenance time
later on. See http://msmvps.com/blogs/jon.skeet/ar.../27/73014.aspx for
more on my view - and that of Charles Petzold (there's a link to a
great article of his).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Except that if you mess with it you may well not be able to use the
designer with it any more - that's why there are big comments saying
that effectively the designer "owns" those sections of code.
It depends on what you do in there. If you're implementing major
functionality that doesn't really have to do with control layout,
you're asking for trouble. But changing the FillMode in the text file
won't hurt anything (assuming the change compiles correctly).
You've just proved the reverse of what you tried to prove - there's
nothing that the designer can do that can't be done manually. There are
plenty of things which can be done manually which can't be done in the
designer.
No, I haven't. Its true that everything that can be done by the design
can be done manually. As well all know though, manually processes are
slower than automated ones. As far as building your UI goes, what
exactly can't you do in the designer? I've yet to find anything.
And a killer for maintenance, unless you're *very* diligent about
naming things. Personally, I don't like having variables called things
like "label1" - but it takes longer to rename them in the designer than
it does to type code in in the first place. (In fact, the designer
often uses member variables for things which don't need to be members
at all, labels being a prime example.)
I've never had any maintence problems using the designer. Do you
REALLY care what some label is named if its always just static text?
No. Oh, and if you rename it in code, pressing Ctrl+F10 will give you
an option to rename it everywhere in code. Nothing you said in that
paragraph is true. As far as labels being member vars, tell the
designer not to generate the member (Generate Member = false), so that
it uses just an instance variable to setup the label, but you don't
have access to it from outside the InitializeComponent method.
In addition, the designer doesn't have any idea of a readable code
layout. It puts the whole UI construction in one big method. When I
write GUIs, I treat that code like any other code, refactoring it and
breaking it up appropriately so that it can be easily read.
Its pretty rare that I've found anyone that thinks they need to
'refactor' the Ui construction. Who cares what that code looks like?
Since partial classes came about, I find I really never need to even
look at what the designer generates; I use the designer to build the
UI, and thus never have to deal with it directly. You're making code
which is mostly throw away (and you will likely throw it away when you
want to target Vista). UI code is the most replaced code (compared to
business logic); since I started in computers we went from text to
Win3.1x GUI, Win9x GUI, and now we're giong to be doing things
different again in Vista. During that time, its entirely likely the
business rules haven't changed nearly as much as the UI technology.
Furthermore, when you're writing actual *code* to create the UI, it's
easy to do things like keeping a running total of the horizontal or
vertical position, so that adding an extra component in the middle is
just a matter of slotting it into the right section of code, and
watching all the other components move down appropriately.
Its just as fast for me to select all the controls and slid them down
out of the way, and create the new text box. One second vs. two
seconds, big deal.
The designer's okay for prototyping, but for production code I'd rather
put a bit more time in at construction time to save maintenance time
later on. See
http://msmvps.com/blogs/jon.skeet/ar.../27/73014.aspx for
more on my view - and that of Charles Petzold (there's a link to a
great article of his).
Guess what though; all that effort you put into building the prototype
in the designer is wasted. You throw all the code it generates away,
and write it by hand TO GET THE EXACT SAME RESULT. You're putting a
lot of effort into making THE most disposible code in the application
maintainable.
Everyone is certainly entitled to their opinion but my opinion is to
spend the effort to keeping your business layer maintainable, as THAT
code is going to live a lot longer than your UI code, which will be
tossed in a few years anyway.
Andy
One more thing; lets not forget the mid 90s when everyone tossed their
desktop apps and wanted to replace them with Web apps..
Andy wrote:
You've just proved the reverse of what you tried to prove - there's
nothing that the designer can do that can't be done manually. There are
plenty of things which can be done manually which can't be done in the
designer.
No, I haven't.
Let's look at what you wrote, shall we?
<quote>
You're not gaining anything by avoiding it, as it can do everything you
can do (the fact that it generates code is proof of this; there's no
reason you couldn't type in the code it generates).
</quote>
How is the fact that it generates code proof that it can do everything
I can do? Surely it's proof that I can do everything it can do, because
I can generate any code that it can generate. Your logic is completely
flawed.
Its true that everything that can be done by the design can be done manually.
Well I'm glad we agree on that.
As well all know though, manually processes are
slower than automated ones. As far as building your UI goes, what
exactly can't you do in the designer? I've yet to find anything.
Suppose you want to have an array of controls, so you can really easily
access them by index. This is something which is often requested in
newsgroups. How do you tell the designer that you want:
TextBox[] inputs;
instead of
TextBox input1;
TextBox input2;
TextBox input3;
etc?
How about automatically generating pieces of the UI based on a
configuration file?
How about creating a number of controls with contents that depends on
the number
of the control ("Address line 1:", "Address line 2:" etc)?
And a killer for maintenance, unless you're *very* diligent about
naming things. Personally, I don't like having variables called things
like "label1" - but it takes longer to rename them in the designer than
it does to type code in in the first place. (In fact, the designer
often uses member variables for things which don't need to be members
at all, labels being a prime example.)
I've never had any maintence problems using the designer. Do you
REALLY care what some label is named if its always just static text?
No. Oh, and if you rename it in code, pressing Ctrl+F10 will give you
an option to rename it everywhere in code. Nothing you said in that
paragraph is true.
And does renaming it in code *definitely* not screw up the designer?
Ever?
Oh, and it doesn't work in VS.NET 2003.
As far as labels being member vars, tell the
designer not to generate the member (Generate Member = false), so that
it uses just an instance variable to setup the label, but you don't
have access to it from outside the InitializeComponent method.
So you've got to do more work to tell the designer not to do something.
In addition, the designer doesn't have any idea of a readable code
layout. It puts the whole UI construction in one big method. When I
write GUIs, I treat that code like any other code, refactoring it and
breaking it up appropriately so that it can be easily read.
Its pretty rare that I've found anyone that thinks they need to
'refactor' the Ui construction. Who cares what that code looks like?
I care what *all* my code looks like. I want to be able to understand
how UIs are constructed without looking at the designer (which makes
things
like tab pages hard to analyse).
Since partial classes came about, I find I really never need to even
look at what the designer generates; I use the designer to build the
UI, and thus never have to deal with it directly. You're making code
which is mostly throw away (and you will likely throw it away when you
want to target Vista).
I don't view UI code as automatically "throw away" code - maybe that's
why I care
about its elegance.
UI code is the most replaced code (compared to
business logic); since I started in computers we went from text to
Win3.1x GUI, Win9x GUI, and now we're giong to be doing things
different again in Vista. During that time, its entirely likely the
business rules haven't changed nearly as much as the UI technology.
Perhaps if the code were easier to refactor, you'd find weren't
throwing it away
and starting again... and if you *did* need to start again, you'd be
able to understand
what you were replacing more easily.
Furthermore, when you're writing actual *code* to create the UI, it's
easy to do things like keeping a running total of the horizontal or
vertical position, so that adding an extra component in the middle is
just a matter of slotting it into the right section of code, and
watching all the other components move down appropriately.
Its just as fast for me to select all the controls and slid them down
out of the way, and create the new text box. One second vs. two
seconds, big deal.
Except you've got to work out exactly how far to slide them down, make
sure it stays consistent, fight against the grid-rules which often
don't *quite* get it right, etc.
If you've never found it a pain in the neck, that's good for you - but
it's not the
same for everyone.
The designer's okay for prototyping, but for production code I'd rather
put a bit more time in at construction time to save maintenance time
later on. See
http://msmvps.com/blogs/jon.skeet/ar.../27/73014.aspx for
more on my view - and that of Charles Petzold (there's a link to a
great article of his).
Guess what though; all that effort you put into building the prototype
in the designer is wasted. You throw all the code it generates away,
and write it by hand TO GET THE EXACT SAME RESULT. You're putting a
lot of effort into making THE most disposible code in the application
maintainable.
I don't view it as that much effort, and I'm a strong believer in
maintainable code.
Everyone is certainly entitled to their opinion but my opinion is to
spend the effort to keeping your business layer maintainable, as THAT
code is going to live a lot longer than your UI code, which will be
tossed in a few years anyway.
It's amazing how much maintenance time can be wasted in a few years
though,
compared with a much shorter time when coding to start with.
Jon
How is the fact that it generates code proof that it can do everything
I can do? Surely it's proof that I can do everything it can do, because
I can generate any code that it can generate. Your logic is completely
flawed.
What I meant was that all the code you would type in to do layout, the
generater can also create. There are no properties on the controls you
CANNOT set on the designer. Sorry if I wasn't clear (but the OP
thought I was I guess).
Suppose you want to have an array of controls, so you can really easily
access them by index. This is something which is often requested in
newsgroups. How do you tell the designer that you want:
Its rather silly to have an array of controls. I have NEVER found a
need where the only way to acomplish what I want is to put controls in
an array.
How about automatically generating pieces of the UI based on a
configuration file?
The designer is a code generator itself, yet you decry its use. Use
the designer to generate your form, than modify it to be a template
which your code generate can use. I'm betting that's a lot quicker
than typing it all by hand...
How about creating a number of controls with contents that depends on
the number
of the control ("Address line 1:", "Address line 2:" etc)?
AddressLine1 and AddressLine2 would very likely be databound to an
object which has those properties. Changing the behavior of a control
based on the number tacked on to the end of it hurts maintainablity; I
know, I've done this in the past, and it always ends up being a bigger
pain in the ass.
And does renaming it in code *definitely* not screw up the designer?
Ever?
At most, I've had to close the designer window, recompile and reopen it
to fix it. That's when I change the code outside of the designer.
Within the designer, I've never had it mess up the designer.
Oh, and it doesn't work in VS.NET 2003.
In 2003 you'll have to do a search and replace (which is all Vs2005 is
doing anyway, just automatically). Unfortunatly the OP never said
which version of .Net he was working in, but I made it fairly clear
that my suggestions revolved around .Net 2.0, since the two controls I
mention don't exist in .Net 1.x either.
So you've got to do more work to tell the designer not to do something.
Yes, 3 seconds to highlight all the controls I don't want members for,
open the property window and double click the property Generate member
so that it switches the value to false is a HUGE productivity drop.
I care what *all* my code looks like. I want to be able to understand
how UIs are constructed without looking at the designer (which makes
things
like tab pages hard to analyse).
If you're not looking at the designer, you have to run the app to see
what the results are. Not very productive I would think. I'm not sure
why you care about the most disposable code in the entire application..
but you're entitled to worry about it if you want.
I don't view UI code as automatically "throw away" code - maybe that's
why I care
about its elegance.
Except that it is. DOS UI code had to be thrown away to move to
Windows. A lot of Windows UI code was thrown away when the Web became
big. Yet more Windows UI code will be thrown away when people move
their applications to Vista. Or to Web Services.
Perhaps if the code were easier to refactor, you'd find weren't
throwing it away
and starting again... and if you *did* need to start again, you'd be
able to understand
what you were replacing more easily.
How does refactoring help you move the UI from a Windows based
application to a Web based one? It doesn't, because you're moving from
a stateful platform to a stateless one, from a platform which rich
controls to one with very simple controls.
Except you've got to work out exactly how far to slide them down, make
sure it stays consistent, fight against the grid-rules which often
don't *quite* get it right, etc.
I'm pretty sure you can turn off the grid rules. Also, in VS2005 the
designer helps you align controls to each other, regardless of the grid
rules. Place your one control manually, and you get nice little lines
helping you to align the controls quickly and easily. Yes, its not
that nice in VS2003, but that doesn't mean that its slower than hand
coding everything either. All it means is that the code generator is
now more helpful than ever before.
If you've never found it a pain in the neck, that's good for you - but
it's not the
same for everyone.
It seems mostly to be a pain in the neck for those that decide they
don't like the designer from the get go, and get frustrated and easily
give up on using it when they can't figure it out in a few seconds.
I don't view it as that much effort, and I'm a strong believer in
maintainable code.
I believe in mantainable code also, but I also believe in putting more
effort into maintaining code that will be around longer than code which
I know will not. The fact that UI technology changes so rapidly,
coupled with the fact that we DO have a very good code generator (the
designer) reduces the benefits of writing very maintainable code. The
cost of handwriting is the same as it always was, but the benefit of
handwriting is much much less than it used to be.
It's amazing how much maintenance time can be wasted in a few years
though,
compared with a much shorter time when coding to start with.
Changes to the UI are very very simple because of the designer. The
problem is you see the later maintenance as a manual process later,
when in reality, you're doing the maintenance with the same time saving
code generator you used in the beginning.
Need to rework a screen? Open the designer, spend a few minutes
re-arranging controls or what have you, and you're done.
Half the reason we have a need for a proper business layer is preciesly
because UIs have become so disposable (the other half being that
changes to our data model would break the application). If the UIs
weren't changing so much, we could just have all the business rules
right in the UI. However that's not the case; UIs DO change a lot, so
the effort in building them by hand has too much of a cost to justify
it.
Andy
Andy wrote:
How is the fact that it generates code proof that it can do everything
I can do? Surely it's proof that I can do everything it can do, because
I can generate any code that it can generate. Your logic is completely
flawed.
What I meant was that all the code you would type in to do layout, the
generater can also create. There are no properties on the controls you
CANNOT set on the designer. Sorry if I wasn't clear (but the OP
thought I was I guess).
But that's simply not true. The designer can't express *logic* while
building up the UI. It can specify any individual property on any
individual control, so long as you know the value at design time.
Fortunately, code allows us to be much more flexible than that.
Even if it were true, your logic would still have been the wrong way
round. You proved the reverse of what you intended to prove - you
couldn't possibly prove what you wanted to prove, as it's incorrect.
Suppose you want to have an array of controls, so you can really easily
access them by index. This is something which is often requested in
newsgroups. How do you tell the designer that you want:
Its rather silly to have an array of controls. I have NEVER found a
need where the only way to acomplish what I want is to put controls in
an array.
Wow, way to be dismissive of a situation that many people (myself
included) have found themselves in several times.
Has it occurred to you that possibly there are situations beyond those
you've encountered which aren't silly?
Whether you view it as silly or not, it's a counterexample to your
claim that the designer can do anything you can do by hand.
How about automatically generating pieces of the UI based on a
configuration file?
The designer is a code generator itself, yet you decry its use. Use
the designer to generate your form, than modify it to be a template
which your code generate can use. I'm betting that's a lot quicker
than typing it all by hand...
I wasn't suggesting writing a code generator. I was suggesting reading
a configuration file and creating controls on the fly at runtime based
on that data. That's a very powerful way of doing things.
How about creating a number of controls with contents that depends on
the number
of the control ("Address line 1:", "Address line 2:" etc)?
AddressLine1 and AddressLine2 would very likely be databound to an
object which has those properties. Changing the behavior of a control
based on the number tacked on to the end of it hurts maintainablity; I
know, I've done this in the past, and it always ends up being a bigger
pain in the ass.
I thought you didn't care about maintainability - after all, you're
always throwing away your code, aren't you?
Anyway, yes, it's often not the right thing to do - but sometimes it
is. When it is, you're screwed in the designer.
And does renaming it in code *definitely* not screw up the designer?
Ever?
At most, I've had to close the designer window, recompile and reopen it
to fix it. That's when I change the code outside of the designer.
Within the designer, I've never had it mess up the designer.
I've seen plenty of cases where changes to designer-generated code have
made the designer fail to open from then onwards.
Oh, and it doesn't work in VS.NET 2003.
In 2003 you'll have to do a search and replace (which is all Vs2005 is
doing anyway, just automatically). Unfortunatly the OP never said
which version of .Net he was working in, but I made it fairly clear
that my suggestions revolved around .Net 2.0, since the two controls I
mention don't exist in .Net 1.x either.
Nothing in your original post is 2005-specific.
So you've got to do more work to tell the designer not to do something.
Yes, 3 seconds to highlight all the controls I don't want members for,
open the property window and double click the property Generate member
so that it switches the value to false is a HUGE productivity drop.
I suspect you don't actually *do* it though - if you do, you're in the
minority, given the bulk of the designer code I've seen. The designer
encourages sloppiness in terms of naming, structure and membership of
the class.
I care what *all* my code looks like. I want to be able to understand
how UIs are constructed without looking at the designer (which makes
things
like tab pages hard to analyse).
If you're not looking at the designer, you have to run the app to see
what the results are. Not very productive I would think.
No, because if the code is nicely written, I can work out what the
results will
be without running the app at all.
I'm not sure
why you care about the most disposable code in the entire application..
but you're entitled to worry about it if you want.
Why thank you.
I don't view UI code as automatically "throw away" code - maybe that's
why I care about its elegance.
Except that it is. DOS UI code had to be thrown away to move to
Windows. A lot of Windows UI code was thrown away when the Web became
big. Yet more Windows UI code will be thrown away when people move
their applications to Vista. Or to Web Services.
Not everyone automatically goes with every passing fad. You'll find
plenty of applications around (particularly internal ones) which
haven't had their UIs changed for years.
Perhaps if the code were easier to refactor, you'd find weren't
throwing it away
and starting again... and if you *did* need to start again, you'd be
able to understand
what you were replacing more easily.
How does refactoring help you move the UI from a Windows based
application to a Web based one? It doesn't, because you're moving from
a stateful platform to a stateless one, from a platform which rich
controls to one with very simple controls.
It makes the intention of each area of the UI to be clearer - partly
because when coding by hand, it's natural to comment the intention.
Except you've got to work out exactly how far to slide them down, make
sure it stays consistent, fight against the grid-rules which often
don't *quite* get it right, etc.
I'm pretty sure you can turn off the grid rules.
At which point you have to be pixel-perfect in your dragging if you
want a consistent API.
Also, in VS2005 the
designer helps you align controls to each other, regardless of the grid
rules. Place your one control manually, and you get nice little lines
helping you to align the controls quickly and easily. Yes, its not
that nice in VS2003, but that doesn't mean that its slower than hand
coding everything either. All it means is that the code generator is
now more helpful than ever before.
I'm sure we'll have to agree to disagree.
If you've never found it a pain in the neck, that's good for you - but
it's not the same for everyone.
It seems mostly to be a pain in the neck for those that decide they
don't like the designer from the get go, and get frustrated and easily
give up on using it when they can't figure it out in a few seconds.
Any evidence for that, or are you just making it up on the spot?
I don't view it as that much effort, and I'm a strong believer in
maintainable code.
I believe in mantainable code also, but I also believe in putting more
effort into maintaining code that will be around longer than code which
I know will not. The fact that UI technology changes so rapidly,
coupled with the fact that we DO have a very good code generator (the
designer) reduces the benefits of writing very maintainable code. The
cost of handwriting is the same as it always was, but the benefit of
handwriting is much much less than it used to be.
Again, we disagree.
Personally I'm looking forward to XAML becoming mainstream - at that
stage, it'll be easy to use the designer for the first pass, edit the
generated XAML for clarity, and still be able to use the designer
afterwards. Wins all round.
It's amazing how much maintenance time can be wasted in a few years
though,
compared with a much shorter time when coding to start with.
Changes to the UI are very very simple because of the designer. The
problem is you see the later maintenance as a manual process later,
when in reality, you're doing the maintenance with the same time saving
code generator you used in the beginning.
Need to rework a screen? Open the designer, spend a few minutes
re-arranging controls or what have you, and you're done.
Our experiences differ.
Half the reason we have a need for a proper business layer is preciesly
because UIs have become so disposable (the other half being that
changes to our data model would break the application). If the UIs
weren't changing so much, we could just have all the business rules
right in the UI. However that's not the case; UIs DO change a lot, so
the effort in building them by hand has too much of a cost to justify
it.
We'll continue to differ. At least you're aware now that others *do*
have differing opinions. I'm aware that Mr Petzold and I (along with
the OP) are in the minority on this one. It doesn't make us wrong
though :)
Jon
But that's simply not true. The designer can't express *logic* while
building up the UI. It can specify any individual property on any
individual control, so long as you know the value at design time.
Fortunately, code allows us to be much more flexible than that.
That's not the scenario for which I'm advocating the designer. That's
also code which you are not likely to generate either. Fortunately
that logic is also miniscule compared to the code which doesn't change
based on some condition; such as the position of the element. Most of
the logic is in (or should be in) the business layer. The remaining
logic of displaying or enabling a control is small. Sure, refactor
that, but to say you shouldn't use the designer and should just hand
code everything because it doesn't handle the 5% of code you want it to
is silly.
Wow, way to be dismissive of a situation that many people (myself
included) have found themselves in several times.
Has it occurred to you that possibly there are situations beyond those
you've encountered which aren't silly?
I'd have to say, if you want an array of controls for some reason, you
may be on the wrong track. If you've encounted a situation where you
absolutely needed an array of controls, and there was no way around it,
please enlighten me.
Whether you view it as silly or not, it's a counterexample to your
claim that the designer can do anything you can do by hand.
Its not much of a counter example; you claim you had a need for a
control array, but didn't specify what that need was that could not be
solved any other way. Your counter example is very vague, which is why
I dismissed it. Also, the purpose of the designer is layout of
controls (and more specific to this thread, how to do a flow layout or
table layout, and since there are controls to do this in .Net 2.0,
which the designer most certainly can handle).
It also sounds like you're trying to twist my words; I certainly never
said the designer removed all need to hand code anything and
everything. But for what the OP wanted, the designer is just fine.
I wasn't suggesting writing a code generator. I was suggesting reading
a configuration file and creating controls on the fly at runtime based
on that data. That's a very powerful way of doing things.
I'm not arguing that it isn't; but for what the OP wanted, the designer
sounds just fine. Also, if you DO need to do this, that doesn't mean
the designer is useless and not to be used ever, which is what you seem
to be advocating. You're right; that is a scenario which you can't
totaly do in the designer, but it doesn't make the designer worthless,
nor is it a very common thing to do.
I thought you didn't care about maintainability - after all, you're
always throwing away your code, aren't you?
I don't care about the maintainability of UI code; I DO care about
maintainability of business code. If your UI is making logic desicions
not related to the UI based on the contents of AddressLine1TextBox,
something is wrong.
Anyway, yes, it's often not the right thing to do - but sometimes it
is. When it is, you're screwed in the designer.
And when you need some logic to change the state of the UI, no the
designer won't help you.. however it doesn't make the designer useless
for control layout either.
I've seen plenty of cases where changes to designer-generated code have
made the designer fail to open from then onwards.
At worst, in VS2003, I've seen the designer fail until you close and
reopen VS. Surely bugs are not a reason to avoid the designer though,
are they? I hope not, since if bugs were a reason not to use
something, I don't think we'd be running Windows either.
Nothing in your original post is 2005-specific.
Nothing in your post is a reason not to use the designer in VS2003.
I suspect you don't actually *do* it though - if you do, you're in the
minority, given the bulk of the designer code I've seen. The designer
encourages sloppiness in terms of naming, structure and membership of
the class.
Actually I do; because I realized that giving a unique name to labels
which i don't update in code due to some logic is a waste of time.
Then I decided that even seeing label1, label2 in intellisense is a
waste of time. I decided all this very quickly, and knowing how to use
the designer, promptly enabled that option for most controls.
The designer is meant to be flexible; what are the majority of your
controls? Controls which need to have state changed during execution,
or controls which don't change state ever? Its likely a mix. Given
that, what is the 'correct' default? The tool makes it very easy to
fix the structure of the class, and visiblity of controls to external
classes.
If people don't bother changing those settings, well, there's not much
that can be done, is there? The designer makes it trivial to change
the things you complain about, so the benefits of using the designer
still outweigh the costs not using it, even if the default control
values and visiblity modifiers aren't what you want.
No, because if the code is nicely written, I can work out what the
results will
be without running the app at all.
I'm glad you can visual how the form will look in your mind, based
soley on the pixel coordinates and other attributes alone. Most people
can't though.
Not everyone automatically goes with every passing fad. You'll find
plenty of applications around (particularly internal ones) which
haven't had their UIs changed for years.
Web applications are hardly a passing fad. I'm actually building
replacements for internal applications now; not just to update the UI,
but because the applications don't do what is required anymore.
Furthermore, I know one of the long term goals is that a good porition
of this same functionality will be availalbe over the web to our
customers, so I'll have to build and update two UIs. The designer
makes it easy to buidl this UIs; I spend much more time building the
business layer than the UI, thanks to the designer. And if I need to
present the users a new view of things, the design makes re-arranging
the UI trivial.
It makes the intention of each area of the UI to be clearer - partly
because when coding by hand, it's natural to comment the intention.
The intention of each area of the UI should clear based on what its
doing with the business objects. However, layout and interaction with
business objects are two different tasks, and the latter is not what
the designer was meant for, nor was I advocating it for such use. The
code that actually matters, say disabling a button because its not ok
for the user to proceed, is clearly visible because its not mixed in
with a bunch of code that creates controls and plops them on the form.
That messiness is put in another file and needn't even been seen by
the developer (unless they choose to see it).
At which point you have to be pixel-perfect in your dragging if you
want a consistent API.
Which is why there's a grid. You've already stated that you want to
line up controls, which is what the grid is for. Also in 2005, you can
set a control to where you want (with the grid off) and then the
designer helps you align the other control by drawing a blue line to
show everything lines up, and snapping to that line.
Also, in VS2005 the
designer helps you align controls to each other, regardless of the grid
rules. Place your one control manually, and you get nice little lines
helping you to align the controls quickly and easily. Yes, its not
that nice in VS2003, but that doesn't mean that its slower than hand
coding everything either. All it means is that the code generator is
now more helpful than ever before.
I'm sure we'll have to agree to disagree.
I'm finding that wiring my business objects up to my UI is being
handled more and more by the designer. Code that would take me a few
minutes to type is now generated for me in seconds. If that's not
helpful, I'm not sure what is.
Any evidence for that, or are you just making it up on the spot?
Sure, just look at all the people that refuse to use the designer,
despite all the benefits it provides. People say the same thing about
the designer that they said to put down C in favor of assembly, and the
same thing that C coders now say about C#. The argument is the same: I
don't have enough control over what the tool is doing.
I believe in mantainable code also, but I also believe in putting more
effort into maintaining code that will be around longer than code which
I know will not. The fact that UI technology changes so rapidly,
coupled with the fact that we DO have a very good code generator (the
designer) reduces the benefits of writing very maintainable code. The
cost of handwriting is the same as it always was, but the benefit of
handwriting is much much less than it used to be.
Again, we disagree.
There are a lot of other bright people on my side of this argument as
well. I'm personally finding my statement to be true; I didn't just
sit down with VS and assume it, I was wary of it first. But I'm
finding the more I use it, the faster I'm getting things done.
Personally I'm looking forward to XAML becoming mainstream - at that
stage, it'll be easy to use the designer for the first pass, edit the
generated XAML for clarity, and still be able to use the designer
afterwards. Wins all round.
You can do this right now with the current designer if you wish. i'm
just debating the need to 'clarify' the UI code, since you can use the
designer for your form layout.
It's amazing how much maintenance time can be wasted in a few years
though,
compared with a much shorter time when coding to start with.
Changes to the UI are very very simple because of the designer. The
problem is you see the later maintenance as a manual process later,
when in reality, you're doing the maintenance with the same time saving
code generator you used in the beginning.
Need to rework a screen? Open the designer, spend a few minutes
re-arranging controls or what have you, and you're done.
Our experiences differ.
I suppose so; I've had bad experiences with the designers of the past,
but I also keep an open mind about the newest tools. I never thought
I'd be advocating them, but MS seems to be building some damn good ones
lately.
Half the reason we have a need for a proper business layer is preciesly
because UIs have become so disposable (the other half being that
changes to our data model would break the application). If the UIs
weren't changing so much, we could just have all the business rules
right in the UI. However that's not the case; UIs DO change a lot, so
the effort in building them by hand has too much of a cost to justify
it.
We'll continue to differ. At least you're aware now that others *do*
have differing opinions. I'm aware that Mr Petzold and I (along with
the OP) are in the minority on this one. It doesn't make us wrong
though :)
I suppose so. I was always aware of the differing opinions, I'm just
suprised how many people I see still hold your opinion. I did hold it
at one point; I just think the designers of today are lightyears ahead
of those of just a few years ago. I was very skeptical of the
Refactoring tools built into VS2005 now, but working with them, I've
come to find them invaluable and saving me quite a bit of typing, so
that I can focus on the bits that really can't be generated somehow.
Given that, and the current trend toward outsourcing everything, I
think not using the designer for form creation and layout is a mistake.
My experience is that it really does make me much more productive, and
can spend more of my time building the interesting parts of the
application (the business layer) instead of spending lots of time on
the UI.
Of course, I respect your right to disagree. :-)
Andy
Andy <aj*****@alum.rit.eduwrote:
But that's simply not true. The designer can't express *logic* while
building up the UI. It can specify any individual property on any
individual control, so long as you know the value at design time.
Fortunately, code allows us to be much more flexible than that.
That's not the scenario for which I'm advocating the designer. That's
also code which you are not likely to generate either. Fortunately
that logic is also miniscule compared to the code which doesn't change
based on some condition; such as the position of the element. Most of
the logic is in (or should be in) the business layer. The remaining
logic of displaying or enabling a control is small. Sure, refactor
that, but to say you shouldn't use the designer and should just hand
code everything because it doesn't handle the 5% of code you want it to
is silly.
When the controls need to be set up dynamically using logic, it doesn't
make much sense to me to rely on the designer for some controls, unable
to see the others.
Do you now accept that your "proof" was backwards, by the way?
Wow, way to be dismissive of a situation that many people (myself
included) have found themselves in several times.
Has it occurred to you that possibly there are situations beyond those
you've encountered which aren't silly?
I'd have to say, if you want an array of controls for some reason, you
may be on the wrong track. If you've encounted a situation where you
absolutely needed an array of controls, and there was no way around it,
please enlighten me.
In several situations you may need a list/array of, say, checkboxes.
You may be generating a UI where you don't even know how many you'll
need to start with. You may be selecting which items from a list of 10
recently used documents should be deleted, or something like that -
anywhere that the UI doesn't attach any meaning to the control beyond
it being one of a collection, and its place within that collection.
Anywhere other than the UI, an array would be used. Why should a UI end
up with checkbox1, checkbox2, checkbox3 etc instead of what would be
natural elsewhere - an array?
Whether you view it as silly or not, it's a counterexample to your
claim that the designer can do anything you can do by hand.
Its not much of a counter example; you claim you had a need for a
control array, but didn't specify what that need was that could not be
solved any other way. Your counter example is very vague, which is why
I dismissed it.
My counter example is very specific - with manual code, I can create an
array of controls, laying the controls out based on the position within
the array. You can't do that within the designer.
Whether that's useful or not is entirely orthogonal to whether or not
it's a counterexample of your claim that you can do everything in the
designer that you can do in plain code.
Also, the purpose of the designer is layout of
controls (and more specific to this thread, how to do a flow layout or
table layout, and since there are controls to do this in .Net 2.0,
which the designer most certainly can handle).
It also sounds like you're trying to twist my words; I certainly never
said the designer removed all need to hand code anything and
everything. But for what the OP wanted, the designer is just fine.
Here are your exact words:
<quote>
You're not gaining anything by avoiding it, as it can do everything you
can do
</quote>
I've demonstrated something I can do - still related to laying out
controls - that it can't do. How is that twisting your words?
I wasn't suggesting writing a code generator. I was suggesting reading
a configuration file and creating controls on the fly at runtime based
on that data. That's a very powerful way of doing things.
I'm not arguing that it isn't; but for what the OP wanted, the designer
sounds just fine. Also, if you DO need to do this, that doesn't mean
the designer is useless and not to be used ever, which is what you seem
to be advocating. You're right; that is a scenario which you can't
totaly do in the designer, but it doesn't make the designer worthless,
nor is it a very common thing to do.
Ah, so you admit that the designer *can't* do everything you can do.
Hooray!
I thought you didn't care about maintainability - after all, you're
always throwing away your code, aren't you?
I don't care about the maintainability of UI code; I DO care about
maintainability of business code. If your UI is making logic desicions
not related to the UI based on the contents of AddressLine1TextBox,
something is wrong.
Sure - but I can still care about the maintainability of UI code.
Anyway, yes, it's often not the right thing to do - but sometimes it
is. When it is, you're screwed in the designer.
And when you need some logic to change the state of the UI, no the
designer won't help you.. however it doesn't make the designer useless
for control layout either.
Well, I've seen it generally have a poor effect on the quality of the
end result code, and in particular I don't think people understand
their own code as well when it's produced for them as if they've
written it themselves. I know I don't.
I've seen plenty of cases where changes to designer-generated code have
made the designer fail to open from then onwards.
At worst, in VS2003, I've seen the designer fail until you close and
reopen VS. Surely bugs are not a reason to avoid the designer though,
are they? I hope not, since if bugs were a reason not to use
something, I don't think we'd be running Windows either.
If the designer screws up often enough that it can't even produce the
poor code properly, that *is* a reason to avoid the designer.
Nothing in your original post is 2005-specific.
Nothing in your post is a reason not to use the designer in VS2003.
I suspect you don't actually *do* it though - if you do, you're in the
minority, given the bulk of the designer code I've seen. The designer
encourages sloppiness in terms of naming, structure and membership of
the class.
Actually I do; because I realized that giving a unique name to labels
which i don't update in code due to some logic is a waste of time.
Then I decided that even seeing label1, label2 in intellisense is a
waste of time. I decided all this very quickly, and knowing how to use
the designer, promptly enabled that option for most controls.
Out of interest, is that option new in 2005? I don't remember seeing it
in 2003...
The designer is meant to be flexible; what are the majority of your
controls? Controls which need to have state changed during execution,
or controls which don't change state ever? Its likely a mix. Given
that, what is the 'correct' default? The tool makes it very easy to
fix the structure of the class, and visiblity of controls to external
classes.
It also makes it easy to forget. I'm pleased to hear that you get rid
of variables which aren't needed - but how many do?
If people don't bother changing those settings, well, there's not much
that can be done, is there? The designer makes it trivial to change
the things you complain about, so the benefits of using the designer
still outweigh the costs not using it, even if the default control
values and visiblity modifiers aren't what you want.
I think we'll have to agree to disagree, as I've said before.
I will, however, mention another thing that the designer unfortunately
encourages: absolute positioning. This brings us back to the original
topic of the thread.
When writing code manually, most developers start getting wary if
they've got too many numeric literals in their code. Somehow, people
often forget that with UI code - they don't mind that each control is
individually positioned with an absolute position.
This is where the Java layout managers requested by the OP are so good
(even if they've taken a long while to evolve, and still aren't as easy
to use as they should be - I believe the JGoodies package is
significantly better, although I haven't actually used it in anger).
They encourage you to think about how an application should look when
it's resized - the designer certainly doesn't do that.
No, because if the code is nicely written, I can work out what the
results will
be without running the app at all.
I'm glad you can visual how the form will look in your mind, based
soley on the pixel coordinates and other attributes alone. Most people
can't though.
I can visualise enough for maintenance purposes. For design purposes, I
tend to use a pencil and paper to work out how I want it to look - or
possibly use the designer, before writing the code properly.
Not everyone automatically goes with every passing fad. You'll find
plenty of applications around (particularly internal ones) which
haven't had their UIs changed for years.
Web applications are hardly a passing fad. I'm actually building
replacements for internal applications now; not just to update the UI,
but because the applications don't do what is required anymore.
Furthermore, I know one of the long term goals is that a good porition
of this same functionality will be availalbe over the web to our
customers, so I'll have to build and update two UIs. The designer
makes it easy to buidl this UIs; I spend much more time building the
business layer than the UI, thanks to the designer. And if I need to
present the users a new view of things, the design makes re-arranging
the UI trivial.
Web UIs are becoming increasingly difficult for designers to cope with,
IMO, as the world becomes more AJAX (etc) focused. There's so much
going on behind the scenes, it's hard for a designer to keep up, in my
experience.
It makes the intention of each area of the UI to be clearer - partly
because when coding by hand, it's natural to comment the intention.
The intention of each area of the UI should clear based on what its
doing with the business objects.
How does its use of business object signal intention such as drawing
the user's eye to a certain feature, or encouraging a certain way of
working, or lining things up appropriately?
However, layout and interaction with
business objects are two different tasks, and the latter is not what
the designer was meant for, nor was I advocating it for such use.
And yet you assumed that I was talking about interaction with business
objects when I talked about commenting intention. Why? Do you believe
there isn't any intention in UI design?
The code that actually matters, say disabling a button because its
not ok for the user to proceed, is clearly visible because its not
mixed in with a bunch of code that creates controls and plops them on
the form. That messiness is put in another file and needn't even been
seen by the developer (unless they choose to see it).
Indeed, partial files are a definite plus on that front.
At which point you have to be pixel-perfect in your dragging if you
want a consistent API.
Which is why there's a grid. You've already stated that you want to
line up controls, which is what the grid is for. Also in 2005, you can
set a control to where you want (with the grid off) and then the
designer helps you align the other control by drawing a blue line to
show everything lines up, and snapping to that line.
I've run into situations (usually with the compact framework) where
neither using the grid nor not using the grid works well. The grid is
fine if absolutely everything can be on the same n*n grid lines, but
that doesn't end up looking nice when you've got a control which needs
to be 4.5*n pixels high, and you want things to be n pixels beneath it
- it works for the items above that, but not those below. Now, by doing
things programmatically you can specify how much space you want to have
between items and let the program do the addition at runtime. (Of
course, layout managers help on this front - not having used WinForms
on 2.0 much yet, I don't know how much ground has been caught up on
this front, or how much support the designer gives for it.)
I'm sure we'll have to agree to disagree.
I'm finding that wiring my business objects up to my UI is being
handled more and more by the designer. Code that would take me a few
minutes to type is now generated for me in seconds. If that's not
helpful, I'm not sure what is.
It depends whether someone later has to take more than a few minutes to
understand what's going on in maintenance mode. As I said before, "a
few years" can amount to quite a lot of maintenance.
Any evidence for that, or are you just making it up on the spot?
Sure, just look at all the people that refuse to use the designer,
despite all the benefits it provides.
Which people, and what evidence do you have that they've only used the
designer for a short amount of time? I've used the designer when I've
had to - i.e. when working with others who use the designer, due to the
limitations on using the designer with hand-crafted code - and it's
always been a bugbear for me when it comes to producing a UI which
isn't just functional, but is *nice*.
People say the same thing about the designer that they said to put
down C in favor of assembly, and the same thing that C coders now say
about C#. The argument is the same: I don't have enough control over
what the tool is doing.
I see your point on that front, but I there's a difference, at least in
my view. I don't shun all new technology (otherwise I wouldn't be using
..NET, would I?) but I like technology which gives me power and control
at the same time. The designer feels too much like an all-or-nothing
affair - if you need to change things that it's done by more than a
notch, you can't use it ever again for that code (IME).
Again, we disagree.
There are a lot of other bright people on my side of this argument as
well. I'm personally finding my statement to be true; I didn't just
sit down with VS and assume it, I was wary of it first. But I'm
finding the more I use it, the faster I'm getting things done.
Getting things done fast to start with is certainly good - but have you
analysed the maintenance costs later on?
Personally I'm looking forward to XAML becoming mainstream - at that
stage, it'll be easy to use the designer for the first pass, edit the
generated XAML for clarity, and still be able to use the designer
afterwards. Wins all round.
You can do this right now with the current designer if you wish. i'm
just debating the need to 'clarify' the UI code, since you can use the
designer for your form layout.
I like all the code in my app to be clear. I want to be able to sit
down and read it if I need to, in a maintenance situation. The code
generated by the designer is far from readable, and in many cases when
you come back to the designer after not seeing an app for a while it's
hard to see everything that's there, particularly when multiple tab
pages are involved.
If you start adding controls programmatically as *well* as using the
designer, you end up in a nasty half-way house where you can neither
read the code to find out what's going on nor use the designer to see
it - at that stage you've really *got* to run the code to see what
happens.
This was particularly true last time I was doing compact framework
development, where using custom controls in the designer was pretty
horrible.
Our experiences differ.
I suppose so; I've had bad experiences with the designers of the past,
but I also keep an open mind about the newest tools. I never thought
I'd be advocating them, but MS seems to be building some damn good ones
lately.
Perhaps the difference is that I'm coming from a largely 2003
background, and certainly in your first posts you didn't make it clear
that you were only really advocating 2005. I haven't worked much with
the designer in 2005 - I'll still be leary of it, but maybe I should
give it another try.
We'll continue to differ. At least you're aware now that others *do*
have differing opinions. I'm aware that Mr Petzold and I (along with
the OP) are in the minority on this one. It doesn't make us wrong
though :)
I suppose so. I was always aware of the differing opinions, I'm just
suprised how many people I see still hold your opinion.
Interesting - I rarely see it at all, certainly on newsgroups.
I did hold it
at one point; I just think the designers of today are lightyears ahead
of those of just a few years ago. I was very skeptical of the
Refactoring tools built into VS2005 now, but working with them, I've
come to find them invaluable and saving me quite a bit of typing, so
that I can focus on the bits that really can't be generated somehow.
Ah, now refactoring is a tool I would be loathe to be without. I was
always amazed that MS brought out 2002 and 2003 without refactoring in,
when Java tools have had it for ages (and other languages before then,
I realise). Even now the range and power of the refactorings available
in VS are weaker than in Eclipse. (I know there are 3rd party tools,
but I'd rather not have to use them, especially if they cost money. I'm
spoiled by so much being free in the Java world.)
Eclipse still has a *vastly* more usable code editor than Visual
Studio, in my opinion, although there are elements of 2005 which would
be nice in Eclipse too. I wish 2005 has open resource and/or open type
shortcuts though, with the instant update of Eclipse...
(It's unfortunate that at work I still have to use 2003. I recently did
some work in C# after writing Java in Eclipse for several months. I
couldn't believe how painful it was to use VS.NET.)
Given that, and the current trend toward outsourcing everything, I
think not using the designer for form creation and layout is a mistake.
On the contrary, I'd say that outsourcing is a reason to focus on
maintainability - think of the long term use of the code beyond the
initial authoring.
My experience is that it really does make me much more productive, and
can spend more of my time building the interesting parts of the
application (the business layer) instead of spending lots of time on
the UI.
Of course, I respect your right to disagree. :-)
Goodo :) This has been a far more productive discussion than I'd
expected.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
When the controls need to be set up dynamically using logic, it doesn't
make much sense to me to rely on the designer for some controls, unable
to see the others.
Do you now accept that your "proof" was backwards, by the way?
Hmm. How about this.. I will conside that this is one instance the
designer cannot help you complete. But I still think the designer is
useful to get started.
In several situations you may need a list/array of, say, checkboxes.
You may be generating a UI where you don't even know how many you'll
need to start with. You may be selecting which items from a list of 10
recently used documents should be deleted, or something like that -
anywhere that the UI doesn't attach any meaning to the control beyond
it being one of a collection, and its place within that collection.
I would say that positional logic (if UI item is in index 5) is harder
to maintain and more prone to error. After all, what if the position
changes? You have the magic number problem..you now need to find
everythere that magic number is used.
As an alternative, I would suggest the Tag property. Since it accepts
a type of object, you can put anything you want in there. Create a
class with all the extra data you'd need, create an instance with the
specific data and put it in the tag.
Anywhere other than the UI, an array would be used. Why should a UI end
up with checkbox1, checkbox2, checkbox3 etc instead of what would be
natural elsewhere - an array?
You can use the Tag approach. Honestly I rarely find I need arrays at
all anymore. Usually I'm using collections. Since I've started .Net
2.0, I seem to use generic Lists. In VB and VBScript, I used arrays a
lot. I rarely every use them anymore, as the exact order doesn't
matter (and when it does, it matters because the collection must be
sorted according to a property on the object in the list.
My counter example is very specific - with manual code, I can create an
array of controls, laying the controls out based on the position within
the array. You can't do that within the designer.
Yes, I had a hard time coming up with a reason, as its not something
I've found the need to do often all. But you're right, that doesn't
mean that its not a valid example, although I think there are better
alternatives than an array.
I've demonstrated something I can do - still related to laying out
controls - that it can't do. How is that twisting your words?
I amend my words to: You can do 99% of everything you need to as far
as UI control layout with the designer. :-)
Ah, so you admit that the designer *can't* do everything you can do.
Hooray!
Yes, a few fringe cases ;-) But you're right.
Sure - but I can still care about the maintainability of UI code.
I suppose this is just something we'll continue to disagree on.
Well, I've seen it generally have a poor effect on the quality of the
end result code, and in particular I don't think people understand
their own code as well when it's produced for them as if they've
written it themselves. I know I don't.
The code I'm specifically talking about is the layout code. Button
click code (which the designer can't generate a body for) does need
manual coding, and yes I think you should make some effort to make it
readable. Not much though.. this is just interaction with business
objects, which do all the real work. Most of my user code in the UI
layer is only a few lines.. so its hard to not be maintainable.
If the designer screws up often enough that it can't even produce the
poor code properly, that *is* a reason to avoid the designer.
I haven't had it screw up enough on me to avoid it. In rare (and
predicable cases) the 2002/ 2003 designer would 'eat' your code. But
that would only be code in InitializeComponent, and only under certain
conditions. The exact conditions escapes me now, its been a while.
Actually I do; because I realized that giving a unique name to labels
which i don't update in code due to some logic is a waste of time.
Then I decided that even seeing label1, label2 in intellisense is a
waste of time. I decided all this very quickly, and knowing how to use
the designer, promptly enabled that option for most controls.
Out of interest, is that option new in 2005? I don't remember seeing it
in 2003...
Yes it is. Everything (except the form of course) has a "Generate
Member" option in the Properties window. It defaults to True (likely
for backwards compatability) but setting it to False keeps the scope of
the control variable to the InitalizeComponent method. Perhaps because
I used the designer so much, it didn't take me long to notice the
option and read up on it and then try it out.
The designer is meant to be flexible; what are the majority of your
controls? Controls which need to have state changed during execution,
or controls which don't change state ever? Its likely a mix. Given
that, what is the 'correct' default? The tool makes it very easy to
fix the structure of the class, and visiblity of controls to external
classes.
It also makes it easy to forget. I'm pleased to hear that you get rid
of variables which aren't needed - but how many do?
Well to be fair its a new feature, and whenever you start a new version
of a tool, I'd say its wise to read up on the new features. I know,
many won't, but that's not a reason to NOT use the designer, its a
reason to check out the new features list.
If people don't bother changing those settings, well, there's not much
that can be done, is there? The designer makes it trivial to change
the things you complain about, so the benefits of using the designer
still outweigh the costs not using it, even if the default control
values and visiblity modifiers aren't what you want.
I think we'll have to agree to disagree, as I've said before.
I'd say this is more of a reason to read up on the new features of the
tool you're using. I don't think its a reason to avoid using the
design. Tools change. Avoiding a tool because version 1 didn't
support what you view as a required feature doesn't mean you should
avoid all future versions. The designer in 2002 / 2003 is light years
ahead of previous designers (vb6, vc++, etc). 2005 actually seems
light years ahead of 2003.
I will, however, mention another thing that the designer unfortunately
encourages: absolute positioning. This brings us back to the original
topic of the thread.
Yes; my second post to this thread pointed out, new in .Net 2.0, the
TableLayout and
FlowLayout container controls, which give the relative positioning you
want. I mention that the are specific to .Net 2.0.
To be fair though, rarely do I have resizable forms. The business
applications I create usually don't lend well to resizing.. it doesn't
buy the form anything (the text boxes stretch wider?).
When writing code manually, most developers start getting wary if
they've got too many numeric literals in their code. Somehow, people
often forget that with UI code - they don't mind that each control is
individually positioned with an absolute position.
If you had to hand code everything, I'd agree. But the designer makes
changing the position of multiple controls at one time a breeze. Also,
form layouts probably don't require shifting controls that much. The
first name text box, for example, never has a reason to move as its
position from the upper left corner of the screen. Why would it? Hard
coding that value is fine; its unlikely to change, and changing it in
the designer is so easy..
This is where the Java layout managers requested by the OP are so good
(even if they've taken a long while to evolve, and still aren't as easy
to use as they should be - I believe the JGoodies package is
significantly better, although I haven't actually used it in anger).
They encourage you to think about how an application should look when
it's resized - the designer certainly doesn't do that.
In VS2005 as I've said, the two new container controls solve these
problems. I'm sure there are more you can buy as well if you need more
than just flow or table. I believe there are also 3rd party controls
available for .Net 1.x as well. You use these controls to handle the
layout, and you can still use the design to generate most of your code.
It seems your problem isn't the designer per se, its the lack of
relative layout positioning. But that can be solved by using container
controls.
I can visualise enough for maintenance purposes. For design purposes, I
tend to use a pencil and paper to work out how I want it to look - or
possibly use the designer, before writing the code properly.
I like to be 100% certain, and the designer helps me acomplish that. I
see the result of my changes right away. Ctrl Z reverts things. I
don't know why you design on paper; if that's your style, I think thats
fine. However it seems to me you can accomplish everything using the
designer in liue of paper and pencil. The advantage is that you don't
need to erase your mistakes; just drag the controls to the new
position. I'd think that would be faster.
Web UIs are becoming increasingly difficult for designers to cope with,
IMO, as the world becomes more AJAX (etc) focused. There's so much
going on behind the scenes, it's hard for a designer to keep up, in my
experience.
I believe Atlas includes controls which the designer can use. In any
event, you'll always have to right the code to make the UI work with
the client business layer. I never meant to claim that the designer
would write THAT code for you. But with Ajax, you usually replace a
div, or add new divs, etc etc. The designer can be used for your
hidden template or, or to create the divs who's content is alwasy being
replaced.
How does its use of business object signal intention such as drawing
the user's eye to a certain feature, or encouraging a certain way of
working, or lining things up appropriately?
That's the job of the UI, and the designer can help with that. For
example, you can drop an ErrorProvider control on your form. The
designer won't help you make a control change color; but that wasn't
the topic of this thread, how to best do the UI layout was. And that's
just what the designer was made for.
And yet you assumed that I was talking about interaction with business
objects when I talked about commenting intention. Why? Do you believe
there isn't any intention in UI design?
I think the UI's sole purpose is displaying the data to the user and
allow the user to interat with the data. How something is done is what
is captured by the business layer. Just about all of my code is just
enabling / disabling controls, responding to user events (such as
clicking the OK button, which should save the current business object)
or responding to data events, which are indirectly raised by the user
when they are modifying the state of the business objects.
Honestly, there's very little non generated code in my UI layer. The
largest routine I have is just figuring which prompt is appropiate when
the user closes a window with a changed object. The UI needs to ask
the user if it should save the object, but only if the object is in a
valid, savable state. If its not, it mearly warns changes will be
lost, and offers the ability to cancel closing the form.
All the other code (which is designer generated) is just binding the
controls to the proper datasources, or passing one object to another
form for editing.
The code that actually matters, say disabling a button because its
not ok for the user to proceed, is clearly visible because its not
mixed in with a bunch of code that creates controls and plops them on
the form. That messiness is put in another file and needn't even been
seen by the developer (unless they choose to see it).
Indeed, partial files are a definite plus on that front.
Finally you've agreed with me! :-)
I've run into situations (usually with the compact framework) where
neither using the grid nor not using the grid works well. The grid is
fine if absolutely everything can be on the same n*n grid lines, but
that doesn't end up looking nice when you've got a control which needs
to be 4.5*n pixels high, and you want things to be n pixels beneath it
- it works for the items above that, but not those below. Now, by doing
things programmatically you can specify how much space you want to have
between items and let the program do the addition at runtime. (Of
course, layout managers help on this front - not having used WinForms
on 2.0 much yet, I don't know how much ground has been caught up on
this front, or how much support the designer gives for it.)
I think the container controls mentioned would help in this front. I
haven't found myself wanting to position something at half a pixel..
technically that's not really possible, since the smallest element
displable is the pixel, I would think.
I'm finding that wiring my business objects up to my UI is being
handled more and more by the designer. Code that would take me a few
minutes to type is now generated for me in seconds. If that's not
helpful, I'm not sure what is.
It depends whether someone later has to take more than a few minutes to
understand what's going on in maintenance mode. As I said before, "a
few years" can amount to quite a lot of maintenance.
I agree; but most of the changes would likely be in the business layer.
You're modifying the code to keep up with business requirements.
Changes to the UI reflect that or make using the application easier.
Either way, it should be relatively easy to understand... especially if
you're making use of databinding, which means most of the UI code is
generated.
Any evidence for that, or are you just making it up on the spot?
Sure, just look at all the people that refuse to use the designer,
despite all the benefits it provides.
Which people, and what evidence do you have that they've only used the
designer for a short amount of time? I've used the designer when I've
had to - i.e. when working with others who use the designer, due to the
limitations on using the designer with hand-crafted code - and it's
always been a bugbear for me when it comes to producing a UI which
isn't just functional, but is *nice*.
I've run across such people on the internet. They always popup in
similar issues. For example, there were a large number of people on
slashdot lately advocating not using an IDE at all, because it 'makes
the developer lazy and stupid.'
Its possible to make a very nice UI in the designer; I had a UI person
look over my UI just to make sure, and she said it looked great. It
doesn't take much; throwing in some icons, group boxes, buying controls
which support styling or theming.
I see your point on that front, but I there's a difference, at least in
my view. I don't shun all new technology (otherwise I wouldn't be using
.NET, would I?) but I like technology which gives me power and control
at the same time. The designer feels too much like an all-or-nothing
affair - if you need to change things that it's done by more than a
notch, you can't use it ever again for that code (IME).
No, it just seems to me you'd be happier using notepad. :-) The
designer does give you a lot of power. The default controls may or may
not take advantage of that.. but the fact that you can build your own
UI for programers using of your control tells me the designer has a
HUGE amount of power to offer users. The amount of work the designer
can handle has been increasing. Databinding in 2003 requires you to
type a lot of code, mostly one line for each bound control. The 2005
designer allows binding to objects of any kind, and eliminates the need
for me to code anything. I just click a control, and set two
properties, and off I go.
Getting things done fast to start with is certainly good - but have you
analysed the maintenance costs later on?
Formal analysis, no. But I haven't really had a problem using the
designer to recreate forms. If a form changes too drastically, most of
the code I had to write originally needs to be tossed anyway; the form
has just changed too much for any of it to be useful.
I like all the code in my app to be clear. I want to be able to sit
down and read it if I need to, in a maintenance situation. The code
generated by the designer is far from readable, and in many cases when
you come back to the designer after not seeing an app for a while it's
hard to see everything that's there, particularly when multiple tab
pages are involved.
That's your preference; I tend not to ever even look at the designer
code. I just use the designer to change it. Its pretty easy to see
all the tabs; just click each one and review it.
If you start adding controls programmatically as *well* as using the
designer, you end up in a nasty half-way house where you can neither
read the code to find out what's going on nor use the designer to see
it - at that stage you've really *got* to run the code to see what
happens.
Yes; that can be a problem. Again though, not many forms I've ever had
to create required creating controls dynamically. Where I do, its
usually commented in a label somewhere, which is hidden by default.
If you have to hand code anything, you need to make it at least a
little maintainable. I don't think a lot of effort is needed though.
And again, if you use the designer, you have time to make code which
you can't create via the designer more maintainable, because the code
easily worked in via the designer doesn't have to be thought about.
This was particularly true last time I was doing compact framework
development, where using custom controls in the designer was pretty
horrible.
Compact development is an area I haven't gotten into yet, I'll have to
trust you that there were problems here. As far as the original topic
of this thread though, it didn't seem the OP was going to be using the
compact framework. I would think if you were, you'd make sure to
mention that, since I'd think most assume normal framework.
Perhaps the difference is that I'm coming from a largely 2003
background, and certainly in your first posts you didn't make it clear
that you were only really advocating 2005. I haven't worked much with
the designer in 2005 - I'll still be leary of it, but maybe I should
give it another try.
I advocate 2003, but yes it does have its problems. 2005 is
signficantly imporved, especially with the new container controls. You
should give it a try. If you want relative positioning of controls
(which I bet is a lot more common than the cases you sight for control
arrays), you should be pleasently suprised.
Ah, now refactoring is a tool I would be loathe to be without. I was
always amazed that MS brought out 2002 and 2003 without refactoring in,
when Java tools have had it for ages (and other languages before then,
I realise). Even now the range and power of the refactorings available
in VS are weaker than in Eclipse. (I know there are 3rd party tools,
but I'd rather not have to use them, especially if they cost money. I'm
spoiled by so much being free in the Java world.)
I haven't been as spoiled in Java. Much of my experience was a college
course. The last project was 'write a program that does this, in
Swing, and without using an IDE.' I didn't do it, since I believed
even that that UI is best left coded to the designers. Its a lot of
code to write, for something which should be rather simple. I did
learn about the layout mode (I was rather annoyed that I couldn't
absolutely position controls; its odd, you don't like the designer
because it takes some power, but relative positioning with flow layout
you seem to like, but it takes away the power to put controls exactly
where you want. Of course, I didn't do the project, so perhaps I was
wrong.)
The refactoring tools are great in VS2005, and I agree wholeheartedly.
About time!
Eclipse still has a *vastly* more usable code editor than Visual
Studio, in my opinion, although there are elements of 2005 which would
be nice in Eclipse too. I wish 2005 has open resource and/or open type
shortcuts though, with the instant update of Eclipse...
Indeed... there is yet no perfect IDE.
(It's unfortunate that at work I still have to use 2003. I recently did
some work in C# after writing Java in Eclipse for several months. I
couldn't believe how painful it was to use VS.NET.)
In that case I'm glad I never used Eclipse. I tried Netbeans, but got
frustred and left it behind... mainly because I didn't have anything I
needed to use Java for.
On the contrary, I'd say that outsourcing is a reason to focus on
maintainability - think of the long term use of the code beyond the
initial authoring.
I think we need to be careful about what we spend our time on; code
which can be generated I don't think needs to be as maintainable, since
it can be regenerated again. It shouldn't be total slop though
either... but the designer only seems to lay out code which is
aboslutely necessary. No lines are emitted that aren't needed. And
there is a method to its madness too. It works with one control at a
time. Look at some generated code now and then... you may start to see
the pattern.
Goodo :) This has been a far more productive discussion than I'd
expected.
I always enjoy a good debate; I was afraid some of my comments might be
taken as flaming, and that's not at all what I was going for. Just
have some strong beliefts and fast typing skills... not always the best
combination. :-)
Andy
Andy <aj*****@alum.rit.eduwrote:
<snip>
Unfortunately I'm running too low on time to answer all the points -
and I suspect we've got as close to agreement as we're going to. So,
just to summarise my current position for posterity:
I'll give the designer in 2005 another try next time I'm doing GUI
work, but I'm still leaning towards hand-coding. It really doesn't take
that long, gives a deeper understanding of how the UI actually fits
together, and makes it easier (IMO) to add new functionality or move
existing functionality.
While UI logic is *often* simply a case of delegating to business
logic, that's certainly not always the case - sophisticated UIs can
include significant logic which really isn't part of any business
object (but which can sometimes creep that way if you're not careful).
Working with code which uses button1, label1 etc is nightmarish - and
all too easy to fall into with the designer, unless you're really
diligent about naming controls etc when you first create them in the
designer.
Thanks for the discussion.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Curious Tom |
last post by:
I'm using ASP.Net and I'm wondering if code generated using the grid layout
will run on netscape browsers? Also what version of netscape?
I've read that Grid Layout uses DHTML and the IE and...
|
by: Meinolf Sander |
last post by:
Do you have experiences using HTML beautifiers (like
1st Page Editor) with nested table structures (like in
<http://www.nexanto.de/m+e.html>)?
Does the layout change significantly with non-text...
|
by: NWx |
last post by:
Hi,
I develop an ASP.NET app which should be used from Internet, so I don't have
control over what browsers will be used.
I don't want to target every possible users, so I don't really mind is...
|
by: Mahesh Devjibhai Dhola [MVP] |
last post by:
Hi,
How to achieve effect of LayoutManagers like java has Grid, Flow, Border etc
layouts in .Net?
The case is: I am creating the form runtime and adding controls on run-time
so at that time its...
|
by: Ben Holness |
last post by:
Hi all,
I am having some trouble with some table code. It works fine in Internet
Explorer, but the layout doesn't work correctly in Firefox 1.0.7
Is this a firefox bug, or am I missing...
|
by: David Veeneman |
last post by:
I'm just getting started with ASP.NET in Visual Studio 2005. The last web
work I did involved ASP 3.0 in FrontPage.
I've been through the MSDN tutorials on creating web pages, but not of them...
|
by: YesGoGoGo |
last post by:
Our product is web-based and for enterprise customer to handle their
daily work.(like CRM system)
We want to redesign this product for better performance and visual
attractiveness.
We found...
|
by: PW |
last post by:
I have a layout that I can not seem to make work. Using a float:right, I can
get the numbered items to wrap as desired around "rightdiv". The problem is,
this is a dynamic list, and "5" shouldn't...
|
by: Ella Matthewman |
last post by:
The website I'm designing works perfectly in Internet Explorer, but I just tested it in firefox and it doesn't work at all.
Site is http://www.nannycompany.co.uk/testing/index.html
And I guess...
|
by: erikbower65 |
last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps:
1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal.
2. Connect to...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: erikbower65 |
last post by:
Here's a concise step-by-step guide for manually installing IntelliJ IDEA:
1. Download: Visit the official JetBrains website and download the IntelliJ IDEA Community or Ultimate edition based on...
|
by: Taofi |
last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same
This are my field names
ID, Budgeted, Actual, Status and Differences
...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: DJRhino |
last post by:
Private Sub CboDrawingID_BeforeUpdate(Cancel As Integer)
If = 310029923 Or 310030138 Or 310030152 Or 310030346 Or 310030348 Or _
310030356 Or 310030359 Or 310030362 Or...
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
| |
