Update

[Paul Squires]

tried on another VM with same result, if I create a new project and place a button on the form and change the font from Segoe UI to Symbol and replace the Text of the button with down-arrow it show on the designer form but not when compiled, also the Font properties shows Symbol in Greek letters.
actually it shows the character but with 3 additional characters before.

This is actually a very important issue that you've raised and I am working on correcting things in the designer now. There are a number of things at play because the designer uses Unicode, the Scintilla editing control uses UTF-8, and then there is always the option the user will have ANSI files. Introducing the "down arrow" as a property value is allowing me to play out all of the different scenarios of producing code that will work in the designer and via generated code. I'm close to having it work for all scenarios. There is/was a big bug with saving CWSTR unicode text to UTF-16 unicode files but Jose cleared up that problem for me in another thread.

[raymw]

Hi Paul, If you change back and forth by double clicking on the tab at top of form/code, changes in button name, for example do not take place in the code until compiled (Or maybe something else- certainly not when code page becomes first visible. If you use the code tab at bottom of page, then it updates as you said above - i.e. on code becoming visible. I can't find a help file for anything other than freebasic in this system.

I think you mentioned somewhere that you intended bundling the editor, gui and freebasic as one install package. I think that was what you originally had on github, but I have probably messed up the paths etc. when I loaded the updated winfbe file. I think I'd best wait until I can make a complete install again.

[Paul Squires]

Thanks Ray - I will check into the double click top of form not regenerating the code.

The bundle is called "WinFBE Suite" and is available from: https://github.com/PaulSquires/WinFBE/releases
It is about a 60MB download but contains everything and all preconfigured ready to start.

[Paul Squires]

Hi Paul, If you change back and forth by double clicking on the tab at top of form/code, changes in button name, for example do not take place in the code until compiled (Or maybe something else- certainly not when code page becomes first visible. If you use the code tab at bottom of page, then it updates as you said above - i.e. on code becoming visible. I can't find a help file for anything other than freebasic in this system.

You are correct. I was using TabCtrl_SetCurSel instead of TabCtrl_SetCurFocus so the bottom tab control was not receiving the TCN_SELCHANGE  message where the call to regenerate the code was placed.

[Paul Squires]

RE: Generated code

I am debating whether to hide the generated code from the code editor altogether. Currently, the form file contains a lengthy series of Properties and Values for every control on the form (meta data). This is hidden from the user but is obviously needed when loading a form from disk file otherwise WinFBE wouldn't know what to create. When you make changes in the designer, code is generated that defines the Form's TYPE and creates the controls, etc. That code is displayed in the code editor, but is it really needed or necessary? Maybe only the Dim Shared Form1 As Form1Type code is needed to be displayed along with the code for any defined Event handlers.

When the form is compiled and run, the code output to file would be as follows:
(1) The meta data that defines the form and it's controls (that the long list of Properties and Values)
(2) The actual code that will run to create the form (the TYPE, constructor, etc)
(3) Code from the code editor which will most likely be Event handler code.

The resulting form disk file would be a UTF-16 encoded file because all forms in WinFBE are unicode enabled.

Anyway, just some food for thought... I haven't decided yet if this is a good approach or not yet. It would certainly make the code editor portion of a form much less cluttered. Having all form related data in one disk file is also nice rather than having a separate file for form meta data, one for code, and another for code generation.

[raymw]

iirc, in visual studio, c#, you can see the gui generated code, but it is flagged with warnings not to alter it. But, I have altered it, in the past, but mainly to resize text boxes and the like. I think showing the code is useful, but I suggest the situation mentioned earlier, wrt the gui overriding the code needs addressing e.g. if there is a 'switch' to turn off some of the code, then the switch should be shown, and the 'turned off' code commented or greyed out, or not shown, whatever. But, imnsho, it would be better if the code/gui was two way - I mean, it is just a couple of different views of the same object.

I'm wondering, if the idea is to attract beginners, that maybe you adopt a sort of layered approach - hide away a lot of the more complex stuff. For example, going back to the button example, the basic attributes for a button are quite few, possibly only position, size, label, distinction between pressed and unpressed. All the other button properties could be on a separate page, say.

Part of the problem, is the richer feature list of free basic, it is going the same way as c++ and c, and it's losing much of it's attraction in the process.

[Paul Squires]

Thanks Ray, I appreciate your comments on this. I've been thinking that a compromise could also be to have a 3rd tab... Design/Code/CodeGen. The generated code boiler plate code would show there. I understand your point about having code/gui two way but frankly it is just way too hard to create a parser that will correctly evaluate all changes made to code to then have it reflected back in the gui itself. Not to say that it couldn't be done, but it would entail a massive effort and as you know, time is my enemy these days when it comes to coding

I can't say that I share your opinion about FB losing its attraction because of adding some C/C++ style features. Sorry Ray   For me, it makes the language a perfect blend between my comfort with old school BASIC and more powerful constructs in C/C++. I wish for more of it... templates, generics, etc.

[raymw]

Hi Paul, I thought you were using a sort of MVC, where the code to be compiled could be altered and viewed by the gui or the editor, just two different views of the same model. If you are not doing it like that, then maybe, as the gui can only edit/view the code it displays, then the editor should only edit/view the code it displays. That would eliminate the misleading editing the gui stuff in the editor, 'cos you wouldn't see it. If you have the third tab, showing all the generated code, I guess you'd better not allow altering anything in there, a viewer only.

[Paul Squires]

tried on another VM with same result, if I create a new project and place a button on the form and change the font from Segoe UI to Symbol and replace the Text of the button with down-arrow it show on the designer form but not when compiled, also the Font properties shows Symbol in Greek letters.
actually it shows the character but with 3 additional characters before.

This is actually a very important issue that you've raised and I am working on correcting things in the designer now. There are a number of things at play because the designer uses Unicode, the Scintilla editing control uses UTF-8, and then there is always the option the user will have ANSI files. Introducing the "down arrow" as a property value is allowing me to play out all of the different scenarios of producing code that will work in the designer and via generated code. I'm close to having it work for all scenarios. There is/was a big bug with saving CWSTR unicode text to UTF-16 unicode files but Jose cleared up that problem for me in another thread.

I have been struggling with this issue for two days. Too many conversion issues trying to allow unicode property values to exist for ANSI, UTF-8 and UTF-16 file encodings. I could never get the "down arrow" to correctly load from file for all file encoding types.

I have solved the problem by enforcing a rule whereby all WinFBE forms are created using UTF-16 file encoding. The user can not change this to the other formats. This is actually the best solution because WinFBE is UTF-16 for all of its internal workings and and it interfaces to the WinAPI using unicode. I can now easily set unicode text for properties and save/restore from file.

I am also now hiding code generation from the code editor. It makes sense because it is not supposed to be edited anyway and only clutters up the editor for no valuable purpose. It also introduced the additional complexity that the code generated had to be converted from UTF-16 to UTF-8 in order to display correctly in the Scintilla editing component.

[Paul Squires]

The attachment contains the latest 32 and 64 bit compiled versions of the WinFBE exe.

If you have created a form or project in a non-UTF16 encoding then the form will not load. Rather, all of the metadata and code generation will load into the code editor. You simply then need to change the file encoding to "UTF-16 (BOM)", and then save the file. Close WinFBE and restart it. Load the form or project and now the form should show.

[Johan Klassen]

thank you Paul
will test it this coming Sunday.

[Paul Squires]

Thanks Johan - you should download from the post above again because I had to re-upload it. I noticed that because I removed code generation from the code editor, the popup codetips would not work. I now parse the codegen string along with any code in the code editor. The codetips seem to work okay now.

[rainheart311]

hi,i have some problems when using WinFBE:1,chinese path is not supported,compile is error.i try to find the problem and change code like this:
   dim s1 as String = wszCommand
   dim s2 as String = wszParams
   RedirConsoleToFile( s1, s2, sConsoleText ) 
then it works.i guess cwstr and wstring to zsting in unicode has some problem
2, UTF-8 (BOM) is not friendly to Chinese support.
3, is it possible to add plug-in functions, like FBEdit?
4, whether the subdirectory can be classified into files in the project directory.
at last,Please forgive my poor English

[Paul Squires]

2, UTF-8 (BOM) is not friendly to Chinese support.

Did you try changing the codepage for the selected font to Chinese? See attached screenshot.

[José Roca]

UTF-8 and Windows aren't good friends. Using WinFBE, UTF16 is the way to go, and forget UTF-8 and code pages (maybe it will useful to remove this option). If I used it in my editor for PowerBasic was because that compiler doesn't allow to work with unicode source files.

Regarding RedirConsoleToFile, why are you using ZSTRING for the parameters?