I have started work on the next update (v2.2.1): https://www.freebasic.net/forum/viewtopic.php?f=8&t=25215&start=795#p288353
I look forward to getting a new version released. :-)
Hello Paul
Glad you are feeling better and have the energy to work on an update again.
I find the idea very good to be able to work with different tool chains.
Greetings from Germany.
Thank you, Santa!
Thanks guys! Feels good to be back programming on WinFBE. I am now in the midst over a *major* overhaul of the look and feel of the editor. One thing that I have realized is that Jose's Afx library of routines and his CWindow class has been instrumental in making these changes somewhat easier. I hope that Jose is still around these days and still programming (or at least still enjoying his photography and history).
Best news I have seen this year!
I am so happy you are back into programming!
-Peter
This was a fun bit of programming.... after trying and failing to create what I wanted with ownerdraw menus, I decided to code the entire top menu system from scratch. The result is fantastic and the only thing missing now is navigation of the menus via keyboard. Keyboard accelerators work but not activating a menu and traverse it via the keyboard. That will be an exercise for another day.
(https://www.planetsquires.com/images/newmenus.png)
Nice! Gets my vote for Dark Mode...
Actually adding keyboard navigation support has been relatively easy given that the individual menu items are simple Label controls. Just needed to set WS_GROUP style for the first label on the menu and then use GetNextDlgGroupItem() to iterate the list. that Win32 api function takes care of bypassing disabled controls (eg. separator bars) and then returns the hWnd of the next menu item that needs to be highlighted. It works in forward and reverse and even loops around the start or end of the list.
I even added a really cool, but subtle, drop down shadow on the popup menus. It is a semi transparent WS_EX_LAYER window that uses alpha blending. It is positioned offset just underneath the popup menu form. Pretty cool. Nerdy... but cool. :-)
Quote from: Paul Squires on December 31, 2021, 03:54:17 PM
Actually adding keyboard navigation support has been relatively easy given that the individual menu items are simple Label controls. Just needed to set WS_GROUP style for the first label on the menu and then use GetNextDlgGroupItem() to iterate the list. that Win32 api function takes care of bypassing disabled controls (eg. separator bars) and then returns the hWnd of the next menu item that needs to be highlighted. It works in forward and reverse and even loops around the start or end of the list.
Switched from using a group of Labels to one single ownerdrawn ListBox for the menuitems. Simplifies the code and makes keyboard movement even easier.
Busy few days writing all of this new UI from scratch using ownerdraw. Looks good.
Here is the finished StatusBar. 100% themed using dark theme. You have the option to theme the UI in any manner you wish simply by editing a simple text file.
(https://www.planetsquires.com/images/statusbar.png)
...and here is the (mostly) complete Explorer.
(https://www.planetsquires.com/images/explorer.png)
Hey Paul
It looks very good. :)
I am already looking forward to the revised version.
Thanks Joerg, I'm working on the top tab control now. About half finished. Once that part is done then the major elements of the GUI will be complete and then I can move on to optimizing a lot of the internal code. Lots of stuff in there that has been added over the years that could be done better and/or completely removed. One thing that would be a really nice to have for the update would be a full keyboard mapping editor whereby the user can pick and choose what keys they want to bind what editor actions. That would be a fair amount of work but it would be well worth it in the long run.
Here is the result of today's work... a 100% re-worked version of the Find/Replace dialog. It is very similar to VSCode's look and feel. It uses a simulated alpha blended drop shadow and edging to give it a sculpted look that makes it stand out more from the flat looking edit windows.
Went down a couple of rabbit holes with this one. You can set cue banner text with standard edit controls, but you can not (easily) center edit control text VERTICALLY so the text in the find and replace text boxes did not look pleasing to the eye (jammed up to the top edge leaving too much space below the text). I switched to RichEdit controls and I could now easily position the text via the EM_SETRECT but using RichEdit controls prevented me from using cue banner text! Basically, I traded one problem for another. I was able to solve the cue banner problem by subclassing the RichEdit controls and allowing the control to paint itself in WM_PAINT & WM_PRINTCLIENT, and then do my painting of the cue banner text. Just needed to do some fancy stuff to ensure that I got the correct HDC. Good thing Google was able to help me figure out the proper sequence of WinAPI calls and flags to use in the calls. :-)
Also, in the screenshot (and in the other screenshots I've posted) you will see that the "icons" are not really icons or graphics. They are unicode glyphs taken from the Segoe UI Symbols font. This makes it easier to correctly size the "graphic" and to paint its fore and back colors easily especially since now that the user can specify any color for these things via a theme text file.
Next up, finish off the code for the custom vertical scrollbar for the Explorer owner draw listbox, and then add a custom horizontal scrollbar for the top tab control. These scrollbars appear (if needed) when the user mouses over the control and disappear when the mouse leaves. They are so much nicer looking than the 30 year old looking standard Windows scrollbars. I will also be using these scrollbars to replace the ones in the Scintilla control. Speaking of Scintilla, I will be compiling the latest Scintilla version and fixing up the freebasic lexer. The Scintilla version I'm using is getting rather dated now.
(https://www.planetsquires.com/images/findreplace.png)
Thanks for your continued work on the IDE. Your generosity is appreciated.
Hi Paul :-)
I like the new look, any estimate on the release?
Quote from: Johan Klassen on January 13, 2022, 09:43:29 PM
Hi Paul :-)
I like the new look, any estimate on the release?
Not sure at this time. I am creating a lot of new code every day but I have a fair amount of to-do items left in my notebook. When it is in a stable condition then I will probably upload test version so you guys can see how the editor reacts to your particular computer setups.
thanks Paul :-)
Hey Paul
When we start programming and the code works, we are satisfied.
Then, as our programming knowledge and skills improve over time, we sometimes wonder how we could create such "modest" code and are no longer quite so satisfied.
I think all good programmers feel that way.
..... I am not such a good programmer..... sometimes I think. :-)
I'm looking forward to the beta or release version.
You are taking WinFBE to a new level with this.
Like I said before... it looks very good.
Thanks Joerg, you are correct. Lots of old code that I look at now and know that I can write it much better now. :-)
Here is what I've learned and implemented over the past couple of days.
- How to create semi-transparent popup windows allowing me to create a custom scrollbar that hovers above the child window much like it does in VSCode. You don't use WM_PAINT for this, you have to use UpdateLayeredWindow whenever you want to update the UI. I also learned that you need to hook into the message pump and redirect mouse messages because semi-transparent popup windows (WS_EX_LAYERED) do not get messages sent to their procedure handlers.
- I am now using the very latest Scintilla editing component. The lexers are no longer part of the Scintilla component itself. You need to compile whatever lexer(s) you need into a separate DLL (Lexilla.dll) and then retrieve the lexer pointer and feed it into the Scintilla control. I learned (after many GPF's) that you need to retrieve a new pointer for EVERY Scintilla window you create. You can not simply get the lexer pointer from Lexilla.dll and share it amongst all your windows. When a Scintilla window is destroyed it also destroys the pointer so therefore you can not share a global pointer. Using Visual Studio 2019 Community Edition, I was able to create 32 bit and 64 bit DLL's for both Scintilla and Lexilla and they work perfectly with the new code base. Now I can simply concentrate on modifying the existing lexer to make it perfect for FreeBasic.
Just finished coding "Load Session" and "Save Session" for people who do not like, or do not need, to work with full blown Projects. A Session basically saves the current open editor windows and your editing position within those windows. It also saves the selected Build Configuration. There is also an Environment Option to automatically load your last used session when WinFBE starts up. Session states are simple configuration files saved to disk in unicode format (*.session).
Next up... Auto save and backup of files.
Auto Save (and crash recovery) of files (thanks to Wallyg for this inspiration)
I analyzed how it works in Glade and also JEdit. They both deal with Auto Save very similarly.
This turned out to be a really cool feature and works perfectly for Project and non-project based files alike. The "Auto Save" option is now available on the File menu (similar to VSCode) so it is very easy to turn and off. This will all be in the next WinFBE update.
When auto save is enabled, every 10 seconds a check is performed to determine if the editor text has been modified further since the last AutoSave was done. If yes, then WinFBE automatically saves the current source code to a filename wrapped in # characters. For example, if the source filename is C:\FB\EXAMPLE.BAS then the auto saved file is called C:\FB\#EXAMPLE.BAS#. Later in a subsequent editing session, when WinFBE tries to load the original file it checks to see if the ### wrapped file exists and if it does, it checks the date on both files. If the auto saved #filename# is newer then WinFBE asks the user if they want to use the new auto saved version.
This feature is fantastic for situations where your computer has a power outage or WinFBE crashes prior to saving your unsaved edits.
This feature is also different than "backup". As Wallyg described in his FreeBasic forum post, he mentioned that Glade attaches a trailing tilde ~ to its auto save file. In actuality, Glade uses the ~ when backing up a file (so does JEdit). Both Glade and JEdit use the ### approach when handling auto save. Automatic backup of files is a different topic and editors approach this differently with some backing up a file when it is first loaded only, and others whenever the file is saved. Of course, some editors allow for multiple backups EXAMPLE.BAS~1, EXAMPLE.BAS~2, EXAMPLE.BAS~3, etc. I am on the fence as to whether I want to implement Backup into WinFBE. I feel that auto save is sufficient and leave the backup and archiving of source code files to the user so that they can handle it however they wish.
(https://www.planetsquires.com/images/autosave.png)
Hey Paul
Thanks to Wally for the inspiration.... :-)
The autosave function is a good thing to reduce losses in case of a power failure. But actually it does not replace a real backup.
I had a big data loss two years ago and lost the complete source code of some programs. It was nothing important, but I miss all those code snippets to this day.
My inconsistency annoyed me the most in retrospect.
Since everything worked for a long time, I slowly lost sight of the need for a backup.
An optional backup feature in WinFBE is very useful and I would definitely use it.
Ultimately, of course, the responsibility for a backup always lies with the user.
Hi Paul,
For "project" backup, I call a batch file from the User menu. This creates a unique folder on my 2 backup drives the names of which contain the date and time of the backup something like this:
C:\Users\Clive\OneDrive\BackUp\TaskMaster\SRC\TeriBasebak.19-Jan-2022-09-03-45-61 Where the last 2 digits are decimal seconds.
The batch file doesn't check the archive bit, just copies all relevant files (modified or not) to the new folder.
For reference, I pipe the output to a pair of text files in the root backup folder. Here is a single entry from the first text file:
==========================================
Backup Begin 19-Jan-2022 at 9:03:45.64
Compiler - FB 64Bit.
TaskMaster.wfbe
------------------------------------------
Copied C:\SRC\TeriBase\modules\*.* to "C:\Users\Clive\OneDrive\BackUp\TaskMaster\SRC\TeriBasebak.19-Jan-2022-09-03-45-61\"
Copied C:\SRC\TeriBase\modules\*.* to I:\Backup\SRC\TaskMaster\TeriBasebak.19-Jan-2022-09-03-45-61\
Copied C:\SRC\TaskMaster\*.* to "C:\Users\Clive\OneDrive\BackUp\TaskMaster\SRC\TaskMasterbak.19-Jan-2022-09-03-45-61\"
Copied C:\SRC\TaskMaster\*.* to I:\Backup\SRC\TaskMaster\TaskMasterbak.19-Jan-2022-09-03-45-61\
------------------------------------------
TaskMaster (subset of TeriBase TaskMaster) SRC backed up as of 19-Jan-2022-09-03-45-61
------------------------------------------
The second text file is simply a list of all the backed-up files.
I created the batch file decades ago and haven't found a need to modify it since, though tweaks for drive designations and so forth have happened from time to time. This works for me, but a proper backup feature built into WinFBE would be much better, less cumbersome than my batch file approach and no doubt have better control over the files being backed up/restored. I back up my projects at the beginning (and sometimes the end) of each session.
1 drive is a cloud drive and the other is a large(ish) hot-swappable SATA drive.
:0)
That's awesome Clive! My backup routine is not quite as elaborate as yours but it does involve an automated process of copying my source codes to a USB attached hard drive which is very convenient when I code from different computers and laptops.
I need to think long and hard about a good backup approach. I am thinking that I may postpone any backup implementations until after I get the next update out. I still have a lot of work left to do on this update and I fear that if I start going down the backup rabbit hole that I will "waste" a week or more that I could be using to polish up the core parts of the editor.
Here is the batch file with comments and unused gotos where > and >> redirect output:
@ECHO off
REM goto getcopied
ECHO Batch file history:
ECHO 2020-03-06 - Add: Created from original
ECHO ============================================================================
REM /E copies directories, /Y suppresses overwrite prompt.
REM Convert the current time (with colons and a decimal)
REM to a string with hyphenated numbers (12-34-56-99):
set coln=%time%
set coln=%coln::=-%
set coln=%coln:.=-%
set coln=%coln: =0%
REM Copy to new dir with date-time designation:
ECHO.
ECHO Standby. . .
ECHO.
ECHO ========================================== >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO Backup Begin %DATE% at %TIME% >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO Compiler - FB 64Bit. >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO TaskMaster.wfbe >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO ------------------------------------------ >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO.
REM
ECHO Copying TaskMaster Shared Modules
ECHO New backup > I:\BackUp\SRC\TaskMaster\BakFiles.log
xcopy /E /Y C:\SRC\TeriBase\modules\*.* "C:\Users\Clive\OneDrive\BackUp\TaskMaster\SRC\TeriBasebak.%date%-%coln%\" >> I:\BackUp\SRC\TaskMaster\BakFiles.log
xcopy /E /Y C:\SRC\TeriBase\modules\*.* I:\Backup\SRC\TaskMaster\TeriBasebak.%date%-%coln%\ >> I:\BackUp\SRC\TaskMaster\BakFiles.log
ECHO Copied C:\SRC\TeriBase\modules\*.* to "C:\Users\Clive\OneDrive\BackUp\TaskMaster\SRC\TeriBasebak.%date%-%coln%\" >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO Copied C:\SRC\TeriBase\modules\*.* to I:\Backup\SRC\TaskMaster\TeriBasebak.%date%-%coln%\ >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO.
xcopy /E /Y C:\SRC\TaskMaster\*.* "C:\Users\Clive\OneDrive\BackUp\TaskMaster\SRC\TaskMasterbak.%date%-%coln%\" > I:\BackUp\SRC\TaskMaster\BakFiles.log
xcopy /E /Y C:\SRC\TaskMaster\*.* I:\Backup\SRC\TaskMaster\TaskMasterbak.%date%-%coln%\ >> I:\BackUp\SRC\TaskMaster\BakFiles.log
ECHO Copied C:\SRC\TaskMaster\*.* to "C:\Users\Clive\OneDrive\BackUp\TaskMaster\SRC\TaskMasterbak.%date%-%coln%\" >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO Copied C:\SRC\TaskMaster\*.* to I:\Backup\SRC\TaskMaster\TaskMasterbak.%date%-%coln%\ >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO Done. C:\SRC\TeriBase\modiles\*.*
ECHO Done. C:\SRC\TaskMaster\*.*
REM
ECHO ------------------------------------------ >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO Done with back up.
ECHO TaskMaster (subset of TeriBase TaskMaster) SRC backed up as of %date%-%coln% >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO ------------------------------------------ >> I:\BackUp\SRC\TaskMaster\backup.log
ECHO.
REM goto end
:getcopied
REM ECHO Copy TaskMaster.exe to C:\ and OneDrive
REM Copy /Y C:\SRC\TeriBase\release64\TaskMaster.exe "C:\TeriBase\" >> I:\BackUp\SRC\TaskMaster\BakFiles.log
REM Copy /Y C:\SRC\TeriBase\release64\TaskMaster.exe "C:\Users\Cive\OneDrive\TeriBase\" >> I:\BackUp\SRC\TaskMaster\BakFiles.log
REM ECHO Copy TaskMaster.exe to "C:\TeriBase\" >> I:\BackUp\SRC\TaskMaster\backup.log
REM @ECHO OFF
ECHO.
:end
REM PAUSE
TIMEOUT 5
It's a bit cumbersome...
In case of a power failure, my laptop battery has got my back. Right??
I do backups in case of hard drive failure.
Hi @BumbleBee, if your laptop battery is in good condition then a power bump or full-on power failure should ensure that any unsaved work is not lost. I believe that Paul's reference to "Auto Save" in the next WinFBE will help those of us not working on laptops (or have a UPS) as a power failure should only result in a lose of data newer than the most recent Auto Save or manual save (it didn't take too many power failures for me to get into the habit of hitting CTRL/S on a regular basis).
QuoteWhen auto save is enabled, every 10 seconds a check is performed to determine if the editor text has been modified further since the last AutoSave was done. If yes, then WinFBE automatically saves the current source code to a filename wrapped in # characters. For example, if the source filename is C:\FB\EXAMPLE.BAS then the auto saved file is called C:\FB\#EXAMPLE.BAS#. Later in a subsequent editing session, when WinFBE tries to load the original file it checks to see if the ### wrapped file exists and if it does, it checks the date on both files. If the auto saved #filename# is newer then WinFBE asks the user if they want to use the new auto saved version.
This feature is fantastic for situations where your computer has a power outage or WinFBE crashes prior to saving your unsaved edits.
Auto Save could save your work to a backup hard drive, though we'll have to wait and see what options will be available for Auto Save.
If your external backup hard drive is powered from your laptop's USB, it may also survive a power failure.
My external drives have separate power supplies and shut down when the power fails so I no longer use them. Instead, I backup to a different (hot-swappable) internal hard drive as well as a Cloud Drive. Auto Save to the Cloud might be a safe way to ensure work is not lost...
Here is today's accomplishment. A keyboard bindings map editor. You can now easily assign/re-assign your own user bindings to the various actions in the editor. Creating your own user defined keybinding simply overrides/replaces the default action. This is something that I've wanted to include in WinFBE for a very long time so it is satisfying to finally have it done. Granted, the dialog is not themed... none of the popup dialogs in WinFBE are themed (yet).
I have also finally finished the top tab control. That was an interesting programming exercise writing all of that from scratch. The result is awesome and looks so much better than the default Windows tab control.
(https://www.planetsquires.com/images/keyboard.png)
We now (finally) have Win32 API keyword syntax highlighting again. Implemented as keyword set #1 (FreeBasic keywords are #0).
Excellent, thanks, Paul!
Here is today's accomplishment. Thankfully, I was able to use Custom Draw for the Listviews and did not have to resort to Owner Draw to make custom implementations for the grid like controls in the Output window. The "tab control" is simply custom tabs drawn on a subclassed static (Label) control.
Here are a few more quality of life improvements that I also finished for the editor as well:
- Added keyboard shortcut "CTRL+~" (ctrl+tilde) to allow you to move keyboard focus back to the active editing window. This is useful, for example, for jumping between the editing window and the Find/Replace dialog.
- Added keyboard shortcuts to move to next and move to previous compiler errors. This is a quick way to jump to and fix errors without having to use your mouse to double click the compiler error message in the Output window.
- The Explorer window now allows for multiple nodes to be selected (via Ctrl or Shift) and to popup right-click menu to perform actions on the group of selected nodes (for example, to re-designate files to different FileTypes, etc).
(https://www.planetsquires.com/images/output.png)
Beware. "~" does not exist in some keyboards, e.g. the Spanish keyboard.
Quote from: José Roca on January 25, 2022, 08:28:13 PM
Beware. "~" does not exist in some keyboards, e.g. the Spanish keyboard.
Thanks José, good to see you again. :-) Luckily, with the new Keyboard Shortcuts, the user can define whatever key binding they wish should the default one that I (arbitrarily) picked is not suitable. As you know, the ~ maps to virtual key VK_OEM_3. I wonder, do the other VK_OEM_* virtual keys map to the Spanish keyboard the same way that they do for US standard keyboard?
Here you have a visual comparison of different national layouts:
http://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Different-National-Layouts/#esES
Asking to a Spanish to press "CTRL+~" is like asking you to press "CTRL+ñ".
Thanks José, I have bookmarked that page as I can imagine that it will be a useful reference. Ctrl+~ is certainly not a viable option on Spanish keyboards. There is certainly a lot of variation amongst the different keyboard layouts.
Great to see you feeling better and back in the saddle Paul!!!
What you're working on looks fantastic! I can't wait to see the fruits of your labour in the not too distant future.
Andrew
Thanks Andrew, and everybody :-) Feels good to be back programming again. Feeling pretty good these days after that health scare back in August/September.
The editor is looking pretty good at this point. I still have to implement the Function List and Bookmarks List but both of those should be relatively quick to do because I can model them after the existing Explorer panel code. For the upcoming update there are not many changes to the Visual Designer portion of the editor because I am concentrating almost exclusively on the core editor itself at this point.
It's been a while since I posted a screenshot. Here is the new Bookmarks list. It shows all bookmarks from all open (and closed) documents. It is useful to allow you to quickly navigate throughout your project. You can also clear all bookmarks, bookmarks from a specific file, or just single bookmarks, right from that window. Next up will be the "Function list" which hopefully I can quickly code because most of the guts for that code already exists in one form or another within the existing WinFBE code base.
(https://www.planetsquires.com/images/bookmarks.png)
Function List using "View as Tree"
(https://www.planetsquires.com/images/functions-tree.png)
Function List using "View as List". I may add a textbox that will allow you to search for function names.
(https://www.planetsquires.com/images/functions-list.png)
Here are a couple of screenshots of the Dark & Light Themes. You can switch between them on-the-fly without having to restart the application. The only thing that I don't like is that the RichEdit & Listview controls in the Output window use the standard Windows scrollbars so they don't really fit in with the look and feel of the custom scrollbars elsewhere in the editor. Maybe someday I'll try to replace them with custom scrollbars. Too big of a job for now.
(https://www.planetsquires.com/images/dark1.png)
(https://www.planetsquires.com/images/light1.png)
I still have a few, mostly minor, issues to deal with regarding the editor portion of WinFBE, but I intend to release a sort of beta version via this forum for you folks to try out on your test projects. I just need to finalized some things with the vertical and horizontal custom scrollbars first. I will then do a day or two of simulated real world use of the program. Things like installing, set up, creating files and projects, and using the various features. After that I will package it all up with the latest WinFBX and FB Compiler and post it here for download.
The release is 95% related to updates to the editor. The visual designer has not been given much love at this point. That will be focus of my efforts once the editor is looking good.
Thanks for the update, Paul!
not everyone uses the visual designer, or uses all afx libraries.
the editor is very nice to work with, although sometimes I miss a built-in debugger.
There are times that I wish that I had separated the editor from the visual designer. That is, make each an individual application. It would certainly help streamline the code base with the downside that not having both together would make the designing and coding of a GUI application a little more cumbersome. A debugger would be very nice and I often wonder how hard it would be to integrate the non-gui elements of FBDebugger into WinFBE.
Probably, I'm the least demanding WinFBE user. I have more than I need since a long time ago. I only use the text editor, with many of the optional features disabled.
The only thing that annoys me a little sometimes is that if you have the "Find" window activated and you close the file that you are editing, the "Find" window remains visible and can't be closed clicking the "x" button.
BTW I can't stand dark themes. They strain my eyes. I know that for some people it is the opposite.
Thanks José, I'll fix up that Find window closing problem to ensure that it is not present in the update.
Dark vs Light themes. I was the same way my entire programming life. I always used light themes. It was only over the past 6 months where I did a lot of web programming using VS Code and Python programming in JetBrains PyCharm that I got hooked on dark themes. Not really pure black themes because I find that is too strong of a contrast, but a more subtle dark/charcoal black is much more pleasing and I can say that now I doubt that I'd revert back to light themes.
I'm looking forward to getting your honest feedback on the new update when I post it here because it is fairly different than the current version.