Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

I switched back to 5.2 because that is the version that ships with the official FreeBasic release. I plan to keep WinFBE in sync with the gcc that ships with the official compiler rather go on my own with different version. Having said that, the next release of WinFBE will make it easy to have multiple backend gcc versions and to be able to switch amongst them easily as you see fit.

codeJeff will be upgrading the gcc for the next FB release:
https://www.freebasic.net/forum/viewtopic.php?f=17&t=27889&start=315#p282252

Paul,

Could you explain the different "GCC" versions for those of us that don't live "under the hood"??

I noticed that when your WinFBE was at 1.07.1 the command-line looked line this:

     =>   FreeBASIC-1.07.1-gcc-8.4 (I think this was a .4, for sure it was 8.)

But, when we updated to 1.07.2 we got this:

     =>   FreeBASIC-1.07.2-gcc-5.2 (the version is now 5... going DOWN)

So what is up with GCC?  Is version 8 not better than version 5

Thx!!  : )

Sounds great, and thanks for all of your work. I'm liking FreeBASIC as an alternative for BASIC development on Windows and it's been fairly straight-forward to convert our header files to use their syntax. Once I get things in a happy place, I'll make them available along with the PowerBASIC headers and examples we already include.


If anyone out there is using SocketTools and wants to give the translated headers a test drive, I can make them available.

Hi Mike, great to see you around here again and thank-you so much for the great list of suggestions. I have copied all of them into my working to-do list and I will work through them with an eye to implement as many of them as I can before the next update.

I can quickly comment on a couple:

I only just recently implemented the Windows Installer. I know about the AppData scenario because I had to do the same with my old FireFly Visual Designer installer. This is just a case of trying to provide a quick install method for those users adverse to the whole unzipping archives to install a program approach. I have to do some internal work to get the config files, etc to default to the AppData folder. I will get there eventually. However, the larger problem is that the "Program Files" folder contains spaces and the current gcc toolchain that I am using seems to choke at the linker stage when it deals with paths with spaces. I have struggled with this problem for some time even attempting to convert long file paths to short, etc. I decided to let the issue rest for a while and come back to it at a later time with the caveat that in the meantime users should install WinFBE into non-secure areas and with non-space file paths.

You specified a number of quality of life improvements that should be easy for me to implement. Thanks!

The default compiler paths normally would have been pre-filled on first use of the program. This was always the case but I recently changed the backend toolchain and forgot to update the default config compiler paths. Silly oversight on my part.

If you come across anything else that you would like to see added, changed, deleted then please let me know.

Lately, I have been trapped into the Linux world, doing a lot of work there so my Windows time has suffered. I will dedicate more time to polishing WinFBE.  :-)

Thanks,
Paul

Hi Paul, I've been porting our header files to FreeBASIC as a side project, and have been working with WinFBE to write some test programs. You've done a really nice job with this, congratulations!  I ran into a few issues and had some thoughts about improvements (I also might be missing something that's already there, and I just haven't seen the option or it may be an issue specific to FB). This is with the latest and greatest build.


A few things that caught me by surprise on first install:


1. I tend to install everything under C:\Program Files\ (or C:\Program Files (x86)\ depending) and was surprised to see that it wouldn't work there. It's not a huge thing, but that's the standard "secure" folder that has restricted permissions, so if there's a way to make that work and the AppData folder to store anything that needs to be created/modified would be great. In the interim, it might be a good idea for your installer to check the install path provided by the user and let them know it can't be in a folder who's name contains whitespace.


2. The Check for Updates option seemed to work pretty sporadically for me. It would be successful sometimes, other times it would just hang the IDE or return a "Failed to retrieve update information" error. I had an active Internet connection at the time, but it might be a good idea to double check that, and perhaps perform the check using a worker thread so it doesn't block the UI thread.


3. When doing a replace all, following that with a Ctrl+Z doesn't undo all of the changes made, only the last one.


4. When searching, preforming subsequent searches with F3 often doesn't work, or when it did, it would actually search on the previous keyword/phrase, not the current one. That was pretty strange and I haven't found a way to make that 100% reproducible, but I've had it happen a number of times. Often, F3 just did nothing and I had to use the arrows in the mini search window.


5. Ctrl+H inserts a control character into the source. I know by default you're using Ctrl+R, but in most editors I've worked with these days (Notepad++, Visual Studio, Visual Studio Code, etc.) Ctrl+H pulls up the find/replace window. Might want to think about mapping that. I'm not sure there's a real world case where you'd want to insert backspace control characters into source code. May at least want to consider making that behavior optional.


6. The Win32 API reference that's included is positively ancient (talking APIs back in the prehistoric days of Windows 95/NT). Instead of just using that HTML Help file perhaps an option to specify a link to the current online docs from Microsoft (e.g.: https://docs.microsoft.com/en-us/windows/win32/api/)


7. Widen the width of the font name selector. I noticed this because I use the "JetBrains Mono NL Medium" font for source code editing, and the dropdown provided is too small to show the complete name, so I had to guess which one I was actually picking (there's a variety of "JetBrains Mono" font styles, some with ligatures, others without).


8. When selecting a control from the toolbox and then just clicking on a form (not "drawing" it), it creates a control with a height and width of 0. Might want to have it default to something that makes it a bit easier to adjust (e.g.: 40x100 for a button). Could also make that configurable in the IDE, but at least not 0x0.


Some more cosmetic and quality-of-life suggestions, in no particular order:



1. On first open, the IDE sizes itself to the full display. On larger, modern displays I think this is a bit distracting. Perhaps consider a maximum size value on first startup. But again, that could just be me and it's purely a visual, not functional, thing.


2. Default to the location for the x86 and x64 compilers on first install. I had to manually set those, and that was a bit of a surprise.


3. The ability to search using regular expressions.


4. The ability to "replace all" in all files in the project, or just those files which are open.


5. An option in "find in files" to exclude files with binary content; that just makes it easier to do a global replace, but not attempt to match anything in binary resources like images, icons and so on.


6. Support for expanding environment variables in command line options, before you pass them off to the FB compiler. This would allow for paths like "%AppData%\Foo\Bar" or "%HOMEPATH%\src\inc" and help make projects more portable. An alternative syntax for that which is also popular is $(EnvVarName) and that's use with Visual Studio.


7. The ability to snap the toolbox to the IDE.


8. If you select Run Executable (Shift+F5) and any of the source code has changed since the executable was last built, provide an option to ignore (current behavior), warn, or automatically compile and run (same as F5) but only if there's been a change.


9. When double-clicking a control in design view, automatically switch to the code view for the default event handler for that control (e.g.: the _Click handler if it's a button).


10. When double-clicking an event in the toolbox, automatically enable that event, create the placeholder (if needed) and switch to that event in the code view.


11. The ability to set the default control font name and size for all controls created for that project, rather than always defaulting to Segoe UI 9pt.


12. Saving the build type (e.g.: Win32 GUI Debug) with the project and switch to that when the project is opened, rather than having it being application wide for the IDE.

I have looked at some examples in C-code, what i wanted to do is very complex. and examples are not very comprehensive.
This is still too difficult for me.

Thanks for the effort.

I was hoping to be able to get the current font of the control and select it into the DC, but that doesn't seem to work. Maybe because it is a RichEdit control? Maybe because RichEdit controls can have multiple fonts, it does not expose access to the WM_GETFONT message?

Code: [Select]

     Case WM_PAINT
            DIM hDC AS HDC                                                                                           
            Dim As RECT  rect
                                                                                                                 
             DefSubclassProc(hwnd, uMsg, wParam, lParam)         
             
             hdc  = GetDC(hWnd)                                                                                                               
             
             dim as long state = SaveDC(hdc)
             
             dim as HFONT hFont1 = GetWindowFont(hWnd)
             
             SelectObject( hdc, hFont1 )
             
             SetBkMode(hdc,TRANSPARENT)
             SendMessageW( hWnd, EM_GETRECT, 0, cast(LPARAM, @rect) )
             
             DrawTextW(hdc,"Hello World",-1,@rect,0)
             
             RestoreDC(hdc, state)
             DeleteDC(hdc)                       

I guess you could create a scaled CWindow font in WM_PAINT, select it into the DC, do your painting, restore the DC, and finally delete the created font. I haven't tried that but it should definitely work.

Hello people,

i am trying to draw with drawtext in a richedit control 'hello world' it works but the text is very small.
I don't know how to scale this correctly.

Code: [Select]

#define UNICODE
#INCLUDE ONCE "Afx/CWindow.inc"
USING Afx

CONST IDC_RICHEDIT = 1001

DECLARE FUNCTION WinMain (BYVAL hInstance AS HINSTANCE, _
                          BYVAL hPrevInstance AS HINSTANCE, _
                          BYVAL szCmdLine AS ZSTRING PTR, _
                          BYVAL nCmdShow AS LONG) AS LONG

   END WinMain(GetModuleHandleW(NULL), NULL, COMMAND(), SW_NORMAL)



' // Forward declaration
DECLARE FUNCTION WndProc (BYVAL hwnd AS HWND, BYVAL uMsg AS UINT, BYVAL wParam AS WPARAM, BYVAL lParam AS LPARAM) AS LRESULT
Declare FUNCTION RichEdit_SubclassProc (BYVAL hwnd AS HWND, BYVAL uMsg AS UINT, BYVAL wParam AS WPARAM, BYVAL lParam AS LPARAM, BYVAL uIdSubclass AS UINT_PTR, BYVAL dwRefData AS DWORD_PTR) AS LRESULT

' ========================================================================================
' Main
' ========================================================================================
FUNCTION WinMain (BYVAL hInstance AS HINSTANCE, _
                  BYVAL hPrevInstance AS HINSTANCE, _
                  BYVAL szCmdLine AS ZSTRING PTR, _
                  BYVAL nCmdShow AS LONG) AS LONG

   ' // Set process DPI aware
    AfxSetProcessDPIAware

   DIM pWindow AS CWindow
   pWindow.Create(NULL, "CWindow with a Rich Edit control", @WndProc)
   pWindow.SetClientSize(500, 320)
   pWindow.Center
   
   DIM hRichEdit AS HWND = pWindow.AddControl("RichEdit", , IDC_RICHEDIT, "", 350, 250, 75, 23, , , , CAST(SUBCLASSPROC, @RichEdit_SubclassProc), IDC_RICHEDIT, CAST(DWORD_PTR, @pWindow))
   SetFocus hRichEdit
   

   ' // Dispatch Windows messages
   FUNCTION = pWindow.DoEvents(nCmdShow)

END FUNCTION
' ========================================================================================

' ========================================================================================
' Processes messages for the subclassed RichEdit window.
' ========================================================================================
FUNCTION RichEdit_SubclassProc ( BYVAL hwnd AS HWND, BYVAL uMsg AS UINT, BYVAL wParam AS WPARAM, BYVAL lParam AS LPARAM, BYVAL uIdSubclass AS UINT_PTR, BYVAL dwRefData AS DWORD_PTR ) AS LRESULT

   SELECT CASE uMsg

     Case WM_PAINT
            DIM hDC AS HDC                                                                                           
            Dim As RECT  rect
                                                                                                                 
             DefSubclassProc(hwnd, uMsg, wParam, lParam)         
             
             hdc  = GetDC(hWnd)                                                                                                               
             
             SetBkMode(hdc,TRANSPARENT)
             SendMessageW( hWnd, EM_GETRECT, 0, cast(LPARAM, @rect) ) 
             
             DrawTextW(hdc,"Hello World",-1,@rect,0)
             
             DeleteDC(hdc)                       
         
      CASE WM_DESTROY
         ' // REQUIRED: Remove control subclassing
         RemoveWindowSubclass hwnd, @RichEdit_SubclassProc, uIdSubclass

   END SELECT

   FUNCTION = DefSubclassProc(hwnd, uMsg, wParam, lParam)

END FUNCTION
' ========================================================================================

' ========================================================================================
' Main window callback procedure
' ========================================================================================
FUNCTION WndProc (BYVAL hwnd AS HWND, BYVAL uMsg AS UINT, BYVAL wParam AS WPARAM, BYVAL lParam AS LPARAM) AS LRESULT

   SELECT CASE uMsg

      CASE WM_COMMAND
         SELECT CASE GET_WM_COMMAND_ID(wParam, lParam)
            ' // If ESC key pressed, close the application sending an WM_CLOSE message
            CASE IDCANCEL
               IF GET_WM_COMMAND_CMD(wParam, lParam) = BN_CLICKED THEN
                  SendMessageW hwnd, WM_CLOSE, 0, 0
                  EXIT FUNCTION
               END IF
         END SELECT

      CASE WM_SIZE
         ' // If the window isn't minimized, resize it
         IF wParam <> SIZE_MINIMIZED THEN
            ' // Resize the controls
            DIM pWindow AS CWindow PTR = AfxCWindowPtr(hwnd)
            IF pWindow THEN
               pWindow->MoveWindow GetDlgItem(hwnd, IDC_RICHEDIT), 100, 50, pWindow->ClientWidth - 200, pWindow->ClientHeight - 150, CTRUE
            END IF
         END IF

    CASE WM_DESTROY
         ' // End the application by sending an WM_QUIT message
         PostQuitMessage(0)
         EXIT FUNCTION

   END SELECT

   ' // Default processing of Windows messages
   FUNCTION = DefWindowProcW(hWnd, uMsg, wParam, lParam)

END FUNCTION
' ========================================================================================


it is possible to inherit the scaling, font, etc. from the RichEdit control so that the text being drawn looks the same as the typed version?

Yes. I changed the code but forgot to update the documentation. Thanks for pointig it.

There is a small mistake in the help text.

WNDPROC ?

Code: [Select]

pWindow.AddControl("Button", pWindow.hWindow, IDC_BUTTON, "Click me", 350, 250, 75, 23, , , , _
   CAST(WNDPROC, @Button_SubclassProc), IDC_BUTTON, CAST(DWORD_PTR, @pWindow))

I think it must be

Code: [Select]

pWindow.AddControl("Button", pWindow.hWindow, IDC_BUTTON, "Click me", 350, 250, 75, 23, , , , _
   CAST(SUBCLASSPROC, @Button_SubclassProc), IDC_BUTTON, CAST(DWORD_PTR, @pWindow))

thanks for sharing the framework