Form-Designer generates wrong code for String Gadgets?

[newtheogott]

String-Gadgets:
When using the Options "Text/Tooltips with variable", the Form-Designer in the latest PB Version generates invalid code here.

On compiling i get the error "Wrong Datatype" because he writes a "0" where it should be a String like "0" or better a Variable.

The generated Code may look like this:

Code: Select all

 FrameGadget(#Frame_1, 280, 10, 190, 380, "Page Margins")
  StringGadget(#Top_Margin, 290, 70, 150, 30, 0)
  StringGadget(#Left_Margin, 290, 160, 150, 30, 0)
  StringGadget(#Bottom_Margin, 290, 240, 150, 30, 0)

And the compiler does not like that he wants something like:

Code: Select all

  StringGadget(#Top_Margin, 290, 70, 150, 30, "0")

Or better like this:

SG_001.s="0"

Code: Select all

  StringGadget(#Top_Margin, 290, 70, 150, 30, SG_001)

I believe this is a bug because a VD should never generate invalid code that does not compile.
While the Editor is generally very good it lacks the Option to PRINT something on a Printer,
and also the Forms-Designer looks rather primitiv, compareds to for Example "Firefly" from PowerBasic or FreeBasic.
Or the Phoenix Visual Designer from PowerBasic, or not ta talk from Visual Studio or WinDev.

Which makes me wonder as there have already been some attempts there in the past to make good form Designers.

What happened with:
PureBasic IDE
or JopBe and PureFORM is also Dead ...

MK-Softs
http://www.purebasic.fr/german/viewtopic.php?t=12579
Seems also to be last updated 2014 .. does it still work?

I like PureBasic but it looks like People run away?
Is there somethign better around?
Anybody only using "SpiderBasic" ?

[ssb]

Purebasic form designer is garbage. Fred has to ditch it and concentrate on fixing some long lasting compiler bugs instead.

[IdeasVacuum]

The PB Form Designer might not be the best but it's free and perfectly adequate:
You Tube: The PureBasic 5.0 Form Designer - A Quick Tutorial

[newtheogott]

I found my "Usage mistake". I checked "Use Variables" and left the fields empty, so they got a "0" inside.
Anyway - whatever I do, it should never generated "invalid code".
Thats not "state-of-the-art".
Personally i come from PowerBasic, and i am recommend that you try "Firefly for Freebasic" so you see how a VD should work (and its even free).
Really - take the time and give it a try. You will see the difference.

Anyway the PureBasic VD is better then to "handmake" the GUI.
And its free included.

Just thought that its nearly 9 years ago that i was looking for PureBasic last time (have my licence for long time)
and so i wondered that there is no significant progress in the Visual Designer.
Even though there have always been some people who tried to do so.
I also took a look on "PureForm" which is commercial, but it seems also not to really make things easy "Like state-of-the-art" programms from elsewhere.

However - i had no compiler-errors this time and thats most important!
Also the Amount of libraries for all possible cases is impressive.

[mhs]

Purebasic form designer is garbage. Fred has to ditch it and concentrate on fixing some long lasting compiler bugs instead.

The form designer is not the best, but much better than its reputation.

[newtheogott]

New people really may get time to get into it.
The problem is that it does not really store the form data somewhere.
And then recreate the sourcecode from there.

Purebasic support so many Database formats.
He should store any control in such a format - wether an Textfile, or INI or whatever - and then work from there.
Its not reliable to work based on Sourcecode.

Any change in the sourcecode has unpredictable consequences.

Look what i got today ... its getting funny before i have a running form module.
HINT: Look at the Font-Enumeration (Ending)

Code: Select all

Global FRM_Main.l

Global CB_Type, Text_0, Combo_1, Text_0_Copy1, Combo_2, Text_0_Copy1_Copy1, CB_Teacher, BTN_Start

Enumeration FormGadget
  #Combo_3
  #BTN_Advanced
  #Edit_Num
EndEnumeration

Enumeration FormFont
  #Font_FRM_Main.l_0
  #Font_FRM_Main.l_1
  #Font_FRM_Main.l_2
  #Font_FRM_Main.l_3
  #Font_FRM_Main.l_4
EndEnumeration

LoadFont(#Font_FRM_Main.l_0,"Lucida Sans", 12)
LoadFont(#Font_FRM_Main.l_1,"Lucida Sans", 10)
LoadFont(#Font_FRM_Main.l_2,"Lucida Sans", 22)
LoadFont(#Font_FRM_Main.l_3,"Lucida Sans Ita", 16)
LoadFont(#Font_FRM_Main.l_4,"Lucida Sans", 16)

__________________________________________________
Quote tags>code tags
12.02.2016
RSBasic

[IdeasVacuum]

The issues you have shown thus-far are self inflicted, but of course the VD GUI could be more user-friendly and avoid some confusion. The underlying cause is being used to something that does the same job in a different way - I've been there and done that too. I posted the link to the movie because that does set straight some confusion.

A lot also depends on how you use the VD to contribute to your application build. Like me, a lot of people only use the VD to get the basic GUI design right. The lines of code for the enumerations and gadgets are copied-over into a .pb or .pbi file and manually tweaked from there.

Edit: Hang on Theo - I just checked-out the screenshots on the FireFly3 website. Their IDE + VD is very similar to PB's! The VD might be more polished but the difference does not appear to be drastic.

[Michael Vogel]

The form designer is a nice approach, but does not reach the (extreme high) quality of all other elements of Purebasic package (compiler, IDE etc.) - it should better be managed like other libraries.

For editing (and creating) dialogs, a simplier approach would be enough for me - look at this thread started by Stargåte and my demonstration code which changes gadget positions in the source code on the fly.

[newtheogott]

You are right, at the moment the Tool is somehow useful "to get a starting point".
But also this only IF you can code a lot of things manually.

I have already had to view a video to even start with the IDE to get something running.

Now in Firefly it is possible - and NORMAL that you can load your "Forms" any time change things.
And the complete code is perfectly regenerated to the new state, no matter if you remove controls, add controls ...
add or remove forms.

Firefly will update anything, even all the Event-Procedures!
In VS and WINDEV the program will even change Variable-Name globally in the code (but these are of xourse much more expensive).

But Firefly and Freebasic are even free, (yet FB does not have the many libraries from Purebasic).

In short, In Firefly (You can check the version for Freebasic- its even free!) you can do the complete "Lifecycle" of the product without leaving the forms designer. No Need to go into any other program.

Having said this, i completely agree, that Purebasic itself has reached a really good level - especially in its multiple libraries and possibilities.
And i did not yet have had any bug in the compiler itself in the last days.

Besides that a "second pass" is still missing - compared to any other product out there.
I still have to "DECLARE ..." Procedures, and even then the compiler is slower then - for example Powerbasic (which however is limited to 32 bit).
But is multi-Pass.

Another question ... what i did not yet try:

Code: Select all

FOR x.f=90.1 to 0.9 STEP -0.001 
...
NEXT

Does this actually work with Purebaisc ?
I remember that i tried this ten years before and it did not ... while this works with any other BASIC out there.

Of course, you can handcode such a loop, with a GOTO and and Subtraction.
But especially THEN the compiler should be able to generate this code.
As i see it, this is not difficult, something any compiler should be able to compile.

The Purebasic IDE has many advantage from the Primitive PowerBasic-IDE, yet its missing a PRINT Function.
Why? Purebasic has many easy to use PRINT-Libraries for example Vector-Print, its not so hard to use.

@Michael Vogel. I like your idea and have also copied yourcode.
However to sell the product and to have Beginners use Purebasic it is not usable.
There is no need to redevelope a wheel that is already round.
HOW does a "Visual Forms Designer work?"
That question is already answered. There are industry-wide standards.
If you want to attract people to come to your product stick to these standards.
THEN if you are better - make changes. NOT try to change it to save time.

[newtheogott]

From today ... Form Designer.

[19:05:14] [COMPILER] Zeile 45: Syntax-Fehler.
[19:05:49] [COMPILER] Zeile 42: Syntax-Fehler.
[19:05:58] [COMPILER] Zeile 45: Syntax-Fehler.
[19:07:29] [COMPILER] Zeile 40: Syntax-Fehler.
[19:08:01] [COMPILER] Zeile 40: Syntax-Fehler.
[19:08:31] [COMPILER] Zeile 40: Syntax-Fehler.
[21:07:08] Executable-Typ: Windows - x64 (64bit, Unicode)
[21:07:08] Executable gestartet.
[21:11:18] Die Programmausführung ist abgeschlossen.
[22:59:25] [COMPILER] Zeile 40: Syntax-Fehler.
[22:59:48] [COMPILER] Zeile 40: Syntax-Fehler.
[23:00:44] [COMPILER] Zeile 43: Syntax-Fehler.
[23:01:20] [COMPILER] Zeile 39: Syntax-Fehler.
[23:01:44] [COMPILER] Zeile 39: Syntax-Fehler.
[23:01:55] [COMPILER] Zeile 39: Syntax-Fehler.
[23:03:59] [COMPILER] Zeile 45: Syntax-Fehler.
[23:04:06] [COMPILER] Zeile 45: Syntax-Fehler.

The smallest change, and it starts again to produce buggy code.
And i do not even understand really what is wrong.

The error-Messages are not very helpful "Syntax Error in Line ...".
Somewhere else i get a detailed description whats wrong (
Undefined variable or whatever ...).

And i did not make this code, its generated from the Forms-Designer.
From my personal opinion this tool has a "Birth defect".

It should store the "architecture" of the Form not in the code, but somewhere else.
Like any other Forms-Designer does.

This way the programmer can touch the code and it will be regenerated.

I do not remember any VIsual Designer from Powerbaisc oder VIsual Studio or whatever that produced "SYNTAX ERROR" code.

Especially not as i am doing simple stuff here.
Just changing some options.

[IdeasVacuum]

We could help you Theo - but you have not shown us the code before and after. The Compiler's message of "Syntax Error" definitely does need to be improved, you are correct - after all, in order to flag the error, the fault is known. This was debated elsewhere on this forum and I think Fred and Freak want to enhance the Compiler with this regard.

The form's code does not have to be in "the same place" as the rest of the app's code. Save it as a .pbf file and Xinclude it into your Main code file (.pb). This way, you will not make any "manual" edits to the form code, you will always load it into the VD to make any edits. The form designer should not normally produce code with syntax errors, there most likely is a bug or two in there but it is in fact pretty robust. However, it is possible that you are doing something that the developer of the VD did not expect - haven't we all been suprised at some time or other by a customer using our app in an unexpected way?

[newtheogott]

Don't get me wrong. I like PureBasic and i am going to use it.
It a very good thing for the money that it costs.
It produces very good and efficient code and has a lot of features.
I was just wondering, why the Visual Designer is so much back behind the competition over so many years.

I see my problem. I am used to "load a form" into the VD and be able to change it.
Doing so will ruin the whole thing.

So what i need to do is, maybe
1. Use the Form Designer as a starting Point
2. Get the generated code into a normal .pbi-file (wher it can not be ruined anymore)
3. Don't use the Forms Designer for changes on the Form.

I had this thing already to compile ... then i changed it a bit and then runs wild.

I think i will get this done, but coming from elsewhere its a bit inconvenient.
Anyway, its a program that is included at no extra expenses.
Seen from that standpoint its Ok, better then to handcode the forms.

As said, i a now generating the form, make a ".pbi" out of this when its ready, this way it should work.

[Fred]

IMHO, you are not using it correctly, because if you do, it (almost) works the way expected. Please be sure to have read this topic: https://www.purebasic.com/documentation ... _form.html

1) each form (ie: each window) has to be in a separate ".pbf" file. This way you can load/change it at anytime. NEVER change the code inside these file !
2) use your own main.pb where you include all your forms and put the event procedure here. The main program look (WaitWindowEvent() has to be here as well.

It should work as long you respect the rules.

[TI-994A]

So what i need to do is, maybe
1. Use the Form Designer as a starting Point
2. Get the generated code into a normal .pbi-file (wher it can not be ruined anymore)
3. Don't use the Forms Designer for changes on the Form.

No; by doing so, you'd lose the main benefits of the form designer as a visual layout tool.

To do this, disable the Generate event loop option, and maintain all executable code, including the main event processing loop, in external code files. That way, the form file will purely contain form code that could easily be updated and modified by the form designer at any time.

In this short example (myForm.pbf), the form file is being used by two separate code files, myCode.pb and myCode_2.pb without any modification. Any additions or layout changes to the form file would not break it or its corresponding code file, so long as gadgets that are actively being referenced from external code are not removed or reassigned. But even so, if the removals or reassignments are tracked correctly and the corresponding codes modified accordingly, there should be no issues.

The power of the form designer should not be discounted so summarily; it is advertised as a visual layout tool, and it performs its intended functions superbly, and then some. The concept is clean, lightweight, portable, and very easy to implement.

Feature-rich is not necessarily better; take Xcode's Interface Builder, for example. Its automated code-control linking makes it a nightmare to update and maintain. One wrong change, and the entire project throws a fit. I personally avoid using IB at all costs, doing away with storyboards and xib files altogether, and creating my interfaces the PureBasic way; programmatically.

[newtheogott]

I think mainly this "use variable for ..." (Title, etc.) Option is what makes it generate strange code that does not compile.
I think it could be done in a way that the user must not decide this.
Idea .. what if it would automatically use variables and pack all the stuff inside a Module?
The the "newbie user" will not be even confronted with that option, and the advanced user generally has variables.

Yes i will need to take a closer look. I do not really remember how this was solved in older times.
PureBasic was one of the first tools that had an included VD, ten years before.

But i really wondered that there was no developement at this place for user-friendlyness.
At this time, you could go and download Freebasic and "Firefly for Freebasic" and you would have a more easy system for free.
Yet, i will stick with Purebasic because i like the lots of libraries and i already have a licence.
Also the compatibility with SpiderBasic for WEB-Applications is interesting.