Re: A moderate view - Adressing Control Arrays.....

[Paul Mc]

> Maybe we can begin to talk about all
>the other compatibility issues other then True = -1, Short Circuiting, etc,
>*and* how to address them.

Right.

I have been thinking about the control arrays problem. Control arrays are
heavily used, and while delegation gives us what seems to be a far more powerful
mechanism for achieving similar results, it is obviously one area where considerable
incompatability exists.

The way I see it, the problem affects us in two ways, each of which should
perhaps be addressed differently.

1) Migration. This does not seem too much of an issue. In my experience,
the migration wizard does an OK job of control arrays, and the various compatibility
objects in Microsoft.VisualBasic.Compatibility.VB6 namespace would seem to
cater for most "classic" control array needs.

If you want me to post some code on this, just ask - it is really quite simple.

2) New development. Using delegation is more powerful than classic conrol
arrays, but correspondingly less simple - ie the need to write extra code
rather than just work with properties. The added power of delegation is not
meaningful for those who only intend to use it to get the functionality they
already have in VB6 control arrays.

One obvious solution to all this is to add the classic control array back
in to the Windows forms package. This seems to me to be a huge overkill,
considering the ease of duplicating control array functionality, but I am
sure others would disagree. How difficult it would be, I don't know - it
would probably be more likely that it could be fixed up to look and behave
like a classic control array.....

If that one option, then let's consider others.

Addressing point 1 (migration).

Well, control arrays migrate well, and remain functional in my experience.
The code changes a little, that is to be expected, but is easily understandable.
I reiterate my opinion - there seems to be little concern for migrating control
arrays. The wizard does a good job - I will post code upon request.

Addressing Point 2 (New development).
Well writing control array functionality is a little more convoluted, I grant
that. Basically it consists of adding/extending the "Handles" clause to an
existing event handler, which is not, in itself, difficult, but can become
tedious if you are coding for many events. Some automation of this process
would be greatly beneficial....

I propose this: an extension to the property pages. One new item, perhaps
titled "Array Name" or something,combination textbox/combo, & its functionality
to be explained below, and a second new item "Index" behaving just like the
classic VB index property.

Here is how it could work. You add a new command button, call it "cmdTest0".
In "Array Name" property type "cmdTest" ie creating a base control array
handler. "Index" property would then default to 0. Changing the name of this
control should update the name in the "Array Name" property of any other
controls....

Then, add a second button, call it "cmdTest1" (Don't worry about the naming
just yet - I will get to that). In "Array Name" property select "cmdTest"
(it would be there in a dropdown). "Index" property would then default to
1.

From these properties, you can see how the behind-the-scenes code would work.
The IDE could easily handle keeping track of the event handlers for different
controls. Control referencing with the Name(Index) form could be handled
similar to the way the wizard handles the migration of control arrays - basically
by creating an object in code to handle the indexed references. In this example,
that object would be called "cmdTest" as entered in the "Array Name" property,
and it would basically manafacture references to controls by way of an index,
and would be iteratable. we would have functional control arrays without
any real change to the existing WinForms package. Seems like a reasonable
solution to me.

I welcome and ancourage any comment - this is pretty off-the-cuff. Are there
any obvious holes in this that I have overlooked?

Cheers,
Paul

[Kathleen Dollard-Joeris]

Paul,

I think this is a good approach. Next time, a new thread might be helpful. I
see it as a good approach because it takes us a step closer to determining
best practices. I also think if the focus is best practices, and how we
accomplish something it should be in the technical group. If it is to ask MS
for something, it should stay here. IMO, the MS team with a lot of input
creates the tool, and we determine how to use it. Best practices are a very
important tool, partly because it is loose.

On control arrays, I would like to remove the word problem. I believe that
giving up VB6- control arrays is an opportunity. Still there are several
ways to implement a replacement strategy, and it seems worth discussing, as
you have introduced here.

There are at least three ways to solve this. MS give us tools to solve it
(in which case those would probably be best practice), add VB6-
functionality via inheritance which is what I think you mean by "extension",
and create new strategies tools to do the job. Let's largely ignore the
first for this purpose (we aren't sure yet what help MS may provide) and
look to the two approaches in our control. I will first comment on what you
said, then discuss the other approach.

(I could add that an argument could be made that a defacto standard is
created by the migration wizard and we could copy that. IMO, the migration
wizard has different goals: as complete a functionality as possible, while
we have a different goal in new code: the best functionality).

> Changing the name of this
> control should update the name in the "Array Name" property of any other
> controls....

I agreed with you until here. How would you then be able to move a control
from one grouping to another.

> Then, add a second button, call it "cmdTest1" (Don't worry about the
naming
> just yet - I will get to that). In "Array Name" property select "cmdTest"
> (it would be there in a dropdown). "Index" property would then default to
> 1.

This is one of two parts of what you suggest that is non-trivial. I don't
think it is terribly difficult, I just have not worked with macros and
property pages enough to know. This is one of the ways that control arrays
have made our lives very easy.

> From these properties, you can see how the behind-the-scenes code would
work.
> The IDE could easily handle keeping track of the event handlers for
different
> controls. Control referencing with the Name(Index)

This is the other slightly non-trivial part. And the other place that
control arrays save us effort in VB6-. This would simply require a separate
block of code autogenerated and placed after (but similar in source) to the
current hidden code.

I actually think the hardest part of doing this would be figuring out how
and when to restrict control arrays to specific control types. If a new
event is added to a control, does that mean it can no longer act as its
parent control type? In VB.Net, I expect we will have far less distinction
in control types.

K, so if I have you convinced that you could probably do what you are
suggesting in a week, then let me try to convince you that you do not want
to do that.

We are in love with control arrays because the alternative in VB is so ****
ugly (forced on you in VBA, so well known to those of us who occasionally
cross that boundary in drag on dark nights). It is very easy right now to
cling to that mindset, which I think is out of date. The alternative in
VB.Net is elegant I think, because of the flexibility, and I think it is
important to abandon old mindsets. If you come back to it fine, but not out
of legacy thinking.

The biggest jumps are that in VB.Net arrays of controls, we can place a
control in multiple arrays and arrays can contain controls of multiple
types. Let's say I have a form with a series of frames or tabs, each frame
separately filled and saved. I want to know whether each frame is dirty.
There are a couple of ways to do this in VB6-, and I will leave thinking
through that to the reader. In VB.Net, it is easy to add a control reference
to one array to handle one set of events (change event to set the dirty flag
in my example) and another to handle another type of control such as
drag/drop. We really do not care whether the dirty item is a combo box or a
test box.

And, oh yes, the same control can be added to multiple event handlers. You
want to color bad data in date and numeric controls, and set a dirty flag in
a particular frame, and do something else all in the change event? Add it to
three different arrays. Confusing with a VB6- mindset, yes. No doubt. We
think of the control array as an unbustable unit that travels about
together. But if you think of it instead as a grouping _for a specific
purpose_ then the horizons just keep expanding.

This requires a couple of things. First, you have to associate your control
with the array. You suggest doing this through a property. I suggest that we
can do this through code with more clarity and flexibility. Either way the
job gets done. And once done, we have an array that can be iterated through
for all the purposes we have iterated through them in the past. I use the
phrase "array" loosely here. We can create a class that has additional
methods, such as loading and unloading, to make life simpler and help us
feel all cozy.

It also requires that each member of the array have event handlers added.
This is a single function call , or a method call to the wrapper mentioned
above, for each array/event pair. Yes we have to do this for each event we
wish to add. We definitely want to say "add this collection" rather than
"add this control" if the controls are logically grouped. But we have
control of how this is accomplished.

I have not explored macros enough to know whether autogenning the event code
fragment could be done, but there are a couple of reasons to consider not
autogenning (based on a double click). First, the signatures are now
predictable. We no longer need to (nor get the help from) having individual
parameters for event specific information. We just don't need it as much.
Second, they aren't cleaned up anymore.

To summarize, the event mechanism is one of the most exciting features of
VB.Net. I really don't want to do all this manually. I want as much help as
I can get or write for myself. _But_, I want to do that by establishing what
is appropriate to do with new designs, in the new paradigm/world, then going
back and seeing how to accomplish it easily. I do not want to bring forward
monolithic unbustable control arrays like we had in VB6- just because we
used to have them. It is my expectation that they are now out of date and a
similar, but more robust mechanism will take their place based on new best
practices, and the new opportunity. Hopefully we can discuss that more.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Mike Mitchell]

On Sun, 6 May 2001 07:45:50 -0600, "Kathleen Dollard-Joeris"
<kjoeris@noemailplease.com> wrote:

What is the bottom line under all this stuff about control arrays'
alternatives in VB.NET? The bottom line is: Control arrays are simple
to comprehend, are very easy to implement, and serve a purpose,
without which we would have countless uncoupled blobs of functionality
littering our apps. Like every good invention, control arrays work and
are used a lot because they are simple in concept and practice. And
every one in the VB.NET camp seems desperate to replicate them!

Everything you wrote in your response to Paul Mc, especially the bit
"...and I think it is important to abandon old mindsets...", tends to
remove this simplicity. You seem to be very keen to reinstate the
implementation of control arrays and want to find ways to achieve
their functionality in VB.NET. My response to that is: Why reinvent
the wheel when the wheel works very well as a wheel?

MM

[Kathleen Dollard-Joeris]

Mike,

> You seem to be very keen to reinstate the
> implementation of control arrays and want to find ways to achieve
> their functionality in VB.NET. My response to that is: Why reinvent
> the wheel when the wheel works very well as a wheel?

I want to see as common practice something that replaces control arrays.
Control arrays were very ugly and inflexible in many ways, and I do not
think it would move the language forward to reinstate them the way they
were. I want them better, and am confident that is also the goal of the
design team.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Phil Weber]

> You seem to be very keen to reinstate the implementation
> of control arrays and want to find ways to achieve their
> functionality in VB.NET. My response to that is: Why reinvent
> the wheel when the wheel works very well as a wheel?

Simple, Mike: Because you and I and Kathleen have no control over what
Microsoft decides to build into VB.NET. Rather than continually whine about
changes over which she has no control, Kathleen and others are moving on to
trying to find acceptable alternatives and solutions given the tools they
have available. I wish you would do the same.
---
Phil Weber

[Gregor R. Peisker]

Hi Kathleen,

I could not agree with you more than I do!

> We are in love with control arrays because the alternative in VB is so ****
> ugly (forced on you in VBA, so well known to those of us who occasionally
> cross that boundary in drag on dark nights). It is very easy right now to
> cling to that mindset, which I think is out of date. The alternative in
> VB.Net is elegant I think, because of the flexibility, and I think it is
> important to abandon old mindsets. If you come back to it fine, but not out
> of legacy thinking.

Yep. Classic VB was revolutionary in that one could click your form together; creating
forms didn't require intensive coding like in C. This was seen as an advantage (and
rightly so, in view of the alternatives available).

But classic VB's approach had a downside. Creating a user interface worked rather
differently from creating the rest of the application. The UI portion was separate from
the application code ("code behing forms"). To create a form, one *had* to use the mouse.

To point in question is code reuse. Let's apply a low standard here: just calling an
existing function amounts to code reuse. Sure, VB didn't support inheritance, but for the
point in question (user interface), this didn't make any difference. It was not possible
to have a sub like this:

Sub CreateButton(ByRef sText As String, ...)
' ...
End Sub

Of course, one could add controls at runtime using control arrays. But that required
creating a dummy control instance for every type of control desired. This was not only an
unneccessary overhead, it mandated that one know at design time about the type of the
controls.

But the worst problem was that this process had to be repeated for every form in every
form in every application. For menus, it was required that all entries in the control
array were in the same sub menu; so one dummy menu item was needed for every menu.

So while control arrays saved some work, they didn't solve the underlying problem. The
problem was that VB was VB only to some extend, and the rest of it was a development
program (VB6.exe) written in C++. One simply didn't write the UI in VB.

It was so much different with the code portion of an app. Even without inheritance (even
without the limited OO suppurt there was), one could write functions, put them in a
module, maybe even compile that into a DLL and reuse the binary.

But creating forms was a tedious process for every new form in every new project. If there
hadn't been control arrays, it just would have been even worse. But the point remained
that for every new app, one whacked out the "File" menu, the "Edit" menu, and what have
you. Every form that used a toolbar required opening the designer and dragging the control
on it. Over and over again. One could write some code to set a few properties (and reuse
that), but creating look-alike forms always required the many repeatitive steps.

..NET, on the other hand, opens up the world of code to UI programming. One can reuse UI
code. From scratch. This works like a charm by visual inheritance. And it's easy to write
a few functions for control creation as well. And the UI code has little to do with window
procedures and messages; there no real advantage from using the WinForms designer. If
there had been classes like those in the WinForms namespace all along, nobody would have
taken VB's UI capabilities seriously. We're just used to it, that's all.

But even with the WinForms designer, things are easy. There will be a list of events in
the properties window (according to the docs; this isn't implemented in Beta 1), similiar
to Delphi or VJ++. Hooking up events to a common handler requires typing the name (the
Name property will be back in Beta 2), and a few clicks. Names are much better at
identifying controls than an index; however, the MenuItem class, as the most important
example, has an Index property as well. I can really not see any increased difficulty
here.

Regards,
Gregor

[Mike Mitchell]

On Sun, 6 May 2001 10:16:30 -0600, "Kathleen Dollard-Joeris"
<kjoeris@noemailplease.com> wrote:

>I want to see as common practice something that replaces control arrays.
>Control arrays were very ugly and inflexible in many ways

What is ugly about a control array? I place one control on a form. I
place another control on a form. I have two separate controls, two
separate event handlers.

Instead, I place both controls on a form and given them a shared
identity, thus they share a single event handler and I have reduced my
coding requirements considerably, plus I have added to the readability
of the program. I can still treat each control separately, if I wish.
And I can add or remove further controls at run-time.

So, my question again: What is ugly about a control array? I see only
the beauty of a simple, purpose-driven design which has stood the test
of time over ten years of programming by millions of classic VB coders
without a squeak of complaint. Once again, you are desperate to fix
what ain't broke, which is the whole sorry tale of VB.Net.

MM

[Mike Mitchell]

On Sun, 6 May 2001 09:43:40 -0700, "Phil Weber" <pweber@devx.com>
wrote:

>Simple, Mike: Because you and I and Kathleen have no control over what
>Microsoft decides to build into VB.NET. Rather than continually whine about
>changes over which she has no control, Kathleen and others are moving on to
>trying to find acceptable alternatives and solutions given the tools they
>have available. I wish you would do the same.

Unlike you, Phil, I believe in pulling my head out of the sand if it
inadvertently got stuck there through uncontrolable .NET evangelism!

MM

[Mike Mitchell]

On Sun, 6 May 2001 19:38:27 +0200, "Gregor R. Peisker"
<gregor@peisker.de> wrote:

>But the worst problem was that this process had to be repeated for every form in every
>form in every application. For menus, it was required that all entries in the control
>array were in the same sub menu; so one dummy menu item was needed for every menu.
>
>So while control arrays saved some work, they didn't solve the underlying problem. The
>problem was that VB was VB only to some extend, and the rest of it was a development
>program (VB6.exe) written in C++. One simply didn't write the UI in VB.
>
>It was so much different with the code portion of an app. Even without inheritance (even
>without the limited OO suppurt there was), one could write functions, put them in a
>module, maybe even compile that into a DLL and reuse the binary.

It is apparent to me that you have not exploited the use of add-ins to
expedite your boilerplate needs. Microsoft provided the excellent
extensibility model for VB5 and VB6, and it does allow you to automate
practically anything. For example, one of my add-ins includes a
'clone' command. I highlight a control (or even a number of multiply
selected controls, including nested controls) and click 'clone'. Then
I select a different form, maybe in another project and click 'paste',
and bingo, the control(s) *and* any code behind them are replicated in
the target form.

>But creating forms was a tedious process for every new form in every new project. If there
>hadn't been control arrays, it just would have been even worse. But the point remained
>that for every new app, one whacked out the "File" menu, the "Edit" menu, and what have
>you. Every form that used a toolbar required opening the designer and dragging the control
>on it. Over and over again. One could write some code to set a few properties (and reuse
>that), but creating look-alike forms always required the many repeatitive steps.

I cannot believe that more users have, apparently, not made use of the
powerful add-in feature. I just assumed that EVERYone coded like that.
No wonder you're all crying out for new features if you found using
classic VB so long-winded. But the tools were there all along to
customise your usage of VB any which way you liked. Just like the
seats in your car can be adjusted for height and position...(don't ALL
rush out now!)

MM ("My code re-use is a reality I know you'd like!")

[DeGojs]

Mike, I've just found these 2 examples somewhere:
------------------------------------
#1:

Public Sub Button_Click(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click

Select Case sender
Case Button1
MsgBox("button 1")
Case Button2
MsgBox("button 2")
Case Else
End Select

End Sub
----------------------------------
#2:

You can use the AddHandler to add an eventhandler to a control, even to a
control declared WITHOUT the WithEvents keyword :

' Withouth WithEvents!
Protected btnTest As System.WinForms.Button

' Put this line for example in the constructor (Sub New())...
AddHandler btnTest.Click, New System.EventHandler(AddressOf
MyThirdEventHandler)

Public Sub MyThirdEventHandler(ByVal sender As Object, ByVal e As
System.EventArgs)
End Sub

[Gregor R. Peisker]

Hi Mike,

> It is apparent to me that you have not exploited the use of add-ins to
> expedite your boilerplate needs. Microsoft provided the excellent
> extensibility model for VB5 and VB6, and it does allow you to automate
> practically anything. For example, one of my add-ins includes a
> 'clone' command. I highlight a control (or even a number of multiply
> selected controls, including nested controls) and click 'clone'. Then
> I select a different form, maybe in another project and click 'paste',
> and bingo, the control(s) *and* any code behind them are replicated in
> the target form.

It seems like you've done an excellent job of duplicating/automating clipboard
functionality (OK, your approach saves a few clicks ...)

> I cannot believe that more users have, apparently, not made use of the
> powerful add-in feature. I just assumed that EVERYone coded like that.

Well, I do use a few Add-Ins. However, duplicating code or forms language has some obvious
problems that even functional programming can solve, IMO.

> No wonder you're all crying out for new features if you found using
> classic VB so long-winded. But the tools were there all along to
> customise your usage of VB any which way you liked. Just like the
> seats in your car can be adjusted for height and position...(don't ALL
> rush out now!)

I'm not very good at analogies, so let's see:

If I adjust the position of the seat in my car, it should still the same seat (I don't
paste in a new seat). Ah, no, you don't mean that, do you? It's more like this: the car's
windshield wipers don't work, but by adjusting the seat's height, I can comfortably put my
head through the sun roof and see the road nevertheless?

> MM ("My code re-use is a reality I know you'd like!")

Oh, I like the clipboard.

Regards,
Gregor

[Mike Mitchell]

On Sun, 6 May 2001 22:27:39 +0200, "Gregor R. Peisker"
<gregor@peisker.de> wrote:

>It seems like you've done an excellent job of duplicating/automating clipboard
>functionality (OK, your approach saves a few clicks ...)

No, you didn't read carefully enough! I said it replicates the
controls AND the code behind. I don't think the clipboard does that!
Mind you, the clipboard is still handy, because that's what I'm using
as a scratch pad to store the controls and code behind (as separate
stages) until it's time to paste them.

What about an add-in that I use to create a new project? Yes, I know
the VB IDE allows me to do that, but I have customised my add-ins to
allow me to create a new project with x number of forms and y number
of modules (haven't got around to something similar for classes yet -
I wonder why!)

>I'm not very good at analogies, so let's see:
>
>If I adjust the position of the seat in my car, it should still the same seat (I don't
>paste in a new seat). Ah, no, you don't mean that, do you? It's more like this: the car's
>windshield wipers don't work, but by adjusting the seat's height, I can comfortably put my
>head through the sun roof and see the road nevertheless?

No, my point was: Find out about what the manufacturer gives you for
free before asking for extras.

MM

[Paul Mc]

G'Day Kathleen.

Totally agree with you re the advantages of (what I'll call) the "delegation
model" over classic VB control arrays. My point is that classic arrays, while
less flexible/powerfull, were a metter of two properties; Name, and Index.
It was realatively inflexible - but it sure was fast and easy to do! Aside:
Sound like any programming language you know? "8-)

The reason that I didn't post that into the technical group was that it was
not really a serious proposal of what should be done, - I jsut wanted to
incite some better ideas - They probably would not be too hard to come up
with! I was hoping that something constructive may result....

Cheers,
Paul

[Gregor R. Peisker]

Hi Mike,

> >It seems like you've done an excellent job of duplicating/automating clipboard
> >functionality (OK, your approach saves a few clicks ...)
>
> No, you didn't read carefully enough! I said it replicates the
> controls AND the code behind. I don't think the clipboard does that!
> Mind you, the clipboard is still handy, because that's what I'm using
> as a scratch pad to store the controls and code behind (as separate
> stages) until it's time to paste them.

That's how I understood it: copy & paste the controls, copy & paste the event handlers
(and/or other code), by selecting the controls on the form. But you're really only saving
a few clicks. And you end up with duplicate code.

> No, my point was: Find out about what the manufacturer gives you for
> free before asking for extras.

Oh, I'm not asking anymore - I got what I wanted :-)

But it seems you keep missing the point. I don't want to cut & paste, even if it's
automated by Add-Ins or templates. I want to use *identical* classes, not just cloned
classes, for several projects.

Regards,
Gregor

[Kathleen Dollard-Joeris]

Gregor,

> But classic VB's approach had a downside. Creating a user interface worked
rather
> differently from creating the rest of the application. The UI portion was
separate from
> the application code ("code behing forms"). To create a form, one *had* to
use the mouse.
>
> To point in question is code reuse. Let's apply a low standard here: just
calling an
> existing function amounts to code reuse. Sure, VB didn't support
inheritance, but for the
> point in question (user interface), this didn't make any difference. It
was not possible
> to have a sub like this:

Interesting points that go beyond control arrays. I agree that VB6- did not
support form reuse. We worked around it, but there was effort, generally at
design time adjusting forms to look the same, even if we did it almost
without thinking.

Hopefully we will have the best of both worlds with VB.Net.

>And the UI code has little to do with window
> procedures and messages; there no real advantage from using the WinForms
designer. If
> there had been classes like those in the WinForms namespace all along,
nobody would have
> taken VB's UI capabilities seriously. We're just used to it, that's all.

"No real advantage from using the WinForms designer"?? Are you exaggerating
or do you really see no advantage? I think that drag and drop visual
development is still the best thing going in the programming world (have
created enough forms manually in my life. Add to that the resizing and
inheritance capabilities of VB.net and you have a far more powerful
mechanism for Windows development than we have had before.

> I can really not see any increased difficulty
> here.

I am waiting to see what MS provides in terms of tools for grouping
controls. But the worst case is what we have now. IMO, this is acceptable
because the tradeoff of a few extra lines of code for a lot of extra
functionality is good.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--