SPONSORS:






User Tag List

Results 1 to 7 of 7
  1. #1
    Senior Member
    Join Date
    Jul 1999
    Location
    Bellingham, WA USA
    Posts
    1,323
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Variables give different behavior than hard coded???

    I have declarations for LandingPage. In this we find several dozen nested menuitems that are HtmlText.

    What is the appreciable difference between:

    LandingPage.MicrosoftHealthcareMenuItem.Click()

    and

    wBasePage.sMenuItem.Click()

    when

    wBasePage = LandingPage
    and
    sMenuItem = MicrosoftHealthcareMenuItem.

    On the latter, I get an error telling me that sMenuItem is not a member of LandingPage. What this tells me is that it is attempting to see that variable literally rather than what it represents. Yet, it debug, the variable is correct. Hard coding this works beautifully.

    What am I missing here?

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

  2. #2
    Senior Member
    Join Date
    Jul 2000
    Posts
    117
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Variables give different behavior than hard coded???

    Just a SWAG ... but is the 'trick' the fact that wBasePage is probably declared as type WINDOW and sMenuItem is declared as type STRING?

    Would it work differently if sMenuItem were declared as a WINDOW, too?

    I just suspect that in your example you would need something along the lines of wBasePage.{sMenuItem}.Click() or worse, the dreaded indirection of wBasePage.@(sMenuItem).Click(), to make it do what you expect ...

    I've spent NO time looking at this so apologize if I'm smokin' something ... it's just an off the cuff observation.


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

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Location
    Des Moines, Iowa
    Posts
    289
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Variables give different behavior than hard coded???

    I do something similar, I won't bore you with the details but, You will have to declare the whole object path in the one window variable.

    (Example)
    ------------------

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

    Re: Variables give different behavior than hard coded???

    Silk uses the variable literally - as part of its concatenation process to create a fully qualified tag. The variable appears to be correct but because it is of type string rather than a variable of type window it won't compile. Note that:

    wBasePage.@(sMenuItem).Click()

    will compile but won't work either even though the contents of variable sItem are now of type window. The reason for this is that the original assignment of the window 'Open' to the string variable results in sMenuItem containing the entire fully qualified tag. In essense the tag has an unnecessary, duplicated parent. To fix it use:

    @(sMenuItem).Click()

    instead. To retain an obvious source-code reference to the parent wBasePage you can 'cast' the variable to a window type using a dynamic tag. The call would look like this:

    wBasePage.MenuItem(sMenuItem).Click()

    Nifty stuff huh?

    John



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

  5. #5
    Senior Member
    Join Date
    Jul 2000
    Posts
    117
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Variables give different behavior than hard coded???

    Makes sense to me!

    Next time I'll try to spend some time before I SWAG it ... sorry for the potential red herring.


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

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

    Re: Variables give different behavior than hard coded???

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Brent Rolland:

    ... sorry for the potential red herring.
    <HR></BLOCKQUOTE>

    Not necessary in my view. I was oh soooo tempted to answer the question last night (without Silk to prove my assertions) but didn't after writing at least 3 different responses. The statement:

    sMenuItem = MicrosoftHealthcareMenuItem

    stopped me because it just had to be wrong - Silk doesn't support that kind of implied cast.


    John


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

  7. #7
    Senior Member
    Join Date
    Jul 1999
    Location
    Bellingham, WA USA
    Posts
    1,323
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Variables give different behavior than hard coded???

    Brent, no need for the apology! I appreciate any and all feedback. (And don't be smokin' that stuff anyway... )

    John,

    You are a gentleman and a scholar. Your solution works beautifully and I've learned something new about Silk as a bonus!

    Thanks all.

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

 

 

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:38 AM.

Copyright BetaSoft Inc.