[Rwp] my early work with sfz player using a dedicated process so opening up in another window

[Chris Belle]

I'm using an older dell machine
a first or second gen i5 with no monitor on it if that helps any.
as my test machine.
I have a feeling it's the first thing,
ahk uses the child window while golden cursor uses screen cordinates.
But what got me scratching my head is why ahk can't find the top level 
window when I'm running in non bridged native mode?
Unless for some reason, that top level window isn't being created then.
is that possible?
But even  then,
I should be able to get some window to recognize.
I changed the window name and ahk wouldn't do a thing.
Mind you, I need to mess about a bit more.
It's been a while since I messed with the ahk stuff, and though not a 
full blown programming language,
it's still pretty stout for a layman, or can be,
I used to know it pretty well,
but I've slept since then.
Let me see if I can nail down anything more,
I just know when I first did this,
I was told to use the in dedicated process thing, by the guys who had 
done some of this before me, and of course, they were using jaws and hsc,
another thing I liked about using ahk is that for me anyway, it was 
easier to test things and change my corrdinates by editing the text file 
rather than noodling my way through the jaws interface for editing the file.
Hotspot can chain clicks and such, but you go through a wizzard,
but with ahk, you just tell it cllick here, and sleep how many ever 
milisecs, move here and click,
ob course ,you don't have all the nice string processing thigs tight 
with the screen-reader, only a message box you can put up, but one thing 
window-eyes does nicer than jaws is read that mouse movement and tool 
tips, jaws can too, but it's more likely just to say, external vst window,
so when exploring stuff even though window-eyes is my least favorite on 
the web and such these days, for locally exploring a screen it's still 
my favorite.
I love NVDA's object nav but it's quite different than using cordinates 
to find things.
If I had one wish for a tool for NVDA is that we could have a cordinate 
tool which works on the top level window name like we have for the other 
readers, just for finding things and cordinate reference, even if we 
don't have the sophisticated hsc kind of thing yet.
Gish Jamie, if I had 50 grand, I'd just hire you and say, ok, write us 
an hsc equivalent for NVDA.
I know you have other stuff to do,
but one can dream right?
Wel, golden cursor is a nice first run,
NVDA is kicking butt and taking names, I'm not religious about 
screen-readers as you know, I am a multi-tool user, and that kind of 
makes me in the minority, people still tend to grab one and say, this is 
it and you just can't do that these days if you want it all.
Because they all do sometehing well,
but over-all I am finding NVDA out performs everything else I have,
even if the upper level hold my hand tools are not quite developed yet.
Especially on the web,
I am just amazed at how far and how fast this little reader has come,
my wife is even a hard core convert now,
but I still keep all three readers on the screen because by god,
there will be that one thing one will do that the others won't
what ever it might be.
and some of it's down to gray matter as well, window-eyes having been my 
first reader, I know it the most intimately,
then learned jaws to help my students, and NVDA came last,
and you know I don't have your giant brain, I have to make up for it in 
pure stubbornness and patience 'grin'.
have a good one.
and thanks for all you do.


On 3/10/2016 5:24 PM, James Teh wrote:
> There are two possibilities regarding the coordinate differences:
> 1. I *think* Golden Cursor uses screen coordinates, not coordinates 
> relative to the top level window, but I'm not certain.
> 2. If you have a high DPI screen, this could be due to DPI scaling. 
> REAPER is not DPI aware, so Windows scales it up for the actual 
> screen, but inside REAPER (and for other non-DPI aware apps), the 
> coordinates will be as if you didn't have high DPI. JAWS and 
> Window-Eyes do much of their work by injecting code inside the app 
> (e.g. REAPER) itself, so they probably see the non-scaled cordinates. 
> AutoHotkey probably isn't DPI aware, though I'm not certain. NVDA is 
> definitely DPI aware and it does much of its work from outside of the 
> app, so it sees scaled coordinates. Try dividing the coordinates by 
> 1.25 or 1.5 and see if they match.
>
> Jamie
>
> On 11/03/2016 1:08 AM, Chris Belle wrote:
>> If anyone wants to mess with this, here's my auto-hot script I did 
>> years ago probably around reaper 4 for the sfz player.
>> I will include source ahk file so spots can be adjusted if necessary.
>> You do need to run this one with the plug-in opened in a dedicated 
>> process, ie in a separate window.
>> I tried to get this to work from the fx window with the sfz window in 
>> there, but I could not, not sure what all the differences are yet, 
>> but I know it works with the separate window.
>> I want to make some comments about what I've noticed working with 
>> golden cursor as well.
>> When I was trying to re-produce what I had done with ahk in golden 
>> cursor, I noticed that even in the separate window, my cordinates 
>> were way different than what I had with ahk and window-eyes and jaws.
>> they are reporting on the actual window of the dedicated process I 
>> think while golden cursor is still using reaper as a reference, so 
>> it's almost like that window is still in the fx window.
>> Golden cursor can't get a reading from the bridged window the plug-in 
>> opens in, but funnily enough, autohotkey can.
>> Wen I tried to save spots using golden cursor it kept erroring out, 
>> once it couldn't find the spots file, then it saved it in my old 
>> reaper file which i made in the first place, another time it did 
>> something called explorer.
>> so there is some crazy jiggery pokery going on as Scott says,
>> ha.
>> Now maybe autohot doesn't have to search for an actual window but can 
>> ping in on the title bar,
>> I know that program is pretty sophisticated, I did pretty good with 
>> it for my skill level with coding, but the deeper elements of it are 
>> beyond me, it comes with some sniffer tools,
>> I have sniffed out controls and such and done some primitive object 
>> oriented programming, calling control names instead of just clicking 
>> on a pixel, and calling other executables, I built a little program
>> to un-mute the sound card which is just a brute force thing that 
>> turns on your sound card, and pushes volumes up and even runs 
>> narrator, just to get myself out of trouble, the difference in this 
>> thing and others is you don't have to install it.
>> But I am not a serious programmer, but if I can I like to use these 
>> little helper tools to help myself and others, and I've even sold a few.
>> but right now
>> as far as I can tell, the bridged window in separate process is not 
>> compatible with the non bridged version in the fx window, I'll have 
>> to poke around to see if some sort of off-set is happening,
>> becaus when I used golden cursor,
>> it did actually kick me off in the other window as if I were there.
>> Even though it can't see the window title if I actually go in there,
>> and doesn't work, if I stay in reaper, it will kick me off in the 
>> other window as if it were still in the fx window I hope I haven't 
>> confused everybody too badly.
>> This whoe thing is confusing, I'm just trying to figure out what 
>> works with what, but right now I know this.
>> My ahk script works if I put sfz in the separate dedicated process 
>> window.
>> And it can trigger on the fact that sfz is in the title name.
>> I have golden cursor working if i do it standard sfz in the fx window 
>> way, and then it creates a file called reaper.gc
>> so it's triggering on reaper itself,
>> which I suspect is not the top level window name but the main 
>> application window name,
>> when I tried to save things in golden cursor while in the bridged 
>> window in separate process thing, it did weird things, and nothing 
>> consistant, so there you have it.
>> Jamie, I do realize now the point you were making, that the plug-in 
>> window may not have a name, and it is in a wrapper and that is probably
>> the window name, I hope I got it right now,
>> you and snow man
>> understand the programatical elements
>> a whole lot better than I do, I'm one of these people just trying to 
>> find out what works,
>> and go with it, but here's another funny thing I can't figure out why 
>> it's not working.
>> I can not make autohotkey work in the non bridged mode at all, even 
>> when I take out the window criteria,
>> or put in what's in the title bar in the fx dialogue, or what I can 
>> see of the sfz window below it,
>> it won't run.
>> I can tell because even if I click something with a macro in the 
>> wrong place, it will tell me something happened, but nothing is 
>> happening.
>> I use jaws or window-eyes
>> when trying to make cordinates a lot of the time to find out where 
>> things are because NVDA doesn't have a native mode to tell the pixel 
>> distance in the window you are in, maybe I need to go grab that old 
>> mouse movement thing you wrote me a long time back, and see if it can 
>> do anything golden cursor can't, but
>> I know that jaws and wineyes will both translate to one another 
>> pretty well in the active window you are in.
>> So i tend to flop around from diferent readers to tell what's going on.
>> When we get a tool which can read from the top left of any given 
>> window whether child or parent, with NVDA then I won't have to do 
>> that anymore, but hey, Rome wasn't built in a day.
>> I was just rying to make some simple spots for peole and here we went 
>> down a rabbit hole, but I am learning so hey, that's good.
>> Thanks to both of you Jamie and snowman and your giant brains for all 
>> you do.
>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>