Anyone want to test v2.1 (Beta)?

[mickey4mice]

hmm...that make sense, if XMBC has to be enabled in order to toggle the scroll then disable inside Firefox windows via hotkey won't work. Cool, thanks for the explanation.

Ahhhh do you mean it stays scrolling in pages? That makes sense - because its a global windows setting that XMBC toggles... so if its disabled, it wont continue to toggle it. So XMBC is in fact disabled, but the scroll pages is left permanently on for all windows.

Moving to the task bar to disable xmbc moves out of firefox, and thus disables scroll pages instead of lines before you then disable XMBC!

I think thats it...
So the solution.. hummm when disabling, reset the "toggle pages" option at that point I guess.

[phil]

OK Folks,

I have released 2.1 Beta 4
It has the following changes from beta 3:

• Fixed thread priority problem (thanks Zoktar)
• Changed to allow application profiles to set advanced scrolling (not just custom window profiles) - needs testing!
• Added simulated keystroke tag {LAYER:<x>} to switch layers from sim keys (not recommended practice unless you have good reason to use it though!)
• Fixed the problem with scroll as pages/scroll lines not being reverted to default when disabling XMBC as reported above by micky4mice

The link in the first post has been updated.

For anyone who raised the issues that I have fixed, please give it a test and see if it works as required (and that I haven't broken anything obvious!).

Thanks,
Phil

[mickey4mice]

Hi Phil,

Page/line scroll via hotkey works fine now. Thanks for the quick "fix"

I do have one question though, have you noticed any lag when open setup dialog in beta version? mine opened instantly in the stable version but now lags behind by almost 15 seconds in some cases, is this normal? I'm on Win7x64 with 8GB RAM.

OK Folks,

I have released 2.1 Beta 4
It has the following changes from beta 3:

• Fixed thread priority problem (thanks Zoktar)
• Changed to allow application profiles to set advanced scrolling (not just custom window profiles) - needs testing!
• Added simulated keystroke tag {LAYER:<x>} to switch layers from sim keys (not recommended practice unless you have good reason to use it though!)
• Fixed the problem with scroll as pages/scroll lines not being reverted to default when disabling XMBC as reported above by micky4mice

The link in the first post has been updated.

For anyone who raised the issues that I have fixed, please give it a test and see if it works as required (and that I haven't broken anything obvious!).

Thanks,
Phil

[clm_de]

Again, great work!

Thanks for the changes in 2.1 beta 4 - the app-name based scrolling works perfectly with VS2010!

With an exception, but that's incurable due to Microsoft's sheer and utter stupidity, and it already was incurable in VS2008: The list of available processes when running "Debug - Attach to Process".
Instead of a list box, a list view or similar, this seems to be a button control and it doesn't process scroll messages at all.

Whatever, with XMBC I can actually use my mouse (or even the Magic Trackpad) and don't have to gobble up some tranquilizers to hinder me from throwing my computer through the (closed) window ...

Thanks from Berlin!

[phil]

clm_de, I wonder if that list box can be added as another window specific profile, or does it's class keep changing too? Due to the nature of the code, it processes (looks for) custom window profiles before application specific profiles.

I will try this out later when I have some time.
EDIT: No it does not work - with any of the profiles - I will have to investigate in more detail

Thanks,
Phil

[phil]

Hi mickey4mice.

Hi Phil,
I do have one question though, have you noticed any lag when open setup dialog in beta version? mine opened instantly in the stable version but now lags behind by almost 15 seconds in some cases, is this normal? I'm on Win7x64 with 8GB RAM.

I haven't but its only been a few hours I will keep an eye on it here. Does it (the lag) happen every time? I don't think I have made any changes in that area.

Oh, and for future, you don't have to quote my entire message every time, it only fills up the page!

Thanks,
Phil

[clm_de]

I wonder if that list box can be added as another window specific profile, or does it's class keep changing too?

No, that doesn't help. The class names aren't the problem here.

I just checked with Spy++ and got an interesting result:

According to Spy++, there is a "SysListView32" layered atop a "Button". The "Button" has the caption "Available Processes", the SysListView32" has the caption "List1".

XMBC's find window tool only finds the "Button", but not the "SysListView32" atop of it.

I tried manually adding a profile for the "SysListView32", entering "devenv.exe" as process name and "SysListView32" as class name, but XMBC seems to route scroll messages to the profile I use for VS2010 (containing just the process name "devenv.exe").

Removing the VS2010 profile also doesn't help, then XMBC does not detect anything fitting for the profile (which it normally shows by highlighting the profile's name in the profile list).

The offending list view even doesn't scroll when clicked upon, the Microsoft geniuses must have done something severely wrong here. The only way to scroll is "grabbing" the scroll handle, clicking into the scroll bar, using the cursor up/down keys on the keyboard or typing the first letter of an entry in the list.

Well, don't invest too much time in this, it is not of utmost importance for me ... and you don't have to fix everything Microsoft botches.

Thanks again and greetings from rainy Berlin
Claudius

[phil]

Yep I know - and Ive already fixed it

The problem is in this case ::WindowFromPoint() does not return the list window (syslistview32) but the group box, which is a sibling, not a parent. I think this is true for all group boxes, and basically its a flaw in the XMBC window over/finder code.

So now, the window finder and the mouse over code now works more like spy and finds the windows inside the group box too - and that means my theory works.

if your interested, I did this:

Code: Select all

HWND RealWindowFromPoint(const POINT& pt)
{
	HWND hRes = WindowFromPoint(pt);
	HWND hParent = ::GetParent(hRes);
	if (hParent)
	{
		POINT ptRelative = pt;
		if (::ScreenToClient(hParent, &ptRelative))
		{
			HWND hRes2 = ::RealChildWindowFromPoint(hParent, ptRelative);
			if (hRes2)
				hRes = hRes2;
		}
	}
	return hRes;
}

However, I've now gone one step further, and now it works without setting a specific profile for VS2010 (in my testing so far). Internally, in the scroll window under cursor code, I look to see if the window class begins with "HwndWrapper[DefaultDomain;;" and if it does, I always send a method 5.

Which means it works in VS2010 WPF windows with no special configs - yay

I will upload a new beta 2.1 b5 when Ive finished (I still need to do horizontal scroll in the same fashion).

Thanks,
Phil

[phil]

I have now made available 2.1 Beta 5
It has the following changes from beta 4:

• Fixed VS2010 (WPF windows) scrolling when not active (without app/window specific profiles)
• Fixed window finder and window under cursor detection that was not finding all windows, esp. when in a group box.
• Fixed highlighting of profiles in setup dialog. Now it only highlights if enabled, and it finds the correct profile relative to the window under the cursor!

The link in the first post has been updated.

Once again, please give it a test and see if it works as required (and that I haven't broken anything obvious!).

Thanks,
Phil

[clm_de]

Thanks for your ongoing work

However, I've now gone one step further, and now it works without setting a specific profile for VS2010 (in my testing so far).

I'm afraid that this does not work, at least on my setup. Without a specific profile there's no scrolling in VS2010.

And I fear that there's something broke, since even with a process-name based profile, there's no scrolling in VS2010, with the exception of windows not being on the primary monitor. These windows behave as they should, but everything on the primary monitor does not scroll - again with an exception: the list of available processes in the "Attach to Process" dialogue.

For clarification purposes a description of my environment:
Three monitors, a vertically oriented one in the middle as the primary monitor (for coding purposes there's one thing better than a lot of visible source code lines: more source code lines).
Windows 7 x64 Enterprise SP1, using both the embedded graphics hardware inside Intel's Core I3 and a Nvidia Geforce 210 to steer these three monitors.

VS2010 SP1 with each source code window floating, so that it's possible to move them from the main monitor to one of the side monitors.

A window that floats on the main monitor (where the task bar is located and where VS2010 fills the screen background) does not scroll, even after being clicked upon, the same window does scroll, when moved to one of the side monitors.
The list of available processes does scroll regardless on what monitor it is being displayed.

The behaviour does not change when I create a process-name based profile and assign scroll method #5 to it.

I'll "downgrade" to beta 4.

Sorry for the bad news, maybe they align to what they're currently doing instead of weather.
End of July is supposed to be a season named summer, it's 14 °C and pouring ... the last few days brought more rain than statistically the whole month usually does.

Greetings from soon-to-be-inundated Berlin

[phil]

End of July is supposed to be a season named summer, it's 14 °C and pouring ... the last few days brought more rain than statistically the whole month usually does.

Sounds like your getting what we had last week!!

OK bad news I will look into it.

[phil]

OK well the good news is that I can reproduce it here with my dual monitor setup. It seems to only be a problem with floating windows on the primary display though - if they are docked then it seems to work for me, even on the primary display. Is that the same for you?

And you say that in beta 4 it did work with un-docked (floating) windows?

I guess my new code to detect the window under the cursor is not quite right!

Thanks,
Phil

[clm_de]

if they are docked then it seems to work for me, even on the primary display. Is that the same for you?

Can't answer that, because I don't use docking windows and have installed a VS2010 plugin that auto-floats windows.

And you say that in beta 4 it did work with un-docked (floating) windows?

Yes, as it did with previous versions.

As I wrote, I'm now back to beta 4 and it works fine.

[mickey4mice]

"Enable profile switching on mouse move" breaks Aero peek on Win 7, preview windows flicker then disappear. Disable "enable profile switching..." completely disable XMBC. Can anyone reproduce?

[phil]

Hummm, not a problem here (win7 x64). That has never been a problem (and we paid quite a lot of attention to that area when testing v2.0). What profiles do you have?

And what does this mean "Disable "enable profile switching..." completely disable XMBC" ?

Thanks,
Phil