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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 16

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

  1. #1
    Paul Mc Guest

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



    > 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









  2. #2
    Kathleen Dollard-Joeris Guest

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

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



  3. #3
    Mike Mitchell Guest

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

    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

  4. #4
    Kathleen Dollard-Joeris Guest

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

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



  5. #5
    Phil Weber Guest

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

    > 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



  6. #6
    Gregor R. Peisker Guest

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

    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














  7. #7
    Mike Mitchell Guest

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

    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

  8. #8
    Mike Mitchell Guest

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

    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

  9. #9
    Mike Mitchell Guest

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

    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!")

  10. #10
    DeGojs Guest

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


    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



  11. #11
    Gregor R. Peisker Guest

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

    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





  12. #12
    Mike Mitchell Guest

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

    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

  13. #13
    Paul Mc Guest

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


    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

  14. #14
    Gregor R. Peisker Guest

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

    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



  15. #15
    Kathleen Dollard-Joeris Guest

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

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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center