Rumors for beta 2 - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 25 FirstFirst 1234513 ... LastLast
Results 31 to 45 of 362

Thread: Rumors for beta 2

  1. #31
    Jacob Grass Guest

    Re: Rumors for beta 2

    <affix palm to forehead>
    You're right. . . .I wasn't thinking clearly. . . . That is just like the
    visible property in VB6 and the visible property is present in VB.NET.

    Jacob


    "Phil Weber" <pweber@devx.com> wrote in message
    news:3aba3b47@news.devx.com...
    > > An alternative solution to a Form_Load event in .Net (I think)
    > > would be a boolean property Form.IsShown. This would be True
    > > whenever the form is visible on the screen and false otherwise.

    >
    > Jacob: How is this different from the .Visible property in VB6? Is the
    > .Visible property gone in VB.NET?
    > ---
    > Phil Weber
    >
    >




  2. #32
    Rob Teixeira Guest

    Re: Rumors for beta 2


    Maybe I'm being a bit dim here (as well as not having followed the thread
    too closely), but here's the way I see things:

    There are several events to consider
    1) new instance created
    2) composition fully initialized
    3) show(ing/n)
    4) hid(ing/den)
    5) activated
    6) deactivated
    7) clos(ing/ed)
    8) instance destroyed

    VB6's Form_Load conformed to both steps #1 and #2. However, it had nothing
    to do with the actual visibility of the form (as it should be).
    VB.NET's form constructor can also be used as #1 and #2. You actually have
    much greater control because you can differenciate between #1 and #2, which
    you could not do VB6.

    There has never been an event to handle #3, even though I've always thought
    it to be vitally important! You had to "CLUDGE" a show event in VB6 with
    some funky code in the Activate event.
    In VB.NET, you can inherit form and override the Show method to raise such
    an event, but I would prefer if it was already there. Apparently that is
    what they are going to add, though I would prefer that it not be called "Load",
    because that is not what it is.

    Again, there has never been an event to handle #4.
    Ditto on the .NET implementation as the previous comment.

    Both versions of VB handle #5 and #6. This corresponds to when the form receives
    focus or has its focus taken away. Another highly desirable and useful event,
    even though it didn't work as expected in VB6 (the event would not fire if
    a *different* app took the focus away for example).

    #7 and #8 are somewhat confusing because there was no real way to tell them
    apart in VB6. When you closed a form, the instance also "disappeared", and
    form instances worked slightly different than normal objects anyway. In VB.NET,
    there are events to support #7, but without DF there is no way to find #8,
    unless you override Dispose.

    One final note: it would be useful to have an OnMove event!

    -Rob


    Craig Powers <enigma@hal-pc.org> wrote:
    >Bob Butler wrote:
    >>
    >> "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
    >> news:3ab935fa.265518835@news.devx.com...
    >> >
    >> > Craig Powers wrote:
    >> >
    >> > >Isn't the pre-.net form_load more like the .net "New" than the .net
    >> > >"form_load"?
    >> >
    >> > No, the constructor (New) only runs once, when the instance is
    >> > created. Similar to the Initialize event in VB6.
    >> >
    >> > VB6's Load, on the other hand, runs every time a Form is loaded, which
    >> > can occur more than once.

    >
    >Yes, but this is still before the form is displayed. VB6 doesn't
    >really have anything corresponding to the .Net Form_Load, AFAIK.
    >
    >As I use forms in VB6, there's little practical difference between
    >creating a form instance (.Net New) and loading it (VB6 Form_Load).
    >My understanding of forms in VB6 (which could be mistaken) is that
    >a form instance behaves rather like an object dim'ed As New, where
    >any reference to one that hasn't been loaded loads it immediately.
    >
    >> Is the .Net Form_Load behavior public yet? My assumption is that it's
    >> simply called immediately after the constructor runs and if that is not

    the
    >> case then I'm curious what triggers it.

    >
    >To quote the post from Sam Spencer of Microsoft, to which I was
    >replying:
    >> On the contrary there is a subtle difference between New and when the
    >> form_load is called. New is called when an instance of the form is
    >> created. The form_load event is fired when the form is actually shown.



  3. #33
    Rob Teixeira Guest

    Re: Rumors for beta 2


    I agree with both your statements, however...

    The visible property states *IF* the form is visible or not. It does not
    help you determine *WHEN* to check for visibility.
    You cannot check for visibility in the constructor as that is pointless.
    Ther is no other event that clearly tells you when the form is shown.
    But again, I don't see what this has to do with "Load". To me, "Load" means
    what occurs in the constructor. See my previous post for more details.

    -Rob

    "Jacob Grass" <JGrass@abilitisolutions.com> wrote:
    ><affix palm to forehead>
    >You're right. . . .I wasn't thinking clearly. . . . That is just like the
    >visible property in VB6 and the visible property is present in VB.NET.
    >
    >Jacob
    >
    >
    >"Phil Weber" <pweber@devx.com> wrote in message
    >news:3aba3b47@news.devx.com...
    >> > An alternative solution to a Form_Load event in .Net (I think)
    >> > would be a boolean property Form.IsShown. This would be True
    >> > whenever the form is visible on the screen and false otherwise.

    >>
    >> Jacob: How is this different from the .Visible property in VB6? Is the
    >> .Visible property gone in VB.NET?
    >> ---
    >> Phil Weber
    >>
    >>

    >
    >



  4. #34
    Bob Butler Guest

    Re: Rumors for beta 2


    "Jonathan Allen" <greywolf@cts.com> wrote in message
    news:3aba5c4d@news.devx.com...
    > I think the problem is that practically everyone thinks this is a problem.
    > Unfortunately, that means there is no controversy, and thus no long

    running
    > arguments. Which means MS doesn't see how important it really is.


    OK, then I think it's good that you can't tell why a form is closing! <g>

    Does the sender object in the close event give you any information? I've
    seen a couple of posts in various places that imply that you can determine
    why based on the sender's identity. I just haven't had time to play with it
    yet...




  5. #35
    Bob Butler Guest

    Re: Rumors for beta 2


    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3aba4730$1@news.devx.com...
    <cut>
    > 1) new instance created
    > 2) composition fully initialized

    <cut>
    > 7) clos(ing/ed)
    > 8) instance destroyed

    <cut>
    > much greater control because you can differenciate between #1 and #2,

    which
    > you could not do VB6.


    Form_Initialize vs Form_Load ?

    <cut>
    > #7 and #8 are somewhat confusing because there was no real way to tell

    them
    > apart in VB6.


    Form_QueryUnload, Form_Unload vs Form_Terminate ?





  6. #36
    Jacob Grass Guest

    Re: Rumors for beta 2

    > Does the sender object in the close event give you any information? I've
    > seen a couple of posts in various places that imply that you can determine
    > why based on the sender's identity. I just haven't had time to play with

    it
    > yet...


    The Closing event is the only what that supports cancelling and there is no
    sender object with this event. The Closed event also does not have a sender
    object and occurs after the form has been closed. I can only think of a
    kludgy way to handle this problem:

    Create a class-level boolean. Set the value to true if the user uses your
    provided methods for closing (e.g. Menu, Button, etc.). Then, test the
    value in the closing event. If it is your method, then continue. If not,
    then throw the Message Box, and continue accordingly.

    It would be nice is there were another way though. . . .

    Jacob



  7. #37
    Bob Butler Guest

    Re: Rumors for beta 2


    "Jacob Grass" <JGrass@abilitisolutions.com> wrote in message
    news:3aba6a7a$1@news.devx.com...
    > > Does the sender object in the close event give you any information?

    I've
    > > seen a couple of posts in various places that imply that you can

    determine
    > > why based on the sender's identity. I just haven't had time to play

    with
    > it
    > > yet...

    >
    > The Closing event is the only what that supports cancelling and there is

    no
    > sender object with this event. The Closed event also does not have a

    sender
    > object and occurs after the form has been closed. I can only think of a
    > kludgy way to handle this problem:
    >


    ??

    Public Sub Form1_Closing(ByVal sender As Object, ByVal e As
    System.ComponentModel.CancelEventArgs) Handles Form1.Closing
    messagebox(Me.Handle, sender.gettype.name, "Closing", 1)
    End Sub

    Public Sub Form1_Closed(ByVal sender As Object, ByVal e As System.EventArgs)
    Handles Form1.Closed
    messagebox(Me.Handle, sender.gettype.name, "Closed", 1)
    End Sub




  8. #38
    Jonathan Allen Guest

    Re: Rumors for beta 2

    > Does the sender object in the close event give you any information?

    Sometimes it is enough, but not often. For instance, it can not determine
    wither Close was generated by a cancel button on the form or by the control
    box.

    --
    Jonathan Allen


    "Bob Butler" <butlerbob@earthlink.net> wrote in message
    news:3aba63c5@news.devx.com...
    >
    > "Jonathan Allen" <greywolf@cts.com> wrote in message
    > news:3aba5c4d@news.devx.com...
    > > I think the problem is that practically everyone thinks this is a

    problem.
    > > Unfortunately, that means there is no controversy, and thus no long

    > running
    > > arguments. Which means MS doesn't see how important it really is.

    >
    > OK, then I think it's good that you can't tell why a form is closing! <g>
    >
    > Does the sender object in the close event give you any information? I've
    > seen a couple of posts in various places that imply that you can determine
    > why based on the sender's identity. I just haven't had time to play with

    it
    > yet...
    >
    >
    >




  9. #39
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Rumors for beta 2

    "Jacob Grass" <JGrass@abilitisolutions.com> wrote in message <news:3aba6a7a$1@news.devx.com>...

    > Create a class-level boolean. Set the value to true if the user uses your
    > provided methods for closing (e.g. Menu, Button, etc.). Then, test the
    > value in the closing event. If it is your method, then continue. If not,
    > then throw the Message Box, and continue accordingly.


    I may be overly sensitive to certain shutdown issues due to California's
    ongoing "rolling blackouts", but what will happen during some sort of
    unattended shutdown, perhaps fired off by a power management program? If
    nothing else, maybe you could set a timeout on the message box? Even in
    an interactive application, the user might step away, end up stuck in an
    elevator when the lights go out, and still be stuck as the workstation's
    UPS hits the two/five minute mark.

    --
    Joe Foster <mailto:jfoster@ricochet.net> Sacrament R2.45 <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  10. #40
    Jacob Grass Guest

    Re: Rumors for beta 2

    > ??
    >
    > Public Sub Form1_Closing(ByVal sender As Object, ByVal e As
    > System.ComponentModel.CancelEventArgs) Handles Form1.Closing
    > messagebox(Me.Handle, sender.gettype.name, "Closing", 1)
    > End Sub
    >
    > Public Sub Form1_Closed(ByVal sender As Object, ByVal e As

    System.EventArgs)
    > Handles Form1.Closed
    > messagebox(Me.Handle, sender.gettype.name, "Closed", 1)
    > End Sub
    >
    >


    'Raises the Closing Event
    Overridable Protected Sub OnClosing(ByVal e As CancelEventArgs)

    Public Event Closing As CancelEventHandler

    'Raises the Closed Event
    Overridable Protected Sub OnClosed(ByVal e As EventArgs)

    Public Event Closed As EventHandler


    At least, those are the events I have been using. . . . I didn't know about
    the ones you list. . .

    Jacob



  11. #41
    Jacob Grass Guest

    Re: Rumors for beta 2

    >
    > I may be overly sensitive to certain shutdown issues due to California's
    > ongoing "rolling blackouts", but what will happen during some sort of
    > unattended shutdown, perhaps fired off by a power management program? If
    > nothing else, maybe you could set a timeout on the message box? Even in
    > an interactive application, the user might step away, end up stuck in an
    > elevator when the lights go out, and still be stuck as the workstation's
    > UPS hits the two/five minute mark.
    >


    I didn't say it was the perfect solution. . . : )

    Jacob



  12. #42
    Rob Teixeira Guest

    Re: Rumors for beta 2


    inline...

    "Bob Butler" <butlerbob@earthlink.net> wrote:
    >
    >"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    >news:3aba4730$1@news.devx.com...
    ><cut>
    >> 1) new instance created
    >> 2) composition fully initialized

    ><cut>
    >> 7) clos(ing/ed)
    >> 8) instance destroyed

    ><cut>
    >> much greater control because you can differenciate between #1 and #2,

    >which
    >> you could not do VB6.

    >
    >Form_Initialize vs Form_Load ?


    Sort of, but not really. In VB6, the Initialize event occurs before the Load
    event, but there's little actual difference between the two. The composition
    (the form object and all its sub-objects) are already initialized during
    the Initialize event, which makes it more like #2 and not #1. Note that you
    can do the following :

    Private Sub Form_Initialize()
    Debug.Print Me.Command1.Caption
    End Sub

    and it is perfectly valid. #1 implies that Command 1 has not yet been created.


    ><cut>
    >> #7 and #8 are somewhat confusing because there was no real way to tell

    >them
    >> apart in VB6.

    >
    >Form_QueryUnload, Form_Unload vs Form_Terminate ?
    >


    Again, from a programming perspective in VB6 there's very little difference
    between Closing a form and terminating the form object. You could also say
    the reverse - meaning that Form1 is *always* available, and the unload inconsistantly
    closes the form and doesn't really unload it.
    Either way, the only difference between QueryUnload, Unload, and Terminate,
    are the parameters which allow you to verify the cause of the unload, and/or
    cancel it. QueryUnload has both, Unload can cancel, and Terminate has neither.
    Other than that, they function almost identically.

    Terminate is useful if you create NEW instances of a form, where closing
    the form actually terminates the object as well - in which case the only
    difference again is the parameters (and the order in which the events fire).
    If you rely on the global reference to a form (such as Form1), then the terminate
    event happens only when the application closes, and you have more of a distinction.

    In .NET, these concepts are more consistant. There is a noticable distinction
    between close and dispose (or finalize if you prefer).

    -Rob

  13. #43
    Bob Butler Guest

    Re: Rumors for beta 2


    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3aba74bc$1@news.devx.com...
    <cut>
    > Sort of, but not really. In VB6, the Initialize event occurs before the

    Load
    > event, but there's little actual difference between the two. The

    composition
    > (the form object and all its sub-objects) are already initialized during
    > the Initialize event, which makes it more like #2 and not #1. Note that

    you
    > can do the following :
    >
    > Private Sub Form_Initialize()
    > Debug.Print Me.Command1.Caption
    > End Sub
    >
    > and it is perfectly valid. #1 implies that Command 1 has not yet been

    created.

    Not really... when Form_Initialize fires the module-level variables and the
    code have been loaded but the GUI and components have not. If you reference
    them, as in your example, they will be loaded and Form_Load will fire so if
    you step through your code you'd see Form_Initialize fire and then Form_Load
    fire and run and then Form_Initialize finish. By referencing the GUI
    elements you are forcing it to happen out of the normal order.

    > ><cut>
    > >> #7 and #8 are somewhat confusing because there was no real way to tell

    > >them
    > >> apart in VB6.

    > >
    > >Form_QueryUnload, Form_Unload vs Form_Terminate ?
    > >

    >
    > Again, from a programming perspective in VB6 there's very little

    difference
    > between Closing a form and terminating the form object. You could also say
    > the reverse - meaning that Form1 is *always* available, and the unload

    inconsistantly
    > closes the form and doesn't really unload it.
    > Either way, the only difference between QueryUnload, Unload, and

    Terminate,
    > are the parameters which allow you to verify the cause of the unload,

    and/or
    > cancel it. QueryUnload has both, Unload can cancel, and Terminate has

    neither.
    > Other than that, they function almost identically.


    Again, I disagree. Form_Unload signals that the GUI and the controls are
    being unloaded. Form_Terminate only fires if you have released the last
    reference to the form and corresponds to something like "Set Form1=Nothing".
    If you are not holding references to the forms apart from the forms
    collection then your description is right but VB6 does allow you to
    distinguish the different events pretty finely and that distinction can be
    very useful.




  14. #44
    Bob Butler Guest

    Re: Rumors for beta 2


    "Jonathan Allen" <greywolf@cts.com> wrote in message
    news:3aba7313@news.devx.com...
    > > Does the sender object in the close event give you any information?

    >
    > Sometimes it is enough, but not often. For instance, it can not determine
    > wither Close was generated by a cancel button on the form or by the

    control
    > box.


    Yep, I did some quick tests and it looks like when the events fire the
    sender is always the form. Worse, the events don't always fire (e.g.
    closing an MDI does not generate the events on chilk forms and shutting down
    the system doesn't generate them at all). This is a BIG problem imo. I
    hope there's another way to get the information reliably.




  15. #45
    Rob Teixeira Guest

    Re: Rumors for beta 2


    "Bob Butler" <butlerbob@earthlink.net> wrote:
    >
    >Not really... when Form_Initialize fires the module-level variables and

    the
    >code have been loaded but the GUI and components have not.


    [snip]

    True enough, you got me there.
    I'm starting to think too much in C# in Java, and seeing constructor patterns.
    With all the new OO changes, and all the middle-tier technology I've been
    working on, it's dawned on me that I'm beginning to forget some of the simple
    VB form basics
    I wonder if that's a bad thing...

    >Again, I disagree. Form_Unload signals that the GUI and the controls are
    >being unloaded. Form_Terminate only fires if you have released the last
    >reference to the form and corresponds to something like "Set Form1=Nothing".
    >If you are not holding references to the forms apart from the forms
    >collection then your description is right but VB6 does allow you to
    >distinguish the different events pretty finely and that distinction can

    be
    >very useful.


    Here I think we're saying the same thing, just in different ways. I agree
    with everything you just said. It's just that in VB6, it's most often the
    case that global form references are never set to nothing. With instances
    of New forms, the unloading often also destroys the object (because you rarely
    hold the reference elsewhere). Also, I've been told that as an optimization,
    form instance data is deleted, but the functions never are until the program's
    termination. I'm not sure how true that is. At any rate, the big difference
    once again is that in VB.NET, to catch that the form object has terminated,
    and must rely on the Dispose or Finalize.

    But before I get waaaaaaay off topic on these two cases - the real point
    I was trying to make in the original post, which I probably didn't across
    too clear, is that there are events that may or may not be consistant in
    VB.NET and VB6, but do in fact provide useful information. Unfortunately,
    the reverse is also true. There are things that happen to a form that do
    not have corresponding events either in VB6 or .Net, or both. These are the
    things I want to bring to everyone's attention. Specifically things like
    a Form's Show(ing/n) event (which again, I hope is NOT called Load).

    -Rob

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