Hey, I just love that disclaimer at the end of your message. Way Cool!
-----Original Message----- From: Chris Belle [mailto:[email protected]] Sent: Friday, April 16, 2010 9:06 PM To: [email protected] Subject: RE: hotspot observations and maybe some constructive remarks >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. 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.
