SPONSORS:






User Tag List

Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Start()-method

  1. #1
    Member
    Join Date
    Jan 2002
    Location
    Nuremberg, Germany
    Posts
    77
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Start()-method

    Hi everybody,

    maybe my problem is too app-specific but let's try:

    Up to now, I was starting a NewApp (C/S, NT) within a testcase by picking a menu item from a FirstApp. Today I changed the script (because the FirstApp containing the menu isn't necessary any more) and launched NewApp directly by using the start()-method:

    sCmdLine = "<Path> NewApp.exe <Parameters>"
    NewWin.Start(sCmdLine)

    This works fine except for the fact that starting NewApp now takes MUCH longer (a timer around the Start command gave me 2.5 seconds including a long wait even AFTER NewWin has appeared which means NewApp is running!) than having started it via FirstApp's menu! Technically the same command line is performed in both cases but it seems that SilkTest needs much longer to recognize(?) or initialize(?) NewApp when using the start() method.

    I also tried several variations on sExtensionReady & nInvokeTimeout without getting a better result. Is it possible that this phenomenon comes from setting sCmdLine at runtime & not having a sCmdLine variable in the declaration of NewWin anymore?

    Or any other ideas? Thanks for your help!

  2. #2
    Senior Member
    Join Date
    Aug 1999
    Location
    Cambridge, UK
    Posts
    470
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    Is this definitely a phenomenon which only occurs when NewApp is invoked by a silktest script? What I mean is, do you not get the same difference in start-up times if you perform the same steps manually?

    ------------------

  3. #3
    Member
    Join Date
    Jan 2002
    Location
    Nuremberg, Germany
    Posts
    77
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    Oops - something vanished from my sCmdLine (a bracket problem?). In full length it reads:

    sCmdLine = "(PATH) NewApp.exe (PARAMETERS)"

    Hope this will appear now.

  4. #4
    Member
    Join Date
    Jan 2002
    Location
    Nuremberg, Germany
    Posts
    77
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by vincebowdren:
    Is this definitely a phenomenon which only occurs when NewApp is invoked by a silktest script? What I mean is, do you not get the same difference in start-up times if you perform the same steps manually?
    <HR></BLOCKQUOTE>

    Thanks for your reply, Vince. Yes, this is definitively different from starting NewApp manually. To be more exact: If I perform the same steps
    - start NewApp
    - (SetActive)
    - Click on a NewApp-button
    manually and via script, then there is absolutely no delay in the manual version, i.e. NewApp's window isn't hanging around for 2 seconds before I can perform the Click (unlike the script).


  5. #5
    Senior Member
    Join Date
    Feb 2000
    Posts
    1,497
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    The delay is inside Start() - a builtin method. Consider submitting this to Segue as a problem; see what they say about it.

    In the mean time, if a one-second save would be useful, replace Start() with a Start/Run routine through NT. (10 loops at 15 seconds using Notepad as an example app').

    I suspect that the delay is historical - once needed in an earlier version, but no longer required.

    John


    ------------------

  6. #6
    Senior Member
    Join Date
    Aug 1999
    Location
    Cambridge, UK
    Posts
    470
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    As well as the sCmdLine variable, it might be worth checking the values of the other relevant variables in your mainwin declaration - sdir, bextensionReady and nInvokeTimeout - to see if they could make a difference.

    ------------------

  7. #7
    Member
    Join Date
    Jan 2002
    Location
    Nuremberg, Germany
    Posts
    77
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    Thanks for all your helpful hints & remarks.

    John: I'll contact Segue & if anything useful returns, I'll post it here. A "one-second save" would be valuable indeed, but I'll keep your suggestion in mind for emergencies.

    Vince: I already tried manipulating these variables without any success.

    ljagelsk: That sounds interesting - I'll try this today.

  8. #8
    Junior Member
    Join Date
    Jan 2002
    Location
    Santa Clara, Ca. USA
    Posts
    22
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    Included in your silktest directory is bwcompat.inc - a backwards compatibility with ver 1.0 file. it contains App_Start :
    [ ] builtin APPID APP_Start (STRING sCmdLine)
    If you include bwcompat.inc with a use stmt you can try this to see if it's any faster.

    ------------------

  9. #9
    Member
    Join Date
    Jan 2002
    Location
    Nuremberg, Germany
    Posts
    77
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    Here's the promised update (Segue's support took quite a while to deal with this issue):

    The delay really comes from within Start(): "The Start() method searches the PATH system variable as part of it's internal operation, which may be what is causing the slow performance." Man, still they hang on to this "may be" statement - even after 3 weeks of mailing.

    Now they suggest using SYS_Execute() instead, which I tried before without getting satisfactory results. What was new to me - and what I have to check out - is the following info: "For example: SYS_Execute("freecell.exe") starts freecell in an invisible window ((!)) and SilkTest does not continue until the freecell process is terminated. On the other hand, SYS_Execute("start freecell.exe") starts freecell in a visible window, and still SilkTest does not continue until the process is terminated."

    They seemed to realize that this is probably no solution for me, too, and added a variant using the windows API & ShellExecute(); if anyone is interested in details, I'll post them here.

    Thanks again for your input,
    cb


    ------------------

  10. #10
    Member
    Join Date
    Jan 2002
    Location
    Nuremberg, Germany
    Posts
    77
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Start()-method

    The end of it all: Segue's dll suggestion didn't solve my problem either, and now I'm using a method described by David Genrich in forum 002635.html.

    Keep rockin',
    cb

 

 
Page 1 of 2 12 LastLast

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 07:27 PM.

Copyright BetaSoft Inc.