PlanetSquires Forums

Support Forums => PlanetSquires Software => Topic started by: Paul Squires on September 19, 2022, 05:10:56 PM

Title: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Paul Squires on September 19, 2022, 05:10:56 PM
Hi everyone,

As promised, I will start working on the visual designer portion of WinFBE this week.

One thing that I am toying with is changing the file format for form files. Instead of having the form data intermixed with the code data, I am thinking of reverting back to the old style of separating both into their own files (I don't think that the added complexity of intermixing form/code data in same file was worth it). Basically, form files would have *.frm file names. I would also most likely change to using JSON format to save the data into those form files. I would have an automatic converter built into winFBE that would seamlessly transition to the new format.

If you folks have any strong opinions on this subject then please let me know.

Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: SeaVipe on September 19, 2022, 06:26:38 PM
 👍 
Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: philbar on September 20, 2022, 04:31:22 AM
IMO, it's a good idea--we'd be less likely to break something with an external editor. Still, never underestimate a user's ability to break things.
Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Bumblebee on September 21, 2022, 06:46:09 AM
Sounds good to me!

Can you explain why .bas files that define forms are UTF encoded?
Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Paul Squires on September 21, 2022, 09:43:34 AM
Form files are UTF-16 encoded to ensure that any unicode text entered in the visual designer Property List (eg. captions, text) by the user is properly saved to file. Under the hood, WinFBE does everything using unicode (UTF-16). If I used plain ANSI files then non-English users would not be able to fully utilize the visual designer. In the code editor, the user has the option to use whatever file format they desire and most people will never have to change from the default ANSI.
Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Paul Squires on September 21, 2022, 10:35:59 AM
To further expand on the unicode answer:

Currently, the form meta data is included in the same file as the actual user code. I thought that this approach would be beneficial because everything related to the form (code & design) would always be in the same file. Having both in the same file means that the form file MUST be unicode for reasons outlined in my previous post.

However, in practice, the co-mingling of form data and user code has resulted in unnecessary complexity that seems to outweigh any perceived benefits. That's why I am moving to separate the two in the new visual designer version.

The changes will see the form meta data stored in a UTF-8 encoded file (because UTF-8 is the JSON standard) and then the user code can be stored in whatever format the user decides (just like any other code file that they create). The only caveat is that the base filename must be the same for the form file and the code file. For example, Form1.frm and Form1.bas, or Form1.frm and Form1.bas


Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: philbar on September 21, 2022, 11:51:37 AM
I understood everything, right up to the "or" in the last sentence.

On a related note, I was always puzzled that the main.bas file is ANSI, while the form.inc file is UTF-16. You've sort of explained that now.
Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Paul Squires on September 21, 2022, 12:48:31 PM
Quote from: Paul Squires on September 21, 2022, 10:35:59 AMFor example, Form1.frm and Form1.bas, or Form1.frm and Form1.bas

I guess what I'm trying to say is that there still needs to be a way to relate the form(design) file to the form(code) file. Previously, everything was in one file so WinFBE knew exactly that the form code related to the user code in that same file. Breaking everything out to two files now entails the need to be able to logically link the two files so that WinFBE knows that a certain form file relates to a certain user code file.

In order to maintain the relationship between a form file and a user code file, I intend to link them by the filenames.

For example, if you are using *.inc for your user code then the form would be linked to it by the name:
Form1.frm
Form1.inc

If you are using *.bas for your user code then the form would be linked to it by the name:
Form1.frm
Form1.bas

Okay, I see my mistake now. I used Form1.bas for both user code filenames in my example in my original post. One should have been .inc and the second .bas. LOL  ;D

Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Paul Squires on September 23, 2022, 12:49:29 PM
Success. The form file format has not been successfully transitioned over to JSON format and is now separated into individual files for the code and design files. Seems to be working very well and simplifies the code immensely.

Next is to work on the implications that the new division of code/design has on the code generation.
Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Bumblebee on September 24, 2022, 08:24:52 PM
Is this a situation that leads to legacy support?
Older .bas files loaded into the new designer will have to be converted ;D
Title: Re: WinFBE Visual Designer - Sept 2022 upgrades
Post by: Paul Squires on September 25, 2022, 08:30:33 AM
Yes, older form files are automatically updated during the first run of your code in WinFBE version 3.02+

The process is very fast and simple. The existing form code is removed from the code file and converted to JSON and saved to a separate disk file. The existing code file is then saved back to file but, of course, now without the embedded form meta data.

The new form file is created with a *.design file extension.

For example,

code file: form1.bas
form file: form1.bas.design

code file: form1.inc
form file: form1.inc.design

The code generation is now working well for all situations. Non-project, Project, or QuickRun.