PlanetSquires Forums

New code in GitHub repository November 12, 2016.
https://github.com/PaulSquires/WinFBE/

Many changes in the editor. Too many to remember and list here.

Of particular note is brand new additions to the user interface. I have added an Explorer window and Output window. Both can be toggled on and off and both are fully resizable via splitters. I may have to tweak the colors but so far the functionality works well.

HOWEVER, in order to maintain the look and feel of the Explorer treeview, i have to create a custom vertical scrollbar. That scrollbar is not 100% complete so if you have too many files in the treeview you won't be able to scroll the list...at least not yet. You can see the scrollbar in the following screenshot.

(https://www.planetsquires.com/winfbe.PNG)

Add ".FBTPL" to get syntax coloring when writing code templates. Not important, just a nice touch.


   If cbool(wFileExt = ".BAS") OrElse cbool(wFileExt = ".INC") _
         OrElse cbool(wFileExt = ".BI") OrElse (this.IsNewFlag = True) Then


Thanks Jose, I have added the change. It will be in the next upload. Thanks!

When compiling a file (without a project) using the GUI option, the console appears. Why?

Sometimes the cursor is unable to change from beam to arrow and flickers when it tries to change.

Quote from: Jose Roca on November 12, 2016, 11:29:38 PM
When compiling a file (without a project) using the GUI option, the console appears. Why?

Thanks Jose, I have this fixed now. I fixed the logic for project and non-project files. Fix will be in next update to GitHub.

Quote from: Jose Roca on November 12, 2016, 11:40:03 PM
Sometimes the cursor is unable to change from beam to arrow and flickers when it tries to change.

Hmmmm.... I haven't noticed this but I will pay attention to see where it occurs.

The follow fixes and changes were just committed to the GitHub repository.

- Added .FBTPL extension to allow color syntax highlighting.
- Fixed logic for showing/hiding console window for GUI projects and non-projects.
- Changed Project Option from "Suppress console window" to "Show console window".
- Fixed new files not being added to Explorer in some situations (eg. Files based on Templates).

A couple more simple changes added to GitHub.

- Clicking ANSI/UNICODE panel area in StatusBar allows you to toggle between the two states.
- Output information from previous compile is now cleared when new project loaded.

When the editor saves a file it adds an additional blank line.

Quote from: Jose Roca on November 13, 2016, 10:55:01 PM
When the editor saves a file it adds an additional blank line.

Right you are. I forgot to add a semicolon at the end of the PRINT # statement.


   ' Save text buffer to disk by directly accessing buffer rather
   ' saving it to an intermediary string variable first.
   f = Freefile
   If Open( wFilename For Output As #f ) = 0 Then
      Dim As ZString Ptr psz = Cast( ZString Ptr, SendMessageW(this.hWindow, SCI_GETCHARACTERPOINTER, 0, 0) )
      Print #f, *psz
      Close #f
   Else
      ' error saving file
   End If         


@Paul,  sorry i'm still not able to test your new editor (XP only)

But if you are interrested on way to input different codepage on your editor,
i've found an interresting tool ( this one not online) is here :
http://www.unipad.org/download/ (http://www.unipad.org/download/)

what's nice is it provides plenty of virtual keyboards to input keys.
so it's simple to select the produced symboles  on the unipad utf8 editor panel ,
       copy them and paste to WinFBE panel , if WinFBE is on utf8 mode 
   or copy as utf8 and paste to WinFBE panel , if WinFBE is on any charset
as long as that literal is considered as utf8 string every thing will work.

have a look yourself , it exists a free version to download...

i think that kind of feature would be very nice to have: embedded,

it would help a lot when using different codepage/charset on the same document.

Sure it would be even better on utf16 editor, but using scintilla it is not possible.

Hope the info, can be helpfull for you or any futur user of your new editor.

I know it works, because i'm using that work-arround when input different charset on my adapted version of FB-CSED or CSED.

Hi Marc, thanks for the information. I appreciate it.

Time for you to upgrade past WinXP  :)

I just committed the following changes to the GitHub repository:

- Fixed problem of saving files with additional ending CRLF being appended.
- Refactor code to eliminate some PROPERTY Get/Set for classes.
- Added vertical scrollbar to Compiler Log File output window.
- Clicking on Project FileType panel in StatusBar now invokes popup selector menu.
- Clicking on Line/Col panel in StatusBar now invokes the GotoLine dialog.

Don't know if it is interntional or not, but the font in the explorer window looks a bit oversized as you are using Segoe UI 10 pt instead of 9pt. Very noticeable at 192 DPI.

Thanks Jose, I have made that change (will be in GitHub later this evening). I also noticed that the Goto Line dialog looked ugly. I had the line to set the DPI *after* the creation of the window rather than before. That fix will also be in GitHub later.


   pWindow->DPI = AfxCWindowOwnerPtr(hwndParent)->DPI

   pWindow->Create(hWndParent, L(168,"Go to Line"), @frmGoto_WndProc, 0, 0, 287, 126, _
        WS_POPUP Or WS_DLGFRAME Or WS_CAPTION Or WS_SYSMENU Or WS_CLIPSIBLINGS Or WS_CLIPCHILDREN, _
        WS_EX_DLGMODALFRAME Or WS_EX_CONTROLPARENT Or WS_EX_LEFT Or WS_EX_LTRREADING Or WS_EX_RIGHTSCROLLBAR)
   pWindow->SetClientSize(281, 97)
   pWindow->Center


Update changes to GitHub repository:

- Changed Explorer font to Segoe UI 9pt in order to scale better at high DPI resolutions.
- Fixed DPI code for the Goto Line dialog.
- Updated to Jose Roca's latest version of CWindow and Templates (RC 25).

You have forgot to rem this line

pWindow->DPI = 96   ' eg. 144 or any other value (96 is default)

in frmMain_Show

The editor has become unusable at 192 DPI.

Oh my.... I am so forgetful sometimes. I will fix it in GitHub later today.

Quote from: TechSupport on November 16, 2016, 08:57:00 AM
Oh my.... I am so forgetful sometimes. I will fix it in GitHub later today.

This is now fixed and GitHub updated.

Added to GitHub tonight:

- Added scrollbars to Explorer Treeview. The custom scrollbars were just too much trouble to implement.
- Added LockWindowUpdate of Explorer Treeview during WM_CLOSE to prevent flickering as documents are closed.

Folding/Unfolding does not work when clicking the folding mark with the mouse.

Thanks Jose, I will get that worked out very soon as well.  :)

Is there already some way to use resource files or is it in the todo list?

Quote from: TechSupport on November 19, 2016, 10:16:43 AM
Thanks Jose, I will get that worked out very soon as well.  :)

This is a 64-bit problem. Works on 32-bit. Most likely to do with how the SCNotification TYPE is defined. I will look at that structure to see what needs to be changed.

Quote from: Jose Roca on November 19, 2016, 10:30:09 AM
Is there already some way to use resource files or is it in the todo list?

The way I do this is to create a project and add the resource file to it. Then, simply designate that file as the "RESOURCE". You do that by changing its type through the right-click menu options or by clicking on the 4th panel in the statusbar.

Quote from: TechSupport on November 19, 2016, 11:32:28 AM

Quote from: TechSupport on November 19, 2016, 10:16:43 AM
Thanks Jose, I will get that worked out very soon as well.  :)

This is a 64-bit problem. Works on 32-bit. Most likely to do with how the SCNotification TYPE is defined. I will look at that structure to see what needs to be changed.

Looks like the "Field = 4" was the problem


Type Sci_NotifyHeader Field = 4
  ' /* Compatible with Windows NMHDR.
  '  * hwndFrom is really an environment specific window handle or pointer
  '  * but most clients of Scintilla.h do not have this type visible. */
hwndFrom as HWND
idFrom As UINT_PTR
code As UINT
End Type

Type SCNotification
   hdr                  As Sci_NotifyHeader
   position             As INTEGER
   ch                   As INTEGER
   modifiers            As INTEGER
   modificationType     As INTEGER
   lpText               As ZString Ptr
   length               As INTEGER
   linesAdded           As INTEGER
   message              As INTEGER
   wParam               As uINTEGER
   lParam               As uINTEGER
   nLine                As INTEGER
   foldLevelNow         As INTEGER
   foldLevelPrev        As INTEGER
   margin               As INTEGER
   listType             As INTEGER
   x                    As INTEGER
   y                    As INTEGER
   token                As INTEGER
   annotationLinesAdded As INTEGER
   updated              As INTEGER
End Type


EDIT: Something is still not right because although the folding now seems to work, the toggling of the Bookmark column does not work on 64-bit (but does on 32-bit).

Updated to GitHub repository:

- Removed unused entries in the English.lang language file.
- Files are now only added to MRU file list if they are not part of an active Project.
- Updated SCNotification TYPE structure in modScintilla.bi in order to work correctly on 64-bit. May not work 100% (Bookmark toggle does not seem to work correctly yet).

I'm having several problems with projects, like GPF when clicking the OK button.

Also, when creating a second project, the compiler setup loses the drive letter

:\Users\Pepe\FreeBasic32\fbc.exe

Something must be wrong in the code when saving the options.

Thanks Jose, when you say clicking the OK button, do you mean the OK button for the Project options dialog form?

I did make changes to the {CURDRIVE} replacement macro code that I use to substitute the drive letter for settings like the compiler, etc. Is your compiler setup on the same drive as your project, or different drive?

Ok.... I can reproduce the GPF with the Project Options OK button.

> I did make changes to the {CURDRIVE} replacement macro code that I use to substitute the drive letter for settings like the compiler, etc. Is your compiler setup on the same drive as your project, or different drive?

In the same drive.

Looks like a GPF during config save during the call to ProcessToCurdrive(). I switched to your newest version of CWSTR and it could be that the passing of the fixed length WSTRING to the function designed now to accept CWSTR is failing. I need to test more to find the exact GPF location but that is my initial findings and it does appear that it is the ProcessToCurdrive where the GPF is happening.

I have stripped out code and created a test file to try to isolate the error:


#Define UNICODE
#Define _WIN32_WINNT &h0602 

#Include Once "windows.bi"
#Include Once "Afx\AfxStr.inc"
#Include Once "Afx\AfxCtl.inc"

Type clsConfig
   Private:
      _ConfigFilename As String
     
   Public:
      FBWINCompiler32      As WString * MAX_PATH = ""
      FBWINCompiler64      As WString * MAX_PATH = ""
      CompilerSwitches     As WString * MAX_PATH = ""
      CompilerHelpfile     As WString * MAX_PATH = ""
      Win32APIHelpfile     As WString * MAX_PATH = ""
End Type


Type clsApp
   Private:
   Public:
      ProjectFilename      As CWSTR     
End Type


'  Global classes
Dim Shared gApp As clsApp
Dim Shared gConfig As clsConfig


' ========================================================================================
' Process prefix {CURDRIVE} and convert to current drive letter.
' ========================================================================================
Function ProcessToCurdrive( ByRef wzFilename As CWSTR ) As CWSTR
   ' For each folder location determine if it resides on the same drive as
   ' the project file. If it does then substitute the replaceable parameter
   ' {CURDRIVE} for the drive letter. This allows you to easily run the editor
   ' on different media (eg. thumb drive) that may be assigned a different
   ' drive letter.
   dim zText as CWSTR
   if AfxFileExists(gApp.ProjectFilename) Then
      zText = gApp.ProjectFilename
   else
      zText = exepath
   end if     
   Dim wzCurDrive As CWSTR = LCase(Left(**zText, 3))  ' eg. D:\

   If LCase(Left(**wzFilename, 3)) = wzCurDrive Then
      wzFilename = "{CURDRIVE}" & Mid(**wzFilename, 2)
   End If

   Return wzFilename
End Function


''  START TEST CODE
gApp.ProjectFilename = "X:\FB\Projects\test.wfbe"
gConfig.FBWINCompiler32 = "X:\FB\FreeBASIC-1.05.0-win32\fbc.exe"


gConfig.FBWINCompiler32 = ProcessToCurdrive(gConfig.FBWINCompiler32)

print gConfig.FBWINCompiler32
sleep



.....hmmmm  Maybe the code above is not the point of failure after all because the test code seems to be working okay (at least in the few tests of the code I have run so far).  :(

Changing the internal code to use CWSTR instead of mixing WSTRING with CWSTR seems to have fixed the problem. Nevertheless, I will continue to change all code within WinFBE to use WSTR when at all possible. I will post an update to GitHub later tonight that should resolve this GPF issue.

I also use WSTRING whenever possible, not because I have noticed any problem with CWSTR, but because it has less overhead. I mainly use CWSTR to return the result of a function or when I need a dynamic unicode variable. But the paths losing the drive letter, seems another kind of problem. Besides, I also had GPFs before you used the latest version of CWSTR, and the constructors haven't changed. The main change has been the removal of the @ operator and the addition of the wstr, vptr, sptr and utf8 methods/properties.

Thanks Jose, no doubt that the CWSTR class was not the problem. That class works very well. I have made many code changes and my initial few tests have not resulted in GPF. I have uploaded the new code and exe's to GitGub. Please give it a quick try to see if it works okay for you. I plan to spend tomorrow working with the editor to specifically try to break it and find problems.

Not GPFs for now. Will do more tests.

It would be nice if you save the width of the explorer window if resized with the splitter. Now it starts always at the same width.

Hi Paul

Still not able to test your new editor (xp only)

But, looked at your code, and here some minor remarks ' ========================================================================================
' Process prefix {CURDRIVE} and convert to current drive letter.
' ========================================================================================
Function ProcessToCurdrive( ByRef wzFilename As CWSTR ) As CWSTR
   ' For each folder location determine if it resides on the same drive as
   ' the project file. If it does then substitute the replaceable parameter
   ' {CURDRIVE} for the drive letter. This allows you to easily run the editor
   ' on different media (eg. thumb drive) that may be assigned a different
   ' drive letter.
   dim zText as CWSTR
   if AfxFileExists(gApp.ProjectFilename) Then
      zText = gApp.ProjectFilename
   else
      zText = exepath
   end if
   Dim wzCurDrive As CWSTR = LCase(Left(**zText, 3))  ' eg. D:\

   If LCase(Left(**wzFilename, 3)) = **wzCurDrive Then        ' better compare homogeneous types , here wstrings
      wzFilename = wstr("{CURDRIVE}") & Mid(**wzFilename, 2)  ' 2 wstrings, not an obligation but faster
   End If

   Return wzFilename
End Function


' ========================================================================================
' Process current drive to prefix {CURDRIVE}
' ========================================================================================
Function ProcessFromCurdrive( ByRef wzFilename As CWSTR ) As CWSTR
   ' For each folder location determine if it resides on the same drive as
   ' the project file. If it does then substitute the replaceable parameter
   ' {CURDRIVE} for the drive letter. This allows you to easily run the editor
   ' on different media (eg. thumb drive) that may be assigned a different
   ' drive letter.
   dim zText as CWSTR
   if AfxFileExists(gApp.ProjectFilename) Then
      zText = gApp.ProjectFilename
   else
      zText = exepath
   end if
   If Ucase(Left(**wzFilename, 10)) = wstr("{CURDRIVE}") Then    ' better compare homogeneous types , here wstrings
      wzFilename = Left(**zText, 1) & Mid(**wzFilename, 11) ' better dereferencing with mid
   End If

   Return wzFilename
End Function

Thanks Jose and Marc, I appreciate both suggestions and I will implement them both for the next update.
:)

Jose, I don't remember seeing such a function in your Afx functions so maybe you can consider adding this one. It is obviously based heavily off of your AfxGetWindowText routine.


' ========================================================================================
' Return CWSTR text for item in ComboBox
' ========================================================================================
Private Function AfxGetComboBoxText( ByVal hWndControl As HWnd, ByVal nIndex As Long ) As CWSTR
   DIM nLen AS LONG = SendMessageW(hWndControl, CB_GETLBTEXTLEN, nIndex, 0)
   DIM wszText AS CWSTR = SPACE(nLen + 1)
   SendMessageW(hWndControl, CB_GETLBTEXT, nIndex, cast(LPARAM, *wszText))
   RETURN wszText
End Function           


Paul,

As Jose said:

QuoteI also use WSTRING whenever possible, not because I have noticed any problem with CWSTR, but because it has less overhead.

if you use in a function intended to be generic, the CWSTR like that to create a buffer:
DIM wszText AS CWSTR = SPACE(nLen + 1)
you have to know , if you use that kind of function heavily on your code , you are drasticly slowing down the process

here different alternatives to create wstring buffer tested for speed

#include once "afx/cwstr.inc"
#Include Once "crt/time.bi"   

using afx

dim as long x
dim as string s1
dim as wstring ptr pw1

dim cw1 as cwstr
dim as double z1, z2


'if you need at least a wstring len of 65  ( so 66 wchar with the null ) = 132 bytes

z1 = clock()
dim as wstring ptr pw2 = allocate(2)  'to initialize with minimum
   for x = 1 to 100000
pw2 = reallocate(pw2,(65 + 1) * 2)  ' 132bytes
   NEXT
deallocate pw2   'no leak
z2 = clock()
pw2= NULL
   print : print "reallocate  time = " + str(z2 - z1) + " ms" : print


z1 = clock()
   for x = 1 to 1000000
      s1 = SPACE(66 * 2)     ' 133 bytes with the null
pw1 = cptr(wstring ptr,strptr(s1))
   NEXT
   z2 = clock()
   print : print "s1 space(cptr)  time = " + str(z2 - z1) + " ms" : print

z1 = clock()
   for x = 1 to 1000000
      s1 = SPACE(66 * 2) ' 133 bytes with the null
pw1 = cast(wstring ptr,strptr(s1))
   NEXT
   z2 = clock()
   print : print "s1 space(cptr)  time = " + str(z2 - z1) + " ms" : print

z1 = clock()
   for x = 1 to 1000000
      s1 = string(66 * 2, 32) ' 133 bytes with the null
pw1 = cptr(wstring ptr,strptr(s1))
   NEXT
   z2 = clock()
   print : print "s1 string(cptr) time = " + str(z2 - z1) + " ms" : print

z1 = clock()
   for x = 1 to 1000000
      s1 = string(66 * 2, 32) ' 133 bytes with the null
pw1 = cast(wstring ptr,strptr(s1))
   NEXT
   z2 = clock()
   print : print "s1 string(cast) time = " + str(z2 - z1) + " ms" : print

z1 = clock()
   for x = 1 to 1000000
      cw1 = SPACE(65) ' space gives you 66 bytes , converted to cwstr gives you 132 bytes, but with minimal buffer size gives you (260+1)* 2
pw1 = *cw1
   NEXT
   z2 = clock()
   print : print "cw1   time = " + str(z2 - z1) + " ms" : print


z1 = clock()
   for x = 1 to 1000000
      cw1.capacity = 132 ' gives you 132 bytes ,  but with minimal buffer size gives you (260 + 1)* 2
pw1 = *cw1
   NEXT
   z2 = clock()
   print : print "cw1 capacity  time = " + str(z2 - z1) + " ms" : print
sleep
print "press any key to finish"

I also like the dynamic wstring , but better not to use them just for buffer , if you don't want to play with alloc/realloc/dealloc,
capacity property is ok or string of spaces with the double of character is an acceptable alternative

> Jose, I don't remember seeing such a function in your Afx functions so maybe you can consider adding this one. It is obviously based heavily off of your AfxGetWindowText routine.

I will add it, and another for list boxes.

BTW without a wrapper is not hard to get it, since I added a constructor to allocate room in characters to CWSTR.


DIM cwsText AS CWSTR = ListBox_GetTextLen(hListBox, curSel) + 1
ListBox_GetText(hListBox, curSel, *cwsText)


Updated GitHub repository:

- Added: Editor now remembers the width of the Explorer pane between sessions.
- Added: WSTR as a FreeBasic keyword.
- Added: WSTR to better dereference the "{CURDRIVE}" string literal located in modRoutines.inc source code.
- Changed: The compiler results output listview is now positioned at the first entry in the list rather than at the first "Error" that is displayed in the list. The first entry could be a Warning or an Error.
- General code cleanup and removal of unused and unreferenced code.

> Editor now remembers the width of the Explorer pane between sessions.

It does not calculate correctly the size with High DPI. Apparently you are multiplying the saved size by the DPI ratio and the windows becomes bigger than it should each time you restart the editor.


   ' Only make the Explorer initially visable if it was already visible
   ' when the most previous instance of the program closed. Also, set the width of
   ' the window to the last used visible width.
   dim as long nWidth = iif(gConfig.ShowExplorer, gConfig.ShowExplorerWidth, 250)

   HWND_FRMEXPLORER = pWindow->Create( hWndParent, "", @frmExplorer_WndProc, 0, 0, nWidth, 0, _
        WS_CHILD Or iif(gConfig.ShowExplorer, WS_VISIBLE, 0) Or WS_CLIPSIBLINGS Or WS_CLIPCHILDREN, _
        WS_EX_CONTROLPARENT Or WS_EX_LEFT Or WS_EX_LTRREADING Or WS_EX_RIGHTSCROLLBAR)


Because pWindow->Create scales the control according to the DPI, you must unscale the saved width:


dim as long nWidth = iif(gConfig.ShowExplorer, pWindow->UnscaleX(gConfig.ShowExplorerWidth), 250)


Thanks Jose! Change made and uploaded to GitHub  :)

Works fine now.

Quote from: TechSupport on November 19, 2016, 11:32:28 AM

Quote from: TechSupport on November 19, 2016, 10:16:43 AM
Thanks Jose, I will get that worked out very soon as well.  :)

This is a 64-bit problem. Works on 32-bit. Most likely to do with how the SCNotification TYPE is defined. I will look at that structure to see what needs to be changed.

Still having problems with this. On the 64 bit version, clicking on the bookmark margin does not work and neither does the SCN_CHARADDED for auto indentation. I really need to figure that out that notification structure before starting to publicize this project to the FB community.


Type SCNotification
   hdr                  As Sci_NotifyHeader
   position             As INTEGER
   ch                   As INTEGER
   modifiers            As INTEGER
   modificationType     As INTEGER
   lpText               As ZString Ptr
   length               As INTEGER
   linesAdded           As INTEGER
   message              As INTEGER
   wParam               As uINTEGER
   lParam               As uINTEGER
   nLine                As INTEGER
   foldLevelNow         As INTEGER
   foldLevelPrev        As INTEGER
   margin               As INTEGER
   listType             As INTEGER
   x                    As INTEGER
   y                    As INTEGER
   token                As INTEGER
   annotationLinesAdded As INTEGER
   updated              As INTEGER
End Type


You are using INTEGER instead of LONG. In FB, INTEGER has a different size in 64-bit, but C++ int data type is 32-bit  always. I always avoid to use FB's INTEGER because it can be confusing.

Try with this one:


Type SCNotification
   hdr                  As Sci_NotifyHeader
   position             As LONG
   ch                   As LONG
   modifiers            As LONG
   modificationType     As LONG
   lpText               As ZString Ptr
   length               As LONG
   linesAdded           As LONG
   message              As LONG
   wParam               As WPARAM
   lParam               As LPARAM
   nLine                As LONG
   foldLevelNow         As LONG
   foldLevelPrev        As LONG
   margin               As LONG
   listType             As LONG
   x                    As LONG
   y                    As LONG
   token                As LONG
   annotationLinesAdded As LONG
   updated              As LONG
End Type


Thanks Jose, I originally had used LONG but it still failed on 64 bit. I then changed it to INTEGER thinking that the 64 bit version of Scintilla used 64 bit integers. I will try your code just to be 100% sure. I will also download the code for the 64 bit scintilla and see how they are setting up the structure.

Oh my, right you are Jose. Your version seems to work well on 64 bit. Not sure why my LONG version did not. Either way, thanks for the code and I'm happy now it's working  :)

The font used in the Compile Log File window is not scaled.

There are projects mixed with files in "Recent Files". Also, no scrollbar.

When compiling starts, you shoud display a Windows wait cursor. Otherwise, if compiling takes some time it looks like if it is doing nothing.

Another problem with projects. If while working in a project I load a template file, the resulting Untitled* file is added to the project and can't be removed because when I click the right mouse button to try to remove it, a new Untitled* is added to the list.

After working with a project and closing it, I have loaded a bas file draging it to the editor and compiling has failed because it tries to link the resource file of the closed project.

FreeBASIC Compiler - Version 1.05.0 (01-31-2016), built for win64 (64bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
standalone
target:       win64, x86-64, 64bit
compiling:    C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.BAS -o C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.c (main module)
compiling C:  C:\Users\Pepe\FreeBasic64\bin\win64\gcc.exe -m64 -march=x86-64 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -masm=intel "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.c" -o "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.asm"
assembling:   C:\Users\Pepe\FreeBasic64\bin\win64\as.exe --64 --strip-local-absolute "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.asm" -o "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.o"
compiling rc:               C:\Users\Pepe\FreeBasic64\bin\win64\GoRC.exe /ni /nw /o /machine X64 /fo "C:\Users\Pepe\FreeBasic64\AfxTests\WinFBE_Projects\ImageCtx_Demo\Resource.obj" "C:\Users\Pepe\FreeBasic64\AfxTests\WinFBE_Projects\ImageCtx_Demo\Resource.rc"

Error!
Line 5 of Resource Script (C:\Users\Pepe\FreeBasic64\AfxTests\WinFBE_Projects\ImageCtx_Demo\Resource.RC):-
Could not find file:-
.\Resources\Manifest.xml

OBJ file not made
compiling rc failed: 'C:\Users\Pepe\FreeBasic64\bin\win64\GoRC.exe' terminated with exit code 1

Hi Jose, thanks for the reports! I will work on them tomorrow and get all fixes and suggestions posted. Appreciate it!

Quote from: Jose Roca on November 28, 2016, 04:31:54 PM
There are projects mixed with files in "Recent Files". Also, no scrollbar.

I wonder if this occurred after you drag/dropped files onto the editor? There was a problem in that code that I have fixed and will upload later.

Quote from: Jose Roca on November 28, 2016, 02:26:48 PM
The font used in the Compile Log File window is not scaled.

My fault. I was using AfxCreateFont rather than pWindow->CreateFont.

Quote from: Jose Roca on November 28, 2016, 08:45:18 PM
After working with a project and closing it, I have loaded a bas file draging it to the editor and compiling has failed because it tries to link the resource file of the closed project.

FreeBASIC Compiler - Version 1.05.0 (01-31-2016), built for win64 (64bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
standalone
target:       win64, x86-64, 64bit
compiling:    C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.BAS -o C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.c (main module)
compiling C:  C:\Users\Pepe\FreeBasic64\bin\win64\gcc.exe -m64 -march=x86-64 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -masm=intel "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.c" -o "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.asm"
assembling:   C:\Users\Pepe\FreeBasic64\bin\win64\as.exe --64 --strip-local-absolute "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.asm" -o "C:\Users\Pepe\FreeBasic64\AfxTests\CGdiPlus\Bitmap\BitmapCloneArea.o"
compiling rc:               C:\Users\Pepe\FreeBasic64\bin\win64\GoRC.exe /ni /nw /o /machine X64 /fo "C:\Users\Pepe\FreeBasic64\AfxTests\WinFBE_Projects\ImageCtx_Demo\Resource.obj" "C:\Users\Pepe\FreeBasic64\AfxTests\WinFBE_Projects\ImageCtx_Demo\Resource.rc"

Error!
Line 5 of Resource Script (C:\Users\Pepe\FreeBasic64\AfxTests\WinFBE_Projects\ImageCtx_Demo\Resource.RC):-
Could not find file:-
.\Resources\Manifest.xml

OBJ file not made
compiling rc failed: 'C:\Users\Pepe\FreeBasic64\bin\win64\GoRC.exe' terminated with exit code 1

I think this was a by-product of the problem with the drag/drop code that I just fixed. I will let you see if you can reproduce it once I upload the new code. My quick test did not show a problem.

Quote from: Jose Roca on November 28, 2016, 08:22:25 PM
Another problem with projects. If while working in a project I load a template file, the resulting Untitled* file is added to the project and can't be removed because when I click the right mouse button to try to remove it, a new Untitled* is added to the list.

This was an interesting scenario. I have it fixed now.

In this function


' ========================================================================================
' Checks if the program that we are going to compile is already running
' ========================================================================================
Function IsProcessRunning( ByVal pwszExeFileName As WString Ptr ) As BOOLEAN

   Dim hSnapShot As HANDLE
   Dim pe32w As PROCESSENTRY32W

   Dim wszExeFileName As WString * MAX_PATH = Ucase(*pwszExeFileName)
   Dim wszExeProcessName As WString * MAX_PATH

   pe32w.dwSize = Sizeof(pe32w)
   hSnapShot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)

   If hSnapShot <> INVALID_HANDLE_VALUE Then
      If Process32First(hSnapShot, @pe32w) Then
         GetProcessImageName( @pe32w, @wszExeProcessName )
         If Ucase(wszExeProcessName) = wszExeFileName Then
            Function = True
         Else
            Do While Process32Next(hSnapShot, @pe32w) > 0
               GetProcessImageName( @pe32w, @wszExeProcessName )
               If Ucase(wszExeProcessName) = wszExeFileName Then
                  Function = True
                  Exit Do
               End If
            Loop
         End If
      End If
   End If
   CloseHandle hSnapShot

End Function


CloseHandle hSnapShot should go before the End If, not after.


      CloseHandle hSnapShot
   End If


Thanks Jose - code changed and will be uploaded shortly.

Changes uploaded to GitHub:

- Fixed: Correct font for Compiler Log output to be HighDPI aware.
- Fixed: Dropping of files onto editor (frmMain_OnDropFiles) now correctly opens regular files or projects.
- Fixed: Problem with "Utitled.bas*" files persisting in Project Explorer list even when untitled source file is closed.
- Added: Change cursor to hourglass during compile process.

Changing the cursor to hourglass is not 100% working. If mouse clicked on compile icon in toolbar then cursor does not seem to change. Maybe toolbar automatically switches the cursor back to an arrow. Elsewhere if compile is initiated then the hourglass seems to appear. Need to figure out a simple way to ensure that hourglass always appears when compile initiated.

I have written some small projects to suplement templates. Need to be projects because they use resources.

The explorer window has not scrollbars when displaying recent files and projects. Is it intentional?

Quote from: Jose Roca on November 29, 2016, 07:06:01 PM
The explorer window has not scrollbars when displaying recent files and projects. Is it intentional?

Yes, intentional because I thought visually it would look better.... however, from a usability standpoint they should be there. I will add them in to see what they look like.

Yup, looks horrible. If I keep the scrollbars then I may as well resort back to the traditional Treeviews and not use the custom draw at all. Wish I could have implemented the custom vertical toolbar for the project explorer. It would have made that look so much nicer as well.

Quote from: Jose Roca on November 29, 2016, 07:01:02 PM
I have written some small projects to suplement templates. Need to be projects because they use resources.

Wow! I just noticed your post. Awesome! Are you okay with me adding it to the download?

> Are you okay with me adding it to the download?

Of course.

I have noticed that when I drag and drop a project, sometimes the main file is opened in the editor and sometimes not.

Quote from: Jose Roca on November 29, 2016, 07:58:02 PM
> Are you okay with me adding it to the download?

Of course.

Excellent! Thanks.

I have noticed that when I use your *.wfbe projects that the files do not open. This is because (of course) my folder structure on my computer is different than yours.

File={CURDRIVE}:\Users\Pepe\FreeBasic64\AfxTests\WinFBE_Projects\MenuWithIcons\MenuWithIcons.bas

What I need to do is save the file locations to the *.wfbe project file as relative filenames to the project file rather than absolute file names. Sounds like a interesting job and will require some work for sure.

This function looks promising  :)

PathRelativePathTo
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773740(v=vs.85).aspx

...and of course Jose already has it in his Afx routines:  AfxPathRelativePathTo

I have posted updated headers, templates and projects. Feel free to incoporate wathever you wish in the WinFBE download. I have added the AfxGetComboBoxText function that you suggested, so you will get a duplicate error because you already are using it in your editor.

> I have noticed that when I use your *.wfbe projects that the files do not open. This is because (of course) my folder structure on my computer is different than yours.

The way to find the problems is to use the editor. I already have begin to use it instead of my own. A pity that there aren't more testers.

Thanks Jose :)
...I hope the testers will follow. That's why I posted it over on the FB forum. Hopefully generate some more users and help accelerate the development.

Updated to GitHub:

- Added: Subfolder called "Sample_Projects" containing many sample projects as written by Jose Roca.
- Changed: Project files are now saved to the project file as relative to the project disk filename (*.wfbe).

I have manually adjusted the filenames in the Sample_Projects folder's *.wfbe files to be relative. Seems to work okay.

But there are not *.wfbe files  ???

Updated to GitHub:

- Added: StatusBar panel 5 shows current compile results (Errors/Warnings). Clicking that panel shows/hide Output window.

Quote from: Jose Roca on November 29, 2016, 11:19:49 PM
But there are not *.wfbe files  ???

They should be there now. I was excluding all wfbe files via the .gitignore file but I have now removed that restriction.

Compiling of the .rc files is failing because GitHub is removing the carriage returns and all the instructions are joined in a single long line.

Quote from: Jose Roca on November 29, 2016, 11:57:40 PM
Compiling of the .rc files is failing because GitHub is removing the carriage returns and all the instructions are joined in a single long line.

Try downloading it again. I just changed the .gitattributes file to treat *.rc and *.wfbe files as CRLF.

Now the problem are the .wfbe files

' WINFBE PROJECT FILE
਍倀爀漀樀攀挀琀吀礀瀀攀㴀 　ഀഀ
ProjectErrorOption= 3
਍倀爀漀樀攀挀琀䐀攀戀甀最㴀 　ഀഀ
ProjectThread= 0
਍倀爀漀樀攀挀琀匀栀漀眀䌀漀渀猀漀氀攀㴀 　ഀഀ
ProjectOther32=
਍倀爀漀樀攀挀琀伀琀栀攀爀㘀㐀㴀ഀഀ
DefaultCompiler=FBC 32bit
਍䐀攀昀愀甀氀琀䌀漀洀瀀椀氀攀䴀漀搀攀㴀䜀唀䤀ഀഀ
CommandLine=
਍䄀挀琀椀瘀攀吀愀戀㴀 　ഀഀ
File=.\PickIconDialog.bas
਍䘀椀氀攀吀礀瀀攀㴀 ㄀ഀഀ
TabIndex=-1
਍䈀漀漀欀洀愀爀欀猀㴀ഀഀ
FirstLine= 3
਍倀漀猀椀琀椀漀渀㴀 㘀㠀　ഀഀ
FileEnd=[-]
਍䘀椀氀攀㴀⸀尀刀攀猀漀甀爀挀攀⸀爀挀ഀഀ
FileType= 4
਍吀愀戀䤀渀搀攀砀㴀 　ഀഀ
FileEnd=[-]
਍

Quote from: Jose Roca on November 30, 2016, 12:11:45 AM
Now the problem are the .wfbe files

' WINFBE PROJECT FILE
਍倀爀漀樀攀挀琀吀礀瀀攀㴀 　ഀഀ
ProjectErrorOption= 3
਍倀爀漀樀攀挀琀䐀攀戀甀最㴀 　ഀഀ
ProjectThread= 0
਍倀爀漀樀攀挀琀匀栀漀眀䌀漀渀猀漀氀攀㴀 　ഀഀ
ProjectOther32=
਍倀爀漀樀攀挀琀伀琀栀攀爀㘀㐀㴀ഀഀ
DefaultCompiler=FBC 32bit
਍䐀攀昀愀甀氀琀䌀漀洀瀀椀氀攀䴀漀搀攀㴀䜀唀䤀ഀഀ
CommandLine=
਍䄀挀琀椀瘀攀吀愀戀㴀 　ഀഀ
File=.\PickIconDialog.bas
਍䘀椀氀攀吀礀瀀攀㴀 ㄀ഀഀ
TabIndex=-1
਍䈀漀漀欀洀愀爀欀猀㴀ഀഀ
FirstLine= 3
਍倀漀猀椀琀椀漀渀㴀 㘀㠀　ഀഀ
FileEnd=[-]
਍䘀椀氀攀㴀⸀尀刀攀猀漀甀爀挀攀⸀爀挀ഀഀ
FileType= 4
਍吀愀戀䤀渀搀攀砀㴀 　ഀഀ
FileEnd=[-]
਍

:)  Okay, that should be fixed now. Git should now be treating it okay now. It is a UTF16 unicode file.

They work fine now.