210 replies to this topic

[cheek]

damnit. This whole posting as 'guest' thing annoys me. That was me

[MainTrane]

Hi cheek, nice to see so much progression on this script. What tool would you recommend to analyze specific window elements?
I'm trying to provide an app setting for jdownloader, which accepts the wheelkey method, but neither the window class nor javaw.exe works.
I was able to give firefox its own specific setting, so I can confirm the update runs fine with ini settings.
UPDATE: tried SysTree++; it doesn't seem to be able to see jdownloaders list elements. Most likely due to it being a java program.

[cheek]

I had actually thought about updating that post with information on how to find class names and such, but the accidental guest post means I can't. I also found a bug in the sample config posted there that I can't correct

As far as determining class names, you should just be able to use Window Spy that comes with autohotkey. Im sure there a number of forum posts on how to use it, if you haven't before.

I actually happen to have a copy of jdownloader, mine reports the window class as SunAwtFrame, so you could use that class name, or the processname javaw.exe. Be warned though, that both of these would match more than just jdownloader; basically all java apps. That may actually be the behavior you want for Java apps in general though, as I suspect that java does not respect windows messaging. That's probably also the reason that you cant use specific control classes, because Java apps do not use windows controls, they use Swing or AWT controls, which do not appear to have classnames visible to windowspy.

You may be running into the same bug I noticed however, where if you apply a comment above the section name, as in the example above, that section name is not parsed correctly, and not picked up as settings. This appears to be a bug in the INI lib. If you have any comments like below, remove them and see if that fixes it.

; Addding a comment here ignores the whole section
; remove these comments
[javaw.exe]
ScrollMethodY=WheelKey

[MainTrane]

Not using any comments in my ini file :?. It seems I'm running into a bug where the method is not being overridden, though the speed can be.

EDIT: poked around some more; it's definitely app specific. Firefox recognizes all changes (method, disabled, speed). Other objects such as JDownloader and the windows taskbar (scrolling taskbar changes volume via Volumouse) do not recognize anything besides speed adjustments, standard & edge speeds tested OK.

[cheek]

I did a bit more looking, and found a bug that would be caused by specific applications, in this case java, because the control class could not be found. Specifically, not checking for empty strings is a problem.

Ive updated the file at https://ahknet.autoh...ragToScroll.ahk with the following correction, and other minor fixes. Hopefully that should fix it..

    if ([color=red]CtrlClass && [/color]InStr(ConfigSections, CtrlClass))
      SectionName := CtrlClass
    else if ([color=red]WinClass && [/color]InStr(ConfigSections, WinClass))
      SectionName := WinClass
    else if ([color=red]WinProcessName && [/color]InStr(ConfigSections, WinProcessName))
      SectionName := WinProcessName

[MainTrane]

This update solved the JDownloader problem; I'd assume any other java apps too.
The Windows taskbar is affected by the INI settings after all, but not on the initial attempt for disabling.

Disabling per app is not recognized on the initial drag, any subsequent drags obey the INI setting. Disabling per app breaks DtS; after the second drag on a disabled app DtS is permanently disabled system wide (icon shows enabled). A reload obviously fixes the issue, but disabling/enabling doesn't.

:!: [.NET APPS] Another app group that seems to ignore INI settings. Tried w/ MouseExtender, WheelKey method, but got no response.

Paint.NET seems to override all mouse input once an image is loaded, so use with this prog isn't a possibility?UPDATE: JDownloader does not respect 'UseEdgeScrolling=true' or 'ConfineToWindow=false'. This is a global issue regardless of INI settings.
UPDATE2: MouseExtender does respond to per-app settings (I probably had the speed set too high, 5.0) So there's no more evidence of per-app-.NET incompatibility :!:

[cheek]

Phew! Glad I posted this as a beta.... Didn't expect there to be so many issues. Guess I should have, opening up to app customizations for the thousands of apps people use Thanks for the feedback.

This update solved the JDownloader problem; I'd assume any other java apps too.
The Windows taskbar is affected by the INI settings after all, but not on the initial attempt for disabling.

Disabling per app is not recognized on the initial drag, any subsequent drags obey the INI setting. Disabling per app breaks DtS; after the second drag on an app DtS is permanently disabled system wide (icon shows enabled). A reload obviously fixes the issue, but disbaling/enabling doesn't.

My best guess here is that you're hitting something else I saw: I was testing per-app disabled settings with the remote desktop window and saw that it was not updating the window information on subsequent drags. So the Disable setting worked great, but then it LEFT it disabled because DtS thought it was still interacting with remote desktop.
If you use RD, this as interesting one.. I connect to work from home, and run DtS on both computers. When you drag on the client machine, it captures the click and actually sends scroll messages to the RD window. The messages are sent through to the remote app correctly, but If you use per-app disable, its actually sending the RButton hold and move through RD, and the remote system's DtS is able to pick it up, and load remote system app customizations.Ive (re-)added a cleanup section to the end of dragging, to clear variables so you should start fresh each time. This corrected the behavior I was seeing, hopefully yours too.


Debugging
There's lots of commented out debugging ToolTips in the code, that can help to tell you whats going on under the hood. For app customizations, the GetSetting method has a tooltip that should show you which window DtS is interacting with, and the override it loaded.Uncomment the lines below

temp := ini_getValue(ini, SectionName, name)
  ;if (temp)
  ;  ToolTip("INI [" . SectionName . "] " . name . "=" . temp)
  return temp

:!: [.NET APPS] Another app group that seems to ignore INI settings. Tried w/ MouseExtender, WheelKey method, but got no response.

Paint.NET seems to override all mouse input once an image is loaded, so use with this prog isn't a possibility?

I doubt its all .Net apps, i've used it successfully with other .Net built apps. I tried it with Paint.Net and was not having any problems with vertical scrolling; Horizontal is still a problem. Lots of apps don't like to do horizontal scrolling; it wasn't introduced until a while after vertical scrolling.

I also had a copy of MouseExtender (never really used it), but I suspect THAT is an app that's not going to work. Its not using standard windows controls, so I suspect it wont respect WM_*. I'd expect WheelKey to work, but I didn't see what scrolling actually would do; don't think i have enough items to scroll anyway. It may be related to mouse position,WheelKey is kind of limited compared to the other scroll methods, it simply does Send {WheelUp}. This means that its not sending scrolling to the application. Depending on your system settings, the window may have to have the target app 'active' and/or you may need to keep the mouse hovering on the window. WheelMessage on the other hand, always sends scroll to the app & control initially clicked on, regardless of what is active or where the mouse is.


Grab the update from Autohotkey.net

[MainTrane]

JDownloader ⁞ the comment is just to convey my standard use of the program, DO NOT COPY THE COMMENT

;JDownloader [window dimensions 960x600]

[SunAwtFrame]

ScrollMethodY=WheelKey

SpeedY=1.0

[cheek]

UPDATE: JDownloader does not respect 'UseEdgeScrolling=true' or 'ConfineToWindow=false'.

In the version you have, edge scrolling and ConfineToWindow are not checked for per-app settings. In this last update I added EdgeScrolling, but Confine is not. In general, (for now, unless this changes) to make a setting app customizable, wrap it in the Get() method.. So for ConfineToWindow, you:

    if ([color=red]Get("[/color]ConfineToWindow[color=red]")[/color] && WinHwnd != NewWinHwnd)
      GoSub DragStop

edit Actually, looks like only the edge scrolling speed is per-app at this time. UseEdgeScrolling is not per app, but, as above, simply wrap all usages in Get(). Will include this later...

This is a global issue regardless of INI settings.

Do you mean that NO app respects those settings in INI, or do you mean JDownloader never respects those settings, regardless of INI or using standard settings? I wasn't having problems with it, but then I don't have anything to scroll. I was seeing scrolling properly start&stop according to Confine.

For EdgeScrolling, I have noticed that this can sometimes be a problem. I think its windows incorrectly reporting their size. There is a debugging tooltip in the EdgeScrolling section which tells you how far you are from the reported edge, and when DtS starts scrolling.

the comment is just to convey my standard use of the program

Be sure NOT to include this comment in the actual INI file, as it appears to cause problems.

[MainTrane]

My best guess here is that you're hitting something else I saw: I was testing per-app disabled settings with the remote desktop window...

I doubt its all .Net apps, i've used it successfully with other .Net built apps. I tried it with Paint.Net and was not having any problems with vertical scrolling; Horizontal is still a problem. Lots of apps don't like to do horizontal scrolling; it wasn't introduced until a while after vertical scrolling.

No, not using RD. I don't know if Actual Window Manager could be causing some interference.
Verticle scrolling in Paint.NET seems to be OK now (haven't updated yet), don't know what was going wrong earlier :roll:.

Horizontal scrolling really has some weird behavior in Winamp's media library and Internet Download Manager, but I had already chalked that up to HScroll being finicky in general.

DtS works with MouseExtender when the method is changed globally to mWheelKey, so it is compatible. It does not work through app specific setting though. I'm not interested in using DtS with ME :wink: I was just using it as an example of a .NET app, there may be analogous apps.

Debugging
There's lots of commented out debugging ToolTips in the code, that can help to tell you whats going on under the hood. For app customizations, the GetSetting method has a tooltip that should show you which window DtS is interacting with, and the override it loaded.Uncomment the lines below

temp := ini_getValue(ini, SectionName, name)
  ;if (temp)
  ;  ToolTip("INI [" . SectionName . "] " . name . "=" . temp)
  return temp

Where should I add the above code?

[MainTrane]

Do you mean that NO app respects those settings in INI, or do you mean JDownloader never respects those settings, regardless of INI or using standard settings? I wasn't having problems with it, but then I don't have anything to scroll. I was seeing scrolling properly start&stop according to Confine.

For EdgeScrolling, I have noticed that this can sometimes be a problem. I think its windows incorrectly reporting their size. There is a debugging tooltip in the EdgeScrolling section which tells you how far you are from the reported edge, and when DtS starts scrolling.

I meant JDownloader doesn't respect the settings whether it be global or app specific. UseEdgeScrolling=true and ConfineToWindow=false work fine in all other uses.

the comment is just to convey my standard use of the program

Be sure NOT to include this comment in the actual INI file, as it appears to cause problems.

I posted the JDownloader setting for other users. I added the line you quoted above to make sure no one else copies the comment. I'll elaborate on the comment :wink:

[cheek]

No, not using RD. I don't know if Actual Window Manager could be causing some interference.

Doesn't have anything to do with RD directly, just an example of a GOOD use (mine ) of per-app settings, under which I was seeing the same behavior. I believe the issue was not cleaning up..... That doesn't address why the new window was not found, but cleaning up after avoids the issue entirely. Did the update correct this? Debugging definitely helps here....

Where should I add the above code?

All of the debugging code, (there's lots of it) is ALREADY in the code, but commented out. The lines I pasted there are actually from the script. Those specifically are in the GetSetting() function, around line 1220.

There's also some useful debugging statements in the CheckEdgeScrolling label, 2 lines around line 755. (or just search for "@Edge") Just uncomment any of these tooltip lines. I checked JDownloader, and its reporting the edge somewhere in the middle of the window..... unless ive got a math error somewhere.

[MainTrane]

Time for another update!

Hey all,
I'm in the middle of an (promised) update to better handle script settings. This update has two goals: [*:3buivx7r]Store user settings separately from the script, so that they are retained between updates...

How do I achieve this? I've added this:

Button=MButton
DragDelay=250
PollFrequency=10
DragThreshold=7
SpeedX=0.1
SpeedY=2.2
UseMovementCheck=true
MovementCheckDelay=333
MovementThreshold=13
ScrollMethodX=WheelKey
ScrollMethodY=WheelMessage
InvertDrag=false
UseEdgeScrolling=true
EdgeScrollingThreshold=20
EdgeScrollSpeed=3.3
ConfineToWindow=false
ConfineToControl=false
UseAccelerationX=false
UseAccelerationY=true
MaxAcceleration=10
MomentumThreshold=3
MomentumStopSpeed=0.4
MomentumInertia=.90
UseScrollMomentum=false
Loop, %MaxAcceleration%
   Accel%A_Index%=.006 * A_Index **2 + 1
DoubleClickThreshold=DllCall("GetDoubleClickTime")
UseDoubleClickCheck=true

to my INI file. Is that the proper way to retain global settings between updates?