I have this scenario of 4 redundant test cases as marked below and the basic idea is running the 4 test cases from the folder highlighted in green.
The last step for each test case is closing the browser and
the first test case step is open a new browser window, open URL, validate a field and then last step, close the browser.
The issue I am facing is the first test case runs fine, but after the execution of the first test case, Tosca is not able to reopen another browser window to execute the second test case. Please help with a solution why Tosca is not able to open a second browser window. The executor simply waits for a certain amount of time before showing a timeout error message in Scrapbook o/p.
You can make use of standard modules open URL and then enter the value of the browser you need to open. Using the wait standard module to verify if the URL is opened. Now, use tbox window operation to close the browser where caption will be the name of the browser page and operation will be closed.
After closing the browser in the first test case give 2 sec wait. What's happening here is that when Tosca tries to close the browser, it executes a command which will take some time to execute, but Tosca will go to the next test case and tries to open the browser in the the second test case.
By the time Tosca opens the browser in the second test case, it will be closed by the first test case close browser command.
A simple wait after closing the browser should fix this issue. I have come across this issue.
Of course, a "wait" helps, but with "TBox Window Operation" you can use a "Wait On Close".
OpenUrl
Url: http://www.deepl.com
TBox Window Operation
Caption: DeepL *
Operation: Wait On Close
Related
So I have a long-running python notebook.
As long as it's open in my browser's tab, it's autosaving every 2 minutes, and life is good.
Is it possible to keep it auto-saving even if I close the browser tab?
The kernel already keeps running when I close the tab, which is great.
This is kind of like "screen", but in jupyter
EDIT: Even if I leave the tab open in my browser, I noticed that after 24 hours, the "kernel status" in the top right becomes "disconnected", even though the running cell still has output being piped to it from the server websocket connection
No, you can't (for now), and their will be no point in doing it.
The reason is, as soon as you close your tab, some critical information is lost because it is in the memory of the Javascript VM that run the page.
Any update sent by the kernel after you've closed your page are lost.For example try the following.
create a cell with sleep(10);print('Hello')
Execute the cell
Quickly close and reopen the tab.
the "Hello" will never be printed.
The mapping between the "Execution request" and the "Execution reply" have been lost, and can't be recovered.
The Jupyter team is aware of that. The fixes are not that hard, but require a lot of careful refactor and API design. There was a long in person discussion in NYC at the end of August 2017. Right now the focus is to polish JupyterLab, and once this is done it will be one of the area of focus. It will go hand in hand with real-time collaboration.
In more detail, the fix requires to "move" the notebook model from the client (your browser) to a server side (what is serverside is handwaved for now, but here is not the place to expand it), there are technical questions about that, like what to do with widgets, and when collaborating what state is shared by everyone and what state is per-client. Like if you fold some code, should this be stored ? or not ?
If you are interested in that, I would suggest getting involved with JupyterLab, there will be soon a number of low hanging fruits to contribute that should quickly fix 80% of the usecases.
when using FlexPrintJob, after calling start(), a OS system print interface will appear, and at the same time Flex code execution will be paused, and it will remain paused until user finished interaction with the OS print dialog. the problem is I do have data from server, and the connection will time out within certain period, so is there any walk around to not pause the Flex code execution while OS print dialog is popped up. Thanks.
From the doc for FlexPrintJob:
You use the FlexPrintJob class to print a dynamically rendered document that you format specifically for printing.
This makes me wonder if you couldn't (essentially) fork off a second page from the browser that contains your print job and do the printing from there. This would leave your original page still running. In my flex apps I do this via PHP (create additional pages for printing and such). Example here.
Otherwise: you should finish all the server data d/l before starting the print job to avoid this issue.
Flex is only just recently starting to add multi-threading. It's adding worker threads of a sort but this won't help what you're asking for.
and by unresponsive I mean that after the first three successful connections, the fourth connection is initiated and nothing happens, no crashes, no delegate functions called, no data is sent out (according to wireshark)... it just sits there?!
I've been beating my head against this for a day and half...
iOS 4.3.3
latest xCode, happens the same way on a real device as in the simulator.
I've read all the NSURLConnection posts in the Developer Forums... I'm at a loss.
From my application delegate, I kick off an async NSURLConnection according to Apple docs, using the App Delegate as the delegate for the NSURLConnection.
From my applicationDidFinishLaunching... I trigger the initial two queries which successfully return XML that I then pass off to a OperationQueue to be parsed.
I can even loop, repeating these queries with no issues, repeated them 10 times and worked just fine.
The next series of five queries are triggered via user input. The first query runs successfully and returns the correct response, then the next query is created and when used to create a NSURLConnection (just like all the others), just sits there.?!
The normal delegate calls I see on all the other queries are never seen.
Nothing goes over the wire according to Wireshark?
I've reordered the queries and regardless of the query, after the first one the next one fails (fails as in does nothing, no errors or aborts, just sits there)
It's obviously in my code, but I am blind to it.
So what other tools can I use to debug the async NSURLConnection... how can I tell what it's doing? if at all.
Any suggestions for debugging a NSURLConnection or other ways accomplish doing the same thing a NSURLConnection does??
Thanks for any help you can offer...
OK tracked it down...
I was watching the stack dump in each thread as I was about to kick off each NSURLConnection, the first three were all in the main thread as expected... the fourth one ended up in a new thread?! In one of my NSOperation thread?!?!
As it turns out I inadvertently added logic(?) that started one my NSURLConnection in the last NSOperation call to didFinishParsing: so the NSURLConnection was async started and then the NSOperation terminated... >.<
So I'll move the NSURLConnection out of the didFinishParsing and it should stay in the main loop and I should be good!
I'm currently writing a macro that performs a series of control sends and control clicks.
They must be done in the exact order.
At first I didn't have any sleep statements, so the script would just go through each command regardless whether the previous has finished or not (ie: click SUBMIT before finish sending the input string)
So I thought maybe I'll just put some sleep statements, but then I have to figure out how best to optimize it, AND I have to consider whether others' computers' speeds because a slow computer would need to have longer delays between commands. That would be impossible to optimize for everyone.
I was hoping there was a way to force each line to be run only after the previous has finished?
EDIT: To be more specific, I want the controlsend command to finish executing before I click the buttons.
Instead of ControlSend, use ControlSetText. This is immediate (like GuiEdit).
My solution: use functions from the user-defined library "GuiEdit" to directly set the value of the textbox. It appears to be immediate, thus allowing me to avoid having to wait for the keystrokes to be sent.
There actually is no problem with my code per se, but if I add my program to run on startup (i.e. every time the user logs in), it fails to create the tray icon, because, at the time it tries to, the taskbar is not yet created/initialized completely. Is there a solution for that? Right now I'm thinking about something like retrying 10 times with a 10 second interval.
It certainly is a race condition. Retrying is a good idea, yes, but instead I'd do it with delays. Have the app launch but use a QTimer::singleShot() to delay for 5 seconds (or whatever) before trying to hookup with the taskbar. If you want to retry after that (which is probably a good idea), delay longer (as retrying immediately likely won't succeed either as the retry will occur too fast).
Quote from http://developer.qt.nokia.com/doc/qt-4.8/qsystemtrayicon.html (pay attention to second paragraph):
"To check whether a system tray is present on the user's desktop, call the QSystemTrayIcon::isSystemTrayAvailable() static function."
...
"If the system tray is unavailable when a system tray icon is constructed, but becomes available later, QSystemTrayIcon will automatically add an entry for the application in the system tray if the icon is visible."
Moca is right, it should work as per the docs. However, it does not due to bug 61898 in Qt.
A workaround is to wait for the system tray to be available using isSystemTrayAvailable(). As Wes Hardaker suggests, you can try every few seconds using a QTimer::singleShot() until the system tray is available.
Note that if you show() your tray icon once the system tray is available, it will always show up again even if the system tray is removed and a new one is created (as the docs says), so you only need to get it right the first time.
I'm using PyQt5, and I replaced
self.show()
with
self._show_when_systray_available()
def _show_when_systray_available(self):
"""Show status icon when system tray is available
If available, show icon, otherwise, set a timer to check back later.
This is a workaround for https://bugreports.qt.io/browse/QTBUG-61898
"""
if self.isSystemTrayAvailable():
self.show()
else:
QtCore.QTimer.singleShot(1000, self._show_when_systray_available)
I can only see one (pretty unlikely) failing case: a race condition where the system tray is removed in the small amount of time after isSystemTrayAvailable() returns true and before your status icon shows.
Edit: Accorging to the bugtracker, this was fixed in 5.12.4.