Support Forums > WinFBE - Code Editor and Visual Designer

WinFBE using CWindow #6

(1/2) > >>

Paul Squires:
I have attached the latest source code and binaries. A lot of work has gone into this version of the code and the editor is now almost to a usable state. Menu and Toolbar states are now working. The majority of the menu items have now been implemented (notable exceptions being the find/replace/goto/MRU and compile options). My first try at syntax coloring and code folding has been implemented. File dirty buffer states are now correctly handled when files are closed or the application ends. Configuration data is now saved and restored using full unicode variables and disk file.

Lots more to do.

Josť Roca:
Looking very good.

A couple of tips:

1) If an user has been working with e.g. 96 DPI with the editor using all the height of the working area and decides to change its DPI setting to a higher value, the bottom of the editor will go outside the monitor and he will be unable to resize it unless he deletes the .ini file.

In my editor I did include a menu option called "Restore Main Window Size" that adjusts the size to the working area:

--- Code: ---      CASE IDM_RESTOREWSIZE
         DIM rc AS RECT
         SystemParametersInfo SPI_GETWORKAREA, 0, @rc, 0
         MoveWindow hwnd, 0, 0, rc.Right - rc.Left, rc.Bottom - rc.Top, CTRUE
         AfxCenterWindow hwnd

--- End code ---

2) Another problem can happen if the user is using more than one monitor and changes the physical order of the displays. This can change the desktop coordinates from zero-based to negative, making the editor invisible because it will be positioned off-screen. Calling the function AfxForceVisibleDisplay (in should solve it.

--- Code: ---' ========================================================================================
' If you use dual (or even triple/quad) displays then you have undoubtedly encountered the
' following situation: You change the physical order of your displays, or otherwise
' reconfigure the logical ordering using your display software. This sometimes has the
' side-effect of changing your desktop coordinates from zero-based to negative starting
' coordinates (i.e. the top-left coordinate of your desktop changes from 0,0 to -1024,-768).
' This effects many Windows programs which restore their last on-screen position whenever
' they are started. Should the user reorder their display configuration this can sometimes
' result in a Windows program subsequently starting in an off-screen position (i.e. at a
' location that used to be visible) - and is now effectively invisible, preventing the
' user from closing it down or otherwise moving it back on-screen.
' The ForceVisibleDisplay function can be called at program start-time right after the
' main window has been created and positioned 'on-screen'. Should the window be positioned
' in an off-screen position, it is forced back onto the nearest display to its last
' position. The user will be unaware this is happening and won't even realise to thank you
' for keeping their user-interface visible, even though they changed their display
' settings.
' Source:
' ========================================================================================
PRIVATE SUB AfxForceVisibleDisplay (BYVAL hwnd AS HWND)
   ' // Check if the specified window-rectangle is visible on any display
   GetWindowRect(hwnd, @rc)
   ' // Find the nearest display to the rectangle
   mi.cbSize = SIZEOF(mi)
   hMonitor = MonitorFromRect(@rc, MONITOR_DEFAULTTONEAREST)
   GetMonitorInfoW(hMonitor, @mi)
   ' // Center window rectangle
   rc.left = mi.rcWork.left + ((mi.rcWork.right - mi.rcWork.left) - (rc.right-rc.left)) \ 2 = + ((mi.rcWork.bottom - - ( \ 2
   SetWindowPos(hwnd, 0, rc.left,, 0, 0, SWP_NOACTIVATE OR SWP_NOZORDER OR SWP_NOSIZE)
' ========================================================================================

--- End code ---

Paul Squires:
Excellent, thanks Jose! I have implemented both of your suggestions and it seems to be working very well.


Josť Roca:
This is enough. We don't need to call AfxCenterWindow.

--- Code: ---      CASE IDM_RESTOREWSIZE
         DIM rc AS RECT
         SystemParametersInfo SPI_GETWORKAREA, 0, @rc, 0
         MoveWindow hwnd, 0, 0, rc.Right - rc.Left, rc.Bottom - rc.Top, CTRUE

--- End code ---

These are little details that don't happen often, but when it happens they are very annoying for the user.

Also, in general, we have to be careful when displaying a dialog or another tool, to no exceed the bottom area. Otherwise, buttons like "Ok", "Apply" or "Cancel" aren't visible. Life was much easier when the resolution was 600x800.

Josť Roca:
Other options that I use when loading in the editor files that have been written and saved in Linux, are replacing tabs with spaces and converting end of line characters.

Converting line characters is very easy: you just send a message to the Scintilla control, e.g. SendMessageA (hSci, SCI_CONVERTEOLS, eolMode, 0), where eolMode can be SC_EOL_CRLF, SC_EOL_CR, or SC_EOL_LF. As I work only with Windows, the one that I use is SendMessageA (hSci, SCI_CONVERTEOLS, SC_EOL_CRLF, 0).


[0] Message Index

[#] Next page

Go to full version