ui stat monitor and vars across scripts

[sj7272 0]

Still new at this, but I'm trying to organise my bots into multiple scripts and using run parameters.

Trouble is, I'm setting (non local) vars in my master script, and running other scripts for my processing loops and the passed vars won't refresh the ui stat fields. The loops are functioning, and I've tried with the stat monitor declaration in both master and loop scripts. In the latter, I can see the ui updating, but only if I click on the loop script.

 

Is there a good way to implement this monitoring via ui stat across scripts?

[Super Dave 26]

The way I build my bots is in functionalized library files like you're talking about. Each of the routines in there accepts parameters and returns a status. If everything goes according to plan that status is SUCCESS any errors are returned instead.

 

Consider your master script is calling a sub that navigates to a page and you want to monitor that the page loaded without errors (like your proxy died or the page no longer has the target element you want, etc)

 

set #monitor = return value (sub navigate HTTP://????)

if #monitor CONTAINS SUCESS

do something cool

else

evaluate #monitor and log errors

 

Does this makes sense?

[sj7272 0]

The way I build my bots is in functionalized library files like you're talking about. Each of the routines in there accepts parameters and returns a status. If everything goes according to plan that status is SUCCESS any errors are returned instead.

 

Consider your master script is calling a sub that navigates to a page and you want to monitor that the page loaded without errors (like your proxy died or the page no longer has the target element you want, etc)

 

set #monitor = return value (sub navigate HTTP://????)

if #monitor CONTAINS SUCESS

do something cool

else

evaluate #monitor and log errors

 

Does this makes sense?

 

Yes, this does - but what if the sub in the child script increments counters or pages, and I want to view these status fields in the ui??

If I put the ui stat in the sub, then it does update, but only if that tab/script has focus i.e. not from the master. If I don't change focus from the master, nada!

[IRobot 43]

Yes, this does - but what if the sub in the child script increments counters or pages, and I want to view these status fields in the ui

Then have the sub return a status value or a 'FAIL' to the parent script.

[sj7272 0]

Then have the sub return a status value or a 'FAIL' to the parent script.

 

Sorry, I meant that the counter would be incremented INSIDE a loop within the child script.

I don't think it would work, and even that it should work - black boxes being black boxes etc.

 

But imagine the "lets create some email accounts" scenario

 

you might set up a "num. accounts to generate" ui text box and variable, but these would be in your master script...

You may then run a child script or a sub in the child script, passing the #num-accs as a parameter

In the child script, you would...

 

set #localcount to 0

while #localcount < #num-accs

nav to sign up page

create $account

fill the fields

hit create button

ui-stat #localcount

ui-stat $email

end-loop

 

forgive the syntax - still a noob, but I think it's ok

 

Unless in the execution, I could change the active tab/script, I can't see how I could achieve the intention of watching the ui change.

 

I would add that this is all with uncompiled bots, I'm not sure if that changes anything.

 

I've not really played with "include" yet but am just trying to work out "best practices" as early as poss.

[Super Dave 26]

Sorry, I meant that the counter would be incremented INSIDE a loop within the child script.

I don't think it would work, and even that it should work - black boxes being black boxes etc.

 

But imagine the "lets create some email accounts" scenario

 

you might set up a "num. accounts to generate" ui text box and variable, but these would be in your master script...

You may then run a child script or a sub in the child script, passing the #num-accs as a parameter

In the child script, you would...

 

set #localcount to 0

while #localcount < #num-accs

nav to sign up page

create $account

fill the fields

hit create button

ui-stat #localcount

ui-stat $email

end-loop

 

forgive the syntax - still a noob, but I think it's ok

 

Unless in the execution, I could change the active tab/script, I can't see how I could achieve the intention of watching the ui change.

 

I would add that this is all with uncompiled bots, I'm not sure if that changes anything.

 

I've not really played with "include" yet but am just trying to work out "best practices" as early as poss.

 

 

I'm a little confused by your example but I think I can walk you through this.. think of each of your subs as a one-time-only routine with a status at the end. So, "sub CreateAccount" will take parameters like desired name, password, email, etc and make one account. At the end of the signup process there's a token you can search for to conclude the account has been created, as in "if searchpage(Account Created!)". If at the end of the whole process I can't find that token I will then search for reasons that token isn't there "Username too long" "password needs to be XXXX" whatever. Do your research into reasons things fail and code cases for them (or do a pagetext dump and examine it later but that's another topic). Here's how it all comes together...

 

set #acct-created = 0
set #acct-limit = 5
while #acct-create < #acct-limit
 set #acct-status = return value(sub CreateAccount)
 if #acct-status = SUCCESS
   inc #acct-created
   change proxy, timer, etc
 else
   Do something with the errors listed in #acct-status and might 
   want to count the number of errors you encounter. Add it into 
   the while statement so if you hit a certain # of errors the bot
   stops so you can review and adjust
end while

sub CreateAccount
 param name

 nav http/account.creation.page
 if searchPage("Create New Account")
   if chooseByAttribute "name"
     change chosen attribute value = #name
   else
     return "ERROR TARGETING NAME FIELD"
   [Rest of the account creation stuff, submit, waitFinish]
   if searchPage "Account Created!"
     return "SUCCESS"  
 else
   RETURN "ERROR LOADING CREATE PAGE"
end sub

[sj7272 0]

I'm a little confused by your example but I think I can walk you through this.. think of each of your subs as a one-time-only routine with a status at the end. So, "sub CreateAccount" will take parameters like desired name, password, email, etc and make one account. At the end of the signup process there's a token you can search for to conclude the account has been created, as in "if searchpage(Account Created!)". If at the end of the whole process I can't find that token I will then search for reasons that token isn't there "Username too long" "password needs to be XXXX" whatever. Do your research into reasons things fail and code cases for them (or do a pagetext dump and examine it later but that's another topic). Here's how it all comes together...

 

set #acct-created = 0
set #acct-limit = 5
while #acct-create < #acct-limit
 set #acct-status = return value(sub CreateAccount)
 if #acct-status = SUCCESS
   inc #acct-created
   change proxy, timer, etc
 else
   Do something with the errors listed in #acct-status and might 
   want to count the number of errors you encounter. Add it into 
   the while statement so if you hit a certain # of errors the bot
   stops so you can review and adjust
end while

sub CreateAccount
 param name

 nav http/account.creation.page
 if searchPage("Create New Account")
   if chooseByAttribute "name"
     change chosen attribute value = #name
   else
     return "ERROR TARGETING NAME FIELD"
   [Rest of the account creation stuff, submit, waitFinish]
   if searchPage "Account Created!"
     return "SUCCESS"  
 else
   RETURN "ERROR LOADING CREATE PAGE"
end sub

 

I appreciate your effort , the above is safely copy/pasted - but my question is more about handling ui-stat-monitor variables (and any others) across scripts.

 

In my testing, it seems that the ui is bound to a single script, so with one ui area, monitoring variables DURING execution of another script seems to not be possible.

 

So imagine a master script with a ui, for example, setting the number of accounts to create...

Then it does a "run script" passing MaxAccounts

Within the child script, you create a loop to run MaxAccounts times

You have a counter incrementing within this loop

 

How can I communicate to the ui, the value of the counter?

Running ui-stat-monitor #counter doesn't update the ui if it is used in the child script

Running it in the master script, it stays at zero

 

There is a ui for the child script, and if you click the child tab during execution, the ui is updated, but there seems no way to force the child script to have focus.

 

I just wanted to confirm this is expected behaviour, that the ui can only reflect actions in the master script, and not in any called scripts.

[pftg4 102]

hey sj

 

ubot does this already unless i misunderstood what you want

 

 

Pftg4

test.ubot

[sj7272 0]

hey sj

 

ubot does this already unless i misunderstood what you want

 

 

Pftg4

test.ubot

 

Thats exactly what I want!

Ok, I'll go and find what I was doing wrong and update. Thx

"It's all a learning curve"

[sj7272 0]

OK, It fails if the monitored variable is passed as a parameter.

 

Like in attachment.UIMonitor.ubot

 

Just trying to discover all the behaviours between subs/scripts/bots/includes - and deffo need more caffeine!

Thx for the input guys.

Simon

[Super Dave 26]

My bad, I've never played with scripts in this sense and subs have always been more portable in my opinion. I've included an example of how to structure the same sub to be used with either a static display that updates at the end of the sub routine, or updates while calling the sub each time. I don't think we're talking about two different things just how we each go about implementing them.

 

 

I'm going to start another thread and get some insight as to the benefits of running scripts vs running subs and see what kind of feedback we get. Cheers!

 

ui-update-examples.ubot

[sj7272 0]

My bad, I've never played with scripts in this sense and subs have always been more portable in my opinion. I've included an example of how to structure the same sub to be used with either a static display that updates at the end of the sub routine, or updates while calling the sub each time. I don't think we're talking about two different things just how we each go about implementing them.

 

 

I'm going to start another thread and get some insight as to the benefits of running scripts vs running subs and see what kind of feedback we get. Cheers!

 

ui-update-examples.ubot

 

Good idea. It would also be good to include er... "includes" in that comparison, and to know the pros and cons of all permutations. That thread should run for a while, but will be hugely enlightening!

Thx guys,

Simon