Mouse clicks not working for website log in

[Scotsman]

I have a simple script for logging into a site so I don't have to type every time. It opens the site and detects the mouse move just fine, but It doesn't  detect the mouse clicks. So the email and password can't be entered. My screen cap doesn't show it but the cursor ends up sitting on the log in button as intended. But that's where it stops. It seems simple but stuck here. I have a laptop with a wireless Logitech mouse, and I've also tried the touch pad with not luck.

Thx!

[Scotsman]

So I realized I can just go straight to the log in page:

"https://todoist.com/users/showlogin"

Then the user name field is sometimes highlighted and the script enters the user name/pass no problem. But sometimes the field is not highlighted and the script fails.

Any ideas?

 

[acantor]

If I'm understanding correctly, when the login page loads, sometimes the user name field has focus, and sometimes it doesn't? When there is no macro in the picture, is this behaviour normal for the page?

 

Adding a two or three second delay after loading the web page might help.

[Cory]

You might want to make sure the Web Browser is focused. 

[Scotsman]

The normal behavior for the page is the user name field is highlighted. But with the script it's hit or miss. I looked around for focus function and saw this:

Not sure if this is what you mean Cory? I don't see anything for the web browser specifically..

 

[rberq]

27 minutes ago, acantor said:

Adding a two or three second delay after loading the web page might help.

The web page may not yet be completely loaded when the macro clicks the mouse and types.  As an experiment, remove the Website command from the macro; load the website manually; then run the macro.  If it then does what you want, then it's a timing issue, so add the delay like acantor says, or try the "wait for website" command.

[Scotsman]

Just added the 3 second delay and it's worked 3 times in a row, which seems better - but then failed again. I added another second, and still hit or miss. How do I make sure the web browser is focused?

thx

[acantor]

8 minutes ago, Scotsman said:

How do I make sure the web browser is focused?

 

That's a big question. There are a lot of focus issues with Windows 10.

 

This might work:

 

Window Activate: Window Title Goes Here!

 

Or maybe something like this. (You'll need to figure out the x,y coordinates):

 

Mouse Move: 100, 200 Relative to Current Window
Mouse Left Click

 

 

[rberq]

1 hour ago, Scotsman said:

How do I make sure the web browser is focused?

If it's hit-or-miss on timing, one way is to find a specific spot on the screen with a predictable color when the web page is completely loaded.  For example, this routine repeats for about 12 seconds, looking for the combination of white in one location, and blue for the login button, which occurs once the web page has finished loading. 

  Repeat Start (Repeat 12 times)
    Mouse Move: 900, 500 Relative to Screen
    Mouse Left Click // Click white area to bring page into focus
    Delay: 500 milliseconds, without ability to halt
    Mouse Move: 770, 560 Relative to Screen // Hover over button area until expected dark blue color is found
    Delay: 500 milliseconds, without ability to halt
    Get Pixel Color from Beneath the Mouse into %N[1]%
    Get Pixel Color at (840, 540) Relative to Screen into %N[2]%
    If Variable %N[1]% Equals "6567680" // Blue
      AND
    If Variable %N[2]% Equals "16777215" // White
      Repeat Exit
    Else
    End If
  End Repeat
  // Type name and password, tab to Submit button and ENTER

 

[Scotsman]

Thanks for the helpful tips. It seems to be working consistently now with a simple delay, so all is good for now. If it stops working, I give these a try.

cheers

[acantor]

It's challenging (verging on impossible!) to write a macro that is 100% reliable, especially when a macro interacts with web content. If adding a longish delay allows the macro to work nine times out of ten, you're doing good. Increasing the length of the delay may improve reliability, or make no difference.

 

Adding extra code to ensure a target window has focus -- as Cory mentions and rberq illustrates with his pixel monitoring routine -- helps a macro run more quickly and more reliably. But you need to be a bit of a "macro geek" to go to this extra trouble!

 

The need to geek-out to improve script reliability is part-and-parcel of using third-party scripting tools. AutoHotkey, for example, is more powerful than Macro Express. Yet many of my AutoHotkey scripts had to be gussied up to handle the inevitable problems that arise when switching from one window to another, when performing clipboard operations, and so on.

 

Adding delays to a script is the path of least resistance. The approach is effective most, but not all of the time.