I've had a few people email me regarding the development of WinFBE and how quiet it has gotten over the past couple of weeks. Just a quick update to let you know that I am still working on everything but at a little slower pace because this is the busiest time of year for my real world job. Every year at this time I slow down with programming but it usually only lasts around the Feb/Mar months. I should be back up to full speed again soon. In the meantime, I have been making modifications to WinFBE's visual designer and that is progressing well. The next WinFBE release will show off that new functionality at least for a handful of basic controls that WinFormsX supports so far.
good to hear from you Paul :)
I seldom make any posts but I follow your work and that of Jose Roca with interest and it's nice to see posts regarding your progress.
Been working on the visual designer portion of the editor. Have you ever run into a problem that bothers you so much that you can't sleep? :) Well, I have. Been encountering a random GPF on project close involving design forms and it's been hard pinpointing it. Time to break out the debugger and trace line by line. :)
...crisis averted. I can sleep now. :)
:D
Back to working on WinFBE. The busiest time of the year for my regular is now over. As discussed before, I am working on the visual designer. Just finished the code for saving the form and controls to disk file. Now need to write code to read that data back into WinFBE when a form file is loaded. I hope that my recent inactivity on the project will now be a thing of the past and this forum can start generating more discussions. Once again, if it wasn't for Jose's WinFBX library, creating WinFBE would be a much more laborious process.
Paul, I'm watching with bated breath. I enjoy seeing the solutions that you guys develop, and am always amazed at Jose's ability to churn out informative and very readable examples of the little trinkets he's developed and shared with the community.
Keep up the good work, it's very much appreciated.
I look forward to the release :)
Finally finished the coding for saving forms/controls and then loading/restoring them. I am very happy with the resulting code. It is simple and works great.
I need to work on the Property List now because it is pretty rudimentary at this point.
Just to let you guys that progress is being made... and should be much faster now that the busiest time of the year is behind me for my day job.
Thanks for the update, Paul.
I finally fixed some high DPI issues I was having with the visual designer. Thanks once again to Jose's WinFBX library. It is an essential tool for all FB programmers.
This week will see the first code generation for the visual designer. I will NOT be taking the approach that I used with FireFly. Instead, it will be kind of like the PB Forms approach where form code will be generated inline with other code. This will allow the user to have all code for a form in one disk file. The generated code will update whenever a change occurs in the visual designer and you either switch to the code editor for the form, save the form, or close the form. Once that code is implemented, I will post a version of WinFBE for you guys to see it in action and provide feedback.
Just to keep the updates coming... my first attempt at code generation as describe above has been very successful. Using the WinFormsX library for code output also reduces the amount of code that needs to be generated.
I'll update again when closer to releasing a test version for you to play with in order to get a feel for how the new system will work.
Why NOT the FireFly approach???
This is the way you teached us.
Quote from: Klaas Holland on April 24, 2018, 05:00:17 AM
Why NOT the FireFly approach???
This is the way you teached us.
:) Hi Klaas, to be honest there really is no longer a need to code output the way that Firefly does it. Firefly has to generate code for every form, callback procedure, and subclass. There is a lot of duplication, but it is needed for Firefly's approach. The new library has all of the code in one place so you just need to #Include the library. The program does not need to manually generate a lot of code that glues the application together. This makes the code generation much cleaner and easier for the user to follow.
The best part of the newer approach is that the user can see exactly how the code works. They will see the code that is used to create the form and all of the controls and also all of the events. It also gives the user flexibility to split the code up as much as they want. You could have all of the form code in one disk file or split the form generation code from the user entered code (stuff like code for the various events).
I personally don't think that the shift from the Firefly approach to the new approach will be hard for anyone. If anything, it will hide a little more of the winapi complexities from the user allowing you to code a little faster. Of course, once we try the new approach for a bit we'll soon see if it has merit or if we'll need to revert or change to something else. :)
Yes, I'm still working on the visual designer... ever so slowly :)
I have the Events code implemented in the Toolbox. Just now need to write the code that gets generated for each selected Event.
Attached is screenshot of how easy it will be to create and generate form/control Events.
Hang in there guys... we're getting there... eventually.
This weekend I *finally* tackled code that I had been procrastinating on for many weeks.... the PropertyList. The PropertyList needs to display several internal tools in order to get the property choice from the user. For example, a textbox to get text data, a combobox to get True/False choices or other lists, a Color picker, Font picker, Picture picker.... etc. I have all of the internal code finished that creates, assigns, and processes properties for forms and controls. I have the edit control and combobox pickers done. Next will be the color picker. Once the PropertyList is finally finished I plan to write the Menu Editor. That one should be easier.
Screenshot of the PropertyList is attached.
Hang in there guys... visual designer will be done as soon as I can.
....man, I'd forgotten how much work building a visual designer actually is! :D
Still working on the PropertyList.
It's looking good.
A couple of screenshots of the greatly enhanced ToolBox. The PropertyList is fully functional (except for Image/Icon selection).
Happy to present a couple more screenshots. This one shows the Label control displaying custom foreground and background colors; a standard system styled button control; and a non-themed styled button with custom colors and different font. The second screenshot shows the code generated that produces this form and controls. WinFBE only generates code for those properties where the property value is different than the default values (in order to prevent too much code bloat in the output).
This syntax will make VB guys very happy.
For coloured buttons and ownerdraw labels, I have a crazy idea to make them yet more colourful: to optionally use gradients. You will need entry fields for two TRIVERTEX structures with fields for Red, Green, Blue and Alpha and, when drawing the background color, instead of FillRect to call GrandietFill.
You will also need a field for the type of gradient: vertical or horizontal.
Hi Jose, I am modelling the code structure off of .net from Visual Studio 2017. I am looking at the C# syntax but this does also look very VB-like. Not sure about the gradients - that style seems very 5 years ago. I don't see many applications these days that make use of gradient themed buttons controls anymore.
Not sure if any help, but can't you use an image for all button colouring, gradients, tartans, tessellations and other patterns? Not sure how it works, never used button images, and I guess it would need more memory, but an image for normal, another for pressed for every button (and then you could create a nice graphics program to generate said images...).
Quote from: Paul Squires on July 04, 2018, 08:16:14 AM
Hi Jose, I am modelling the code structure off of .net from Visual Studio 2017. I am looking at the C# syntax but this does also look very VB-like. Not sure about the gradients - that style seems very 5 years ago. I don't see many applications these days that make use of gradient themed buttons controls anymore.
I personally don't like them. Maybe in a label, but for buttons I use a icon at most. Some think that an abundance of colors makes a gui more appealing, but I find them tacky.
Tacky. Exactly.
Windows seems to be moving towards a more clean, uncluttered, flat style.
My plan is to upload a test version of the editor package by Thursday, July 12 so you guys can see the direction that the visual designer is headed in and provide some feedback. I will include a small sample program showing the available buttons and some code that responds to events, etc. So far the controls available are Button, CheckBox, ListBox, Label and TextBox.
hello Paul Squires
will the visual designer work like VB?
my guess is probably not, but unless you are proficient in Windows SDK programming or are willing to spend 2 years in learning, it will not help people like me.
recently I had promised a friend to write a small GUI app and I wrote in VB6, had only briefly been exposed to VB about 20 years ago, it took me 2 weeks to learn and make the app, and that was spending maybe one hour a day (about 12 hours total)
I had a crazy thought, what if there was a cheat-sheet giving in two or four lines of code the different actions for basic controls, for example
how to get the text from a TextBox
how to set the text in a TextBox
how to select all the text in a TextBox when in focus, that is, the text is automatically selected when visited via Tab key
how to intercept the Shift and or Return keys
how to send a key to TextBox, for example, send Tab key when the return or enter key is pressed, also send shift-tab when shift-return or shift-enter is pressed.
Hi Johan, that is EXACTLY the type of help reference that I will write for this project. Basically a series of How to Do Things with each control rather than an endless list of properties, methods and events. The visual designer is working like VB - actually, like a hybrid of VB and Visual Studio C# and .Net. The idea is to abstract away as much of the Windows SDK programming as possible because the last 10 years has shown me that most users tend not to take the time to learn the nuts and bolts of WinAPI programming but rather higher level wrappers. At this point, not many of those methods/wrappers are written yet because I am concentrating on getting the actual controls basics to work first. Wrappers/methods are the easy part to write. For example, below I wrote the SelectNextControl method in about a minute and added it to the base control class.
Here is how it would work for your TextBox example (assume the TextBox is called txtAddress and is located on a form called frmMain):
(CWSTR is a dynamic unicode string class type from Jose's WinFBX library). The new visual designer is 100% unicode only.
- how to get the text from a TextBox
Dim As CWSTR wszAddress = frmMain.txtAddress.Text
- how to set the text in a TextBox
frmMain.txtAddress.Text = "This is my new address"
- how to select all the text in a TextBox when in focus, that is, the text is automatically selected when visited via Tab key
This is how the visual designer already works in the resulting produced compiled exe. As the textbox gains focus the text is highlighted. Likewise, when the code below is executed to simulate TAB, SHIFT+TAB, it also highlights the textbox text (if the textbox.MultiLine property is False).
- how to intercept the Shift and or Return keys
- how to send a key to TextBox, for example, send Tab key when the return or enter key is pressed, also send shift-tab when shift-return or shift-enter is pressed.
The following code works perfectly in the current code of the visual designer. I am still deciding how to handle trapping keyboard input. The code below cataches it in KeyUp but you can also catch it in KeyDown or KeyPress (which is WM_CHAR). I am thinking of routing all keys ultimately through KeyPress (ascii and virtual) so you have one method where you can reliably know you'll find all keypresses (I will see how .Net handles this kind of thing).
''
''
Function frmMain_txtAddress_KeyUp( ByRef sender As wfxTextBox, ByRef e As EventArgs) As LRESULT
' Catch the RETURN key to simulate TAB and Shift-TAB
' If you were wanting to test multiple textboxes controls (eg. a series of textboxes) then
' I would the following code in a dedicated function rather than duplicating it each time.
if e.KeyCode = VK_RETURN then
if e.Shift then
sender.SelectNextControl(false)
else
sender.SelectNextControl(true)
end if
e.Handled = true
END IF
Function = 0
End Function
Looks like I am already handling keyboard input very similarly to the way that .Net handles it:
Key events occur in the following order:
KeyDown
KeyPress
KeyUp
The KeyPress event is not raised by non-character keys other than space and backspace; however, the non-character keys do raise the KeyDown and KeyUp events.
Therefore to catch the ENTER key, need to use KeyDown or KeyUp. I chose to do it in KeyUp.
This is very similar to how the WinAPI handles keyboard input through messages like WM_KEYDOWN, WM_KEYUP, and WM_CHAR.
wow, I am excited :)
this is exactly what I was hoping for.
Thanks Johan, still a long way to go but the future looks promising.
:)
Quote from: Paul Squires on July 08, 2018, 07:25:59 PM
My plan is to upload a test version of the editor package by Thursday, July 12 so you guys can see the direction that the visual designer is headed in and provide some feedback. I will include a small sample program showing the available buttons and some code that responds to events, etc. So far the controls available are Button, CheckBox, ListBox, Label and TextBox.
OMG, I hate writing documentation. :)
Won't have the docs finished tonight so upload will have to wait.
thanks for the update :)
http://www.planetsquires.com/protect/forum/index.php?topic=4170.msg31834#new
thank you Paul :)
I gave it a test and found some issues
1. there's no apparent way to switch between the form view and code view
2. TextBox TextAlignment can't be changed from the default left to something else
3. if you try save a form-file with the same name as the project WinFBE closes without saving the file
but I managed without much effort to make a simple GUI app, thank you :)
Hi Johan,
#1, there is two easy ways. (1) Double click the tab (the top top with the filename in it), or (2) At the bottom of the screen there is another tab control with two tabs "Design", "Code". This is only available for those files created via top menu "Designer", "New Form".
#2, yup broken. I must have not wired the code that loads the drop down combobox with the choices.
#3, I can't duplicate that. I assume you save the form as <projectname>.bas and not <projectname>.wfbe, because obviously if you save it as <projectname>.wfbe then you have overwritten the project file.
thank you Paul :)
I can't believe I missed the design/code tabs, guess I should have consulted the help file :-[
regarding item 3, it's tricky to replicate.
At times there will be a random GPF when the compiled application ends. I noticed it happen more on Windows 7 than on Windows 10. I'll track down the cause of that but it certainly looks like a reference to a null pointer.
hello Paul
WinFBE exited again yesterday when trying to save a project, the project had already been saved before, I only wanted to save it again due to to changes.
today I tried to open the same project again, it took WinFBE about 5 minutes to open the project, I am not sure what the problem might be, is it Windows 10 hogging up the system or is WinFBE having a problem parsing the project files?
[edit]
after changing the names of the Buttons and saving the project and trying to compile, WinFBE exits, launch WinFBE again and try to load the project -- after four minutes of waiting WinFBE exits.
launch WinFBE again, load the project -- took five minutes -- all the button name changes are gone
Thanks for the update and the file... I will work on it now to see if I have the same results as you have seen.
Hi Johan
Quote from: Johan Klassen on July 17, 2018, 11:23:41 AM
hello Paul
WinFBE exited again yesterday when trying to save a project, the project had already been saved before, I only wanted to save it again due to to changes.
today I tried to open the same project again, it took WinFBE about 5 minutes to open the project, I am not sure what the problem might be, is it Windows 10 hogging up the system or is WinFBE having a problem parsing the project files?
[edit]
after changing the names of the Buttons and saving the project and trying to compile, WinFBE exits, launch WinFBE again and try to load the project -- after four minutes of waiting WinFBE exits.
launch WinFBE again, load the project -- took five minutes -- all the button name changes are gone
Hi Johan,
The incredible slow loading was the result of me using AfxStrParse to retrieve each individual line in the full edit buffer. I should have known this would be a problem because in my old FireFly visual designer code I had experienced the same problem with I used PB's PARSE statement. I modified the code to progressively scan the edit buffer from each found CR/LF and extract the line using that method. This is incredibly fast - code shown below:
' Iterate all of the lines related to the visual designer
dim as long iLineStart = 1
dim as long iLineEnd
do until iLineStart > len(sAllText)
iLineEnd = instr(iLineStart, sAllText, vbcrlf)
if iLineEnd = 0 then iLineEnd = len(sAllText) ' cr/lf not found
wst = mid(sAllText, iLineStart, iLineEnd - iLineStart)
iLineStart = iLineStart + len(wst) + len(vbcrlf)
...
...
I have attached a new 32-bit compiled version of the WinFBE32.exe for you to try. It seems to load your project (pretty cool looking calculator by the way) :)
Please let me know if it works for you or continues to crash.
Hi Paul
thank you for the new executable, it loads the project quickly but after making some changes to the project WinFBE exited for no apparent reason, but it worked a lot longer before crashing than the previous version.
a simple switch from form-view to code-view will trigger the crash
btw, save project does not seem to save but when compiling it saves the files.
Hi Johan,
Thanks for continuing to test the designer - greatly appreciated!
I think I have tracked down the source of the GPF. It appears to be when I used the CWSTR class method to convert the string to UTF. I changed it to a dedicated function call and it appears that the new approach worked. Here is the code that was changed.
' sReplaceText = sStartTag & vbcrlf & _
' wszText.Utf8 & _ ' Convert the unicode CWSTR to UTF-8
' sEndTag & vbcrlf
sReplaceText = sStartTag & vbcrlf & _
UnicodeToUtf8(wszText) & _ ' Convert the unicode CWSTR to UTF-8
sEndTag & vbcrlf
I also added code to the "Save Project" menu option to save all dirty code files. Previously, it simply saved the actual project file (*.wbfe) file itself.
Please let me know if the attached exe works for you.
Thanks,
thanks a million Paul :)
will let you know if there are any problems.
Paul, the new WinFBE32 won't generate code from the designer.
if you create a new project and a new designer file, place some controls on the form, there's no code generated.
Lol, oh my, yeah it sure will be hard to test if no code is generated! :D
I had commented out a couple of lines as I was testing for that GPF.
The attached 32-bit WinFBE should work. Sorry about that - sometimes I can be real dumb.
If the exe that I posted is okay then I will start adding the other controls and menu and toolbar editors. The core of the designer and generator is looking pretty good at this point.
Hi Paul :)
it appears OK, however try the following, on a button set the text to a character from the Symbol font, the character displays OK on the designer form but not when compiled.
Quote from: Johan Klassen on July 18, 2018, 08:16:10 PM
Hi Paul :)
it appears OK, however try the following, on a button set the text to a character from the Symbol font, the character displays OK on the designer form but not when compiled.
It seems to be working okay for me with my limited tests. Maybe you can send me a project showing the problem?
For me, the button text changes seem to be OK, but colors, although in the code, do not change in display.
For colors you need to set the ThemeSupport property to False.
maybe Windows is messed up, I will try it on another VM tomorrow and let you know.
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.
I see Symbol in Greek letters as well. How did you "...replace the Text of the button with down-arrow"
I used Character Map
in retrospect I should not have mentioned this issue, I apologize for diverting you attention from more important matters.
Quote from: Johan Klassen on July 18, 2018, 10:57:35 PM
I used Character Map
in retrospect I should not have mentioned this issue, I apologize for diverting you attention from more important matters.
:) This is an important issue. A person should be able to see in the designer and the resulting code, the exact same results.
I can see the problem exactly as you have described it. Now I need to find out why it works okay in the visual designer but not in the resulting compiled exe.
Hi Paul,
setting themesupport to false does the trick, but wrt your statement re. designer and code showing the exact same results, that is not quite true in this case, the constructor code shows colors (and does not show theme support). Also textmargin is not defined. I guess somewhere there is a list of what is and what is not yet implemented.
Quote from: raymw on July 19, 2018, 08:30:03 AM
Hi Paul,
setting themesupport to false does the trick, but wrt your statement re. designer and code showing the exact same results, that is not quite true in this case, the constructor code shows colors (and does not show theme support). Also textmargin is not defined. I guess somewhere there is a list of what is and what is not yet implemented.
Hi Ray - the constructor will output all properties where the property value differs from the default value. Because you set the colors, the values differ from the defaults so they get outputted. The default value for ThemeSupport is True so that does not get output to the constructor until it is set to False. You can see in the property descriptions in the Property List for each of the color properties that you need to set ThemeSupport to False in order for the colors to take effect. TextMargin does not do anything because I think that margin relates to the distance between the text and any image assigned to the button - images are not yet implemented.
Thanks for the explanation, but I think although it is logical, it is misleading, at least initially, and expect it may be worse later on. Sticking with pushing buttons, should there be a backcolordown for the button, as there is for the button text? (could easily end up with fifteen pages of parameters for a button, if not careful). I can't think of the situation where the text background color needs to be different to the button color for plain colored buttons, but I expect if the option wasn't there I'd think of one.
Having used firefly, will you be implementing the double click on an item in the visual designer generating a code stub?
Changing the button text, say, in the code is not reflected in the visual designer until you compile, (and then it seems not always) but changing the name in the toolbox immediately changes the text in the button gui, but not in the code, until compiled. It seems a change is needed in the button name in the toolbox, to over-ride the name shown in the code, and when the program is run.
The visual designer is not two way like PB's PBForms. The code is generated based on what settings and text you enter into the Property List.
Per the help file:
Quote
Code is generated between to comment labels. You should NEVER modify any code between these labels because WinFBE will regenerate code between the labels so whatever you add, change or modify will eventually be lost.
' WINFBE_CODEGEN_START
' WINFBE_CODEGEN_END
When you change the text in the Property List, the code will get updated when you switch from Design view to Code view. That is, the code between the two tags mentioned above will get regenerated. If you modify anything in the Constructor then that will simply get overwritten again when you switch back and forth between design and code view - anything you change in code does not get reflected back to the design form. If you must change text via code, then the best place to do that would be in the Form's Load event.
Quote from: Johan Klassen on July 18, 2018, 10:32:00 PM
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.
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.
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.
Quote from: raymw on July 19, 2018, 07:01:39 PM
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.
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.
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.
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.
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.
Quote from: Paul Squires on July 19, 2018, 04:28:49 PM
Quote from: Johan Klassen on July 18, 2018, 10:32:00 PM
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.
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.
thank you Paul :)
will test it this coming Sunday.
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.
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
Quote from: rainheart311 on July 21, 2018, 01:08:23 PM
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.
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?
So, your opinion would be to maybe remove UTF-8 altogether and just stick with ANSI and UTF-16?
If in WinFBE you choose Chinese Big 5 as the code page and you use
DIM cws AS CWSTR = "毛澤東"
and you save it as ansi, it will be saved as
DIM cws AS CWSTR = "¤ò¿AªF"
Then, to display it in Windows, you need to convert it to unicode specifying the correct code page:
AfxMsg AfxUcode(cws, 950)
where 950 is the code page for Chinese Big 5.
Therefore, if you use code pages, you must save the file as ansi.
Quote from: Paul Squires on July 21, 2018, 05:19:35 PM
So, your opinion would be to maybe remove UTF-8 altogether and just stick with ANSI and UTF-16?
I think so. Think about it:
If you save the file as UTF-8, to use it with Windows it must be converted to Unicode; therefore, it is more advantageous to save it directly to utf-16.
In the FreeBasic compilers for Windows, the native functions to read a file convert utf-8 string literals to WSTRINGs (utf-16 string literals don't need to be converted), but maybe the code that they use to do the conversion does not do a good job in all cases (if it does not work well with Chinese saving the file as utf-8 and it works if it is saved as utf-16 then this may be the case). An additional problem is that these functions don't work with unicode filenames.
If you treat the file as binary or use the Windows API functions or the C functions to read a file they won't convert utf-8 to unicode, so you will have to do the conversion. If it has been saved as unicode, no conversion is needed.
The only problem is the Scintilla control, that does not work with utf-16 but with utf-8. But for FreeBasic source code files there is not any need to save it as utf-8, since the compilers can work with utf-16 encoded source files.
I implemented code pages in the CSED editor for PowerBasic because this compiler only works with ansi source files.
So, I think that the only options needed are ansi and unicode. I can't see any need/advantage to save a FreeBasic source file using utf-8.
Thanks Jose, that certainly gives me reason to think and consider removing UTF-8. I can say the past couple of days spending countless hours dealing with situations in the editor where code has to loaded, saved, converted between ansi, utf8 and utf16. A huge pain in the butt. I also think that I will switch all my code to use winapi for file handling just to be safe.
The only thing that I can think of where someone might question is if they are using source code files between Windows and Linux in editors where they want to save as utf8 on both platforms.
Quote from: Paul Squires on July 21, 2018, 04:14:17 PM
Quote from: rainheart311 on July 21, 2018, 01:08:23 PM
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.
Yes, I've tried all of it. Although most of them are effective, there will be spaces in individual Chinese characters.like "复制",it will be "复 制",it is hard to change.
Hi Paul :)
if I create a new project and a designer form, place a ListBox and a Button on the form
check the Click event for the button and after compiling I delete the button from the form, the code for the button remains and if compiled and executed the button shows as it had not been deleted.
Paul
when setting a project BOM from ANSI to UTF-16 everything but the event code is in triplicate, for example
#include once "WinFormsX\WinFormsX.bi"
Declare Function Form1_Load( ByRef sender As wfxForm, ByRef e As EventArgs) As LRESULT
Declare Function Form1_Load( ByRef sender As wfxForm, ByRef e As EventArgs) As LRESULT
Declare Function Form1_Load( ByRef sender As wfxForm, ByRef e As EventArgs) As LRESULT
if you save a project and exit WinFBE and relaunch WinFBE and reload the project it will duplicate event code
Quote from: Johan Klassen on July 22, 2018, 01:40:25 AM
Hi Paul :)
if I create a new project and a designer form, place a ListBox and a Button on the form
check the Click event for the button and after compiling I delete the button from the form, the code for the button remains and if compiled and executed the button shows as it had not been deleted.
Thanks Johan - all fixed now. I set the file to dirty but omitted to set the code regeneration flag to true.
Quote from: Johan Klassen on July 22, 2018, 03:25:50 AM
if you save a project and exit WinFBE and relaunch WinFBE and reload the project it will duplicate event code
This one is now fixed also. Had to reparse the document code prior to checking for non-existent event handlers.
I am preparing a full package to upload to GitHub.
Hi Paul,
On my Windows 10 machine the following click sequence will crash WinFBE64.exe:
-Start program WinFBE
-Select sample project VisualDesigner
-Select tab frmLogin.inc
-Select tab Design
-Select Tools/Properties
-Select any control on the form.
Also crashes if the control is selected first and then the Properties tab is clicked.
Quote from: SeaVipe on July 22, 2018, 05:38:02 PM
Hi Paul,
On my Windows 10 machine the following click sequence will crash WinFBE64.exe:
-Start program WinFBE
-Select sample project VisualDesigner
-Select tab frmLogin.inc
-Select tab Design
-Select Tools/Properties
-Select any control on the form.
Also crashes if the control is selected first and then the Properties tab is clicked.
Thanks! Yes, that bug was reported over in the FreeBasic forum a couple of days ago. I fixed it for the 64 bit version (it did not show in the 32 bit version). I'm uploading a new package now.
Same for me, just the 64 bit.Thanks.
Thank you Paul :)