I just installed Kantu in Windows 7/Firefox 64, and then the XModules. Looks like a great tool, and I really hope I can get it to work!
I ran the macro “DemoXType”. It opened the webpage, then opened the Save dialog and correctly entered the long filename with the current date and time. But then it just sat there (with the filename highlighted in blue as a selection) until I closed the Save dialog myself. I could close it by either saving the file with Enter or Alt-S or by canceling with Escape. It appears the the Enter keystroke in the macro was just not executed.
Since the Save dialog has the alternative completion of Alt-S, I modified the demo by changing ${KEY_ENTER} to ${KEY_ALT+KEY_S}. The file is still not saved, but the behavior is different. After the filename is inserted, there is a beep and instead of the filename being highlighted in blue as selected, the cursor is blinking at the end of the filename. The beep that I hear is the same beep that Windows makes when an unrecognized key is pressed.
So while it seems that the Enter was just not executed, it seems that the ${KEY_ALT+KEY_S} command caused some unrecognized keystroke to be executed. At least that’s the most sense I can make of this.
Can someone say why this is happening and what I need to do to get the dialog to complete by saving the file?
Thank you.
Edit: I just looked at the two page saves that I made by manually pressing Enter or Alt-S in the Save dialog. And it turns out that the page that was saved was not “Page Not Found”, but was 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 happened. I hope someone there does.
And then it saved the file. Can I be the first person who has experienced this, whereas that demo works for everyone else? Why have I had to debug a demo?
Now, it saved a file, but as before when I completed the macro manually, the browser window that got saved is the Kantu window, not “https://a9t9.com/kantu/demo/xtype”. I’ve posted that as a new topic because now that the Enter keystroke problem is solved, that is a separate issue.
Thanks for this hint, we will update the demo macro accordingly.
Actually, we recommend to break up longer text entry sequences in two or more separate XType commands - because then the short internal break between both commands makes the keystroke simulation speed is naturally. And if needed, one can add a PAUSE in some places (just like you did). Most applications and websites are not tested and designed for robotic process automation speeds
Is that recommendation in the documentation somewhere?
Given what you said here, is there a reason that both the XClick and XType demo macros start by setting the play speed to fast? Wouldn’t medium be a better setting unless (a) one is doing a long procedure where speed makes a difference, and (b) the browser and website are certain to be able to handle the speed?
What is the default value of !replayspeed? The manual section on speed doesn’t say. (Edit: Oops, sorry, yes it does: medium.)
Given what you said here, is there a reason that both the XClick and XType demo macros start by setting the play speed to fast ?
With “fast” there are no artificial delays between the commands, but even then, there are a few milliseconds delay between each command. This is usually enough for the keystroke entry to work well. But you are right: If speed is not an issue, it is good idea to replay such macros on medium speed.
Oops, I was wrong. The Enter problem is not solved. A macro I’ve developed has the same problem, except that sometimes the page gets saved, and sometimes the macro just leaves the dialog box hanging. I don’t see any pattern for when it concludes the dialog and when it doesn’t.
The macro is working except for that. The result is that the process is only semi-automated, since I have to sit here and watch to see if the dialog box got closed and if it didn’t, I have to press Enter myself to close it and let the process move on to the next webpage.
I’ve posted the code for the macro on StackOverflow along with a long explanation. If you want to take a look and see if you know what’s going on with this Enter problem, or if you can offer any other suggestions for improving the macro, that would be great.
Yes, that’s right. Everything else works fine, right up to, and except for, the Enter at the end.
Yes, when it fails, the focus is in the dialog box. That’s why all I have to do to continue is press Enter myself.
I know I tried increasing the pause at least to a full second. Do you think I ought to also try it with two seconds? That seems unlikely to make a difference because the dialog box is sitting there waiting for action. It’s not as if it has to wait for something else, such as loading a page. But if you want, I’ll give it a try. (However, see my note below about two one-second pauses.)
I did try adding an additional half-second pause followed by a second Enter keystroke.
I also tried it with Alt-S instead of Enter. I think I mentioned before, and if I remember correctly, the computer beeped when I used Alt-S. I don’t understand that because Alt-S is supposed to be an alternative way to conclude the dialog.
And I see now I have a test macro that had a one-second pause followed by Enter followed by another one-second pause, and then an Alt-S.
Can you think of a conceptual reason that a keystroke would be ignored? Of course, sending keystrokes too fast could cause that, but you see I have the speed set at 0.3 seconds. Except for going too fast, are there any other circumstances in which a keystroke has been ignored?
I have an idea, but I can’t test it with the free XModules. Is it possible that Kantu is getting tripped up by those sequences of five control keys in the same XType command, and then having those sequences repeated multiple times? That doesn’t seem likely to be the problem because the effects of those sequences are occurring correctly. The cursor has to move to the beginning of the URL in the filename textbox, and then the selection has to step back through the path part of the URL with exactly eleven Shift-Ctrl-Rights. If any of those Shift-Ctrl-Rights got lost, the page would not save with the right filename. And the filename has never been wrong in all the tests. So there doesn’t seem to be a problem there. But if you don’t have any other ideas, I would try separating out all those control keystrokes into one per XType and run that at slow speed. But I can’t do that because it would exceed the 25-command limit.
Any other thoughts, questions, or anything else you want me to try?
Can you recreate this issue in a short test macro that we can run locally on our test systems? I am confident that as soon as we can recreate the issue, we can fix it.
As mentioned above, I posted the code for the macro on StackOverflow. I don’t want to post a link to the material being archived, but I could e-mail it to you if you want to test the macro there. If we get this problem resolved, I’ll edit that answer on StackOverflow to say so.
I can confirm that this is still an issue in Firefox 66.0.3 (64-bit). Neither the DemoXType is able to get to the save button or my custom script. Attempted multiple variations including the AltS and sending the tab keys then the enter button. The script gets stuck on the file name field and won’t budge, but no errors are thrown.
