SPONSORS:






User Tag List

Results 1 to 7 of 7
  1. #1
    Member
    Join Date
    Dec 1999
    Location
    Portland, OR, USA
    Posts
    91
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    fails to close confirmation window

    When trying to close from MS Word97 with an unsaved document , a dialog box pops up.

    Silk Test (v 5.0.3) by default should close it by hitting the N button.

    Sometimes this works, sometimes it does not, hence sometimes results in the message "cannot close window".

    Why is this occurring ?
    Quality Control Analyst at Syntel Inc
    Project Test Lead for client Daimler Trucks - North America.
    Interested in testing dot net web services and SOA systems.
    Charles F. Radley
    Oregon, USA.

  2. #2
    Senior Member
    Join Date
    Mar 2000
    Location
    pisctaway, NJ USA
    Posts
    188
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: fails to close confirmation window

    Probably timing...ie., Word is "closing", then the confirm dialog is appearing. When you have these issues, overide the Close() method for the window and close with a menu pick followed by a if theConfirmBox.Exists(3)
    and close it appropriatly. Or in the testcase dont say word.Close(), close like I mentioned above.

    Anthony

  3. #3
    Member
    Join Date
    Dec 1999
    Location
    Portland, OR, USA
    Posts
    91
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: fails to close confirmation window

    [QUOTE]Originally posted by Pontoriero:
    [B]Probably timing...ie., Word is "closing", then the confirm dialog is appearing. When you have these issues, overide the Close() method for the window and close with a menu pick followed by a if theConfirmBox.Exists(3)
    and close it appropriatly. Or in the testcase dont say word.Close(), close like I mentioned above.
    =================================

    Ouch, that will not work for us. True, it works for this one specific instance. But I need a general solution, to cover UNEXPECTED boxes, which happen a lot in testing.

    The confirm box should not even be there, there is some kind of bug causing it to happen and hang the macine. I need to simply log the fact there was an unexpected window (which did not really matter), dismiss it, and move on to the next test case.

    I cannot always predict when what boxes will appear, so I cannot write code to close them. It is preferable that the Silk command work as documented.
    Quality Control Analyst at Syntel Inc
    Project Test Lead for client Daimler Trucks - North America.
    Interested in testing dot net web services and SOA systems.
    Charles F. Radley
    Oregon, USA.

  4. #4
    AJ
    AJ is offline
    Moderator AJ's Avatar
    Join Date
    Jun 1999
    Location
    San Jose, CA
    Posts
    1,691
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: fails to close confirmation window

    For unexpected boxes use DeclaredMessageBox.SetTrap("ButtonToClick")

    ------------------
    AJ Alhait
    BetaSoft Inc.
    AJ Alhait
    BetaSoft Inc.

  5. #5
    Super Member
    Join Date
    Jul 1999
    Location
    Rancho Santa Margarita, CA
    Posts
    1,439
    Post Thanks / Like
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)

    Re: fails to close confirmation window

    I agree with Craig. SetTrap slows things down and it does not seem to work well in a while...loop (how do you branch out of the loop when the trap is executed?)...

  6. #6
    Member
    Join Date
    Dec 1999
    Location
    Portland, OR, USA
    Posts
    91
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: fails to close confirmation window

    Hi,

    Thanks for the replies here. It is a shame we have to write our own handlers, but there does not seem to be much alternative.

    I have found another variation of the problem:

    window.closewindows() gets confused. When exiting a powerpoint document, soemtimes two child windows appear. One child window is masking the other child so is not enabled; closewindows tries to close the masked child first, it throws and exception and exits ! You would think it would close the enabled children first, but looks like it is not that intelligent.

    Quality Control Analyst at Syntel Inc
    Project Test Lead for client Daimler Trucks - North America.
    Interested in testing dot net web services and SOA systems.
    Charles F. Radley
    Oregon, USA.

  7. #7
    Junior Member
    Join Date
    Dec 1999
    Location
    San Mateo, CA, USA
    Posts
    17
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: fails to close confirmation window

    I disagree with the "SetTrap" approach. For one thing, it seems to take a great deal of memory, and slows down execution quite a bit. Also, you can only set one trap at a time without this problem being exacerbated to the point of distraction.

    What I did was to make a standardized handler, then overrode the default classes to use this handler to check for errors after every Click() and Pick() event.

    This has allowed my to define expected messages as well as unexpected messages in a generalized way, and has simplified conditions in testcases as well as improved robustness of execution. I have defined the handler to allow specification of handling functions to be optionally specified for recognized messages, which has simplified many testing problems.

    For instance, my browser application under test has a feature that pops up a message box whenever a form is browsed away from that has information on it that wasn't submitted. The handler always logs that it found this box, then accepts it whenever it is found in a script. If I am specifically testing for this box, that's still OK because the event returns the identifier of the message box so if I want to verify that it was there at the given point then I can, but I don't have to. Either way, it's no additional effort on my part.

    Also, if you are testing browser pages, some significant unexpected messages are not MessageBoxes, but content on the browser page. When you make your own handler, you can define entire lists of potential error type thingys to search for and acct according to. It's simply a more flexible approach than SetTrap.

    There is a performance hit, but much less than what I observed with SetTrap, and execution seems to be more stable. Oh, and I almost forgot... another benefit is that SetTrap is handled like an exception, if you override and include your own handler, it is handled however you want it to be handled.
    Craig Koozer
    Lead Test Automation Engineer
    www.oraclesmallbusiness.com

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 10:37 AM.

Copyright BetaSoft Inc.