Thank you again. I'll see what progress I make in building a Macro and using GG's really helpful example.
I expect I'll have to make a few detours to become really familiar with the KM basics.
But - I wonder whether you realize it - you've both done something extremely helpful that you probably take for granted: confirmed that the best way to stroke this cat (I love animals so would never dream of skinning them ) is by clicking into fields and not trying to name or script them. That gets me a long way very quickly. Thanks.
Maybe you need to talk to your restaurant manager about why they choose Tuesday to change their menus.
Encouragement? You bet!
Back soon after some investigating and trial and error.
I think we've steered you in the right direction. As long as your boat doesn't have a hole in it you should make it to your destination now. That tip about clicking to activate a field seemed to be really helpful to you. If there's a hole in your boat we can patch it up. But you've got the rudder right now and the wind is at your back. Bon voyage.
It certainly was: I was imagining all sorts of other ways to automate selection of fields in that app. But the simplest one - using pointer and caret, mouse and screen location means I can eliminate those.
Provided - as GG says - I can consistently assume (and/or if necessary account for) the position of the window etc.
Half the time my code requires windows to be in certain positions on the screen. What I tend to do is move them into the upper left corner at the start of my macro, sometimes using this code. This way my hardcoded mouse positions will generally not fail because the window will be in a known fixed location. You should consider this too.
From a quick experiment, BookPedia seems to keep its edit window always in the same place. But to be double-sure is a good step.
As I said, a novice user probably imagines all sorts of ways to work specifically in a field. Conventional scripting (e.g. locating and changing the contents of a field on a webpage in JavaScript) certainly tends towards naming the fields. To know that KM takes a different approach by choice has saved me hours of waiting in blind alleys .
Here a more traditional (but presumably faster) approach with UI scripting (since Bookpedia doesn’t provide any AppleScript dictionary):
Script:
set {saveTID, AppleScript's text item delimiters} to {AppleScript's text item delimiters, {":"}}
# Max. number of records to be processed with one run
set maxEntries to 3
tell application "System Events"
repeat with i from 1 to maxEntries
tell application process "Bookpedia"
tell window "Bookpedia"
tell splitter group 1
tell splitter group 2
tell group 1
tell scroll area 1
tell table 1
tell row 1
tell text field 1
try
set oldTitle to its value
set newTitle to text item 1 of oldTitle
set newTitle to my trimLeadingSpaces(newTitle)
set originalTitle to text items 2 through -1 of oldTitle as text
set originalTitle to my trimLeadingSpaces(originalTitle)
on error
set originalTitle to ""
end try
perform action "AXShowMenu"
delay 0.1
end tell
end tell
click menu item "Edit…" of menu 1
end tell
end tell
end tell
end tell
end tell
end tell
tell window oldTitle
tell group 1
tell scroll area 1
delay 0.1
set value of text field 1 to newTitle
if originalTitle is not "" then set value of text field 3 to originalTitle
end tell
end tell
tell button "OK" to perform action "AXPress"
end tell
end tell
end repeat
end tell
set AppleScript's text item delimiters to saveTID
on trimLeadingSpaces(str)
repeat with i from 1 to count of str
if str begins with space then
set str to text 2 through -1 of str
else
exit repeat
end if
end repeat
return str
end trimLeadingSpaces
It is required that in the editor window the “Original Title” is the third text field, like this:
More Notes:
In the current test form the script only runs on the first three entries. You can change this in the AppleScript (“maxEntries” variable.)
Currently the script only removes leading spaces for each of the re-defined fields. (Trailing spaces usually do no harm, but this can be implemented too.)
When you test the script, make sure the Bookpedia window is open.
The screen position of the windows doesn’t matter at all.
If you get an error like “Can’t get menu item…” try to uncomment the delay 0.2 (It’s the only commented line in the script.)
The script is meant as a test: if it basically works for you (on a couple of entries), then we can still refine it. (I have no clue what a window with 8000 records looks like, or if your database is somehow setup differently. I just downloaded the app and used the default setup.)
Removed macro download link (for the time of the debugging stage)
Edit 2019-08-21T02:43+02:
Updated script:
Colon-separated text items after the first colon go all into Original Title (leaving the colons in that part untouched)
Added some delays
No longer overwrites Original Title if we don’t have a value for it. (I know, you were OK with overwriting, but it is better this way, in case you are accidentally processing records you already had processed before. No data loss.)
I count three different solutions from three different people in this thread that have been given to you. You have the rudder. Pick your preferred path. But we're here to help if you get stuck. Each path has its own advantages.
One of my hobbies is to take intransigent macOS apps (or websites) and automate them even if they weren't designed to be automated... even if they are designed with self-defence mechanisms to prevent automation. So I have a few tricks up my sleeves. Bookpedia is a cakewalk compared to the apps/sites I automate, but I won't tell you what apps those are. I help people with their problems on this website when my problems are too difficult, or when I have a toothache, like now. Yes, I'm getting that addressed. Another hobby is to build robots that use cameras to move. That's also difficult. I won't say much about what those robots are doing.
I actually have a fourth solution that might work, but it requires that your app be able to back up its database into a text file. If so, there's a much simpler solution than any of our solutions here. But I have no idea if your app has the ability to back up its book database into a text file. In fact it may already be stored in a text file, or multiple files. If this is actually the case, I could solve the problem in a single KM action, and a fairly simple one at that.
I'm willing to tell you that the robots are made out of a bunch of $9 servos which are controlled by a Phidgets servo controller which KM sends signals to based on the images coming from a camera. The servos and the controller look like these images I just got from the web. Physically the parts look like this image I found online:
So you know based on the size of these parts that I'm not exactly building a Terminator robot to send back in time to take Peter out before he builds Skynet using Keyboard Maestro.
I was expecting you to reply "more like 90%". Half of my posts are designed to manipulate people into responding with certain responses. But you didn't bite on this setup. My setup skills are failing me.
The thing with the CSV is that is not completely trivial to split an optionally colon-separated entry in the first column, and send the second part to the second column. And getting rid of spaces. Bit doable, of course.
Since you told me you didn’t download the app, here an example CSV dump (only 3 records) to play with (if you want):
I just caught your "yet" joke. Nice one. Big smile. I think the chance I'll ever build Skynet is under 1%. To be honest, I don't think any software that I've ever written has ever "learned" anything. I still have no idea what "learning" is. I can't even define it. But once I can define it, watch out. Five minutes after I understand what leaning is, Skynet will be born.
If the second column is always blank (a pair of empty quotes), I think it probably is nearly trivial. It's just a matter of moving the quotes. I could be wrong, but it feels quite trivial.
It always takes me an hour to get these things working.