Currently running a Windowblind called Murishani by Jonep and it works with this blind.

Good call Fuzzy...works everytime... now u dont even have to travel all the way to the left of titlebar either Harri   

Alternatively Alt + F4 which can be customized by any number of small apps to something conventient.

ToeJo...this..certainly WWW Link stays permenantly in my links bar. I was a little prideful to use it at first but..that soon goes away when you see how often it can be helpful in a pinch.

To follow-up on Fuzzy's comments:

As he said, the action on double-click for the System Button can be set to "close" in the skin - Windows' inherent functionality isn't "broken" at all, just amplified.

In addition, you can set a skin-specific double-click action for the Titlebar itself to "close" as well, so double-clicking anywhere on the Titlebar (other than on control buttons) will close the window, as shown in this SkinStudio snapshot:



And you have a global override to make double-clicking the Titlebar "always" close the window. So you have 3 options that ought to satisfy your need.

Thanks for the link vStyler.   

Ok, let's wrap this up:


Yes, one could fix or modify the skin - with proper tools etc. But in my mind there's a better and simpler solution (see below).


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

Doesn't seem logical nor practical, since I (like most?) have to work between different computers, and functional consistency is nice.

Maybe it's the developer in me who likes solving stuff and making things better, but when I see a bug (or "a missing feature causing problems" -- call it what you want), my mind tries to come up with a way to make it just work.

And this shouldn't be so difficult, after all.

Just in case, here's the summary of WB behavior as far as I have observed and interpreted - and please let me know if it contains any errors:

Three separate and closely related GUI actions can by modified by the WindowBlinds skin author. However, only two of them can be overridden by the user:

1. Double-clicking the title bar (Restore/Maximize window)
2. Right-clicking the title bar (Open the system menu)
3. Double-clicking on the program icon on the left side of title bar area (Close window)

Please let me know if I'm missing something (maybe a hidden option added to 5.51 or something similar), but if not, then how about a simple solution:

All we need is a third check-box to the settings, so the user could override the skin-supplied behavior of the program icon!

Or not?

Rgds,
Harri

---

PS. Photoshop compatibility in WinXP x64 isn't a "pet peeve from customers".

Also, I don't understand how your comment is related to this topic.

Microsoft released Windows XP Pro x64 in April 2005 shortly after Adobe released Adobe Creative Suite 2. All CS2's are 32-bit programs, so they have to run on x64 with the help from heavy WOW64 "middleware" plumbing etc.

FYI, Adobe has not certified any of their CS2 products to run on WinXP x86.

(My theory your menu corruption might be related to video drivers.. but then again.. just a theory.. and also getting *really off topic* ...)

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.

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

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

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.

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.


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

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