WinFBE Suite 1.7.0 (July 29, 2018)

[Paul Squires]

Version 1.7.0 (July 29, 2018)
- Added: Button BackColorDown property added. The ThemeSupport property must be set to False.
- Fixed: Right click mouse popup menu not showing in code editor of a visual designer form.
- Fixed: Added a Relative path check for Help files.

https://github.com/PaulSquires/WinFBE/releases

[raymw]

Hi Paul, for button, backbuttondown and textmargin element not defined.

If I use the link you have in this topic, I get a rar download, if I go via the winfbe on github, I get a zip download. They also have different folder names when extracted.  (suite/master) Neither seem to install the fb help, and the top menu does not have the api help selection.

[Paul Squires]

Hi Paul, for button, backbuttondown and textmargin element not defined.

BackButtonDown color is definitely there. I just downloaded the rar and extracted to folder. Loaded the test project, changed ThemeSupport to False, and then changed the BackColorDown color.

TextMargin has not been implemented yet because I haven't implemented support for assigning images to the button yet.

If I use the link you have in this topic, I get a rar download, if I go via the winfbe on github, I get a zip download. They also have different folder names when extracted.  (suite/master) Neither seem to install the fb help, and the top menu does not have the api help selection.

The rar download is the WinFBE_Suite download. That's the all-in-one package containing all of the source code, WinFBE Editor, FBC compilers, and help files. If you go to WinFBE on github and select the "green" download button then you are getting a copy of the WinFBE master branch source tree. The source tree does not contain all of the stuff that is in the WinFBE_Suite rar file.

The rar download definitely has the FreeBasic help file. It is installed in the "Help" folder and is called "freebasic_manual.chm". There is also an old Win32 api help file there as well called "win32_fb.chm". Jose's WinFBX hep chm is also there, as well as two PDF files for the visual designer.

I will add a Help menu item for the win32api help file to WinFBE's top menu. I will also add one for Jose's WinFBX help file.

[Paul Squires]

If you are simply downloading the WinFBE Editor (via that zip file) then you will get undefined error if you try to run the visual designer with BackColorDown. That is because you would need to also download the latest WinFormsX include files and copy them into your \inc\winformsx folder. This is why using the WinFBE Suite is always easier. Everything is doen for you.
https://github.com/PaulSquires/WinFormsX

[raymw]

Hi Paul, Easier is good. It's OK now, I deleted all folders which had any version of winfbe in them, and reinstalled from the rar. Maybe you should consider putting a big red warning note on the zip install that you need the latest winfbx too. Another question, of course... in the compiler error messages, what does the line number currently refer too? It seems to vary, but always a low number. I'm hoping it would eventually refer to the line of basic code which is in error.

just a note - the code completion tip in editor does not include 'backcolordown'

something I've noticed, keywords you show as capitals, but in fb help, many are not capitalised e.g. RGB and Right.  However, I had a variable 'argb', which sometimes it would get changed to 'aRGB'. Not a problem, I can't definitely replicate it, but it would be nice, as in Visual Studio, that there could be a constancy in user created variable names. iirc VS makes all instances of a variable the same as the last alteration wrt case of each character.

[Johan Klassen]

Hi Paul
I thoughtlessly renamed one of the stub functions generated by the VD and when trying to compile I get the error message

linking failed:'F:\dev\WinFBE_Suite\FreeBASIC-1.06.0-win32\bin\win32\ld.exe' terminated with exit code 1

I was doing copy/paste editing when I inadvertently renamed one of the stub functions to something other than the original name and the error message had me stumped.

[José Roca]

In the Compiler Setup add additional compiler switches to get moew verbose information.
I use: -w pedantic -v

[Johan Klassen]

hello José Roca
yes the options you suggested are helpful, however I think the error reporting could be improved, instead of the error message in my first post, it should give

F:\FreeBASIC Programs\Project7\Untitled1.o:fake:(.text+0x9dca): undefined reference to `FORM1_BUTTON1_CLICK@8'

the compiler log gives

F:\FreeBASIC Programs\Project7\Untitled1.o:fake:(.text+0x9dca): undefined reference to `FORM1_BUTTON1_CLICK@8'
linking failed: 'F:\dev\WinFBE_Suite\FreeBASIC-1.06.0-win32\bin\win32\ld.exe' terminated with exit code 1

so WinFBE is giving the last line which is not helpful

note that I made a new project for this test and did not give meaningful names to the project or the control

[José Roca]

> it should give [...]

The problem is that FB doesn't stop at the first error, so the list can be too long to be displayed in a message box. Click the "Compiler Log File" tab to see full details.

[Marc Pons]

Hi Paul

still very impressed by your job

I'm wondering why you are not using the -i compiler version internally on your ide? And as a consequence simplifying your suite...

it would be easier to only put somewhere and  once the WinFormsX folder and the Afx folder as José is also suggesting here :

As long as they're in a folder or subfolder called Afx, you can put them anywhere. When compiling you will need to use the switch -i followed by the path of the include files.

You could use that -i option as default without any risk in your compiler command line with a path to these folders relative to the ide executable path.
-i option can be several times in the compile cmd, so no risk if the user activate also that option, you only extend the path to search the includes...

I know it's not a big point, but as you and José are very often improving your codes, it would be easier to update for you and your followers.

anyway, thanks for your tremendous job.

Marc

[raymw]

Hi Paul, dunno whether 'tis better to modify previous posts to add fault? reporting, or start a new post. Anyway, it seems if I change the name of items in the visual designer, it adds new code, (but only event stubs, if any) leaving the old code in place.

[Paul Squires]

Hi Paul, dunno whether 'tis better to modify previous posts to add fault? reporting, or start a new post. Anyway, it seems if I change the name of items in the visual designer, it adds new code, (but only event stubs, if any) leaving the old code in place.

I am debating with myself whether to have the names of existing Event stubs update when a name changes. Likewise, should code in the current form (or entire project) be updated to change all occurrences of, say, a name change from Form1 to frmMain? Or, should I leave that exercise to the user in case they want full control over what names they want, or do not want, changed. What are your thoughts?

[Paul Squires]

> it should give [...]

The problem is that FB doesn't stop at the first error, so the list can be too long to be displayed in a message box. Click the "Compiler Log File" tab to see full details.

That is indeed the problem. Many errors and warnings could be present in the resulting log file. I could parse the file to associate "linking failed" errors with "undefined reference" line but there could be a multitude of different types of linking issues.

Personally, I never use the popup messagebox when compiling programs. I have ticked on the option (Environment Options / General Options) called "Hide successful compile results message". If the compile is successful, I get a pleasant beep/bell sound and a nice green icon in the statusbar. If an error occurs, then the "Output window" will pop open at the bottom of the screen and I can switch between Compiler Results and Compiler Log File.

[raymw]

Hi Paul

I am debating with myself whether to have the names of existing Event stubs update when a name changes. Likewise, should code in the current form (or entire project) be updated to change all occurrences of, say, a name change from Form1 to frmMain? Or, should I leave that exercise to the user in case they want full control over what names they want, or do not want, changed. What are your thoughts?

I thought I'd see if there was any advantage to me, to have this proposed full control. I don't think so. Rapidly the visual designer can get out of step with the code, it is too easy to delete/edit the wrong code. If it were possible to refer to the same object with a different name, then maybe useful, but as is, then I think the code should be updated to match the visual designer (and maybe even vice versa)

[SeaVipe]

Yes. And the existing Event stub becomes a Function? Or change the existing Event stub name (better)?