New release for WinFBE Editor and the also the integrated WinFBE Suite (includes the latest 32/64 bit FreeBasic compilers).
This release is dedicated to changes and fixes to the integrated visual designer. Too many to list. :)
https://github.com/PaulSquires/WinFBE/releases
(had to re-upload because of problem with sample project and duplicates)
thank you Paul :)
made a simple RPN calculator https://www.freebasic.net/forum/viewtopic.php?p=249807#p249807
Thanks Johan!
I didn't realize you were srvaldez over on the FB forum (or maybe I did and just forgot!). Awesome, thanks for sharing. Greatly appreciated :)
Paul, how would I catch keyboard input in my simple calculator, for example the keys 0 thru 9 and decimal point and also the return and enter keys.
thanks in advance
The best way to solve this kind of problem would be for me to implement a Form "KeyPreview" property.
Here is what the KeyPreview property would do based on how it is handled in .Net
Gets or sets a value indicating whether the form will receive key events before the event is passed to the control that has focus.
When this property is set to true, the form will receive all KeyPress, KeyDown, and KeyUp events. After the form's event handlers have completed processing the keystroke, the keystroke is then assigned to the control with focus. For example, if the KeyPreview property is set to true and the currently selected control is a TextBox, after the keystroke is handled by the event handlers of the form the TextBox control will receive the key that was pressed. To handle keyboard events only at the form level and not allow controls to receive keyboard events, set the KeyPressEventArgs.Handled property in your form's KeyPress event handler to true.
You can use this property to process most keystrokes in your application and either handle the keystroke or call the appropriate control to handle the keystroke. For example, when an application uses function keys, you might want to process the keystrokes at the form level rather than writing code for each control that might receive keystroke events.
Give me a bit of time and I will get this put into the designer.... I'm working on it now.
thank you Paul :)
No problem at all. I have most of the code written but there is still a few things left to do in order to get it working 100% correctly. This will entail uploading a full WinFBE Suite because the WinFormsX library code has changed as well. If everything goes as expected, I will upload the package tomorrow evening. If I run into trouble, I will let you know. This functionality is important because it is a pretty common situation that users will encounter.
Paul, yesterday I downloaded the new suite (1.6.7) and installed it. Both IDE's crashed when I tried to run them. I was a bit surprised as I have not had any problem with previous builds. I waited to see if anyone else reported this and when no one had, I started to investigate the cause. After a lot of copying files and different setups, I found that the problem was with the WinFBE.ini file. If I used the one from the source code zip, then all was good and either IDE would open. However, using the one that comes with the suite would lead to program crashes. There were four differences in the two files and by swapping them out one at a time, the trouble was found to be with the [compiler] settings for 32 and 64 bits. Removing these settings and both IDEs would start. However, if I now went to Options->Environment->Compiler settings and searched for the compiler folder, then the program crashes again and will not start. In other words, the only way I can start either IDE is to blank out the compiler settings in WinFBE.ini but now I can't restart the program if I set the compiler path(s).
By the way, I notice that Help->About still shows this as 1.6.5
I forgot to add that this is on a Windows 7 laptop. Later today I will test on a Win10 desktop.
A little update. After doing a bit more fiddling about, I think I may have fixed this problem. If I navigate to the compiler path via Options etc and then put the file location in doubles quotes e.g. "C:\WinFBE_1.6.7_Suite\FreeBASIC-1.06.0-win32\fbc.exe", then WinFBE opens normally. I don't know why this has happened with this installation as the ini file appears to be tha same as that for version 1.6.5 and that worked perfectly.
Hi Gregory, thanks so much for the bug report and your fine investigative analysis. I will look at this issue today and fix it for a new release this evening. I have had one more report from a user related to compiler path problems with the Suite and your identified issue could very well be a contributor to this other problem as well. I'll get to the bottom of it.
Thanks
hello Paul
on another VM running Windows 10, WinFBE would not launch, strangely if you open command prompt and drag-and-drop WinFBE on the command window WinFBE launches without a problem.
I made batch file like the following
f:
cd F:\WinFBE_Suite
WinFBE64.exe
but does not work, however if I simply place the full path into the batch file it works
F:\WinFBE_Suite\WinFBE64.exe
Yes, thanks Gregory,
I wasn't able to get WinFBE32 running either so I tried your fix like so: "C:\WinFBE_Suite\FreeBASIC-1.06.0-win32\fbc.exe"with double quotes and WinFBE32 now runs properly.
Clive Richey
Hi Paul,
Sample Projects, VisualDesigner, FormTest project.
New CheckBox control added to the frmLogin form (32 and 64). BackColor: System Colours all work except "Control" which is correct in the designer but has a white background when running and "Menu Text" which results in "error 18: Element not defined, SystemMenuText".
For other controls on the form the BackColor "Control" works correctly, but "Menu Text" causes the error 18 mentioned above.
Quote from: SeaVipe on July 24, 2018, 02:29:47 PM
Hi Paul,
Sample Projects, VisualDesigner, FormTest project.
New CheckBox control added to the frmLogin form (32 and 64). BackColor: System Colours all work except "Control" which is correct in the designer but has a white background when running and "Menu Text" which results in "error 18: Element not defined, SystemMenuText".
For other controls on the form the BackColor "Control" works correctly, but "Menu Text" causes the error 18 mentioned above.
Thanks Clive, I have now fixed both issues. Thanks for finding these problems and reporting them.
Quote from: SeaVipe on July 24, 2018, 02:13:29 PM
Yes, thanks Gregory,
I wasn't able to get WinFBE32 running either so I tried your fix like so: "C:\WinFBE_Suite\FreeBASIC-1.06.0-win32\fbc.exe"with double quotes and WinFBE32 now runs properly.
Clive Richey
I have not (yet) been able to reproduce or find a reason for the problems you guys are seeing with regards to compiler path not found issue. I will continue testing tomorrow. Not much sense for me to upload a package until I am confident of the reason/solution regarding this problem.
The WinFBE Suite default the compiler paths to be "relative paths". That's why when you go into Compiler Setup you will see a path liek the following:
.\FreeBASIC-1.06.0-win32\fbc.exe
That path gets resolved to a full path via this code:
' Convert relative path to absolute path if needed.
if AfxPathIsRelative(gCompile.CompilerPath) then
gCompile.CompilerPath = AfxPathCombine(AfxGetExePathName, gCompile.CompilerPath)
END IF
If the resulting compiler path has embedded spaces then I do not enclose it in quotes. This is because I ran into trouble invoking the CreateProcess api, so instead I convert it to a short path filename using this code:
' If spaces exist in the compiler path then convert the path to shortpathname in
' order to work well with CreateProcess and FBC. Just using double quotes causes problems.
if instr(gCompile.CompilerPath, " ") THEN
wszCommand = AfxGetShortPathName(gCompile.CompilerPath)
else
wszCommand = gCompile.CompilerPath
END IF
I have a feeling that the combination of the code above coupled with your individual situations may hold the key to the solution.
Quote from: Paul Squires on July 23, 2018, 08:33:11 PM
The best way to solve this kind of problem would be for me to implement a Form "KeyPreview" property.
Here is what the KeyPreview property would do based on how it is handled in .Net
Gets or sets a value indicating whether the form will receive key events before the event is passed to the control that has focus.
When this property is set to true, the form will receive all KeyPress, KeyDown, and KeyUp events. After the form's event handlers have completed processing the keystroke, the keystroke is then assigned to the control with focus. For example, if the KeyPreview property is set to true and the currently selected control is a TextBox, after the keystroke is handled by the event handlers of the form the TextBox control will receive the key that was pressed. To handle keyboard events only at the form level and not allow controls to receive keyboard events, set the KeyPressEventArgs.Handled property in your form's KeyPress event handler to true.
You can use this property to process most keystrokes in your application and either handle the keystroke or call the appropriate control to handle the keystroke. For example, when an application uses function keys, you might want to process the keystrokes at the form level rather than writing code for each control that might receive keystroke events.
This took a fair amount of time to correctly code. I have it now implemented and it seems to work well. I have also created two sample pieces of code. One that shows how to filter characters from a TextBox, and a second example on how to filter characters at the Form level (KeyPreview).
thanks again Paul :)
I am eagerly awaiting the release.
Paul, finally got around to testing on Win10 desktop and again neither program would start. At least with Win7 I was informed of the crash but in Win10 just nothing. I have since found that the easiest fix to to edit the WinFBE.ini and enclose either or both compiler paths in quotes and then the will start. If you only do one, then you can go to Options and enclose the other path in quotes. As you say, there are no spaces in the path but when I found that this was causing the problem I just enclosed the path in quotes to see what it would do. A pleasant surprise when it worked. A bit of a puzzle as I doubt you have changed this code from previous releases and they all work as expected.
Thanks Gregory - I appreciate you continuing to test.
Something Jose mentioned in a post a couple of days ago (about Chinese characters) got me looking at the source code again for the compile process. There were two functions there I coded the incoming parameters as ZSTRING when technically they should be WSTRING. I have changed the parameters and am now testing to see if it makes any difference especially with regard to wrapping the compile path in enclosed double quotes.
The two functions were: CreateChildProcess and RedirConsoleToFile.
Quote from: Paul Squires on July 25, 2018, 09:15:34 AM
Something Jose mentioned in a post a couple of days ago (about Chinese characters) got me looking at the source code again for the compile process. There were two functions there I coded the incoming parameters as ZSTRING when technically they should be WSTRING. I have changed the parameters and am now testing to see if it makes any difference especially with regard to wrapping the compile path in enclosed double quotes.
The two functions were: CreateChildProcess and RedirConsoleToFile.
This was definitely a problem and since I've changed it I can now correctly run the compiler from long path names with embedded spaces (without having to enclose in double quotes - which itself would cause compile fails). I will continue to look at this but the failing compiles that I experienced earlier today have now ceased. I hope this will also fix the issue that you guys have been seeing. I will post a test 32-bit exe for you to try before I upload a full package later this evening. I'll post that exe here in a couple of hours.
Since I began to work with unicode my rule of thumb is that ZSTRING no longer exists and that STRING is only useful when you want to easily allocate a byte buffer without having to use Allocate/Deallocate.
Quote from: Paul Squires on July 23, 2018, 06:32:35 PM
Thanks Johan!
I didn't realize you were srvaldez over on the FB forum (or maybe I did and just forgot!). Awesome, thanks for sharing. Greatly appreciated :)
Maybe he should look at my unicode clipboard functions AfxGetClipboardText and AfxSetClipboardText (in AfxWin.inc) instead of trying hacks to return unicode in an ansi string. ( https://www.freebasic.net/forum/viewtopic.php?f=2&t=26905 )
Hello Paul
does this WinFBE superceed Firefly for freebasic?
so shall i start with WinFBE to compile programs with Freebasic?
Indeed.