dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 4 123 ... LastLast
Results 1 to 15 of 59

Thread: Bad programming practice? Advice needed ...

  1. #1
    Shannon Guest

    Bad programming practice? Advice needed ...


    As my current app builds in size I have noticed that I put many housecleaning
    chores beneath the command button that backs out of a current form. For
    example, an exit button might contain code to hide and unload the form, as
    well as code clearing and unloading variable and object arrays pertaining
    to the departing form, or what have you. Is this bad programming practice
    to put this stuff beneath the command button? Should I be writing most of
    it into the form.unload (or another) procedure, then just initiate the unload
    with the command button?

    Trying not to develop bad habits early on. Any input or advice from experienced
    programmers is greatly appreciated.

  2. #2
    FrisbeeŽ, MCP Guest

    Re: Bad programming practice? Advice needed ...

    "Shannon" <se_eckert@hotmail.com> wrote in message
    news:3c941fe3$1@10.1.10.29...
    >
    > As my current app builds in size I have noticed that I put many

    housecleaning
    > chores beneath the command button that backs out of a current form. For
    > example, an exit button might contain code to hide and unload the form, as
    > well as code clearing and unloading variable and object arrays pertaining
    > to the departing form, or what have you. Is this bad programming practice
    > to put this stuff beneath the command button? Should I be writing most of
    > it into the form.unload (or another) procedure, then just initiate the

    unload
    > with the command button?


    You're on the right track. Clean-up does indeed need to be done, but don't
    put it in the command button's click event, place it in the form's unload
    event, as you suspected.

    The reason for this is that while you intend for your users to close the
    form using the command button, they might use the "X" title bar button of
    the form, or the system might terminate the program (for a shut-down).
    Placing the code in the form's unload event ensures that your clean-up
    executes if the form is being closed by other methods. It's also good
    programming practise to place code in the queryunload event to allow a user
    to save changes or abort the unload, should they attempt to close the form
    while unsaved data exists on the form, for example.


    --
    Bill Hileman, MCP, CPP, BCIP
    Programmer/Analyst, DASI

    Yahoo! Club for Certaholics
    http://clubs.yahoo.com/clubs/certaholics

    Computer Language Comparison
    http://www.boneville.net/programming/default.htm




  3. #3
    Michael Culley Guest

    Re: Bad programming practice? Advice needed ...

    > Should I be writing most of
    > it into the form.unload (or another) procedure, then just initiate the

    unload
    > with the command button?


    Yes, the code is better in the form_unload than in cmdCancel_Click. This is
    because it will run if the user clicks then little cross in the rop right,
    clicks cancel or pushes ctrl-F4. Generally the only code I have in
    cmdCancel_Click is "Unload Me".

    The convention I use is that any code that might cause the form to not
    unload should go in form_queryunload. eg:

    Sub Form_QueryUnload
    Select case MsgBox ("do you want to save")
    case vbCancel
    cancel=true
    etc....

    Any form I put in form unload then I assume that the form will definately
    unload, ie I never cancel a form_unload.

    --
    Michael Culley
    www.vbdotcom.com



  4. #4
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    >>
    It's also goodprogramming practise to place code in the queryunload event to
    allow a user to save changes or abort the unload, should they attempt to
    close the form while unsaved data exists on the form, for example.
    <<

    True, but it is not good design. :-)


    --
    Anthony Jones
    Nuesoft Ltd



  5. #5
    Michael Culley Guest

    Re: Bad programming practice? Advice needed ...

    Why is this not good design?

    --
    Michael Culley
    www.vbdotcom.com


    "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote in message
    news:3c9497e5@10.1.10.29...
    > >>

    > It's also goodprogramming practise to place code in the queryunload event

    to
    > allow a user to save changes or abort the unload, should they attempt to
    > close the form while unsaved data exists on the form, for example.
    > <<
    >
    > True, but it is not good design. :-)
    >
    >
    > --
    > Anthony Jones
    > Nuesoft Ltd
    >
    >




  6. #6
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    Users very rarely make changes they don't intend to keep. Better design is
    to assume that closing causes the changes to be saved. Even better design
    is to hide the techicalities of RAM (volatile) and Disk (non-volatile)
    storage altogether.

    Of course you will have to give the users the ability to abandon changes
    made so far in the current session and at least the changes made in the
    previous session as well.

    For more info read Alan Coopers books on UI design. However be prepared for
    some serious chagrin. He is right but it hurts.

    --
    Anthony Jones
    Nuesoft Ltd



  7. #7
    Michael Culley Guest

    Re: Bad programming practice? Advice needed ...

    Ok, I thought you meant it was a bad programming practice as opposed to a
    bad UI design practice.

    > Better design is
    > to assume that closing causes the changes to be saved.


    I'm not sure I like this. Quite often when I really screw things up I push
    the little cross and push 'NO'. If an app saved my changes at the point I
    wouldn't be too pleased.

    --
    Michael Culley
    www.vbdotcom.com




  8. #8
    Mark Alexander Bertenshaw Guest

    Re: Bad programming practice? Advice needed ...

    > "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote in message
    > news:3c9497e5@10.1.10.29...
    > > >>

    > > It's also goodprogramming practise to place code in the queryunload

    event
    > to
    > > allow a user to save changes or abort the unload, should they attempt to
    > > close the form while unsaved data exists on the form, for example.
    > > <<
    > >
    > > True, but it is not good design. :-)


    "Michael Culley" <m_culley@hotmail.com> wrote in message
    news:3c94c41a@10.1.10.29...
    > Why is this not good design?


    Michael -

    One good argument about not using the QueryUnload event is that most of the
    time the event would be in response to a deliberate effort to close the
    form, so why should we have to ask them whether they really want to close
    the form? Instead, you the programmer should make a judgement call. If the
    user closes the form now, will there be any unfortunate effects -such as
    losing the state of the form. If no - then fine. If yes, then is there a
    possibility that the state might be invalid i.e. some compulsory fields are
    not filled. If no, then just go and save the state. If yes, then create a
    mechanism to simply store the invalid state in a special "invalid" location,
    so that when the user reopens the form, the form is repopulated. I have
    often thought that it is really frustrating when you are told that you
    cannot save if the data is "invalid". If I can type crap into my Word
    document, why can't I do the same in a database type application?

    As in all things - it depends. My example is one in which opening the form
    is not a very taxing occurence - maximum 4 seconds. Of course, if it took a
    long time for the form to load, then the user would be very pleased to get a
    warning message. Then again - perhaps your design is flawed if it takes
    such a long time (no comments about combo boxes please, Anthony :-) ).

    --
    Mark Alexander Bertenshaw
    Programmer/Analyst
    Chordiant Software, Inc.
    Brentford
    UK



  9. #9
    Jeff Pipes Guest

    Re: Bad programming practice? Advice needed ...


    This sounds terrible. I find annoying when programs assume that they know
    what I'm thinking. Now that you mention it, it isn't just annoying, it's
    dangerous. Can you imagine a web page that automatically places your order
    without you clicking submit? Anyone who closes their browser or clicks the
    back button gets charged anyway?

    -Jeff

    "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote:
    >Users very rarely make changes they don't intend to keep. Better design

    is
    >to assume that closing causes the changes to be saved. Even better design
    >is to hide the techicalities of RAM (volatile) and Disk (non-volatile)
    >storage altogether.
    >
    >Of course you will have to give the users the ability to abandon changes
    >made so far in the current session and at least the changes made in the
    >previous session as well.
    >
    >For more info read Alan Coopers books on UI design. However be prepared

    for
    >some serious chagrin. He is right but it hurts.
    >
    >--
    >Anthony Jones
    >Nuesoft Ltd
    >
    >



  10. #10
    Bob Butler Guest

    Re: Bad programming practice? Advice needed ...


    "Jeff Pipes" <JeffP622@msn.com> wrote in message
    news:3c953c1f$1@10.1.10.29...
    >
    > This sounds terrible. I find annoying when programs assume that they know
    > what I'm thinking.


    It's also annoying when programs continually question the user. Do you want
    to save? Do you want to exit? .... If I didn't want to I wouldn't have
    clicked the *^%^&%&^ button!

    > Now that you mention it, it isn't just annoying, it's
    > dangerous. Can you imagine a web page that automatically places your order
    > without you clicking submit? Anyone who closes their browser or clicks the
    > back button gets charged anyway?


    Obviously any one approach is inappropriate for some situations. In the
    case where the user is going to be charged there needs to be a very obvious
    confirmation and not an automatic processing. On the other hand I don't
    want to click "Confim Order" and be prompted "are you sure you want to
    proceed" when I just made a positive action to move ahead.

    I've done a few apps where the form simply saves if the user clicks the X
    and in many cases it feels very natural to the user. Most expect the
    computer to remember whatever they typed in. Of course, there's an easily
    accessed "abandon changes" option that let's the user back out when they
    want to.

    In some situations a prompt is the best way to go - any time the action is
    irreversible. There just aren't that many cases where that's really the
    case.




  11. #11
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    Yeah, well that is the way _you_ but are you sure that's the way your
    _customer_ sees it.

    Self-referential design, 'I know what I would prefer', isn't necessarily
    going to win the approval of your users.

    Also, as I said, you wouldn't just save without giving the users the tools
    to recover from unwanted changes. However, you wouldn't make such tools
    apart of the normal flow of interaction since normally they do want to keep
    their changes.

    --
    Anthony Jones
    Nuesoft Ltd



  12. #12
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    I find Amazon One-Click ordering no problem at all. I can go back and
    cancel the order if I wish. Most of the time I don't unintentionally order
    something.

    BTW, Brower based UI has the excuse that it's ability to deliver interaction
    is steeped in the dark ages of batch based processing. So may be you're
    right there. Let's just not kid ourselves into thinking that this is good
    design.

    --
    Anthony Jones
    Nuesoft Ltd



  13. #13
    Anthony Jones Guest

    Re: Bad programming practice? Advice needed ...

    >>
    create a
    mechanism to simply store the invalid state in a special "invalid" location,
    so that when the user reopens the form, the form is repopulated. I have
    often thought that it is really frustrating when you are told that you
    cannot save if the data is "invalid". If I can type crap into my Word
    document, why can't I do the same in a database type application?
    <<

    I have been giving this some thought recently myself. It would be the next
    logical step. There are some barriers to break down before this can happen.
    I'm pretty sure that it wouldn't be appropriate in all situations e.g.,
    mutliple users sharing data.

    Often the DB schema reflects rules that are enforced by the business
    objects. E.g., 'Name can only be 50 characters long'. With latest hardware
    such arbitary limits are probably unreasonable. We could do one of two
    things with such rules. We could abandon the rule altogether or we could
    have the business object highlight it yet allow it to be saved to the
    database with an appropriate status.

    Another barrier is how to keep the appropriate users informed of the
    existance of invalid/incomplete data and allowing them to navigate easily to
    it.

    We will need to evolve our UIs one step at a time toward the Users mental
    model. There are only so many things _we_ can unlearn at a time. :-)

    Enough with Combo-boxes already. :-D

    --
    Anthony Jones
    Nuesoft Ltd



  14. #14
    Michael Culley Guest

    Re: Bad programming practice? Advice needed ...

    > Yeah, well that is the way _you_ but are you sure that's the way your
    > _customer_ sees it.


    Not just me, pretty much every user is used to a form asking them if they
    would like to save changes. It really is the standard behaviour. I can
    guarantee that if I changed this behaviour I would get more complaints than
    I would gain happy customers.

    Providing some mechanism to reverse their changes would be complicated. Most
    likely they would not notice for a few days and have to go back through some
    sort of 'autosave history' to undo their changes. You expect me to write
    code to keep this history for hundreds of possible different forms? This is
    really going to make them much happier than having to push yes or no to a
    messagebox.

    --
    Michael Culley
    www.vbdotcom.com




  15. #15
    Michael Culley Guest

    Re: Bad programming practice? Advice needed ...

    > If I can type crap into my Word
    > document, why can't I do the same in a database type application?


    Mark,

    I agree that this would be good but I don't think it would really be worth
    the trouble. I've always got a stack of user requests coming in faster than
    I will ever be able to add them (I think the pile will never get smaller).
    To add this feature ahead of some other highly useful feature wouldn't be
    the best idea.

    --
    Michael Culley
    www.vbdotcom.com


    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
    news:3c95048e@10.1.10.29...
    > > "Anthony Jones" <anthony.jones@nonuesoft.spamco.uk> wrote in message
    > > news:3c9497e5@10.1.10.29...
    > > > >>
    > > > It's also goodprogramming practise to place code in the queryunload

    > event
    > > to
    > > > allow a user to save changes or abort the unload, should they attempt

    to
    > > > close the form while unsaved data exists on the form, for example.
    > > > <<
    > > >
    > > > True, but it is not good design. :-)

    >
    > "Michael Culley" <m_culley@hotmail.com> wrote in message
    > news:3c94c41a@10.1.10.29...
    > > Why is this not good design?

    >
    > Michael -
    >
    > One good argument about not using the QueryUnload event is that most of

    the
    > time the event would be in response to a deliberate effort to close the
    > form, so why should we have to ask them whether they really want to close
    > the form? Instead, you the programmer should make a judgement call. If

    the
    > user closes the form now, will there be any unfortunate effects -such as
    > losing the state of the form. If no - then fine. If yes, then is there a
    > possibility that the state might be invalid i.e. some compulsory fields

    are
    > not filled. If no, then just go and save the state. If yes, then create

    a
    > mechanism to simply store the invalid state in a special "invalid"

    location,
    > so that when the user reopens the form, the form is repopulated. I have
    > often thought that it is really frustrating when you are told that you
    > cannot save if the data is "invalid". If I can type crap into my Word
    > document, why can't I do the same in a database type application?
    >
    > As in all things - it depends. My example is one in which opening the

    form
    > is not a very taxing occurence - maximum 4 seconds. Of course, if it took

    a
    > long time for the form to load, then the user would be very pleased to get

    a
    > warning message. Then again - perhaps your design is flawed if it takes
    > such a long time (no comments about combo boxes please, Anthony :-) ).
    >
    > --
    > Mark Alexander Bertenshaw
    > Programmer/Analyst
    > Chordiant Software, Inc.
    > Brentford
    > UK
    >
    >




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