I have an instance of a word document running (opened through a New Word.Application). I have populated the document and sent it to print, however, if i then use the Msword.application.quit method as the next statement it cancels the print job
I have put in a do while MsWord.BackgroundPrintingStatus = 1 loop in but this then goes into an infinite loop.
stepping into the code and giving the print job time to run before continuing to the quit command works fine and the MsWord.BackgroundPrintingStatus does return to 0.
Why would a do while loop go into an infinite loop while waiting for the status to change?
OK found a way to do it. put the quit in a do while printingstatus = 0
Related
I have a very different problem here.
I have this code
xpath = "//div[#class='z-listheader-content'][normalize-space()='Name']/ancestor::table/../following-sibling::div/table"
array = #browser.table(xpath: xpath, visible: true).rows.map { |row| [row.cells[0], row.cells[0].text] }
col = array.filter_map { |x| x if x[1].eql?(result) }
When I am executing the aforementioned code, it throws the following error
timed out after 10 seconds, waiting for #<Watir::Row: located: false; {:xpath=>\"//div[#class='z-listheader-content'][normalize-space()='Name']/ancestor::table/../following-sibling::div/table\", :visible=>true, :tag_name=>\"table\"} --> {:index=>10}> to be located\""
10 is actually the last index of the table.
But it works fine if I put sleep 5 before my code segment. However, I was expecting WATIR to be automatically waited, but this is not the case, May I know why?
Here is more clear explanation
I am printing this line
p #browser.table(xpath: xpath, visible: true).rows.count
With sleep this is printing 10
without sleep, this is throwing the following error ends with {:index=>11}> to be located\, you could see the full error below
"timed out after 10 seconds, waiting for #<Watir::Row: located: false; {:xpath=>\"//div[#class='z-listheader-content'][normalize-space()='Name']/ancestor::table/../following-sibling::div/table\", :visible=>true, :tag_name=>\"table\"} --> {:index=>11}> to be located\""
Per the Documentation on waiting there are a few key points that should be noted:
The idea behind implicit waits is good, but there are two main issues with this form of implementation, so Watir does not recommend and does not provide direct access for setting them.
The wait happens during the locate instead of when trying to act on the element. This makes it impossible to immediately query the state of an element before it is there.
Implicit waits by themselves will not be sufficient to handle all of the synchronization issues in your code. The combination of delegating waiting responsibilities to the driver and leveraging polling in the code (explicit waits) can cause weirdness that is difficult to debug...
...The second and recommended approach to waiting in Selenium is to use explicit waits...
...Note that Watir does its automatic waiting when taking actions, not when attempting to locate...
In your case the wait is needed for location and thus the "automatic" wait you were expecting is not actually how watir works.
The Watir library does however provide mechanisms for explicit waits:
wait_until which waits until a specific condition is true
wait Waits until readyState of document is complete.
It appears that based on your posted issue that a waiting timeout has expired for your location before the element could be found.
It is possible that wait_until would resolve this e.g.
table = #browser.table(xpath: xpath).wait_until(&:visible?)
puts table.rows.count
While tracing a function in bash, I can return non-zero value (say,1) from by DEBUG trap handler to skip the execution of the next line.
Also, I can return the value 2 to execute a return statement to return out of the function without executing the rest of the function body
However, I would like to be able to step out of the current function, not by `return'ing, but by executing the remainder of the function body in just a single shot (instead of executing it line-by-line till the end of its body).
Is this possible?
Tedious sure, but it seems this can be done with the existing callstack information provided by Bash.
Here's how.
Keep executing your DEBUG trap handler till you reach the next callstack frame, F2, sitting right under the current one, F1, and stop on a line number that is greater than or equal to the BASH_LINENO saved in F2. The '... or equal to' check is required to address recursive calls.
While learning asyncio I was trying this code:
import asyncio
from asyncio.coroutines import coroutine
#coroutine
def coro():
counter: int = 0
while True:
print("Executed" + str(counter))
counter += 1
yield
loop = asyncio.get_event_loop()
loop.run_until_complete(coro())
loop.run_forever()
print("Finished!")
I was expecting the coroutine to be executed only once because it contains a yield and should have returned control to the caller. The output I was expecting was:
Executed 0
Finished!
I was expecting this behaviour because I thought the loop was going to run the coroutine forever once every "frame" returning to the caller after each execution (something like a background thread but in a cooperative way). But instead, it runs the coroutine forever without returning?. Output is the following:
Executed 0
Executed 1
Executed 2
Executed 3
...
Could anyone explain why this happens instead of my expectations?
Cheers.
You have a couple of problems. When you call run_until_complete, it waits for coro to finish before moving on to your run_forever call. As you've defined it, coro never finishes. It contains an infinite loop that does nothing to break out of the loop. You need a break or a return somewhere inside the loop if you want to move on to the next step in your application.
Once you've done that, though, your next call is to run_forever, which, just as its name suggests, will run forever. And in this case it won't have anything to do because you've scheduled nothing else with the event loop.
I was expecting the coroutine to be executed only once because it contains a yield and should have returned control to the caller.
Looking past the fact that your coroutine has no yield, awaiting (or yielding from depending on which syntax you choose to use) does not return control to the caller of run_until_complete or run_forever. It returns control to the event loop so that it can check for anything else that has been awaited and is ready to resume.
One of my users is running a script in his R GUI in Windows. He takes the script itself and copy-paste it into the R console. If the user sets some incompatible parameters the script has errors but the rest of it executes giving the impression that everything has gone well. Is there some way such that the R session is terminated if an error is encountered? or any other way to stop execution without terminating the session as soon as any error is spotted?
Just rewrite your script as calls to one or more functions. If this is too much work, you can also just wrap lines of code in a {...} block. Execution will stop at the first encountered error.
halt = function() q('no')
options(error=halt)
will do the job
I have some problems with controlling a while loop inside an event structure.
Say I have an iterative procedure and I want to stop the iterations during run-time (say to check out the results).
while(resid > 1e-10 )
{
for (int iter = 0;iter < 1000;iter++)
{
// some thing //
}
}
I have 3 buttons ("Start Running, Stop Running, Quit Program"). When the while loop is running, it should be possible to stop the running by clicking on "Stop Running", but this does not work.
I am not saying it has to be buttons but it could be a console app and the termination is done by writing something on the console.
Has anyone an idea on it can be implemented?
Thanks a lot and best regards,
Mohammed
You need to check for "Button was pressed" inside the loop and then break out of the loop if it was detected.