dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 3 FirstFirst 123
Results 31 to 42 of 42

Thread: Using the Call statement

  1. #31
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Using the Call statement

    "Michael Culley" <mike@vbdotcom.com> wrote in message <news:3c224e5d@147.208.176.211>...

    > I don't totally disagree with what you say, I think they can be over used.
    > But I give standard behaviour alot of weight and I think in this situation
    > the standard behaviour would be to show a messagebox. Anything else has the
    > big potential to confuse the user.


    Many users don't even read messageboxes and instead just click on the
    first button they see. They don't look at status bars, either.

    --
    Joe Foster <mailto:jlfoster%40znet.com> 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!



  2. #32
    Michael Culley Guest

    Re: Using the Call statement

    Doesn't matter, they have acknowledged that something happened, it might
    give them a clue at least. Beside, thats not really the point. The point is
    that they are more likely to miss a status bar message.

    --
    Michael Culley
    www.vbdotcom.com


    "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
    news:3c227803@147.208.176.211...
    > "Michael Culley" <mike@vbdotcom.com> wrote in message

    <news:3c224e5d@147.208.176.211>...
    >
    > > I don't totally disagree with what you say, I think they can be over

    used.
    > > But I give standard behaviour alot of weight and I think in this

    situation
    > > the standard behaviour would be to show a messagebox. Anything else has

    the
    > > big potential to confuse the user.

    >
    > Many users don't even read messageboxes and instead just click on the
    > first button they see. They don't look at status bars, either.
    >
    > --
    > Joe Foster <mailto:jlfoster%40znet.com> 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!
    >
    >




  3. #33
    Jim Pragit Guest

    Re: Using the Call statement


    Hi Anthony,

    Data validation is performed upon submit.

    - Jim

    "Anthony Jones" <yadayadayada@msn.com> wrote:
    >>>

    >For example, the user clicks the OK or Save button
    >on a form and the program displays a MsgBox because there's a data
    >validation
    >error that prevents the data from being saved.
    ><<
    >
    >Why would the OK or Save button be available when the user can't use them!
    >
    >--
    >Anthony Jones
    >Nuesoft Ltd
    >
    >
    >



  4. #34
    Anthony Jones Guest

    Re: Using the Call statement

    >>
    For example, the user clicks the OK or Save button
    on a form and the program displays a MsgBox because there's a data
    validation
    error that prevents the data from being saved.
    <<

    Why would the OK or Save button be available when the user can't use them!

    --
    Anthony Jones
    Nuesoft Ltd




  5. #35
    Anthony Jones Guest

    Re: Using the Call statement

    >>
    But I give standard behaviour alot of weight and I think in this situation
    the standard behaviour would be to show a messagebox.
    <<

    Of course that assumes that your users are expecting standard behaviour, if
    they do fine. Most of our users will be first timers. Also many
    'standards' are a product of the capabilities of the languages and machines
    of the past. If more compute power had been available when the 'standards'
    where established would they be the same.

    Fundamentally question is, I am using a message box for my own convenience
    or is it indeed the most friendly way to give users what they need? As
    this thread demonstrates there a zillion factors that go in to answering
    that question.


    --
    Anthony Jones
    Nuesoft Ltd




  6. #36
    Anthony Jones Guest

    Re: Using the Call statement

    Quite often we hear (including this thread) 'I like this' and 'I don't like
    that' but frankly who cares what we like, it's what our users will like
    that counts. It's clear from this thread that different things work for
    different types of users in different circumstances.

    --
    Anthony Jones
    Nuesoft Ltd




  7. #37
    Anthony Jones Guest

    Re: Using the Call statement

    >Data validation is performed upon submit.

    I see. There is probably a good _techinical_ reason for that, right? Is
    there any _business_ reason why validation couldn't be done more
    dynamically?

    "He reached out and pressed an invitingly large red button on a nearby
    panel. The panel lit up with the words 'Please do not press this button
    again.'"
    -- Douglas Adams


    --
    Anthony Jones
    Nuesoft Ltd




  8. #38
    Alex Guest

    Re: Using the Call statement



    Don't you think that this discussion is very similar to 'goto statement'
    discussions?

    There are various technics to accomplish the same task. There are also many
    factors to be considered for each particular task.

    I don't think each technic should be used instead of the other. Sometimes
    it is simplier and less expensive (in terms of development cost) to put message
    box, sometimes application functionality dictates the use of other ways to
    give feedback to user


    Alex

    "Anthony Jones" <yadayadayada@msn.com> wrote:
    >>Data validation is performed upon submit.

    >
    >I see. There is probably a good _techinical_ reason for that, right? Is
    >there any _business_ reason why validation couldn't be done more
    >dynamically?
    >
    >"He reached out and pressed an invitingly large red button on a nearby
    >panel. The panel lit up with the words 'Please do not press this button
    >again.'"
    > -- Douglas Adams
    >
    >
    >--
    >Anthony Jones
    >Nuesoft Ltd
    >
    >
    >



  9. #39
    Jim Pragit Guest

    Re: Using the Call statement


    Hi Anthony,

    With all due respect, I really don't feel like getting into a debate on data
    validation. I've studied this topic extensively and I could easily write
    a few articles about it. The short version is there is no reliable, maintainable,
    performant way to do data validation on the fly in VB6. The Validate event,
    for example, is too buggy and IMHO is not suitable for data validation.
    LostFocus events are worse. You could try to do data validation on each
    KeyPress, Click and Change event but do you really want data validation spread
    across (or at least being called from) a few dozen events on each form?
    Maintainabilty is as valid a concern as any other.

    There's also the issue of *where* to display error messages. Obviously,
    you don't want to pop up a MsgBox while the user is inputting data (although
    I've seem programs that do this). One possibility is to include a list box
    or grid somewhere on the form that lists error messages. The VS.NET IDE
    uses this technique. But this creates another dilemma in terms of screen
    real estate. I've seen users complain their monitor is too small, but never
    too big. Do you really want to take up valuable screen real estate with
    a grid just to display data validation error messages? The VS.NET IDE attempts
    to solve this by making its TaskList window resizable. But even the VS.NET
    IDE resorts to using a message box to tell you compilation errors were found
    when you press F5. So, you can combine approaches.

    Another alternative is to use ToolTips to display error messages such as
    .NET's ErrorProvider control. The problem with this is that the user may
    not know that they have to hover their mouse over a control to find out what's
    wrong. Also, not all computers have mice.

    Also, I'm not sure that the indirect approach is the best. Imagine this
    real life scenario. Let's say you go to McDonald's and order a combo meal
    which costs $5.95. But you only hand the cashier a $5 bill.

    As the customer, would you prefer:

    a) The cashier politely tell you that that your meal is $5.95 and they'll
    need another 95 cents.
    b) The cash register display a 'Not enough money' message while the cashier
    stares at you blankly waiting for you to read the message on cash register.

    Or perhaps you would want both? Well, like I said, I could easily write
    an article about the pro's and con's of each approach and even then, different
    users will prefer different UIs. As they say, your mileage may vary.

    - Jim

    >I see. There is probably a good _techinical_ reason for that, right? Is
    >there any _business_ reason why validation couldn't be done more
    >dynamically?
    >
    >"He reached out and pressed an invitingly large red button on a nearby
    >panel. The panel lit up with the words 'Please do not press this button
    >again.'"
    > -- Douglas Adams
    >
    >
    >--
    >Anthony Jones
    >Nuesoft Ltd



  10. #40
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Using the Call statement

    "Anthony Jones" <yadayadayada@msn.com> wrote in message <news:3c2359c6@147.208.176.211>...

    > >Data validation is performed upon submit.

    >
    > I see. There is probably a good _techinical_ reason for that, right? Is
    > there any _business_ reason why validation couldn't be done more
    > dynamically?


    Yes -- the user might change the Control Panel / Regional Settings right
    before hitting the submit button... The beeyootiful SHINY button! The
    jolly CANDY-LIKE button! Will he hold out, folks? CAN he hold out?

    http://ourworld.cs.com/WeezelX/rs/madness.html

    --
    Joe Foster <mailto:jlfoster%40znet.com> Wanna buy a Bridge? <http://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!



  11. #41
    Willy Van den Driessche Guest

    Re: Using the Call statement

    We consistently show a grid of messages at the bottom of detail screens.
    The grid is sorted on severity of the messages (serious errors, errors,
    warnings, hints) so that the user can see at any time what problems there
    are in the detail screen. In addition to that, the error is shown with a
    little icon next the faulty editor. The icon reflects the seriousness of
    the error. For cross-checks it is put on the editor that is "most" probably
    wrong. Hovering over the error icon show a multiline tooltip with all the
    messages for the particular editor.
    Since validation is really what our application is about, we try to show the
    user all errors without really pushing her in one direction. When a screen
    is partially filled our comboboxes are split in two parts. The first part
    show values that could be a valid continuation of the current values on the
    screen, the second part shows values that conflict with the current
    (partial) values.
    Our screen performs a "request for validation" upon each change (or click or
    whatever is applicable for the editor) event. This request starts a timer.
    If another validation is requested before the timer fires, the timer is
    reset to prevent the validation process to interact with the user
    manipulations. 2 seconds seems like a very good mean value. Upon LostFocus
    of an editor, an immediate validation is performed.
    Errors and serious errors cause the ok button to be disabled. Since timing
    can be important, the OKbutton_click performs an additional validation. If
    any errors have been found there, they are shown in a messagebox.

    Our users definitively love it. They can make any error they want as long
    as the entire screen is correct at the end of the session. Usability
    studies have pointed out that will just start filling the form. When an
    icon appears next to an editor they will go and have a look at what is wrong
    and correct it early on. Since the screens are complex they really feel
    like they are being taken by the hand to fill in the screen. We now have a
    different product in the same product line with more data entry but much
    less complex business logic. Even there the first response of the users is
    they very much appreciate a direct non-intrusive response.

    --
    Van den Driessche Willy
    For a work in progress :
    http://users.skynet.be/wvdd2/index.html

    Part of this is described at :
    http://users.skynet.be/wvdd2/PseudoP...ors/editors_an
    d_selectors.html
    and
    http://users.skynet.be/wvdd2/PseudoP...tion/brokenrul
    es_validation.html
    (unfortunately it is not yet complete)



  12. #42
    James Barbetti Guest

    Re: Using the Call statement


    Hi Ken, Eric, et.al

    >> So, my question is. Is my colleague correct? Can not assigning
    >> the result cause problems?


    Well, actually, yes. For some API calls.

    1.
    Some API functions set a return code indicating whether they have
    succeeded or not. Such return codes should be checked. Otherwise, you
    may make one okay call, followed by a second call that assumes the
    first call did something it didn't. This *can* cause a GPF.
    But the fault isn't "not assigning" the return code. It's
    "not examining" it. If the API function indicates success or failure
    via its return code, check it. Do not just assume it worked. That's
    asking for a GPF.

    2.
    Also, some API functions return allocated items (pointers to allocated
    memory, handles, or object references), which should always be freed up.
    Usually the documentation for the API function will state what these are.
    Read the doco for the API call (if you have it!).

    >Absolutely NOT.. smack him around a bit for adding confusion to a
    >simple case of "I don't care what the result is.. so don't store it"...


    It's quite possible that what he was saying was, in general, you
    *should* care about the result of the function call. Because it
    mightn't work and it may use the return code to tell you.
    I wouldn't smack him around, I'd ask him to clarify.

    >There's an intermediate buffer that stores the result..


    ...Or the eax register (wintel)...

    >that will be transferred to your variable if you want.. nothing
    >requires this... it's the same as calling a function in your VB
    >program.


    Pretty much.
    If you've got no use for the return code; or no way of handling an error
    return (say on a deallocation call at the end of *your* function...),
    then you do not risk a GPF by ignoring it. You can illustrate this
    by running the example code under the C++ debugger, with DebugBreak()
    API calls in front of each the example calls. The difference between

    retCode = APIFunction(...)
    and
    Call APIFunction(...)

    is pretty minor. Often it's just a difference of a

    movd dword ptr[ebp-?], eax

    in the assignment version (store the return code somewhere).
    That isn't going to make or break your program!

    Assigning the return code into a variable can be useful for debugging
    purposes. And if you plan to do something *about* the return code,
    (if say it indicates there's an error) it's also a plus. But whether
    or not you assign the return code of an API call to a variable usually
    won't make much of a difference, *by itself*. Assigning it won't even
    slow down your program measurably.

    Hope this helps,
    James

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