WindowBlinds breaks Window close detection?

htalvitie

Join Date 01/2006

WindowBlinds breaks Window close detection?

External Link

Dear Stardock,

Early last year I purchased Object Desktop and ran WindowBlinds 5.0 on my Windows XP.

Soon I noticed that most (if not all) skins break the close functionality on the system menu, e.g. double-clicking the icon on the left side of the title bar doesn't close the window as it should.

I struggled for a while and then finally uninstalled WB. I was unable to change my Windows habits.

Today, I was brave enough to give WindowBlinds another run. I installed the current 5.51 on a fresh Windows Server 2003, and found the exact same problem.

Am I really the only one with this problem, or are everybody else using some other shortcut for closing their windows? Since I actually work on my computer and must choose functionality over eye-candy, I was forced to uninstall WB once again. Maybe I'll retry again when 6.0 comes out.

I really like WB and would like to use it permanently so hopefully this single annoyance gets fixed.

For information, I made a screencast of my desktop with v5.51: http://s3.amazonaws.com/BugCast/WindowBlinds/WindowBreaks.html

Hope this helps in locating & fixing the problem!

Regards,
Harri

windowblinds

Locked Post

Advanced Search

Watch this post

Do not email me updates for this post Email me updates for this post

Successfully updated karma reason!

Daiwa

Join Date 07/2001

+351

But wouldn’t this conflict with the existing standard action Maximize/Restore window in place?

No. The standard control buttons still work normally. The point is you can choose how windows respond to titlebar double-clicks to suit yourself. But that assumes you want to. The "proper tools" are simple enough even for this non-developer so I suspect even you could easily use them. In the time you've devoted to posting, you could have fixed this 10 times over.

Successfully updated karma reason!

Jafo

Join Date 03/2001

+1846

Remember....skins are designed the way the skinner himself wants them.....unless they are a commissioned work. If one or other of them doesn't look or function the way you would like there are only two options....find another that does, or, failing that....make [or adapt] your own.

Many skinners started out in exactly that way....

Successfully updated karma reason!

I've always thought WindowBlinds is the right tool for making run-time selections like these - not SkinStudio.

Successfully updated karma reason!

Sign Up or Login and this ad disappears!
There are many great features available to you once you register. Sign Up for a free account and browse the forums without ads.

Daiwa

Join Date 07/2001

+351

SkinStudio is the tool with which one creates a WindowBlinds skin and determines the properties/actions of various GUI elements that are customizable using WB. SkinStudio is to a skin what the Toyota factory is to a Celica. You want the steering wheel on the right instead of the left? Gotta order it that way. Does that help?

A skin is fully changeable by the end-user - you can modify a skin to your heart's delight using SkinStudio.

Successfully updated karma reason!

You want the steering wheel on the right instead of the left? Gotta order it that way. Does that help?

No, it doesn't.

According to the product description, WindowBlinds by itself should "give the user freedom to completely change all aspects of the GUI of WindowsXP." I'm not feeling the freedom here.

I'm simply asking for the manufacturer to stop interfering (randomly, as shown in my screencast) with my existing "steering wheel" by not causing breaks or loosing coordination.

Why should I accept all this silly reasoning trying to convince me to "shut up, buy something extra (and I already have the full Object Desktop), fix it yourself" when there's a clear defect in the product?

Yes, WindowBlinds is broken and no, the skin author isn't the one in the driver's seat telling where to turn when the system menu receives a double-click.

SkinStudio is to a skin what the Toyota factory is to a Celica.

I'm sorry, I don't find any logic in what you're saying.

If anything, the Model T comes to my mind: "Choose any color, so long as it's black."

Successfully updated karma reason!

Jafo

Join Date 03/2001

+1846

The idea of 'skinning' a GUI is not 'just' to give it a pretty colour other than the Fisher-Price blue and green of MS, but also to alter/enhance the GUI functionality. It's called 'modding'.

Windowblinds has ALWAYS been capable of relocating buttons....altering their function...adding functions.....in fact two of the MOST productive are arguably 'rollup' and 'ontop'....so much so that there are other proggies around also with those particular abilities.

Windowblinds is NOT broken....simply because many [most] skinners do not care for the double-click to close function being set for THEIR skins.....probably many have never used the function....only discovering it by accident.

What CAN be argued to be 'broken' is the suitability of many existing skins...for YOUR personal functionality choices.

The fix is actually not something for the Proggy...but something for the skin chooser....

Successfully updated karma reason!

[I don't have the energy to do a proper grammar anymore. Sorry for my ESL, try to decipher...]

Thank you Jafo for the (yet another) not-so-interesting infomercial about what skinning is all about.

Oh well. I should just stop commenting these post's since it's clearly becoming a sad troll fest, but maybe there is still somebody who is able to discuss the technology and not childish OS advocay.

Just to recap: I'm came here to report a bug to the WB manufacturer. Yes, on a public enthusiast forum, and yes, initially a bit on the provocative side.

Tried to tone down, but appearantly too late.

I was greeted by an advocacy group, pre-assumptious people totally ignoring the facts. Sorry if I made you feel bad, but that wasn't my point. I have already bought WB. Even upgraded. You don't have to convince me - I'm a believer already.

If you don't have problems with WB, happy to hear. I believe you, really. Move on.

As for the comment

The software product X is not broken

This is simply a lie. Where did you study software engineering exactly may I ask? You don't seem to have any kind of realistic idea of the average defect rate in software. Of course WindowBlinds has bugs - lot's of them.

Let's leave it there.

For anybody still here intersted in the technical stuff, here's a script I created to help to overcome the bug.

I have some ideas on what causes it, and it's basically timing-related. The window procedure responsible for painting the system menu kicks in before the double-click event handler get's a chance to run. A typical race condition, hard to locate and debug.

If somebody is interested, here's a modified version of a "anti-WB double-click bug fix" which I got to work. It's based open source code from the Autohotkey community which I have commented and modified a bit for my personal debugging needs.

;
; A script used for detecting double-click gesture with the mouse button.
; Based on code from http://www.autohotkey.com/forum/viewtopic.php?t=8357,
; modified slightly during my "WindowBlinds 5.x debugging week".
;
; Basic assumptions / algorithms:
;
; * single-click detected when release occurs in less than 200 ms
; * double-click detected when second press occurs in less than 200 ms
; * drag detected when press and mouse coordinate differential occurs
; * hold detected when press duration exceeds 300 ms

RightButton?double_click@threshold = 200
RightButton?hold@threshold := RightButton?double_click@threshold+100

~RButton::
OutputDebug EnterHandler
if ( A_TickCount-RightButton?double_click@threshold < RightButton@mark )
; Double-click detected (time between previous click was less than RightButton@mark ms)
{
SetTimer, timer_RightButton, off
; .. stop timer!

; We want to check if the right double-click occured above the system menu area
MouseGetPos, m_x1, m_y1
if (m_x1 < 32 && m_y1 < 24) {
; Coordinates indicated mouse is located on top of the system menu button
OutputDebug, System menu right-clicked
} else {
OutputDebug %m_x1% and %m_y1%
}
return
}

RightButton@mark := A_TickCount ; Record the time when clicked
MouseGetPos, m_x1, m_y1 ; Record mouse position

SetTimer, timer_RightButton, 10 ; Start polling timer_RightButton
return

timer_RightButton:
if GetKeyState("LButton") {
; Rocker Gesture (Right & Left button) detected
SetTimer, timer_RightButton, off
; .. stop timer!
OutputDebug Rocker
return
}

; This block gets called last, since it has highest time-out threshold!
if ( A_TickCount-RightButton@mark >= RightButton?hold@threshold )
{
; Right button has been down for more than 300 ms => hold detected
SetTimer, timer_RightButton, off ; .. stop timer!
OutputDebug Hold detected
}
else if ( A_TickCount-RightButton@mark >=
RightButton?double_click@threshold and !GetKeyState( "RButton", "P" ) )
; GetKeyState tells that RButton is UP already!
{
; User released right mouse button within 200 ms => traditional single-click
SetTimer, timer_RightButton, off
OutputDebug Single-click
}
else
{
MouseGetPos, m_x2, m_y2
if ( m_x1 "," m_y1 != m_x2 "," m_y2 ) {
; Drag detected. To improve accuracy, you might add +-4 threshold.
SetTimer, timer_RightButton, off
OutputDebug Drag
}
}
return

Successfully updated karma reason!

Daiwa

Join Date 07/2001

+351

Fair winds & following seas, htalvitie.

Successfully updated karma reason!

Refusing to accept normal operation of WB is not a bug, and that the double click close does work meant this thread was over long ago.

Have a good one

Successfully updated karma reason!

Jafo

Join Date 03/2001

+1846

This is old,[2001], grey and boring....but double-clicking the top bar will close it.

You may call it 'advocacy' 'pre-assumptious' [sic] or even a 'bug', but I'd say that this Windowblinds proggy is skinning the Window GUI and still enabling double-click to close.

Partial extract of UIS file [simple text]....

;ExplorerBmp =
ialogBmp =
;MDIBmp =

RightClickAction = 2
DoubleClickAction = 0

[Text]
Use3DText = 1 ;0(normal), 1(Shadow), 2(Outlined)
ShadowTextR = 165
ShadowTextG = 165
ShadowTextB = 165
ShadowOffset = 1
NoShadowInactiveText = 1

Note the bold text entry....

[Button10]      ;CLOSE
XCoord =   22
YCoord =   4
Align =   1
Action =   0
ButtonImage = BlindJafo\close.bmp

And this bit....shows what the close button action is....so you see the 'action = 0' means 'close'...

Again I MUST repeat.....Windowblinds does NOT break the interface...it intercepts it. The skinner 'may' then break it [to use your word] by HIS assigning a different function to 'double click'.

Having Windowblinds NOT handle/control what 'double-clicking the title bar' would be seen [by skinners] as a loss of modding feature/function....or itself a 'bug' to be rectified.

Bit more of the UIS file....dating back to March, 2001....Tells you what various actions can be assigned [some may since be obsolete]...

; Action ID
; 0 Close this window
; 1 Maximize this window - Shows Disabled State
; 2 Minimize this window - Shows Disabled State
; 3 Help button
; 4 Rollup / Unroll this window
; 5 Execute this command (see Command line next)
; 6 Force this Window to be always on top
; 7 Attach this window to the desktop (Always on bottom)
; 8 Litestep Only - Keep this window visible always
; 9 Prevent this window from being sized or moved
;10 Execute the screensaver
;11 System icon (I.e. The icon used for this window)
;12 System Menu (Does not show the system icon, but works just like it
;   with the menus)
;13 Size from the top
;14 Size from the bottom
;15 Size from the left
;16 Size from the right
;17 Size from top left
;18 Size from the top right
;19 Size from the bottom left
;20 Size from the bottom right
;21 Send to back of z-order
;22 Maximize Button - For use with MouseOver
;23 Minimize Button - For use with MouseOver
;24 Unsupported Experimental Code - Minimize to Sys Tray
;25 Unsupported Experimental Code - Windows 2000 specific
;-1 Do nothing. For when you just want to show an image. This does not
;   intercept mouse messages
;-2 This is like the above but it intercepts mouse messages, so clicking
;   it stops you moving the window
;-3 This tells WindowBlinds that this is a dll button. See later in this
;   section
;-4 Custom action. Clicking is handled in a UIS2 plugin dll, but drawing
;   is done by WindowBlinds
;-5 Non clickable. This is like an action 3, but it is treated as an
;   integral part of the titlebar

Successfully updated karma reason!

vStyler

Join Date 11/2004

+919

Yes, I'm an advocate.. *Steps outside advocacy based bias* It's not a bug. No software is designed to accomodate EVERY user..none. You have been given several quite viable different options. If you choose not to listen to the people whose help you have asked then you should probably just move on too. I have literally dozens and dozens of issues I would like fixed by developers also.. get in line.. your not special.

Successfully updated karma reason!

Hey htalvitie, was just testing with the skin in your video, Acrylic, works fine here to close on double click if clicked on right 2/3 or so of icon. FF also has close, min, max etc menu access from or around left of system icon. Noticed in your video that was what you were mostly on, double clicking there will just keep opening and closing the menu. If you open any window that does not have this menu, my pic, videos etc, double click anywhere on system icon will close window.

Successfully updated karma reason!

Just tested some other apps, seems to change app to app, in Paint Shop Pro the close menu access takes up about 1/2 of the system icon.

Successfully updated karma reason!

Jafo

Join Date 03/2001

+1846

Ah...now hang on!!!!!

htalvitie ....you mean the window proggy icon...typically top left...single click opens the menu...double click shuts the window?

My bad....was thinking 'double click' on titlebar.

However...yes, it works exactly as 'wanted' on my example skin above...so it is still not a WB 'fault'....

Successfully updated karma reason!

Jafo

Join Date 03/2001

+1846

Just tested some other apps, seems to change app to app, in Paint Shop Pro the close menu access takes up about 1/2 of the system icon.

Nope...again that is going to be skin/skinner - specific. Works as 'expected' here...

Successfully updated karma reason!

Nope...again that is going to be skin/skinner - specific. Works as 'expected' here

PSPX here, may be older version did not have the menu access from system icon. Even changing icon in SKS to close window, was set as system icon, still have menu from left side of icon, double click to close on right.
May have seemed 1/3-2/3 in FF as FF default icon may not be centered on background whereas PSP icon is a square and fill background so would be 1/2-1/2.

Successfully updated karma reason!

Daiwa

Join Date 07/2001

+351

This is old,[2001], grey and boring....

JAFO -

Easy there... you're talking about my inspiration, you know, & still one of my favorite skins.

Successfully updated karma reason!

Firefox - WC Select - double clicking FF icon in upper left closes window

Same for IE7

Same for Opera

Successfully updated karma reason!

not sure why the FF icon is on IE7 or Opera... eh, still works..

Successfully updated karma reason!

Some on this thread have blamed the skin author of the leaving the double-click action non-defined for the system icon on the top-left side in a window frame.

I'm using a Stardock-provided skin and checked the customization on system icon:

As far as I can tell, it's properly defined.

Successfully updated karma reason!

And you have a global override to make double-clicking the Titlebar "always" close the window.

I do not want to make double-clicking the title bar close the window..

Successfully updated karma reason!

Since people have misinterpreted my description of the problem repeatedly, I will once again add a visual aid. This time with an animated GIF, since some commenters haven't clearly analyzed the Flash versions.

I'll try to keep it simple this time.

Successfully updated karma reason!

Quentin94

Join Date 08/2006

+119

* double-click detected when second press occurs in less than 200 ms

did you try to change the speed of the double click occurs in less or more?

Successfully updated karma reason!

did you try to change the speed of the double click occurs in less or more?

The 200 ms speed detection quote was from the Autohotkey script, not built-in Windows value. That script is a kludge, and doesn't provide a real solution.

Just in case you are interested in the built-in values, I have experimented the different double-click timeout and pixel thresholds. I have modified HKCU\Control Panel\Mouse\DoubleClickWidth and HKCU\Control Panel\Mouse\DoubleClickWidth (TweakUI, mouse control panel), but haven't noticed any change in the success ratio.

Since WindowBlinds bring more processing overhead, I would start solving this problem based in the timing-consideration. It has been discussed for example at Raymond Chen's blog post:

On a heavily loaded system, delivery of messages can be delayed. If the WM_LBUTTONDBLCLK message is delayed more than the WM_LBUTTONDOWN message, then the time would expire and the program would incorrectly interpret the action as a single click, before subsequently receiving a double click message.

(Source: Logical consequences of the way Windows converts single-clicks into double-clicks)

Successfully updated karma reason!

Just my additional 5 euro cents:

On a Terminal Services connection, identical double-clicking closes window always. I'm using rdesktop v1.5.0 on a Gentoo Linux (IBM TP770ED) and a rdp5 connection to my Windows Server 2003 box.

Interesting (and also quite nice), that my WB-themed desktop works better on a remote desktop connection to a Linux box than natively. Just slower. :-/

And as somebody mentioned here earlier, it's not consistent from app to app. There seems to be a small group of programs allowing the clickety-click to work correctly.

For example, when I was closing the Control Panel window (and/or an Control Panel applet, don't remember now for sure which) by double-clicking, I was able to close it with a 100% success rate.

For most apps, however, it's closer to 0%.

Successfully updated karma reason!