PlanetSquires Forums

Last Sunday I was sitting on the couch getting ready to watch the Portugal/France match and started doing a little research on code editor features looking for ideas for things to add to WinFBE. I started reading reviews of all of the major code editors. One review of Notepad++ stood out to me because it said that the editor was amazing in terms of functionality but it's user interface was horribly dated. That got me thinking that WinFBE's interface must look dated as well because it is based on very traditional concepts.

Last year when I was doing a lot of web development, I used SublimeText editor a lot. I loved it's interface because it was so unobtrusive. A few reviews pointed to Microsoft's new open source code editor, VS Code. I downloaded it and it looks awesome.

So.... I just started coding out of enjoyment wondering if I could emulate those editors. Got to use a lot of my old Win GDI skills. Decided to use GDI because it is so fast and I didn't want to take the time to learn Direct 2D or DirectWrite, etc. Everything progressed quite quickly. Custom made tab control, custom statusbar, popout panels, etc. Best of all, it is high dpi ware, localized, and based on color theme files. I created a "dark" theme that you will see in the screenshot below. Just about everything on the screen can be assigned a color.

I have attached some demo files if you are adventurous and would like to see the application live. There is not very much functionality in it yet. The tab control does not scroll left or right yet. I eliminated all scroll bars from the controls because I need to create my own so that they look better visually with the color scheme.

The hardest/coolest/most frustrating thing to code so far was the control for the file/folder explorers. I started writing it from scratch and then a couple of days into it, it made more sense to use a standard Treeview. I had to use some cool custom draw and other programming magic in order to get it to look and act like the control in VS Code. Still more work needed on it though but it's getting there.

Long story short, I like the new style and I guess I'm a little excited to show it off. I now need to use Jose's latest CWindow and Afx code into the codebase. That will be great test of Jose's new tools. Looking forward to using WSTR instead of all those fixed WSTRINGs.

Now it will be nice to have to separate versions of WinFBE that will cater to just about everyone's tastes.

....it's getting late here. Time for bed.  :)

Oh, and this only works on Windows Vista or higher.

You will notice just how super fast and flicker free the program is. I took great care to eliminate flicker. I just tested CWindow RC13 and only had to make a couple of changes for it to compile.

thank you Paul, looks really good :)

hi Paul,

your new editor, will it be unicode compliant ?
if yes using what kind of encoding , uft8, utf16, ucs2... ?

and as I have seen, it uses the scintilla lexer , wich seems to only plays with utf8 unicode encoding,

i'm wondering how do you manage that?

Marc

The application itself is UTF-16 because it is Windows based only. There is a way to use Scintilla with Unicode but I haven't delved into it yet. Apparently, Notepad++ uses Scintilla and Unicode.

Scintilla doesn't support UT16, but UT-8. In CSED I have an option called "Enable Unicode (UT-8)". Then, when I set the Scintilla options, I do:


   ' // Enable unicode (UTF-8 encoding)
   IF pSed.UnicodeEnabled THEN
      SCIP_SetCodePage pSci, %SC_CP_UTF8
   ELSE
      SCIP_SetCodePage pSci, 0
   END IF


But Windows doesn't support UTF-8. Therefore, you have to use:


DIM cbs AS CBSTR = AfxUcode("Дми́трий", CP_UTF8)
SetWindowTextW pWindow.hWindow, cbs


If you don't activate UTF-8, you can do:


DIM cbs AS CBSTR = AfxUcode("Дми́трий", 1251)
SetWindowTextW pWindow.hWindow, cbs


Either activate UTF-8 and use CP_UTF8 as the code page, or choose the appropriate charset and pass the code page for that language.

In the first case, the literal is saved as ansi UTF-8 encoded: "Дми́Ã'‚Ã'â,¬ÃÂ¸ÃÂ¹"

In the second case, the literal is saved as ASCII: "Ã,,ìèòðèé"

So simply add the option of enable UTF-8 and let the user to choose if he wants to use UTF-8 or choose a charset.

Since I added UTF-8 support to the last version of CWSTR, you can also use:


DIM cbs AS CBSTR = CBSTR("Дми́Ã'‚Ã'â,¬ÃÂ¸ÃÂ¹", CP_UTF8)
SetWindowTextW pWindow.hWindow, cbs


That in the editor will look like


DIM cbs AS CBSTR = CBSTR("Дми́трий", CP_UTF8)
SetWindowTextW pWindow.hWindow, cbs


if you implement the enable UTF-8 option and the user has checked it.

It can be the simpler solution because you will always use CP_UTF8 as the code page, and it also works with CWSTR.


DIM cws AS CWSTR = CWSTR("Дми́трий", CP_UTF8)
SetWindowTextW pWindow.hWindow, cws


It also has the advantage of working with accented Russian vocals,  whereas choosing the Russian charset Scintilla doesn't understand them. So, my advice is to use UTF-8 encoding, because it is what Scintilla supports.

With the lastest version of CWSTR we can even do:


SetWindowTextW pWindow.hWindow, CWSTR("Дми́трий", CP_UTF8)


or


SetWindowTextW pWindow.hWindow, CBSTR("Дми́трий", CP_UTF8)


Of course, don't use FB's WSTR, that does not support a code page.

Thanks Jose, I will come back to this once I get to the point of adding the unicode functionality for Scintilla. I am still pretty new to the whole unicode universe :)

Jose, Paul


yes i think, the more convenient way is doing,  as Jose is saying

have implemented the  "enable UTF-8 option" and the user has to checked it.
( or better if the file was saved as utf_8 it could be automaticaly selected)

using the lastest version of CWSTR
after the user would  can see on the screen :

SetWindowTextW pWindow.hWindow, CWSTR("Дми́трий", CP_UTF8)


but , if in fact the real typing the user has to do is the following:
SetWindowTextW pWindow.hWindow, CWSTR("Дми́Ã'‚Ã'â,¬ÃÂ¸ÃÂ¹", CP_UTF8)

because scintilla can show utf8 as unicode representation , but user have to enter all as utf-8 code
scintilla does not have convertion tool .

Paul , i think you probably have to give somewhere , a menu for encoding / converting ( as notepad++ is giving)
or better vitual keyboards to make the input WYSIWYG...

Paul

Convertion tool: A dialog with two text boxes, one for input and another for output. Input: Enter text in your f**g language and click the Convert button. Output: Text translated to UTF-8.

found a site that gives the direct input with virtual keyboards
and after you simply copy the selected text ,wich is utf8 encoded,
to the editor .

it works perfectly with csed when enabling utf8 usage

the site : https://www.branah.com (https://www.branah.com)

as sample,for russian https://www.branah.com/russian (https://www.branah.com/russian)

After having used the new format for the editor I am not impressed with the usability of the left hand side popout menu panels or the concept of using actual disk folders for a project. Although they look cool, they just do not add enough value to the editor.  I am removing both of those concepts and reverting back to a simpler left hand side treeview that displays files belonging to the project. Projects will be implemented in the same manner as they are in the current WinFBE version rather than the using the "folder" concept.

I am putting this modern version of the editor on hold. I am working on feature completing the original classic version of the editor. I will be adding the UTF-8 capability today and will update the GitHub repository later tonight.

I added the UTF-8 support by following Jose's suggestions in this thread. Once I upload the source/exe change tonight to GitHub I will ask for help in testing that the Unicode characters function correctly in the editor.

New WinFBE with UTF-8 unicode support added to GitHub repository.

It works as expected and it is all you can do using Scintilla, that has not UTF-16 support.

However, keep in mind that, since Windows does not understand UTF-8, it is only a workaround. What will be needed is UTF-16 support in Scintilla, but I don't think that this will happen.

People wanting to use unicode through UTF-8 will need to always use a function like AfxUcode to convert from UTF-8 to UTF-16.

The code templates are outdated.

I will revise them to use CWSTR instead of WSTRING.

Awesome, thanks Jose for testing the UTF-8 functionality. I am working on some user interface changes this morning and hope to have it posted today. I will start a separate thread detailing changes once that is done.

(feels good to be back programming again)

Using the 64-bit version I have noticed two problems, but I can't repeat them at will, ie. sometimes happens and sometimes don't.

The first one is that sometimes the editor is unable to load the text of a template. Must be because you have changed my original code posted at http://www.planetsquires.com/protect/forum/index.php?topic=3867.msg28442#msg28442

You're using REDIM PRESERVE and this causes problems. With REDIM PRESERVE apparently the memory changes and some of the pointers stored in the listbox are no longer valid. This is why I first get the number of files to dimension the array.

   ' // Search templates
   DIM hSearch as HANDLE, WFD AS WIN32_FIND_DATAW, FileNo AS LONG, nType AS LONG, nItem AS LONG
   DIM wszPath AS WSTRING * MAX_PATH, wszCurPath AS WSTRING * MAX_PATH, wszText AS WSTRING * 260
   DIM wszFullPath AS WSTRING * MAX_PATH * 2, idx AS LONG, nLin AS LONG
   wszPath = ExePath & "\Templates\"
   wszCurPath = wszPath & "*.fbtpl"

   ' // Count the number of files and dimension the array
   ' // REDIM PRESERVE causes problems
   DIM nCount AS LONG
   hSearch = FindFirstFileW(wszCurPath, @WFD)
   IF hSearch <> INVALID_HANDLE_VALUE THEN
      DO
         IF (WFD.dwFileAttributes AND FILE_ATTRIBUTE_DIRECTORY) <> FILE_ATTRIBUTE_DIRECTORY THEN
            nCount +=1
         END IF
      LOOP WHILE FindNextFileW(hSearch, @WFD)
      FindClose(hSearch)
   END IF
   ' // Dimension the array
   IF nCount = 0 THEN EXIT FUNCTION
   DIM rgwszPaths(nCount - 1) AS WSTRING * MAX_PATH
   idx = 0

   ' // Find the files
   hSearch = FindFirstFileW(wszCurPath, @WFD)
   IF hSearch <> INVALID_HANDLE_VALUE THEN
      DO
         IF (WFD.dwFileAttributes AND FILE_ATTRIBUTE_DIRECTORY) <> FILE_ATTRIBUTE_DIRECTORY THEN
            wszFullPath = wszPath & WFD.cFileName
            ' // Get the description
            FileNo = FREEFILE
            OPEN wszFullPath FOR INPUT AS #FileNo
            IF ERR = 0 THEN
               nLin = 0
               DO UNTIL EOF(FileNo)
                  LINE INPUT #FileNo, wszText
                  nLin += 1
                  IF nLin = 1 THEN nType = VAL(wszText)
                  IF nType < 1 OR nType > 2 THEN EXIT DO
                  IF nType = 1 AND nLin = 3 THEN EXIT DO
                  IF nType = 2 AND nLin = 4 THEN EXIT DO
               LOOP
               CLOSE FileNo
               ' // Display the description in the listbox
               nItem = SendMessageW(hListBox, LB_ADDSTRING, 0, cast(LPARAM, @wszText))
               ' // Store the full path in the array
               rgwszPaths(idx) = wszFullPath
               ' // Store a pointer to the element of the array in the listbox item
               SendMessageW hListBox, LB_SETITEMDATA, nItem, cast(LPARAM, VARPTR(rgwszPaths(idx)))
               idx += 1
               IF idx > UBOUND(rgwszPaths) THEN EXIT DO
            END IF
         END IF
      LOOP WHILE FindNextFileW(hSearch, @WFD)
      FindClose(hSearch)
   END IF



The second one are random crashes when changing colors and clicking the OK button. The selection is saved, but the editor sometimes crashes.

Thanks Jose, I will revert the code back. I will also check the color selection crash problem. I have been testing using the 32-bit version but I will switch to the 64 bit version tonight.

I have been making lots of changes to the user interface today so I can't upload new code until that is stable.