This problem was described in my edit to a previous topic. But with the main problem of that topic solved, this one remains.
When the macro DemoXType completes, the page it saves is not “https://a9t9.com/kantu/demo/xtype”, but is the Kantu window, the window with the list of macros on the left, table or source view on the top right, and logs, etc. on the bottom right. This is obviously not the right behavior and I have no idea how it happens. I hope someone else here does.
Maybe this is related to another window problem. When the macro executes the open command, sometimes it opens that URL in the window in which the Kantu icon was clicked to start Kantu, but sometimes it opens it in some other Firefox window. I haven’t found a pattern for that other window. It’s not necessarily the last Firefox window that had the focus. It seems to be just some random other Firefox window that happens to be open. To complicate things further, usually, the URL is opened in the main tab of a Firefox window (I always only use one tab per window), but sometimes it gets opened in a new tab. I also have found no pattern for when it opens the URL in an existing versus a new tab.
Is there a way to tell Kantu which Firefox window and tab to open a new URL in and which Firefox window to save as a page?
I’m running Kantu in Firefox 64 under Windows 7.
Which window or tab the URL gets opened in is not so critically important, but obviously, which window gets saved is. The macro is useless if it saves the Kantu window!
I confirmed the problem. The solution is to add the BringBrowserToForeground command to the macro. It brings the browser to the front. This makes sure that the simulated keystrokes apply to the correct window.
We will update the demo macro with the next release.
I added BringBrowserToForeground to the macro and got the error: “Command BringBrowserToForeground not supported yet”. That would also explain why I didn’t find it in the command reference. So I guess you tested this solution in your development platform. Is there a workaround for us guys out here until it’s included in a production release?
It would also be a good idea, on the doc page for that command that you linked to, to add a note saying that the command is under development and is not yet available for use.
If you could suggest a workaround as soon as possible, it could help me accomplish something I’m trying to get done on a deadline. Thanks.
Okay, I don’t know what just happened here. I was having trouble getting bringBrowserToForeground to work. When I put it in, other things stopped working, such as the open command would hang or the Enter key was again not recognized. But then, in the middle of troubleshooting those problems in a stripped down macro, I accidentally ran the full macro I’m developing, and somehow it worked – URL opened, Enter was recognized, and the correct webpage was saved, not the Kantu window.
So thank you. You have solved this problem. Maybe in time for me to meet that deadline.
One of the issues I was looking at in troubleshooting was that your sample above in this thread put bringBrowserToForeground after open, whereas the doc page puts it before. In my troubleshooting, it looked like I was getting different behavior from the different orders, but that’s part of what I was testing when my macro suddenly started working. I need to get that macro finished, so I don’t have time to go back to that testing now. Do you have any knowledge of whether the order makes a difference or not?
Also, since it turns out that bringBrowserToForeground is an implemented command (as long as the text case is correct), are you aware that it’s not listed in the command reference?
