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.
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.
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.
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.
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.
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.
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
