Unusual Problem

[Marty Francom]

I have run into an unusual problem with a FF2 program. 
The problem is that when the program is run on my Dell LapTop computer which has the Vista OS,  the programs window is truncated by 1/8th inch aprx.  However, the the same program is run on my older XP computers or on my Del DeskTop Computer the screen appear normal and is the correct size.   
This problem seems to be computer specific so not likely to be a FF problem.
Anyone have any idea what might be causing this and what I might do to correct the problem?

I have attached two screen prints so you can see what I am talking about.  Notice the bottom of the programs window.  The DelScrnLT.jpg shows the truncated problem.  The other picture DelScrnDT.jpg is normal.

[BudDurland]

Is the size of the form window static or calculated at run time? 

[Marty Francom]

I believe it is static.  The form create routine sets the size when the form is created.  There is no ability for the user to reset size after the form/window is created.  Except the user can minimized to task bar and Restore from Task bar, but doing so has no effect on the problem.

[Chris Boss]

A quick guess.

The Menu font on the clipped version is much, much larger.

If a window is created using a fixed pixel size, CreateWindowEx creates the window based on outside dimensions. This means the border thickness, as well as the menu height effects the overall client area size. In essence, if the window is created the same size on two systems, with different system metrics (size of menu font, size of border) the client area (inside area of form) is not guaranteed to be the same.

This appears to be your problem.

The solution is to autosize the form based on your desired client area.

This is why scalable coordinate systems are so useful , particularly those which define a window based on its desired client area.

This is a problem with fixed pixel based coordinate coding.

One useful technique is to call GetClientRect and GetWindowRect in the windows %WM_CREATE message. Compare the two width/heights of the two rectangles. The difference is the area of all the non-client areas (borders, menu, scrollbars). Once you have the offset for the non-client area, then resize the window to get the expected client area size.

Code Select Expand


' calculate non-client area offsets to resize for proper client area
GetWindowRect hWnd, WR
GetClientRect hWnd, CR
' calculate the difference between client area and actual area of window
XOffset=(WR.nRight-WR.nLeft)-(CR.nRight-CR.nLeft)
YOffset=(WR.nBottom-WR.nTop)-(CR.nBottom-CR.nTop)
' W = Desired width of client area
' H = Desired height of client area
NewWidth = W+XOffset
NewHeight = H+YOffset
NewX=WR.nLeft+(((WR.nRight-WR.nLeft)-NewWidth)/2)
NewY=WR/nTop+(((WR.NBottom-WR.nTop)-NewHeight)/2)
' now resize the window using the new coordinates and width/height


[TechSupport]

Thanks Chris - you're right, the form needs to be expanded based on the client area. In FF3, I'm adding a call to AdjustWindowRectEx similar to what Dominic does in his designer.

I notice that you have a new forum. SMF is pretty good software. It should be a big improvement over your old forum software. Good luck with your new 5.0, I see that you have some nice new features in the works. 

[Chris Boss]

Paul,

The technique I posted is a better solution.

AdjustWindowRect

does not take into consideration scrollbars, nor can it take into consideration the height of the menus if they wrap.

I create the window without the WS_VISIBLE style and then resize it and then show it.

I define windows (forms) based on desired client area and not on window size.
Also I use autoscaling based in the end users system font setting. If you define everything in pixels, it will not take into consideration larger fonts because of the system font setting. This can make the end users app look strange in some instances.

As an example, create a FireFly app with a number of different controls on it, with very exact spacing between the controls and unique font sizes for some of the controls.

Compile the app and then change the system settings for the system font and other system metrics and then see the results.

One example where things can get messed up is things like a Tab control. If the system font makes its font larger, then the client area of the tab control (where you place your tab pages) can be smaller and then you have some strange results.

On another note:

I won't mention much here (not the place to do it), but yes EZ... 5 will have some interesting new features.

[TechSupport]

Code Select Expand


Function FLY_AdjustWindowRect( ByVal hWndForm As DWord, _
                               ByVal cxClient As Long, _
                               ByVal cyClient As Long _
                               ) As Long
                               
   Local dwStyle As DWord
   Local hMenu   As DWord
   Local rc      As Rect
   
   If (cxClient <> 0) And (cyClient <> 0) Then
      dwStyle = GetWindowLong( hWndForm, %GWL_STYLE )
      rc.nLeft = 0: rc.nTop = 0: rc.nRight = cxClient: rc.nBottom = cyClient
      hMenu = GetMenu( hWndForm )
      AdjustWindowRectEx rc, dwStyle, (hMenu <> %Null), GetWindowLong(hWndForm, %GWL_EXSTYLE)
      If (dwStyle and %WS_HSCROLL) = %WS_HSCROLL Then rc.nBottom = rc.nBottom + GetSystemMetrics(%SM_CYHSCROLL)
      If (dwStyle and %WS_VSCROLL) = %WS_VSCROLL Then rc.nRight  = rc.nRight  + GetSystemMetrics(%SM_CXVSCROLL)
      SetWindowPos hWndForm, %Null, 0, 0, _
                   rc.nRight-rc.nLeft, rc.nBottom-rc.nTop, _
                   %SWP_NOZORDER Or %SWP_NOMOVE Or %SWP_NOACTIVATE
   End If

End Function



Mostly stolen from Dominic.