This is a pretty major update to the editor especially with the new build configuration system. Please try it out and post your comments below. I will fix any issues and then make a post over on the FreeBasic site that v1.4.0 is available.
- Added: Major change. New Build Configuration system.
- Added: Quick Run (added to Compile menu and Toolbar).
- Added: Option (Environment Options :: General Options) for "Ask before exiting the editor".
- Added: Check added to catch whether a loaded file has been *deleted* by something external. Message now displays asking whether to keep file open or close it.
- Change: The "Run Executable" functionality now runs the currently active source code file should the EXE exist. Previously would always run the most recently executed exe.
https://github.com/PaulSquires/WinFBE/releases
When clicking Delete configuration, I would ask if I'm sure? Too easy to click the button by accident.
After selecting a different configuration, the change it's not immediately displayed in the status bar.
Weird. Sometimes, when I click F5 to compile, instead of compiling it activates the Explorer window.
Quote from: Jose Roca on August 02, 2017, 06:35:13 PM
After selecting a different configuration, the change it's not immediately displayed in the status bar.
Thanks! Done. Easily fixed. Will be in next upload.
Quote from: Jose Roca on August 02, 2017, 06:26:16 PM
When clicking Delete configuration, I would ask if I'm sure? Too easy to click the button by accident.
Done. Change will be in the next upload.
Quote from: Jose Roca on August 02, 2017, 06:53:10 PM
Weird. Sometimes, when I click F5 to compile, instead of compiling it activates the Explorer window.
Hmmm... can't say that I've ever experienced that. F9 would activate the Explorer window. I just checked the code and everything seems to be mapped to the correct places.
New EXE's uploaded to GitHub. You would also need to download the .lang language files because I added a string for the "confirm delete build configuration".
Quote from: TechSupport on August 02, 2017, 07:24:25 PM
Quote from: Jose Roca on August 02, 2017, 06:53:10 PM
Weird. Sometimes, when I click F5 to compile, instead of compiling it activates the Explorer window.
Hmmm... can't say that I've ever experienced that. F9 would activate the Explorer window. I just checked the code and everything seems to be mapped to the correct places.
I don't mean the explorer of the editor, but Windows Explorer.
Quote from: Jose Roca on August 02, 2017, 07:35:26 PM
Quote from: TechSupport on August 02, 2017, 07:24:25 PM
Quote from: Jose Roca on August 02, 2017, 06:53:10 PM
Weird. Sometimes, when I click F5 to compile, instead of compiling it activates the Explorer window.
Hmmm... can't say that I've ever experienced that. F9 would activate the Explorer window. I just checked the code and everything seems to be mapped to the correct places.
I don't mean the explorer of the editor, but Windows Explorer.
Well, that seems even weirder! :) ;) :)
Just some points to consider:
You will notice that if you load multiple source files into the editor (not in a project), that you can designate a different build configuration for each one.
Also, in the Build Configuration dialog you can set one (or none) build to be the "default". If a default build is selected then any file loaded into the editor will use that default build. If no default is specified then the file being opened will use whatever build happens to be selected at that time. Projects save whatever build is assigned to them.
The builds are each assigned a GUID string when they are created. This allows you to add new builds, delete builds, move builds around, and the loaded editor files will always reference the correct build. It does not rely on the listbox index of the build.
Quote from: TechSupport on August 02, 2017, 07:54:04 PM
Quote from: Jose Roca on August 02, 2017, 07:35:26 PM
Quote from: TechSupport on August 02, 2017, 07:24:25 PM
Quote from: Jose Roca on August 02, 2017, 06:53:10 PM
Weird. Sometimes, when I click F5 to compile, instead of compiling it activates the Explorer window.
Hmmm... can't say that I've ever experienced that. F9 would activate the Explorer window. I just checked the code and everything seems to be mapped to the correct places.
I don't mean the explorer of the editor, but Windows Explorer.
Well, that seems even weirder! :) ;) :)
It has happened to me several times, but can't repeat it at will. I'm working in a new class, and I run the test code many times, sometimes letting the editor to save the changes before compiling and sometimes saving it before compiling, just to see if not saving the code had something to do with iy, but it has happened to me in both cases.
Always activates Windows Explorer with the My Documents folder selected.
I have been scouring Google trying to find some reference to Explorer getting invoked by F5..... haven't found anything. Every article just talks about F5 as invoking a refresh. I wonder do you have any programs in the background that may be stealing focus from the editor just before you press F5 to compile. I think you have have stumbled onto one of the great mysteries of the universe :)
No, I don't, and it only has happened when using this last version.
I wonder does it happen when the "Run compiled programs using command window" option is set in Compiler Setup? That option generates a batch file during compile so maybe it somehow triggers something in Windows 7.
I have this option unchecked. Didn't even know that it existed.
The way to launch Windows Explorer is using ShellExecute. Check your code if you're using this function.
I added it a few days ago for fxm so that runtime error messages could be caught/viewed when compiling and running a program using -exx compiler option. Originally I tried to catch the STDERR output through a pipe but it did not work cleanly because unfortunately the compiler was designed to output error messages to STDOUT.
...yes, I am using ShellExecuteEx in a few places within the code_Compile.inc source file.
I use it to execute the batch file that does the actual compiling and I also use it again in the RunExe function that executes and runs the compiled program.
Maybe it is failing sometimes and launching Windows Explorer as a side effect.
On my side it append every time I press or click F5.
Win7-pro
Explorer in C:\Users\Pierre\Documents
64bit WinFBE
If I REMout RunEXE( gCompile.OutputFilename, gApp.Projects(idx).ProjectCommandLine)
in modCompile.inc, I got no Explorer nor exe running
Something append to gCompile.OutputFilename...
Now all is fine, no more Explorer and program is executed,
problem is I don't know what I did?
I will restart from unzipping the source...
OK, seems that gCompile.OutputFilename is erased somewhere between
If i Then gCompile.OutputFilename = AfxStrRemove(Left(wszTemp, i), wDQ)
and
RunEXE( gCompile.OutputFilename, gApp.Projects(idx).ProjectCommandLine)
Just after
Function code_Compile( ByVal wID As Long ) As BOOLEAN
I did add
DIM wOutputFilename AS wSTRING * MAX_PATH
as a backup for gCompile.OutputFilename
After
If i Then gCompile.OutputFilename = AfxStrRemove(Left(wszTemp, i), wDQ)
I did add
IF gCompile.OutputFilename <> "" THEN wOutputFilename = gCompile.OutputFilename
and I did add
gCompile.OutputFilename = wOutputFilename
just before
RunEXE( gCompile.OutputFilename, gApp.Projects(idx).ProjectCommandLine)
and all run fine now.
Not a final solution of course, but this should give you a starting point.
Pierre
(See you tomorrow...)
Thanks Pierre, I am investigating this today.... I have a good idea where the problem may be.
I have changed the compile code back to the way it was before the last upload. These changes should undo the ill effect that you guys are experiencing. I will re-upload to GitHub in a few hours (I need to recompile the 64 bit version but I am only on 32 bit machine until then).
New files and binaries uploaded to GitHub.
The release is numbered 1.4.1
https://github.com/PaulSquires/WinFBE/releases
Hopefully this fixes that issue of invoking Windows Explorer.
Tested. So far, so good...
Thanks Pierre, hopefully no more issues. I was pretty confident I knew the reason for the problem so I think I was able to eliminate the issue. Hopefully Jose has similar good results.
Seems to work fine now.
Awesome - thanks!
Updated the FreeBasic project thread for WinFBE http://www.freebasic.net/forum/viewtopic.php?f=8&p=234739#p234739
Added a shout out for Jose's awesome CWindow and class libraries.
Thanks for the shout out.
You must check the code for Find/Replace. There must be a memory leak somewhere. The number of GDI objects in the Task Manager increases by more than 400 each time that I use it and eventually the editor stops working.
Thanks Jose, I will investigate this today and track down the GDI leak. I'll post an update once it is corrected.
From time to time I get a "Permission denied" message from the linker. This was also happening with previous versions of the editor.
Quote from: Jose Roca on August 03, 2017, 11:37:38 PM
Thanks for the shout out.
You must check the code for Find/Replace. There must be a memory leak somewhere. The number of GDI objects in the Task Manager increases by more than 400 each time that I use it and eventually the editor stops working.
This appears to be related to me using GDI function to load png from resource but not releasing those pointer handles when subsequent calls to load additional images. I need to use GdiDispose (which I wasn't doing).
Quote from: Jose Roca on August 04, 2017, 01:49:09 PM
From time to time I get a "Permission denied" message from the linker. This was also happening with previous versions of the editor.
This has happened to me also from time to time. Would love to be able to faithfully reproduce the circumstances that cause it.
Quote from: TechSupport on August 04, 2017, 03:12:46 PM
Quote from: Jose Roca on August 03, 2017, 11:37:38 PM
Thanks for the shout out.
You must check the code for Find/Replace. There must be a memory leak somewhere. The number of GDI objects in the Task Manager increases by more than 400 each time that I use it and eventually the editor stops working.
This appears to be related to me using GDI function to load png from resource but not releasing those pointer handles when subsequent calls to load additional images. I need to use GdiDispose (which I wasn't doing).
Actually, this is not the case at all. I am using icons, not png for the find/replace graphics. Looks like I was using DeleteObject rather than DestroyIcon. Making the change helps considerable but there is still a 20 or 30 gdi leak each time the dialog is invoked. I am still investigating that.
Quote from: Jose Roca on August 03, 2017, 11:37:38 PM
Thanks for the shout out.
You must check the code for Find/Replace. There must be a memory leak somewhere. The number of GDI objects in the Task Manager increases by more than 400 each time that I use it and eventually the editor stops working.
Rarely do programming problems kick my ass as badly as this problem did. It took me hours to finally track down the source of the leak. Had really not much to do with the icons at all. There were two main problems:
1) Not DELETE the allocated pWindow memory for the main frmFindReplace dialog every time it was open and closed. Of course this prevented the destructor for each instance of the pWindow from firing.
2) For every child image button on the frmFindReplace dialog I was assigning a tooltip. However, I was not destroying the HWND window associated with the tooltip during the WM_DESTROY of each image button.
Things seem to be good now with the GDI resources.
As an aside, instead of tracking the GDI resources with the Windows Task Manager, it was much easier to display the GDI cound in the WinFBE task bar using a timer that fired every 500ms.
if uMsg.message = WM_TIMER then
Dim As HWnd hStatusbar = GetDlgItem(HWnd_FRMMAIN, IDC_FRMMAIN_STATUSBAR)
static GUILeak as wstring * 100
dim hProcess AS HANDLE
dim dwProcessID as dword
getwindowthreadprocessid( HWnd_FRMMAIN, @dwProcessID)
hProcess = openprocess(PROCESS_QUERY_INFORMATION OR PROCESS_VM_READ, 0, dwProcessID)
GUILeak = "GDICount: " & str(getguiresources(hProcess, GR_GDIOBJECTS))
StatusBar_SetText(hStatusbar, 0, GUILeak)
end if
I am uploading the new version (1.4.2) to GitHub and will post the release details.
Seems to we working fine now.
And apparenty you also have fixed the problem of DebugView reporting a bunch of wrong API calls. Maybe it was caused by the wrong use of DeleteObject rather than DestroyIcon.
I'm working on adding the User Tools dialog (attached). Similar to the functionality in FireFly.
Jose, anything you need added? I'm thinking that after this dialog that I should concentrate on improving the codetips/completion. Most likely implement it with threads to monitor code as it is typed rather than doing the parse whenever the source file is saved. I want to switch to use your dictionary code rather than the primitive db system I cobbled together within the editor.
I also want to get back at the GUI library that I am building on top of your CWindow and classes. I have a strong feeling that if I can present a .dot style framework with all of the flexibility and speed that your framework provides then there would be much more uptake from Windows programmers in the FB world.
In the tools manager that I did for my editor, I have a checkbox labeled "Display this item in the editor menu". When the editor starts, it reads the database and displays the checked items in a Tools menu and, if the extension is .chm, it does it in the Guides menu.
Quote
I also want to get back at the GUI library that I am building on top of your CWindow and classes. I have a strong feeling that if I can present a .dot style framework with all of the flexibility and speed that your framework provides then there would be much more uptake from Windows programmers in the FB world.
With so many VBer's wandering around, I won't be surprised. The pity is that coding this way they will never learn to use the Windows API, and what would be of them without the SDK programmers?
Many years ago I read something like C++ programmers should be gratefully indebted to the designers of VB because they had provided them with a good way of earning money writing OCXs for VB.
Quote from: Jose Roca on August 06, 2017, 02:46:18 PM
Many years ago I read something like C++ programmers should be gratefully indebted to the designers of VB because they had provided them with a good way of earning money writing OCXs for VB.
:D That's so true, and I was one of those poor souls who started Windows programming using VB. I learned WinAPI and GUI programming when I switched to PB and starting coding the JellyFish editor. Seems like a lifetime ago now!
Quote from: Jose Roca on August 06, 2017, 02:38:44 PM
...I have a checkbox labeled "Display this item in the editor menu". When the editor stats, it reads the database and displays the checked items in a Tools menu and, if the extension is .chm, it does it in the Guides menu.
Great idea - I will do the same.
Some code extracted from CSED.
' GUIDES MENU
ENUM FBSED_GUIDES_MENU_ENUM SINGULAR
IDM_GUIDESMENUHEADER = 4200 ' // Guides menu
END ENUM
' TOOLS MENU
ENUM FBSED_TOOLS_MENU_ENUM SINGULAR
IDM_TOOLSMENUHEADER = 4500 ' // Tools menu
END ENUM
' When building the menu, read the tools database and add menu items
pSed.MenuGuidesCount = 1
pSed.MenuToolsCount = 1
strDbPath = EXE.Path$ & "FBSED_TOOLS\FBSED_TOOLS.TRM"
IF ISFILE(strDbPath) THEN
hToolsFile = trm_Open(BYCOPY strDbPath, %TRUE)
IF hToolsFile > 0 THEN
RecordStr = trm_GetFirst(hToolsFile, 1)
WHILE LEN(RecordStr)
AfxDoEvents pWindow.hwnd
LSET tTools = RecordStr
strName = TRIM$(tTools.strName)
strPath = TRIM$(tTools.strPath)
IF VAL(tTools.strMenu) = 1 THEN
IF UCASE$(RIGHT$(strPath, 4)) = ".CHM" OR UCASE$(RIGHT$(strPath, 4)) = ".PDF" THEN
AppendMenu pSed.hMenuGuides, %MF_ENABLED, %IDM_GUIDESMENUHEADER + pSed.MenuGuidesCount, BYCOPY strName
pSed.MenuGuidesCount = pSed.MenuGuidesCount + 1
ELSE
AppendMenu pSed.hMenuTools, %MF_ENABLED, %IDM_TOOLSMENUHEADER + pSed.MenuToolsCount, BYCOPY strName
pSed.MenuToolsCount = pSed.MenuToolsCount + 1
END IF
END IF
RecordStr = trm_GetNext(hToolsFile)
WEND
trm_Close(hToolsFile)
END IF
END IF
' // Right justify some menus
AfxRightJustifyMenuItem(hMenu, 7)
AfxRightJustifyMenuItem(hMenu, 8)
AfxRightJustifyMenuItem(hMenu, 9)
' // Bold the text of the Help menu
AfxSetMenuItemBold(hMenu, 9)
' // Bold the text of Exit
AfxSetMenuItemBold(pSed.hMenuFile, 18)
' // Attach the menu to the main window
SetMenu pWindow.hwnd, hMenu
' In the main dialog callback, get the path of the tool or help file and launch it
' // Guides
CASE %IDM_GUIDESMENUHEADER + 1 TO %IDM_GUIDESMENUHEADER + pSed.MenuGuidesCount
strText = AfxGetMenuItemText(pSed.hMenuGuides, LO(WORD, wParam))
' // Retrieve the path of the help file
hToolsFile = trm_Open(EXE.Path$ & "FBSED_TOOLS\FBSED_TOOLS.TRM", %TRUE)
IF hToolsFile THEN
RecordStr = trm_GetEqual(hToolsFile, 1, BYCOPY strText)
LSET tTools = RecordStr
strPath = TRIM$(tTools.strPath)
IF LEN(strPath) THEN
IF UCASE$(RIGHT$(TRIM$(tTools.strPath), 4)) = ".CHM" THEN
HtmlHelp( 0, BYCOPY strPath, 0, 0)
ELSEIF UCASE$(RIGHT$(TRIM$(tTools.strPath), 4)) = ".PDF" THEN
ShellExecute(%NULL, "open", BYCOPY TRIM$(tTools.strPath), BYCOPY TRIM$(tTools.strParams), "", %SW_SHOWNORMAL)
END IF
END IF
' // Close the file
trm_Close hToolsFile
END IF
EXIT FUNCTION
' // Tools
CASE %IDM_TOOLSMENUHEADER + 1 TO %IDM_TOOLSMENUHEADER + pSed.MenuToolsCount
strText = AfxGetMenuItemText(pSed.hMenuTools, LO(WORD, wParam))
' // Retrieve the path of the help file
hToolsFile = trm_Open(EXE.Path$ & "FBSED_TOOLS\FBSED_TOOLS.TRM", %TRUE)
IF hToolsFile THEN
RecordStr = trm_GetEqual(hToolsFile, 1, BYCOPY strText)
LSET tTools = RecordStr
strPath = TRIM$(tTools.strPath)
IF LEN(strPath) THEN
IF UCASE$(RIGHT$(TRIM$(tTools.strPath), 4)) <> ".CHM" THEN
PID = SHELL(strPath & " " & TRIM$(tTools.strParams), 1)
END IF
END IF
' // Close the file
trm_Close hToolsFile
END IF
EXIT FUNCTION
Works very well to make the tools and help files directly available from the menu.
I was using the old Tsunami database manager and was thinking to change it to SQLite to work with 64 bit, but I'm no longer in the editor's business.
Quote from: Jose Roca on August 06, 2017, 03:30:14 PM
Some code extracted from CSED.
Awesome, thanks for the code :)
Quote
....but I'm no longer in the editor's business.
Luckily for me :)
A suggestion, if you find it worthwile.
An option in the Projects menu to add a manifest.
In its simplest form, it can create a resource file, e.g.
Resource.rc
//=============================================================================
// Manifest
//=============================================================================
1 24 ".\Resources\Manifest.xml"
And a manifest:
Manifest.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="*"
name="ApplicationName"
type="win32"/>
<description>Optional description of your application</description>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
<!-- Compatibility section -->
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--This Id value indicates the application supports Windows 8 functionality-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!--This Id value indicates the application supports Windows 8.1 functionality-->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!--This Id value indicates the application supports Windows 10 functionality-->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
<!-- Trustinfo section -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
</assembly>
As they will become part of the project, they can be easily modified in the editor if needed.
Sounds like a great idea. I'll add it. :)
Quote from: Jose Roca on August 08, 2017, 11:32:40 PM
A suggestion, if you find it worthwile.
An option in the Projects menu to add a manifest.
In its simplest form, it can create a resource file, e.g.
Resource.rc
//=============================================================================
// Manifest
//=============================================================================
1 24 ".\Resources\Manifest.xml"
And a manifest:
Manifest.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="*"
name="ApplicationName"
type="win32"/>
<description>Optional description of your application</description>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
<!-- Compatibility section -->
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--This Id value indicates the application supports Windows 8 functionality-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!--This Id value indicates the application supports Windows 8.1 functionality-->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!--This Id value indicates the application supports Windows 10 functionality-->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
<!-- Trustinfo section -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
</assembly>
As they will become part of the project, they can be easily modified in the editor if needed.
I implemented this via adding a checkbox to the Project Options dialog. If checked, then when the dialog is closed it will create new resource file and/or manifest in the project folder (for safety, it will not overwrite existing files). The resource is then automatically added to the project.
Excellent. This should ease the use of projects, having something where to start. Otherwise, we first have to create the project, then search for an .rc file and a manifest file to copy...
I have pushed all of the changes to GitHub if you want to download the repository zip and preview the package before I create an actual release.