Hi guys,
Well, I've been putting hotspot through it's paces, and have been
pretty pleased at what I've been able to accomplish for the most part.
I find being able to string all these commands together very helpful
and one could almost do anything one needed to to make an app talk
that otherwise wouldn't.
In my last post on this subject, I refered to hotspot not always
getting the cordinates right even when I used the use current button,
sometimes even when the cordinates exactly match the actual screen
cordinates, the mouse gets moved somewhere else.
My work around was to use a setfile and route the mouse to a
pre-defined window using hotspot to do the grunt work, ie, load up
the set file and trigger the relevant keys.
this is a good work around.
But one thing I'm noticing that might be a real show stopper is the
inability for hotspot to differentiate between child windows of an
app like sonar.
This means that one will very quickly run out of hot-keys because you
can't use different hotspot environments for different plug-ins.
Seems to me at one time way back in the early hotspot days, that when
I'd create spots say for sfz, I actually got sfz as a window title
for triggering, as well as sonarpdr and of course, global.
Then we had a couple of versions where hotspot got confused and
couldn't find it's spots, and now we are working again with the slick
new stuff, but what this wonderful tool needs to make ot perfect, or
as perfect as software can ever get is the ability to differentiage
between top level window titles like hotspot clicker or auto hotkeys does.
Actually, hsc will trigger on any number of things, window class,
object, app name, top level window name, etc, most of the time you
don't need the extra junk, but that top level child window seems to
always work.
Now what could we maybe do to give hotspot users more control over
what hotspot environment gets loaded when in different child windows
or plug-ins?
Could we look for a text string in the window title or any
criteria which is specific to just that child window to trigger only
a specific set of hotspots?
One thing I just tried was to inport all my hotspots from a sonar 8
session to try and use them with sonar 6 and that didn't work.
When I used the hot keys, I got nothing, but when I manually
triggered the spots with the hotspot dialogue, I got that long
standing can't find window error, but instead of crashing the hot
spot script eventually found the spot and triggered it but not until
asking me if I wanted to search for it and telling me it couldn't be
found, but actually it did route the mouse.
I know top level window names can change, but with the jaws hsc what
we try to do is to find a part of the top level window name that
doesn't change, and use that, the karet ^ symbol is a wild card which
allows that for that script, but what won't change for most people no
matter what version of sonar they're running is the actual name
sonar, and say a child window might say sfz1 or sessiondrummer 2 but
we just look for sessiondrummer or sonar without the numbers, or any
of the dynamic information.
Anyway, just some thoughts.
One partial way I've figured out how to get new environments is to
load different setfiles, but if we had this kind of control over
hotspot itself, it would just rock the sky would be the limit.
All the best over there, and I'll keep working with this tool and see
what else I find.
I've already got spots with 4 or 5 actions
to do complex things it's great.
WARNING!!!
This email could contain innocent phrases which, if taken out of
context, or read from an existing inclination to be hostile, or an
overly politically correct world view could induce cursing, abusive
language, or other indications of less than desirable behavior in a
public venue.
No ill will is intended.
The sender takes no responsibility for mis-interpretation or
otherwise extrapolated extended meaning, intent, or purposes implied
or imagined from said phrases.
The receiver of any such email containing such phrases is solely
responsible for good
interpretation and intelligent deployment of subsequent responses to
the above communication.
If you reply to this message it will be delivered to the original sender only.
If your reply would benefit others on the list and your message is related to
GW Micro, then please consider sending your message to [email protected] so
the entire list will receive it.
GW-Info messages are archived at http://www.gwmicro.com/gwinfo. You can manage
your list subscription at http://www.gwmicro.com/listserv.
