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....

[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

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

Fair winds & following seas, htalvitie.

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   

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

 

 

 

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.

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.

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.

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'....

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.

JAFO -

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

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

Same for IE7

Same for Opera

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

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.