ResizeWindow() with Flags = #PB_Window_SystemMenu

[mestnyi]

If the window is installed flag = #PB_Window_SystemMenu
ResizeWindow does not work properly
Confirm if so
PoreBasik 522 Windows 7

Code: Select all

OpenWindow(30, 10, 550, 280, 60, "30",#PB_Window_BorderLess)
SetWindowColor(30,$F650F1)

Define x=WindowX(30,#PB_Window_FrameCoordinate)
Define y=WindowY(30,#PB_Window_FrameCoordinate)
Define w=WindowWidth(30,#PB_Window_FrameCoordinate)
Define h=WindowHeight(30,#PB_Window_FrameCoordinate)


;Flags1 = #PB_Window_SizeGadget
;Flags1 = #PB_Window_BorderLess
Flags1 = #PB_Window_SystemMenu

OpenWindow(1, 0, 0, 280, 60, "30",Flags1)
SetWindowColor(1,$0050F1)

If Flags1 ! #PB_Window_SizeGadget And Flags1 ! #PB_Window_BorderLess
  x+5
  y+5
EndIf

ResizeWindow(1,(x+w),y, #PB_Ignore, #PB_Ignore )

While WaitWindowEvent() ! #PB_Event_CloseWindow :Wend

[mestnyi]

nobody wants to hold it, is this the way it should be?

Code: Select all

OpenWindow(30, 10, 550, 280, 70, "30",#PB_Window_SystemMenu)
SetWindowColor(30,$F650F1)

Define x=WindowX(30,#PB_Window_FrameCoordinate)
Define y=WindowY(30,#PB_Window_FrameCoordinate)
Define w=WindowWidth(30,#PB_Window_FrameCoordinate)
Define h=WindowHeight(30,#PB_Window_FrameCoordinate)

OpenWindow(1, 0, 0, 280, 60, "30",#PB_Window_SystemMenu)
SetWindowColor(1,$0050F1)

ResizeWindow(1,(x+w),y, #PB_Ignore, #PB_Ignore )
 
While WaitWindowEvent() ! #PB_Event_CloseWindow :Wend

I don't, and I propose to fix it

Code: Select all

Macro IsFlag(Window, Flag)
  (GetWindowLongPtr_( WindowID(Window), #GWL_STYLE) ! 348127232) & Flag
EndMacro

Procedure __WindowX(Window,Mode)
  If IsFlag(Window,#PB_Window_BorderLess) Or 
     IsFlag(Window,#PB_Window_SizeGadget)
    ProcedureReturn WindowX(Window,Mode)
  Else
    ProcedureReturn WindowX(Window,Mode)+5
  EndIf
EndProcedure
Macro WindowX(Window,Mode)
  __WindowX(Window,Mode)
EndMacro

Procedure __WindowY(Window,Mode)
  If IsFlag(Window,#PB_Window_BorderLess) Or 
     IsFlag(Window,#PB_Window_SizeGadget)
    ProcedureReturn WindowY(Window,Mode)
  Else
    ProcedureReturn WindowY(Window,Mode)-5
  EndIf
EndProcedure
Macro WindowY(Window,Mode)
  __WindowY(Window,Mode)
EndMacro

Procedure __ResizeWindow(Window,X,Y,Width,Height)
  If IsFlag(1,#PB_Window_BorderLess) Or 
     IsFlag(1,#PB_Window_SizeGadget)
    ResizeWindow(1,x,y, #PB_Ignore, #PB_Ignore )
  Else
    ResizeWindow(1,x+5,y+5, #PB_Ignore, #PB_Ignore )
  EndIf
EndProcedure
Macro ResizeWindow(Window,X,Y,Width,Height)
  __ResizeWindow(Window,X,Y,Width,Height)
EndMacro


;---------------------------------------


OpenWindow(30, 10, 550, 280, 70, "30",#PB_Window_SystemMenu)
SetWindowColor(30,$F650F1)

Define x=WindowX(30,#PB_Window_FrameCoordinate)
Define y=WindowY(30,#PB_Window_FrameCoordinate)
Define w=WindowWidth(30,#PB_Window_FrameCoordinate)
Define h=WindowHeight(30,#PB_Window_FrameCoordinate)

OpenWindow(1, 0, 0, 280, 60, "30",#PB_Window_SystemMenu)
SetWindowColor(1,$0050F1)

ResizeWindow(1,(x+w),y, #PB_Ignore, #PB_Ignore )

While WaitWindowEvent() ! #PB_Event_CloseWindow :Wend

[luis]

If the window is installed flag = #PB_Window_SizeMenu

What is #PB_Window_SizeMenu ?

ResizeWindow does not work properly

Why ? You are using ResizeWindow() as a MoveWindow(), by specifying only the destination x,y of the upper left corner of the window, and omitting width and height using #PB_Ignore. The window moves there and keep its size. Looks ok to me.
But I'm using "PoreBasik" 531, so maybe I'm not seeing what you see. If that's the case I apologize.

In any case I think you should express with words what is the behavior you would expect and why, where in your opinion the actual behavior differs and only after that show the minimum code required to demonstrate it.

Use google translate if you have to, some approximate text explaining in detail is better than just some random code like the one in the first post, where one can only try to guess what you have in mind.

Confirm if so

If you are asking for a confirmation maybe you should have posted this in coding questions first, as a general rule.
In the second post you seem to be asking if this is the correct behavior or not, so definitively coding question would have been better.

PoreBasik

Is that something to fight acne ?

[mestnyi]

What is #PB_Window_SizeMenu ?

wrong

But I'm using "PoreBasik" 531,

I also

Why ? You are using ResizeWindow() as a MoveWindow(), by specifying only the destination x,y of the upper left corner of the window

me at that time was not interested in the size of the window, because the problem in positioning, you are my examples do not run or what? the question clearly visible after running both examples, the first example demonstrates the error, and the second shows what I was expecting from the first example. I hope now it's clear.

is this the way it should be ?

I ask why the second window zooms in on first?
Don left coordinate second window should not begin where it ends the width of the first window?

[netmaestro]

It does seem like a bug as the window sizes are all correct but the second window is moving to the wrong place if #PB_Window_SystemMenu is set. There is no logical reason for this and it works as expected if the flag isn't set.

[luis]

I ask why the second window zooms in on first?
Don left coordinate second window should not begin where it ends the width of the first window?

It's clear now.

OK, knowing you were looking after the relative positioning of the two windows I looked further into it.

The problem you are talking about seems to have to do with the external frame size of the window you got reported back for example by using the #PB_Window_FrameCoordinate flag.

Code: Select all

Define x=WindowX(30,#PB_Window_FrameCoordinate)
Define y=WindowY(30,#PB_Window_FrameCoordinate)
Define w=WindowWidth(30,#PB_Window_FrameCoordinate)
Define h=WindowHeight(30,#PB_Window_FrameCoordinate)

http://www.purebasic.fr/english/viewtop ... =4&t=61350

You are using windows 7, and the problem I think it's caused by the fact PB get the size of the external frame of the window using GetWindowRect_() or something of that kind.

Under Vista/Win7 GetWindowRect_() will return a misleading set of values that do not account for the extra padding of "glass" pixels Aero applies to the window.

This appears to happen even in Aero Basic (without Glass) to retain sizing consistency.

https://social.msdn.microsoft.com/Forum ... evelopment

The workaround to get the real values seems to be to dynamically bind to dwmapi.dll, use GetProcAddress() to obtain the DwmGetWindowAttribute() function, and call it with the DWMWA_EXTENDED_FRAME_BOUNDS argument to request the genuine window frame dimensions.

In code:

Code: Select all

Enumeration
 #DWMWA_NCRENDERING_ENABLED = 1
 #DWMWA_NCRENDERING_POLICY
 #DWMWA_TRANSITIONS_FORCEDISABLED
 #DWMWA_ALLOW_NCPAINT
 #DWMWA_CAPTION_BUTTON_BOUNDS
 #DWMWA_NONCLIENT_RTL_LAYOUT
 #DWMWA_FORCE_ICONIC_REPRESENTATION
 #DWMWA_FLIP3D_POLICY
 #DWMWA_EXTENDED_FRAME_BOUNDS
 #DWMWA_HAS_ICONIC_BITMAP
 #DWMWA_DISALLOW_PEEK
 #DWMWA_EXCLUDED_FROM_PEEK
 #DWMWA_LAST
EndEnumeration

Procedure GetWindowRectEx (hWnd, *tRECT.RECT)

 Protected hDll, iDwmUsed
 Protected *DwmGetWindowAttribute
 Protected tRECT.RECT

 If OSVersion() >= #PB_OS_Windows_Vista
    hDll = OpenLibrary(#PB_Any, "dwmapi.dll")
    If hDll
        *DwmGetWindowAttribute = GetFunction(hDll, "DwmGetWindowAttribute")
        If *DwmGetWindowAttribute                 
            If CallFunctionFast(*DwmGetWindowAttribute, hWnd,  #DWMWA_EXTENDED_FRAME_BOUNDS, *tRECT, SizeOf(RECT)) = #S_OK
                iDwmUsed = 1               
            EndIf           
        EndIf           
        CloseLibrary(hDLL)
    EndIf
 EndIf
 
 If iDwmUsed = 0 ; fallback
    GetWindowRect_(hWnd, *tRECT)
 EndIf
EndProcedure


Global rect.RECT

OpenWindow(30, 10, 550, 280, 70, "30",#PB_Window_SystemMenu)
SetWindowColor(30,$F650F1)

GetWindowRectEx (WindowID(30), @rect)

; Define x=WindowX(30,#PB_Window_FrameCoordinate)
; Define y=WindowY(30,#PB_Window_FrameCoordinate)
; Define w=WindowWidth(30,#PB_Window_FrameCoordinate)
; Define h=WindowHeight(30,#PB_Window_FrameCoordinate)

Define x = rect\left
Define y = rect\top
Define w = rect\right - x
Define h = rect\bottom - y

Debug x ; 5 vs 10
Debug y ; 545 vs 550 
Debug w ; 296 vs 286
Debug h ; 105 vs 95


OpenWindow(1, 0, 0, 280, 60, "30",#PB_Window_SystemMenu)
SetWindowColor(1,$0050F1)

Debug x+w ; 306 vs 296
Debug y ; 545 vs 550

ResizeWindow(1,(x+w),y, #PB_Ignore, #PB_Ignore )
 
While WaitWindowEvent() ! #PB_Event_CloseWindow :Wend

Now the windows are almost aligned correctly horizontally, since the width reported for the first one is now correct, but since both OpenWindow() and ResizeWindow() still suffer from the same problem (the window top [left,right] does not really end up where you are asking to put it) there is still an offset which make all not work correctly.

The values after the ";" in the code above are what I got using this API under Win7 x64, the ones which follows are the originals using PB commands.

Vertically they are also misaligned for the same reason. You are asking to open the first window at (10, 550) but in reality it has been opened at (5, 545). The real correct coordinates of the window should be the ones returned in the structure.

Even CreateWindowsEx_() seem to set the actual upper left x,y coordinates on screen for the window in a position different to what passed to it.

Anyway there are also reports (in that MS thread and elsewhere) saying all this should not always be needed. But those people are using different languages/compilers, and maybe those are adding some settings (manifest or something else) under the hood influencing the outcome of the call to GetWindowRect_() and family to always get the correct result. So maybe it's possible to fix it in PB too by doing something like that when linking the exe.

Due to compatability requirements, certain metrics are reported in such a way that they're not consistent with what is actually drawn on the screen when Aero Glass (more accurately, "Windows Vista Aero") is enabled. This sort of approach is needed in order to change the look of the system for the vast majority of apps for which this isn't an issue.However, there's been a recent change in the system which will be coming out in Vista RC1 that will return the correct rendered value from GetWindowRect() for executables that are linked with "winver = 6.0". This allows new and newly-linked applications to get the "correct" values from GetWindowRect().

What really happened after that I don't know.

I hope I didn't make mistakes with all these coordinates floating around

[mestnyi]

I don't understand you say all right as it should be?

[luis]

Frankly after doing the tests you'll find here I'm not sure of what should be changed if any.

Please read on.

What I see which looks probably wrong are the returned values for these:

Code: Select all

Define x=WindowX(30,#PB_Window_FrameCoordinate)
Define y=WindowY(30,#PB_Window_FrameCoordinate)
Define w=WindowWidth(30,#PB_Window_FrameCoordinate)
Define h=WindowHeight(30,#PB_Window_FrameCoordinate)

They are not always the real values, and using DwmGetWindowAttribute() the values are correct.
If you are asking for these metrics I think the commands should always return the real on-screen values.
So probably this should be addressed.


Now, let's put this aside for now ... and look this.
I've tried an API only test:

Code: Select all

Enumeration
 #DWMWA_NCRENDERING_ENABLED = 1
 #DWMWA_NCRENDERING_POLICY
 #DWMWA_TRANSITIONS_FORCEDISABLED
 #DWMWA_ALLOW_NCPAINT
 #DWMWA_CAPTION_BUTTON_BOUNDS
 #DWMWA_NONCLIENT_RTL_LAYOUT
 #DWMWA_FORCE_ICONIC_REPRESENTATION
 #DWMWA_FLIP3D_POLICY
 #DWMWA_EXTENDED_FRAME_BOUNDS
 #DWMWA_HAS_ICONIC_BITMAP
 #DWMWA_DISALLOW_PEEK
 #DWMWA_EXCLUDED_FROM_PEEK
 #DWMWA_LAST
EndEnumeration

Procedure GetWindowRectEx (hWnd, *tRECT.RECT)

 Protected hDll, iDwmUsed
 Protected *DwmGetWindowAttribute
 Protected tRECT.RECT

 If OSVersion() >= #PB_OS_Windows_Vista
    hDll = OpenLibrary(#PB_Any, "dwmapi.dll")
    If hDll
        *DwmGetWindowAttribute = GetFunction(hDll, "DwmGetWindowAttribute")
        If *DwmGetWindowAttribute                 
            If CallFunctionFast(*DwmGetWindowAttribute, hWnd,  #DWMWA_EXTENDED_FRAME_BOUNDS, *tRECT, SizeOf(RECT)) = #S_OK
                iDwmUsed = 1               
            EndIf           
        EndIf           
        CloseLibrary(hDLL)
    EndIf
 EndIf
 
 If iDwmUsed = 0 ; fallback
    GetWindowRect_(hWnd, *tRECT)
 EndIf
EndProcedure

Structure RECT2
 x.i
 y.i
 w.i
 h.i
EndStructure

Procedure CalcDecoratedWindowSize (Style, StyleEx, *rect.RECT2)
 Protected r.RECT

 r\left = 0
 r\top = 0
 r\right = *Rect\w 
 r\bottom = *Rect\h
 
 AdjustWindowRectEx_(@r, Style, 0, StyleEx)

 *Rect\w = r\right - r\left
 *Rect\h = r\bottom - r\top
EndProcedure

Global hBrush = CreateSolidBrush_(GetSysColor_(#COLOR_WINDOW))

; window procedure

Procedure WinProc (hWnd, Msg, wParam, lParam)
 Select Msg
    Case #WM_CLOSE
        DestroyWindow_(hWnd)     
    Case #WM_NCDESTROY
        DeleteObject_(hBrush)
        PostQuitMessage_(0)
        ProcedureReturn 0     
 EndSelect 
 ProcedureReturn DefWindowProc_(hWnd, Msg, wParam, lParam)
EndProcedure

; window class

Classname$ = "MyApiWindow"

With wClass.WNDCLASSEX
    \cbsize  = SizeOf(WNDCLASSEX)
    \lpfnWndProc  = @WinProc()
    \hCursor  = LoadCursor_(0, #IDC_ARROW)
    \hbrBackground  = hBrush
    \lpszClassName  = @classname$
EndWith

RegisterClassEx_(@wClass)

; create window and process messages

StyleEx = 0

Define rect.RECT2
Define r.RECT



rect\x = 10
rect\y = 150
rect\w = 280
rect\h = 70

Style = #WS_VISIBLE | #WS_SYSMENU | #WS_CAPTION 
CalcDecoratedWindowSize(Style, StyleEx, @rect)
Debug "requested = " + rect\x
Debug "requested = " + rect\y
Debug "requested = " + rect\w
Debug "requested = " + rect\h
hWnd1 = CreateWindowEx_(StyleEx, Classname$, "without #WS_SIZEBOX (bad)", Style, rect\x, rect\y, rect\w, rect\h, 0, 0, 0, 0)

ShowWindow_(hWnd1,  #SW_SHOWDEFAULT)

GetWindowRectEx (hwnd1, @r)

Debug "actual = " + r\left
Debug "actual = " + r\top
Debug "actual = " + Str(r\right - r\left)
Debug "actual = " + Str(r\bottom - r\top)



rect\x = 10
rect\y = 300
rect\w = 280
rect\h = 70

Style = #WS_VISIBLE | #WS_SYSMENU | #WS_CAPTION | #WS_SIZEBOX 
CalcDecoratedWindowSize(Style, StyleEx, @rect)
Debug "requested = " + rect\x
Debug "requested = " + rect\y
Debug "requested = " + rect\w
Debug "requested = " + rect\h
hWnd2 = CreateWindowEx_(StyleEx, Classname$, "with #WS_SIZEBOX (good)", Style, rect\x, rect\y, rect\w, rect\h, 0, 0, 0, 0)

ShowWindow_(hWnd2,  #SW_SHOWDEFAULT)

GetWindowRectEx (hwnd2, @r)

Debug "actual = " + r\left
Debug "actual = " + r\top
Debug "actual = " + Str(r\right - r\left)
Debug "actual = " + Str(r\bottom - r\top)


While GetMessage_(msg.MSG, 0, 0, 0 )
    TranslateMessage_(msg)
    DispatchMessage_(msg)
Wend

UnregisterClass_(Classname$, GetModuleHandle_(#Null))

Code: Select all

[23:34:46] requested = 10
[23:34:46] requested = 150
[23:34:46] requested = 286
[23:34:46] requested = 95
[23:34:46] actual = 5
[23:34:46] actual = 145
[23:34:46] actual = 296
[23:34:46] actual = 105
[23:34:46] requested = 10
[23:34:46] requested = 300
[23:34:46] requested = 296
[23:34:46] requested = 105
[23:34:46] actual = 10
[23:34:46] actual = 300
[23:34:46] actual = 296
[23:34:46] actual = 105

For some reason the upper left corner of the window is not what specified in the CreateWindowEx_() call for the first window, and it's correct for the second one. The difference is the second one has the #WS_SIZEBOX style.
Looks like is the missing #WS_SIZEBOX the cause, and not the presence of #PB_Window_SystemMenu.
Adding or removing the #WS_SYSMENU style in the API example does not seem to have an effect. The positioning is correct in both cases.

Why this happens I don't know. But PB should be using the same API I believe and if the code above is correct (is it ? to me looks ok) then the result cannot be different.

In fact if you put that style in the PB window using #PB_Window_SizeGadget (which should be the #WS_SIZEBOX equivalent), all works ok.

Code: Select all

; BAD

OpenWindow(0, 10, 150, 280, 70, "30",#PB_Window_SystemMenu)
SetWindowColor(0,$F650F1)

OpenWindow(1, 0, 0, 280, 70, "30",#PB_Window_SystemMenu)
SetWindowColor(1,$0050F1)

x=WindowX(0,#PB_Window_FrameCoordinate)
y=WindowY(0,#PB_Window_FrameCoordinate)
w=WindowWidth(0,#PB_Window_FrameCoordinate)
h=WindowHeight(0,#PB_Window_FrameCoordinate)

ResizeWindow(1,(x+w),y, #PB_Ignore, #PB_Ignore)


; GOOD

OpenWindow(2, 10, 350, 280, 70, "30",#PB_Window_SystemMenu | #PB_Window_SizeGadget)
SetWindowColor(2,$F650F1)

OpenWindow(3, 0, 0, 280, 70, "30",#PB_Window_SystemMenu | #PB_Window_SizeGadget)
SetWindowColor(3,$0050F1)

x=WindowX(2,#PB_Window_FrameCoordinate)
y=WindowY(2,#PB_Window_FrameCoordinate)
w=WindowWidth(2,#PB_Window_FrameCoordinate)
h=WindowHeight(2,#PB_Window_FrameCoordinate)

ResizeWindow(3,(x+w),y, #PB_Ignore, #PB_Ignore)
 
While WaitWindowEvent() ! #PB_Event_CloseWindow :Wend

Using plain API return the same results.

If you know how to fix the API example, then probably the same thing can be applied to PB.

I would say I'm missing something but at the moment I don't see why the missing #WS_SIZEBOX should influence the correct positioning of the upper left corner of the window created.

EDIT: updated the API code with both the "requested" and the "actual" dimensions of the two windows.

[netmaestro]

WS_SIZEBOX goes by another name: WS_THICKFRAME, which should provide a subtle hint.

[luis]

WS_SIZEBOX goes by another name: WS_THICKFRAME, which should provide a subtle hint.

I know that, but maybe the hint it's too subtle for me as I don't see it explaining what's happening in the code above.
Can you elaborate ?

In the meantime I'll explain why I don't get the hint.

If the border is thicker, AdjustWindowRectEx_() should calculate a larger bounding rectangle for the second window while keeping the client area of both windows the same.
In fact it does just that.

bounding rectangle calculated for the first window (10, 150, 286, 95)
bounding rectangle calculated for the second window (10, 300, 296, 105)

So the second window should be slightly wider/larger, but both windows are asked to be created with the upper left corner at the same x coordinate.
The first one is at the wrong place, the second one is at the right place.
Also unexpectedly both windows on the screen have the same 296 x 105 bounding rectangle (they have the same dimensions and the border has the same thickness, yet one is resizable and one it isn't).




Where the equivalence between WS_SIZEBOX and WS_THICKFRAME comes into play here and how ?

[luis]

@mestnyi

After further testing I would say I verified the problem is really due to what discussed above and the OS lying back to your program.

That's why my snippet using DwmGetWindowAttribute() bypass the lies and return accurate information, but unfortunately it seem you can't entirely bypass this mechanism by using parallel APIs for everything, they simply are not there AFAIK.

So, to make the story short:

create a text file with this line

Code: Select all

/subsystem:windows,6.0

and when compiling your program point to that file in Compiler Options -> Linker options file

That fixed the problem for me, now the windows are created at the right offset and #PB_Window_FrameCoordinate seems to return the correct dimensions when using API or PB commands.

Please note using this setting your program should run only on Vista and above (I didn't verified it firsthand).

I think Fred should add a flag ASAP in the compiler options to enable this setting, similarly to the "Enable modern theme support (for Windows XP and above)".

Maybe something like "Enable true windows metrics (for Windows Vista and above)"

I found about this problem in 2009 and posted it in the forum, then I forgot about it because had no impact in what I was doing, so thanks for remind me.

[mestnyi]

create a text file with this line

Code:
/subsystem:windows,6.0

Indeed it works, at the end I heard at least somebody I'm happy.
But how ? What this mean for the marvel line?
In Linux this will be a way to work to check yet?

[heartbone]

create a text file with this line

Code:
/subsystem:windows,6.0

Indeed it works, at the end I heard at least somebody I'm happy.
But how ? What this mean for the marvel line?
In Linux this will be a way to work to check yet?

Yes and I am also happy for you mestnyi.
It's not easy tracking down these bugs and the amazing luis just applied strong logic to solve the mystery.
And normally I'm not one to endorse Google, but in this case I must join him in the suggestion to try that language translator.
Thanks for your kind offer to help me a bit earlier.

luis, just thought I'd butt in here at the happy resolution and ask you two questions.
Is the avatar of you, or of some Italian idol? The latest avatar reminds me so much of a postage stamp.
Does the avatar change indicate a new, even better luis?

Once again luis, a big heartfelt thanks for sharing your time with the forum, answering our questions.
As long as this forum remains, and hopefully at the web archive it is totally cataloged, people will be deriving knowledge from your efforts.

[luis]

But how ? What this mean for the marvel line?

/SUBSYSTEM is an option available in the Microsoft linker and by extension, since it tries to be compatible with it, in the POLINK linker used by PB.

It's used to set a flag in the executable which tells to the OS the type of subsystem the binary image is targeting.
Typically on Windows is WINDOWS or CONSOLE.
Optionally it's possible to specify a version for the subsystem, in our case 6.0.
6.0 is the internal version number used by Windows Vista -> http://en.wikipedia.org/wiki/List_of_Mi ... s_versions
When the OS loads the image binary, in our specific case it sees the minimum requirement is Windows Vista (the 6.0) and so under XP refuses to launch the exe (in the meantime I verified that) while under Windows 7 for example (again our specific case) it runs it and interprets the 6.0 as a message saying "hey, I'm aware of all the stuff happening in Vista and higher, don't go all "appcompatible" on me and treat all our exchanges regarding the windows' metric without lying".
So the well mannered pathological liar complies for once and we can be all happy as you are.

Well, I could be happier.

For more info about the MS link flags -> https://msdn.microsoft.com/en-us/librar ... 00%29.aspx

In Linux this will be a way to work to check yet?

Not sure what you are asking, but I a see a "Linux" string in the phrase and I'll try replying with "this stuff is obviously Windows-only".

[luis]

The latest avatar reminds me so much of a postage stamp.

I see what you mean, a 2 (something) stamp. But no, it's a version number.

The illustrious man in the picture is inspector Sledge Hammer (TV show) -> http://en.wikipedia.org/wiki/Sledge_Hammer!

Does the avatar change indicate a new, even better luis?

It's more a reminder to myself than anything else.