Tutorial: events handling with the Form Designer

[Fred]

This 'create event loop" flag will be removed in the next PB version as it's not useful but very confusing. It should be always uncheked to use the form designer properly.

[TI-994A]

...i have to disable the "create Event Loop" in the Form Designer and do that manually in an include file, then i can write my Form-initialization just in front of that.

Yes. The preferred approach would be to disable the Generate event loop option altogether; just as Fred has said in the preceding post.

The form file would then contain purely form code, while all executable code would reside in external code files, including the main event processing loop.

[newtheogott]

I would really like a system, where the Form Designer generates all the code.
Including all the Event-Procedures. This is normally the Standard.

Thats only possible, if all the Form-Data is stored in a separate file (such files are known from VB).
Then the Form Designer can always "regenerate" the code from this file.
No matter what changes the user did in the code.

As a help, the Form-Designer could use comments in the code-file to find each item-line.
For example:

Code: Select all

;###FD:Gadget 021 Begin
... (Code that was generated)
;###FD:Gadget 021 End

And between these blocks the user could do what he wants.

Otherwise "Newbies" like me will not be able to make a usable form without first studying the manual.
And - in case of many buttons - have a lot of typing work that could easily be automated by somebody who really knows how to use the underlying system.

[falsam]

This 'create event loop" flag will be removed in the next PB version as it's not useful but very confusing. It should be always uncheked to use the form designer properly.

100% agree.

[Marc56us]

If I do not use the IncludeFile statement, ...

... then you can't use form designer

Look here (at bottom) « Using the form designer in real world projects »
https://www.purebasic.com/documentation ... _form.html

PS. A very good option of the form designer is the Image manager
Check Catch Image and Relative path and the FD write all the complicated code for including images



('create event loop' flag (checkbock) is removed since 5.50)

[Mindphazer]

Check Catch Image and Relative path and the FD write all the complicated code for including images

100% agree

[bfernhout]

Hei.

Almost 10 years later. But for me its pretty new. I did user Pure Basic already more then 10 years. But more to give students a handle to learn programming. And always i did it in PB itself. And never used the from designer.

Now i want to use the forms to start a program to make a tile editor for level designing. All the level editors I found had some shortcoming. Tile Studio use XML and that i can handle. But not the way the program is working. Many time its lockout some functions without any reason. Or frees up completely. To find out it make a call error because it lost a handler.

This has nothing to do what you give as a tutorial. Cause that one is very good. There is only one thing is miss at the end at the reaction list. to newtheogott you explained that the file has to be in the same folder as the program. That's correct. Than I found that there is nothing about the event procedure. But the events is also in the resource code. And this part is overwritten by PB every time. When the event has to be handled this part calls or execute a piece of program it's inserted manually. As soon as PB form designer is opened all the code is removed. This is not desirable.

What is do is creating the form. When I am happy I save it. And make a backup of the form in the work folder backup folder. Then I copy the PBF itself and rename the file to a PBI file. In that file I adjust some tings. E.g. The event handling and some items that are opened with gadgets where some gadgets are to hide of not opened at all. This is working perfect for me.

That's all. Again i did love the way you explain the use of forms. It did do al lot for me and give me more time to program and not searching for why or how.

[TI-994A]

... This has nothing to do what you give as a tutorial. Cause that one is very good. There is only one thing is miss at the end at the reaction list. to newtheogott you explained that the file has to be in the same folder as the program. That's correct. Than I found that there is nothing about the event procedure. But the events is also in the resource code. And this part is overwritten by PB every time. When the event has to be handled this part calls or execute a piece of program it's inserted manually. As soon as PB form designer is opened all the code is removed. This is not desirable. ...

Hi @bfernhout, and thank you for your kind words. Since this tutorial was posted, the mechanics of the form designer had changed quite a bit. I had also created some videos on the use of the form designer, and this is the latest one from 2022:

> PureBasic Form Designer Tutorial 2022

It does explain briefly about the requirements for event handling (around 11:30 and again around 13:30), and that the event procedures have to be contained in a separate file.

However, the code and form files do not have to reside in the same folder, as long as the code file is able to locate the form file with proper path declarations.

For example, if both the code and form files reside in the same folder, this would be sufficient:

Code: Select all

XIncludeFile "MyForm.pbf"

But if they are not in the same folder, the absolute path to the form file must be expressly provided in the include declaration, like so:

Code: Select all

XIncludeFile "C:\Users\UserName\Documents\Code\PureBasicForms\MyForm.pbf"

This is also indicated in this tutorial, under the Using PureBasic Forms section, point #11.

[Fangbeast]

TI-994A, your tutorials and help make your blood worth bottling. However, keep the blood where it is or you won't be able to do more!!

/me falls off the chair laughing

[TI-994A]

.../me falls off the chair laughing

Hi Miki! Trust you are well.

You always crack me up, my friend.

But be careful falling off chairs - we "Fortran-folks" can't afford to crack anything else!

[Fangbeast]

I'll reply privately:):)

[bfernhout]

Thanks for the replay.

I did look at your video. And it does look very good. But there was one tiny glitch. When saving a file you can click on the save file icon but you can not press F5 to save the file. But this is a tiny glitch.

When a file is saved and keep the extension PBF. the file still had the option to turn to the form editor. And the events in that file can't be programmed for use. That is my experience. I must rename the file to PB or PBI. When the file has the new extension it can be edit. What you can do, if you are not sure of the changes you made,I have added this code at the bottom of the IDE script.

Code: Select all

OpenWindow_Your_Creater_Screen()

Repeat
  event = WaitWindowEvent()
Until Window_Your_Creater_Screen_Events(event) = #False

End

This will show you the screen you already have made. End when you made an error it will show up.

Slowly i start understanding the concept of creating gadgets and changing gadgets. Its nice to see that PB have so much things to use in the form designing and alter the way a gadget behave when the code is changes to it.
But your tutorial had give me a good starting point to learn the basics.

Bart Fernhout.

[TI-994A]

... there was one tiny glitch. When saving a file you can click on the save file icon but you can not press F5 to save the file. ...

Wow! I totally didn't catch that mistake. It was meant to be Ctlr+S / Cmd+S.

Apparently, during video editing, I had re-used one of the text blocks, namely the one to execute a RUN command, but I must have forgotten to change the text in the third line.

Thanks for pointing that out. I'll try to upload a correction soon.

... When a file is saved and keep the extension PBF. the file still had the option to turn to the form editor. And the events in that file can't be programmed for use. ...

This is done by design. Forms are meant to be standalone objects which are created and managed exclusively by the Form Designer. Any manual amendments or additions to the form file code will be purged.

Programs should utilise these .PBF form files as objects by including them with the XIncludeFile function. The events of the forms should then be handled by the hosting program according to the event-procedure parameters specified in the form designer. Please allow me to demonstrate this.

Here is the default code generated by the Form Designer before any form specifications are changed and before any gadgets are added:

Code: Select all

Global Window_0

Procedure OpenWindow_0(x = 0, y = 0, width = 600, height = 400)
  Window_0 = OpenWindow(#PB_Any, x, y, width, height, "", #PB_Window_SystemMenu)
EndProcedure

Now, in the properties window of the Form Designer, select the Generate events procedure? option, like so:



The form code should now look like this, with the additional Window_0_Events() procedure:

Code: Select all

Global Window_0


Procedure OpenWindow_0(x = 0, y = 0, width = 600, height = 400)
  Window_0 = OpenWindow(#PB_Any, x, y, width, height, "", #PB_Window_SystemMenu)
EndProcedure

Procedure Window_0_Events(event)
  Select event
    Case #PB_Event_CloseWindow
      ProcedureReturn #False

    Case #PB_Event_Menu
      Select EventMenu()
      EndSelect

    Case #PB_Event_Gadget
      Select EventGadget()
      EndSelect
  EndSelect
  ProcedureReturn #True
EndProcedure

Next, let's add a single button to the form and set these two properties for it:



Now, the form code includes:
1. the declaration of the new button gadget captioned as "BUTTON" in OpenWindow_0()
2. the call to a procedure named buttonHandler() in Window_0_Events() for handling the button gadget

Code: Select all

Global Window_0

Global Button_0

Declare buttonHandler(EventType)

Procedure OpenWindow_0(x = 0, y = 0, width = 600, height = 400)
  Window_0 = OpenWindow(#PB_Any, x, y, width, height, "", #PB_Window_SystemMenu)
  Button_0 = ButtonGadget(#PB_Any, 10, 10, 100, 25, "BUTTON")
EndProcedure

Procedure Window_0_Events(event)
  Select event
    Case #PB_Event_CloseWindow
      ProcedureReturn #False

    Case #PB_Event_Menu
      Select EventMenu()
      EndSelect

    Case #PB_Event_Gadget
      Select EventGadget()
        Case Button_0
          buttonHandler(EventType())          
      EndSelect
  EndSelect
  ProcedureReturn #True
EndProcedure

Save the above form file as myForm.pbf, and create the following code file:

Code: Select all

XIncludeFile "myForm.pbf"

OpenWindow_0()

; the procedure to handle the button as specified in the form
Procedure buttonHandler(eType)
  Debug "Button Clicked!"
EndProcedure

Repeat 
  ; relay all the events to the form
  If Window_0_Events(WaitWindowEvent()) = #False : Break : EndIf
ForEver

Finally, SAVE THE CODE FILE IN THE SAME FOLDER AS THE FORM FILE (the code file name is not important here), and run it.

The code file relays all the events to the form file, and the form file responds and routes the events as specified. In this example:
1. the form file returns a FALSE value when it receives the close-window event (default behaviour), causing the program to end.
2. the form file routes execution to the buttonHandler() procedure when it receives the button gadget event.


Very simple! The code in the form file remains modular and unchanged, and all programming logic resides within the code file. The form file can be continuously updated and modified within the Form Designer without affecting the code logic, as long as any changes to the event logic are updated in the code file accordingly.

I hope this clarifies the matter.

[bfernhout]

WOW TI-994A
I neven look that at that way. But its work i try it.
Thanks for this. That is the short comming in the manual.
I did found BindEvent and that is working to.

Code: Select all

BindEvent(#PB_Event_SizeWindow,@Resize_All())

This piece of code called the procedure Resize_All() (I did wrote it myself) To update the screen live at changing the size of it.

Its beautiful how all thing come together.

Thanks.