WinFBE using CWindow #4

[Paul Squires]

Attached is the latest source code. I have been working on the "Environment Options" dialogs. The options are also saved and restored from a configuration file.

Updated: June 7, 2016
Updated: June 7, 2016 (later that evening)

[José Roca]

Remove the deletion of CWindow from the WM_DESTROY message and put it after DoEvents:

Code Select Expand


Function frmOptions_Show( ByVal hWndParent As HWnd, _
                          ByVal nCmdShow   As Long = 0 _
                          ) As Long

...
...


   ' Process Windows messages
   Function = pWindow->DoEvents(nCmdShow)

   ' // Destroy the CWindow class
   Delete pWindow


Otherwise, DoEvents is going to call a method that doesn't exist anymore.

[José Roca]

Remember that after receiving the WM_DESTROY message, the message pump must still exist to process the PostQuitMessage. If you delete the class, the pWindow pointer of pWindow.DoEvents is no longer valid.

[Paul Squires]

Thanks Jose! I have now made those changes.

The gpf is in my version of the color selection combobox. I see mistakes where I forgot to change code when going from ANSI to the UNICODE version.  I should have it all fixed by tomorrow.

[Paul Squires]

Updated the first post with the latest code.
Fixed gpfs on 64 bit.
Now using Jose's COM implementation of the FileOpenDialog (AfxIFileOpenDialogW).

[James Fuller]

Paul,
  Looks good but no menu items working except Exit and Environment the latter is still a bit goofy.
Sometimes it gpf's other times not. Setting paths and or the help path can trigger a gpf.
Sometimes the popup  just shows the headings.
James
Win10 and fb64

[Paul Squires]

Hmmm... I am wondering if the gpfs are related to using Jose's new COM version of the FileOpenDialog? I hope that I am using it correctly. I need to track down 100% of why the gpfs occur. It seems to happen on 64 bit more often.

I haven't moved the code for the other menu items there yet because I wanted to nail down the core of the environment options first. The techniques I learn there will help me using the CWindow class throughout the rest of the editor. I have huge chunks of code ready to put into the editor because I had already a large portion of the editor using FireFly. Lots of code is based on Jose's code from his SED Editor.

[Paul Squires]

Sometimes the popup  just shows the headings.

That's interesting. I have never seen that happen in all my tests.

[James Fuller]

Sometimes the popup  just shows the headings.

That's interesting. I have never seen that happen in all my tests.

Here are the screen shots.
James

[Paul Squires]

Thanks James! Not sure why that would happen. If it happens again then maybe you can run Spy.exe and examine the main options window to see if the 3 child windows exist. Tey should be named FBWindowClass:2, FBWindowClass:3, and FBWindowClass:4. Maybe they are created but now being shown correctly by my code.

My code calls:
TreeView_SelectItem( hWndTreeview, hItem)

and that should trigger the TVN_SELCHANGED notification. The code that responds to that notification hides/shows the correct child window and moves it into place.

[Paul Squires]

I have updated the initial post with new source code. I moved the DELETE pWindow code out of the WM_DESTROY for each of the 3 child sub-forms of the Options Dialog. I moved it a place after the main Options dialog is destroyed. I recompiled and ran the program several times and have not seen a GPF. I have also changed some code that I think was wrong related to using the function SetWindowTextW.

Please let me know if you continue to see any GPFs.

Thanks!

[José Roca]

Hi Paul,

One thing that you have to change is pWindow->GetControlWindowRect( hLabel, @rc ) to GetWindowRect( hLabel, @rc ).

Code Select Expand


             ' Move the child Form into place. The child form will be displayed under the header label.
             Dim rc As Rect
'             pWindow->GetControlWindowRect( hLabel, @rc )
             GetWindowRect( hLabel, @rc )
             MapWindowPoints( Null, HWnd, Cast(LPPOINT, @rc), 2 )
             SetWindowPos hForm, HWND_TOP, _
                            rc.Left + pWindow->ScaleX(5), pWindow->ScaleY(50), _
                            pWindow->ScaleX(370), pWindow->ScaleY(300), _
                            SWP_SHOWWINDOW

             InvalidateRect HWnd, ByVal Null, True
             UpdateWindow HWnd


The CWindow Rect functions, and also others, return unscaled values suitable to be used when they are going to be passed to another CWindow function that will scale them. But as MapWindowPoints s an API function, we have to pass the scaled values (as the windows and controls are already scaled, GetWindowRect will return the correct values).

[José Roca]

Another way to do it:

Code Select Expand


             Dim rc As Rect
             GetWindowRect( hLabel, @rc )
             MapWindowPoints( Null, HWnd, Cast(LPPOINT, @rc), 2 )
             ' // Unscale rc.Left because SetWindowPos will scale the values
             rc.Left   /= pWindow->rxRatio
             pWindow->SetWindowPos hForm, HWND_TOP, _
                            rc.Left + 5, 50, _
                            370, 300, _
                            SWP_SHOWWINDOW


[José Roca]

That is, CWindow methods such CWindow.GetWindowRect, CWindow.GetClientRect, CWindow.GetControlWindowRect, CWindow.ControlWidth or CWindow.ControlHeight, return unscaled values suitable to be passed to another CWindow method.

But if the target is an API function, then use the API counterparts, such GetWindowRect or GetClientRect. Otherwise, you will be passing unscaled values to functions that don't scale them.

Clear as mud

[José Roca]

After my change, it looks correct in my computer, at 192 DPI. See the capture.