WinFBE using CWindow #4

[José Roca]

In the CTabPage class of CWindow, the method that creates the tab page unscales the values because the Create method will scale them.

Code Select Expand


   .GetWindowRect(hTab, @rc)
   .SendMessageW hTab, TCM_ADJUSTRECT, FALSE, CAST(lParam, @rc)
   .MapWindowPoints NULL, hTab, CAST(LPPOINT, @rc), 2
   ' // Adjust for High DPI because create will resize the values
   rc.Left   /= this.rxRatio
   rc.Right  /= this.rxRatio
   rc.Top    /= this.ryRatio
   rc.Bottom /= this.ryRatio
   ' // Calculate coordinates and size
   x = rc.Left
   y = rc.Top
   nWidth  = max(1, rc.Right - rc.Left)
   nHeight = max(1, rc.Bottom - rc.Top)
   m_hTabPage = this.Create(hTab, wszTitle, lpfnWndProc, x, y, nWidth, nHeight, dwStyle, dwExStyle)


but in the method that resizes the pages I don't unscale anything because I'm just caling API functions.

Code Select Expand


            DIM rcParent AS RECT
            .GetWindowRect(hTab, @rcParent)
            ' // Calculates the tab control's display area given its window rectangle
            .SendMessageW(hTab, TCM_ADJUSTRECT, FALSE, CAST(LPARAM, @rcParent))
            ' // Convert to window coordinates
            .MapWindowPoints(NULL, hTab, CAST(LPPOINT, @rcParent), 2)
            ' // Move the tab page
            .MoveWindow(pTabPage->hTabPage, rcParent.Left, rcParent.Top, _
               rcParent.Right - rcParent.Left, rcParent.Bottom - rcParent.Top, CTRUE)


[Paul Squires]

Yup, clear as mud 

I have made the changes and I'll try to remember this as I continue coding the application.

[José Roca]

Another suggested change:

In modCBColor.inc, change

Code Select Expand


SelectFont( lpdis->hDC, GetStockObject(DEFAULT_GUI_FONT) )


to

Code Select Expand


SelectFont( lpdis->hDC, AfxCWindowPtr(hwnd)->Font)


With GetStockObject(DEFAULT_GUI_FONT) the font appears smaller than it should in my system.

With SelectFont( lpdis->hDC, AfxCWindowPtr(hwnd)->Font) it will use the same scaled font that the main window.

Notice the convenience of AfxCWindowPtr(hwnd), a clever function that not only allows you to retrieve the CWindow pointer passing the handle of the main window or the handle of any of its child controls, but also lets you to call the methods of CWindow directly, using the -> notation, without having to do:

Code Select Expand


DIM pWindow AS CWindow PTR
pWindow = AfxCWindowPtr(hwnd)
pWindow->Font


BTW I'm working in wrappers for the common controls.

[Paul Squires]

AfxCWindowPtr(hwnd)->Font

That syntax is very clever!

Yes, i am making the change right now. 

[Paul Squires]

BTW I'm working in wrappers for the common controls.

Definitely looking forward to these wrappers!

My next step now is to revisit the class structure that I set up for document handling. I want the editor to be able to handle multiple projects at once.

Workspace
-- Project 1
---- File 1
---- File 2
---- File 3
---- etc
-- Project 2
-- etc

Each project will need to be able to specify compiler options. Likewise, each file within a project needs to be able to have compiler options specified (because some files may be compiled into OBJ and then linked to the main BAS).

Also, need to think about how to handle the build process so that only dirty files are recompiled (unless Rebuild All is specified).

Just starting to think about this stuff but it is important to get it right because the entire guts of the editor will then revolve around it.

[José Roca]

AfxCWindowPtr(hwnd)->Font

That syntax is very clever!

Yes, i am making the change right now. 

That's a technique that I suggested to the late Bob Zale to improve the PB COM support and that I called calculated object reference. FB classes are not COM classes, but the principle is the same, only the way to achieve it differs. Fortunetely, some clever guys did a good job implementing function pointers in FB, so it has been easy.

I tried hard to modernize PB programming, but apparently my techniques are above most PBer's heads. DDT has triumphed and it wil turn against them.