Anyone want to test v2.1 (Beta)?

[phil]

If anyone wants early access to v2.1, then I have just put v2.1 Beta1 online.
Be aware, v2.1 is a minor update with a few bug fixes and no significant new functionality.

This is the fix list:

• Fixed simulated keys in IE9 and other apps that use multiple processes (chrome?)
• Changed code to allow user mapped tilt when other buttons are held down.
• Fixed scroll under cursor in VS2010 using new method 5 in advanced scrolling.
• Fixed high CPU usage/mouse lag around the edge of the desktop area.
• A few other minor fixes like spelling mistakes!

EDIT: beta 2 released with a few more fixes, see below.
EDIT: beta 3 released with a few more fixes, see below.
EDIT: beta 4 released with a few more fixes, see below.
EDIT: beta 5 released with a few more fixes, see below.
EDIT: beta 6 released with a few more fixes, see below.
EDIT: beta 7 released with a few more fixes, see below.
EDIT: beta 8 released with a few more fixes, see below.
EDIT: beta 9 released with a few more fixes.
EDIT: beta 10 released with another fix, see below.

NOTE: This beta has closed as version 2.1 has been release!

If you find any problems let me know - I hope to release this as soon as I can fully test the last fix.

Thanks,
Phil

[clm_de]

Again, thanks for your great work.

I've just tested 2.1.1 with my setup (VS2010 on W7x64) and a quick test with several edit windows shows the desired behaviour - the scroll wheel works!

A sligth stumble I had setting it up.

I added a window profile to use the new "method 5" and used the "find window" method, pointing it to the application's main window, which resulted in the correct process name and a class name, but no parent class name.

No result.

To get it to work, I had to swap class name and parent class name, so that class name remains empty and parent class name contains what "find window" originally returned as class name.

Now it works like a charm.

A final idea:
Wouldn't it be useful to initialize the "Advanced Window Scrolling" lines and character parameters with what is already set up in Windows' control panel?

These parameters are stored in the registry:
[HKCU\Control Panel\Desktop]
WheelScrollChars (REG_SZ)
WheelScrollLines (REG_SZ)

Again, thanks from Berlin to Maidenhead!

Claudius

[phil]

Hi,

Firstly, I'm glad it works

I'm not sure why you had that stumble setting it up... On my machine I pointed to the sourcecode window and that was all I needed to do.

The parent class is/was empty but all that means is that XMBC does not care what the parent is.
I will try and see if there is anything I can do to make it easier.

A final idea:
Wouldn't it be useful to initialize the "Advanced Window Scrolling" lines and character parameters with what is already set up in Windows' control panel?

The value in here do not necessarily translate directly to lines scrolled. It depends on the method and how the individual application responds to the scroll messages received. Some methods, 1 increment scrolls the number of lines in control panel, other methods, this is not the case. So its not quite as simple as that.

As it happens, the way method 5 works with VS2010, is I have to send a message for each line to scroll so there is a 1:1 relationship between lines scrolled and the number in that field. But If I were to initialise to what's in control panel (e.g. 3) by default, then some methods would scroll 9 lines while other would scroll 3. It might be better to equalise it elsewhere, but again the problem is that each application can behave differently, hence I have no fixed "defaults" other than 1.

I hope that makes sense - its rather complex because of all the little differences between messages and applications

Thanks,
phil

[clm_de]

A small glitch I've noticed.

VS2010 allows to vertically split edit windows, showing one part of the source file in the upper region and another part of the source file in the lower region.
(This is done by using the small symbol directly above the vertical scroll bar)

Scroll events are always sent to the upper split window, regardless of the mouse pointer position.

But I fear that there will be no remedy, as Spy++ shows me no more windows involved than the complete editor window, no subwindow, no separate scrollbar control. Apparently MS decided to do all of the UI stuff without controls, thus disabling your application to interact with parts of the window.

Well, what are human interface guidelines worth if the creators of these guidelines ignore them at will?

Anyway, now I've had most part of a workday using the 2.1.1 beta with VS2010 and this is the first problem I've came across - no really big deal, I just have to change my standard way of using split windows. I used to have the non-editing part on top and the editing part in the lower half, a swap fixed that.

If you wonder how I come to use such a feature with today's trend of reduced screen height, I'm using a UXGA display in portrait orientation, thus getting about 90 lines of source code.

Did I already thank you for your work?

[phil]

I fear you are right on this one... If Spy++ cant see it, there is little hope for XMBC as it basically does the same thing. I wonder why MS have done this - is it just a side effect of using WPF (I'm not familiar with WPF myself yet).

Is there any way to scroll the windows with keyboard short-cuts I wonder? Although I presume that is only going to work with the active window.

If you think of anything, let me know, and I will have a think while I fix a few more bugs

Thanks,
Phil

[clm_de]

Another woe ...

Apparently the window class names used by VS2010 are not constant, but generated at random upon each(?) startup.

Today's choice is

Code: Select all

HwndWrapper[DefaultDomain;;1c825d6e-d7c9-4165-82ef-b90701682381]

Last week it was

Code: Select all

HwndWrapper[DefaultDomain;;7af17adc-e1b4-42e6-8835-cccb1ab57190]

So it would be helpful if it were possible to have window profiles with "advanced window scrolling" based on application name only.

BTW:
I've tried to remove the parent class name, the edit box' content was replaced by some gibberish and XMBC crashed.

Steps to reproduce the crash:

1) Create a new window profile
2) use the "specific window" button
3) use the "find window" dialogue to choose a window
Notepad.exe suffices.
Remove the contents of the "class" edit box
Remove the contents of the "parent class" edit box
(so that the only filled-out edit box is "process")
4) click OK
5) try to edit the window profile once or twice
the "parent class" edit box now contains some characters and upon clicking OK XMBC crashes.

Are you interested in the crashdump data?

And yet another thing (I'm really sorry).
Apparenty the "microsoft management console" gobbles up all mouse events. When mmc.exe (started for instance with the event viewer) has the input focus, no other window gets scroll messages.

Well, I can live with that, I'm not using the "management console" too often.

(My setup: W7x64 SP1 Enterprise, Logitech RX250 using the default HID driver)

[phil]

Hi,

I don't believe it - random window class names - great!
It is possible to have just application only profiles, but I think it does not allow the advanced scrolling. Im not sure if that is possible - I will look into why I did it that way.

I don't need crash dump data - never really figured out how to use that
Your not the only one who reported that crash - I dont know if its new in 2.1.1 but either way I will investigate and fix it before release.

Thanks,
Phil

[clm_de]

I don't believe it - random window class names - great!

Well, knowing about that and being a proficient user of Windows' hibernation mechanism, I don't restart VS2010 more often than once in several weeks (as long as it doesn't crash), so even being quirky as it is now, XMBC makes my mouse's life easier.

The random window class name thing isn't the end of it - depending on what kind of window is being used, scroll messages still get lost. In normal text editor windows, everything works, but for instance in a "Transact-SQL Editor" window the window structure is different. You can see that when using Spy++, the standard text editor window is just one window with no further subwindows in it (scrollbars etc. are completely owner-drawn and implemented by hand), in the SQL editor window, some additional subwindows appear, making it quite difficult to find the correct window to send scroll messages to.

Mind, that is not a problem I have, I instructed VS2010 to use the standard text editor for SQL stuff and everything is fine, but it's a description of the steaming heap of ... unmentionable things MS now thinks to be the leading edge of software design. Apparently the VS creators had close to no knowledge about how Windows works, something which I'm not astonished about, since VS is made using some or other part of the .Net layer cake.

Back to topic:

I sincerely hope that it would be possible to have advanced scrolling based on process name only - at least for the new scrolling method, but I have to admit to have close to no knowledge about the magic things you work to re-route mouse messages.

I've since tested XMBC on my setup using an Apple Magic Trackpad, with the additional help of a tool named "Trackpad Control Panel" to get the various click and drag things to work the way I like it.
That combination works quite good, not as slick as on a real Mac, but good enough to use it.

Again, thanks for your good work!

-Claudius

[phil]

The re-routing is not that complicated, but at the moment is is done by the window under the cursor... ie, get the windows handle, and then manually either send a message to it (eg WM_VSCROLL for method 5) or to use the API Get/SetScrollPos etc.

If I were to do it by process, I guess the only difference is that it would only have to check that the window's process name is 'blah' rather than checking its class name etc. But I cant remember why I did not do that before - there may have been a gotcha I cant recall. I will give it a go next time I have some free hours

EDIT: FYI i have reproduced the crash, its definitely something I did in 2.1.1 with the replacement of the ';' separators!

Thanks,
Phil

[phil]

Hi All,

I've updated the beta.
It is now 2.1 Beta2.

The following has changed:

• Problems setting Launch Application and Open Explorer [raised by Pope5]
• Simulated keystroke for {LEFT} broken in during mode [raised by evilc]
• Sim Keys problem (Windows 7 Shake) [raised by cableghost] NOTE: Note sure this is fully fixed awaiting feedback
• Fixed crash in 2.1B1 in specific window definition (from previous fix for VS2010 scrolling).

its not finished yet, I still have to look into some of the issues raised above like allowing the advanced scrolling to work with any profile, not just the window specific profiles. I haven't had time to do this yet.

Thanks,
Phil

[zoktar]

sometimes the mousespeed, speed up and down while holding down a simulated keystroke button on mouse, so its on 200ms, i hold it down, and when hold down rightmouse also, and move the mouse around, it will speed up and down erratically. or it might be having some sort of "hanging" issue making it seem like its speeding up and down if you get what i mean. i have a g500 logitech, with setpoint 5.42.34. to make some buttons availble for sim keys, i have to reassign them in setpoint to keys wich XMBC can access, wich works fine, iv tried shutting setpoint off, and it will retain the reassingment, but the speedup/hang issue still persists.

heres an example simkeyed on a mousebutton,

23{CTRL}1{SHIFT}f

at 200ms autorepeat while held down.

2.1 beta2
win7-64-sp1, all updates.
logitech g500
setpoint 5.42.34

owh and when setpoint was set to use OS driver, it was way way worse. changed it to use logitech setpoint driver and it reduced the issue by like 70%. setpoint off, and yet again the button reassignment is still intact, but the issue tho reduced is still there.

[phil]

Hi Zoktar,

Is this a new problem in v2.1 beta that you are reporting or is it something that has always happened (in v2.0 or earlier)?

Is it better/worse if you increase/decrease the 200ms delay?

Also what are you PC spec, how many CPU cores, what speed? I have a quad core i5 and no problem here. Does CPU usage spike when you get this erratic movement?

Thanks,
Phil

[zoktar]

Hi Zoktar,

Is this a new problem in v2.1 beta that you are reporting or is it something that has always happened (in v2.0 or earlier)?

Thanks,
Phil

same in 2.0

e8600. dualcore 3.33ghz@4ghz
4gb ram.

ill try some different speeds later today. and check the cpu usage.

[phil]

OK, first point, if its the same in 2.0 it might have been better to start a new thread but never-mind its done now.

I think I might know whats going on, the mouse stuff is done in one thread, and the repeat timer, when it fires, locks the thread up while it checks that things are good and proper, that the window under the cursor has not changed etc.

This causes a delaying to further mouse message processing (inc. movement I guess). I expect it to be worse if the cursor moves outside the window where you initially pressed the button and also to be worse if you have more application profiles defined.

I'm going to try and optimize the code some more but that will only make a significant difference if you have lots of profiles. Anything more than that is going to get rather complex.

Thanks,
Phil

[zoktar]

OK, first point, if its the same in 2.0 it might have been better to start a new thread but never-mind its done now.

I think I might know whats going on, the mouse stuff is done in one thread, and the repeat timer, when it fires, locks the thread up while it checks that things are good and proper, that the window under the cursor has not changed etc.

This causes a delaying to further mouse message processing (inc. movement I guess). I expect it to be worse if the cursor moves outside the window where you initially pressed the button and also to be worse if you have more application profiles defined.

I'm going to try and optimize the code some more but that will only make a significant difference if you have lots of profiles. Anything more than that is going to get rather complex.

Thanks,
Phil

Hey, i was wrong about a few things, there needed to be a process still active to retain the button reassignment from logitech setpoint, i hadnt bothered to check taskmanager. not sure if selecting the logitech driver instead of native os in setpoint actually made any difference. The reason why it looked like it was reduced was because i had really low sensitivity, so when it hanged, it didnt insta glich across the screen very far.

Im only using the default profile in XMBC now, and disabled the "profile on mouse move" in settings, didnt seem to make a differance. I was wondering if it is indeed the error-checking thingy clogging up the mouse data, maybe a non errorchecking option with or without profile checking?. Maybe some sort of permanent profile switch or something like that.

Owh and yeah it starts happening alot faster if i move the mouse outside like you said, tho the lockup issue still happens inside aswell.

cheers /zok