[Rwp] Plug-in hot spots
Snowman
snowman at snowmanradio.com
Wed Mar 9 22:27:42 EST 2016
Right,
HSC can search the entire system for a window with certain attributes.
But the problem it often has is that the window you actually need to use as
the reference has a control ID which is equal to the handle, and thus
dynamic, has no name, might even be a dynamic window class, is an unknown
type and subtype, and can't be distinguished from any number of other
windows in the system.
One way to deal with that is to search for one that you, can, uniquely
identify, which is up the tree from the one you actually want, and then
provide an x-path to crawl down the tree from the one you found, to the one
you need.
HSC doesn't do that. It does know how to do it with MSAA objects, but not
windows. It could, but I haven't told it.
At some point, I just broke off and said, if you want to do complicated
things like that, learn to write scripts.
----- Original Message -----
From: "James Teh" <jamie at nvaccess.org>
To: "Reapers Without Peepers" <rwp at bluegrasspals.com>
Sent: Wednesday, March 09, 2016 5:29 AM
Subject: Re: [Rwp] Plug-in hot spots
> That's just the thing. Your parent, top level, whatever you're calling it
> isn't actually the plug-in window. The plug-in window is several windows
> beneath that. If you were dealing with the plug-in window itself, you
> wouldn't have to worry about bridging or not bridging. For the most part,
> the plug-in window usually doesn't have a name at all. The window you're
> talking about is generated by Sonar/REAPER, not the plug-in.
>
>
> On 9/03/2016 9:27 PM, Chris Belle wrote:
>> Right that's how sonar does it with ahk and hsc.
>> the only time you want to use the parent window name is if you were doing
>> sets for botgh daw's and the plug-in windows were named the same.
>> I was meaning the closest title or plug oin window when I said top level
>> window,
>> on top of the tree.
>> But I'll start saying child and parent.
>> I get confused, there are so many types of windows, for instance
>> window-eyes uses overlap, and focussed,
>> and current and
>> on and on,
>> jaws kind of does that too, along with home row and other stuff,
>> but i understand parent and child.
>> It's just different terminology but we're talking about boxes inside of
>> boxes,
>> and we want to take the smallest box outside of the big box so we can
>> root around inside it and see what's in it.
>> right now with my set-up reaper isn't cooperating, the window is opening
>> up I can use object nav and see the title window of say sforzando or
>> dimension pro,
>> but it is incdeed opening up inside the fx window.
>> So I need to figure out how to get it to fly outside.
>> and I don't have those controls where I remember them being.
>>
>>
>> On 3/9/2016 5:15 AM, James Teh wrote:
>>> Actually, every plug-in renders at least one real "window" (or HWND)
>>> according to Windows. The problem is that many plug-ins just draw only
>>> into this single window. REAPER, Sonar, etc. don't do any interpretation
>>> at all; they just provide a parent window in which the plug-in can
>>> create its own windows. The reason coordinates are different in Sonar
>>> and REAPER is that coordinates in hot spot sets are being based off the
>>> top level window, which is, for example, the REAPER FX Chain dialog, the
>>> Sonar FX window, etc. I'm suggesting that they could instead be based on
>>> the plug-in window *beneath* that top level window, which would mean
>>> they're the same for every single DAW.
>>>
>>> Jamie
>>>
>>> On 9/03/2016 9:01 PM, Alan wrote:
>>>> If I am not wrong, James, the bridge window is like a container for non
>>>> standar controls deffined by each plug in. However, it is not a real
>>>> window, but a kind of generated layout, so reaper, sonar or any daw
>>>> makes is own interpretation, that is the reason behind the need of a
>>>> different set of hotkeys for each daw. the window on screen is not a
>>>> real window according to the windows operating sistem api, so you
>>>> cannot access programatically to its properties.
>>>>
>>>>
>>>> Enviado desde mi iPhone
>>>>
>>>>> El 9 mar 2016, a las 11:39, Chris Belle <cb1963 at sbcglobal.net>
>>>>> escribió:
>>>>>
>>>>> Here's my thinking.
>>>>> If there's a compelling reason to go to fractions then we should, but
>>>>> right now jaws and window-eyes use cordinates which you can easily
>>>>> look at and translate say you want to re-produce
>>>>> the hard work
>>>>> of an hsc guy,k you can look in the file and say ok, the load button
>>>>> for sfz is 193,86
>>>>> relative to the child window cordinates.
>>>>> So that's easy to do, and it doesn't seem child windows resize that
>>>>> much or if they do those cordinates seem to always work,
>>>>> maybe they stay relatively the same in ahk and hsc,
>>>>> that no matter how the windows shrink or grow the cordinate amounts
>>>>> stay the same.
>>>>> At least it seems to do so in sonar.
>>>>> I don't know how they're pulling this trick off,
>>>>> because I change display sizes and it doesn't usually break the hsc
>>>>> sets.
>>>>> But if it does, then the bottom number seems to be more critical,
>>>>> like 1024 by 768
>>>>> if you change the 768 it breaks more hsc sets.
>>>>> But that's the whole screen, the numbers of pixels across and down a
>>>>> child window seem to stay the same.
>>>>> Anway it's easy to see what been done, and if we stay compatible with
>>>>> other tools doing this already, then we can share a lot more and not
>>>>> re-envent the wheel, unless there's a good reason to do so.
>>>>> Just thoughts,
>>>>> both jaws and window-eyes can use cordinate related to other windows
>>>>> than just the child window,
>>>>> and maybe we could take advantage of NVDA's object nav and use
>>>>> container edges when they're available, and other stuff to zoom in on
>>>>> stuff even more.
>>>>> With the jaws version there are lots of criteria you can use,
>>>>> but like I said, even though I've done some hsc dev, the tool I am
>>>>> most familiar with is auto hot key.
>>>>> It uses the title window you are working with,
>>>>> and it can defferentiate between the parent and child windows
>>>>> where it can fall down is when you need to drill down further than
>>>>> that and say you have different windows that open up in a child window
>>>>> say for instance sessindrummer 3 has a drumkit page and
>>>>> a mixer page, but both have the same title window.
>>>>> I hacked around it in autohotkey,
>>>>> which can use hot strings and so doesn't limit the number of hotkeys
>>>>> you can use,
>>>>> but I ran out of hotkeys in the jaws vesion and tried to make another
>>>>> hsc set for the mixer window but I had to hard-wire manually loading
>>>>> that set since the title windows were the same.
>>>>> Hsc has come a ways since i did that a few years ago, but being able
>>>>> to designate a certain conrol or string, or something to say, hey,
>>>>> this set of controls is active now, use this set of commands and
>>>>> ignore those others,
>>>>> I hope I'm making sense.
>>>>>
>>>>>
>>>>>> On 3/9/2016 4:14 AM, Chris Belle wrote:
>>>>>> I meant the plug-in window.
>>>>>> Not the application main window.
>>>>>> Yes, we need to zero in on the closest container,
>>>>>> for some reason I was thinking hot spot clicker called the top level
>>>>>> window the child window,
>>>>>> but yeh, when I made my sfz ahk thing for reaper years ago I did it
>>>>>> for the
>>>>>> window opening up in a separate window, and the sfz window title.
>>>>>> Like it's supposed to be.
>>>>>>
>>>>>>
>>>>>>> On 3/9/2016 3:59 AM, James Teh wrote:
>>>>>>> My point is that the top level window isn't good enough. That's why
>>>>>>> it breaks when you use a different host or change bridging modes.
>>>>>>> The plug-in itself has a window beneath the top level window and I'm
>>>>>>> arguing that coordinates should be based off that window, not the
>>>>>>> top level.
>>>>>>>
>>>>>>> As for fractions being difficult for humans, that's certainly true,
>>>>>>> but I'm imagining a tool would calculate this for you. This is done
>>>>>>> already to some extent with HSC.
>>>>>>>
>>>>>>> Sent from a mobile device
>>>>>>>
>>>>>>>> On 9 Mar 2016, at 5:18 PM, Chris Belle <cb1963 at sbcglobal.net>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hey Jamie,
>>>>>>>> You are right, I am not the top dog developer of the pack,
>>>>>>>> but I have used both hsc, and ahk and also hotspots from
>>>>>>>> window-eyes
>>>>>>>> and golden cursor and I can see the differences in each method.
>>>>>>>> You definitely want that top level window going on,
>>>>>>>> hsc can slice it any way you want to,
>>>>>>>> with lots of criteria for determining cordinates, but the most
>>>>>>>> common used is the plug-in name, or immediate application name.
>>>>>>>> And yes, doing it with the plug in a separate windows is best.
>>>>>>>> When I did my spots for golden cursor I was racking my brain on how
>>>>>>>> to make the plug express in a separate window, I have done this
>>>>>>>> before as I made the ahk script for sfz a while back for reaper,
>>>>>>>> but I'll be darned if I can remember where that setting is, maybe
>>>>>>>> it's not there anymore.\
>>>>>>>> I look in vst and compatibility, and plug-ins,
>>>>>>>> but I can't find that open plug in a separate process anymore.
>>>>>>>> Huh, it's hell getting old,
>>>>>>>> but anyway, I did the best I could,
>>>>>>>> but the way I did it depends on the limits of golden cursor which
>>>>>>>> can only ping the main application,
>>>>>>>> so if the plug moves around, or changes some how, it won't account
>>>>>>>> for that.
>>>>>>>> But Rome wasn't built in a day,
>>>>>>>> we got to start someplace right?
>>>>>>>> I think a good first move would be to have that top level window
>>>>>>>> name and I think it will be easier for folks to remember cordinates
>>>>>>>> when programming instead of fractions, that seems to be the way
>>>>>>>> everyone else does it,
>>>>>>>> going by the top left corner,
>>>>>>>> of the window, other wise, you'd have things like what the heck 600
>>>>>>>> by 800, and I'm at 125,136 what the heck is the fraction for that?
>>>>>>>> Maybe some sort of way to auto-resize,
>>>>>>>> anyway, people with higher pay grades than me can figure out the
>>>>>>>> inner gears of this stuf,
>>>>>>>> I can squeeze the oil can, and turn a screw driver, and wipe a rag,
>>>>>>>> but someone else will have to build the engine from the whole frame
>>>>>>>> 'grin'.
>>>>>>>> Thank you for your attention to this, one final thought,
>>>>>>>> I think hsc and ahk do searches by color and such from matching
>>>>>>>> patterns, and they set restrictinss on how far to search up and
>>>>>>>> down, it can get terribly complicated,
>>>>>>>> but for us just having basic find me here in this location will be
>>>>>>>> a great start.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 3/8/2016 10:49 PM, James Teh wrote:
>>>>>>>>> Hi plug-in hot spot creators (HSC, AutoHotkey, whatever),
>>>>>>>>>
>>>>>>>>> As I've watched discussion about creation of hot spots for
>>>>>>>>> plug-ins and associated problems, I've been starting to wonder
>>>>>>>>> about why they aren't done in a way which makes them more reliable
>>>>>>>>> across different configurations. I don't have much experience in
>>>>>>>>> this area, so there may well be a good reason and I'm just not
>>>>>>>>> seeing it. So, I'd appreciate some thoughts on the below.
>>>>>>>>>
>>>>>>>>> In the following discussion, let's assume we're dealing with
>>>>>>>>> simple hot spots; i.e. spots which don't change such as the
>>>>>>>>> program browser button in Dimension Pro, the load button in SFZ,
>>>>>>>>> etc. I realise there are many cases where this isn't the case, but
>>>>>>>>> that's beyond the scope of what I'm getting at here.
>>>>>>>>>
>>>>>>>>> As I understand it, there are two main problems that cause basic
>>>>>>>>> hot spots to be unreliable:
>>>>>>>>>
>>>>>>>>> 1. Different screen resolutions/DPI settings. If hot spots are
>>>>>>>>> created for one screen configuration, they sometimes don't work on
>>>>>>>>> other configurations.
>>>>>>>>> I notice that even though some hot spots use relative coordinates,
>>>>>>>>> they're still absolute as far as the window is concerned. That is,
>>>>>>>>> they don't account for the window being a different size, only the
>>>>>>>>> window being in a different starting position. So, why not use
>>>>>>>>> width and height fractions? So, if the coordinate is half way
>>>>>>>>> across the width of the window, you would store 0.5 instead of an
>>>>>>>>> absolute value like 200. This way, if the window shrinks to half
>>>>>>>>> size, you can still calculate the correct coordinates. In
>>>>>>>>> practice, some windows probably don't resize everything in direct
>>>>>>>>> proportion, but I would have thought this would be more rare than
>>>>>>>>> not.
>>>>>>>>>
>>>>>>>>> 2. Different applications. Hot spots created for Sonar don't work
>>>>>>>>> in REAPER and vice versa. Even in REAPER, hot spots created for
>>>>>>>>> bridged don't work in non-bridged.
>>>>>>>>> From what I've seen, even hot spots that are relative are
>>>>>>>>> calculated relative to the top level window. The problem is that
>>>>>>>>> the top level window is part of the host (e.g. REAPER), not the
>>>>>>>>> plug-in. That means it's going to be different for every host. So,
>>>>>>>>> why not calculate the coordinates relative to the window for the
>>>>>>>>> plug-in itself? The plug-in should render exactly the same way no
>>>>>>>>> matter where it's hosted. Therefore, if coordinates are all
>>>>>>>>> relative to the plug-in window, they will work the same regardless
>>>>>>>>> of the host used.
>>>>>>>>>
>>>>>>>>> On a related note, I'd be interested to know whether it'd be worth
>>>>>>>>> implementing some kind of basic hot spot support into OSARA. The
>>>>>>>>> question is what kind of complexity is needed for the majority of
>>>>>>>>> plug-ins. I know HSC has support for searching for colours, etc.,
>>>>>>>>> but I never quite grasped how this was applied in practice.
>>>>>>>>>
>>>>>>>>> I'd appreciate any thoughts.
>>>>>>>>>
>>>>>>>>> Jamie
>>>>>>>> _______________________________________________
>>>>>>>> RWP mailing list
>>>>>>>> RWP at bluegrasspals.com
>>>>>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>>>>> _______________________________________________
>>>>>>> RWP mailing list
>>>>>>> RWP at bluegrasspals.com
>>>>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>>>> _______________________________________________
>>>>>> RWP mailing list
>>>>>> RWP at bluegrasspals.com
>>>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>>> _______________________________________________
>>>>> RWP mailing list
>>>>> RWP at bluegrasspals.com
>>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>> _______________________________________________
>>>> RWP mailing list
>>>> RWP at bluegrasspals.com
>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: jamie at nvaccess.org
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>
More information about the RWP
mailing list