• Welcome to PlanetSquires Forums.
 

WinFBE Suite 1.6.7 (July 22, 2018)

Started by Paul Squires, July 22, 2018, 06:24:16 PM

Previous topic - Next topic

Paul Squires

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)
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Johan Klassen


Paul Squires

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 Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Johan Klassen

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

Paul Squires

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.


Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Johan Klassen


Paul Squires

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 Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Gregory Mayo

#7
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.

Paul Squires

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
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Johan Klassen

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

SeaVipe

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
Clive Richey

SeaVipe

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.
Clive Richey

Paul Squires

Quote from: SeaVipe on July 24, 2018, 01:59: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.
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Paul Squires

Quote from: SeaVipe on July 24, 2018, 01:43: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.

Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Paul Squires

Quote from: Paul Squires on July 23, 2018, 08:03: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).
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer