How to automate a point-and-click procedure in Windows, involving tray icons and menus

Solution 1:

This is a pretty challenging problem, but you can definitely do this in AutoHotkey if you spend enough time at it. How reliable you get it to be and having it work correctly every time will also be a function of how much time you spend on it.

You already have the steps broken down, so what you would need to do for each step is figure out what code you would need to implement, and tackle each of the problems until they are all working.

Here are a few thoughts for getting started, in no particular order...

1. Clicking on things is 'easy;, it's knowing where to click that's a problem, so if there's any other way to programmatically do something, it's almost always better to do it that way instead of trying to click on things.
2. PixelSearch and ImageSearch can find certain spots on the screen based on what you're looking for (so say you're looking for an icon, if you save what it looks like in an image file then this can help you find that spot on the screen). ImageSearch can fail if the background changes due to transparency though
3. There is specific code you should be able to find to help deal with Tray Icons programmatically (here for example), although it might be easier to start off using simple interface techniques to try and click on things
4. If you do wind up being able to click on a tray icon, I would recommend going back to keyboard navigation/selection wherever possible, for example if you are able to get the tray icon menu to appear programmatically (by clicking), the item to execute the Export HTML option for example, could be done by sending {Down 3}{Enter}, vs. using coordinates to click on a new spot relative to the first click
5. Manipulating the GUI when you have it open to select yesterday's data will be easiest by determining which controls you want to modify and using the Control name (ComboBox1 for example, for selecting the "Yesterday" data set)
6. Manipulating the Save As dialog... you will probably want to use WinWaitActive to make sure the window is open, before using SendInput for the path (or loading the edit control value) to set the proper path and confirm the dialog
7. Using BlockInput can enhance reliability while you are debugging (use sparingly, and always make sure to turn off at the end of your test code)

The problems I foresee with this type of setup, manipulating the GUI and clicking on tray menu options and whatnot, is reliability when the tray icons shift places or whatnot, and having your code still work.

What I would really recommend with such a simple program like ProcrastiTracker is digging through the source code that's posted on GitHub. Something else that might be a lot easier than automating all of this, or even reverse engineering the database structure, would be to do your own build of ProcrastiTracker that supports a commandline argument to export yesterday's data, or seeing if the author would even consider implementing it for you. That way you could hardcode the options you want for export (i.e., data from yesterday, folder location, filename), and just launch the program separately with that special commandline argument once a day.