> 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