Minimising the role of .PBF form files

[Oso]

Simply written: Never use numbers, always use predefined constants or like here enumerations.
Disadvantage: You have to write more code. In larger applications, however, this will be worthwhile. Especially because there are not so many errors caused by wrong numbers.

Code: Select all

 
  Repeat
    Select WaitWindowEvent() 
      Case #PB_Event_CloseWindow   ; deal with the events here or use BindEvent() 
        Break  ; exit the main loop 
      Case #PB_Event_Gadget  
        Select EventGadget()
          Case #GADGET_StrInput 
            Select EventType() 
              Case #PB_EventType_Change          :Debug "Change"         ; The text has been modified by the user. 
              Case #PB_EventType_Focus           :Debug "Focus"          ; The StringGadget got the focus.              
              Case #PB_EventType_LostFocus       :Debug "LostFocus"      ; The StringGadget lost the focus.
          Case #GADGET_BtnClickMe 
            Debug "Click on ClickMe Button" 
          EndSelect 
      EndSelect
    EndSelect 
  ForEver 
EndIf 

Thanks for the example. Yes, I think the enumerations are better. Incidentally, clicking #GADGET_BtnClickMe only detects the loss of focus. Your message Debug "Click on ClickMe Button" doesn't appear to be executed. I just mention this for the benefit of anyone taking a look at this.

It works if you move your first EndSelect up by two lines. I guess that's what was intended anyway.

Click in the string box - Focus
Press 1 - Change
Press 2 - Change
Press 3 - Change
Click button - LostFocus

[Oso]

Already posted many times Basis for a program

I think it's great if most of your code falls into a skeleton framework like this, sure.

This leads me to a much broader question I have regarding PB. So far, I've created small standalone executables, utilities and so on, but how do we structure a sizable application that consists of what we might refer to as traditional menu choices?

Much of my own career has been centered around accounting, order processing and business applications. These systems consist of many routines, wrapped inside a menu structure (icons or options). Traditionally there are three crucial steps...

1. A login prompt for entering the user's name and password (the application then retains this information throughout the login session to determine access rights).
2. A menu system that can be navigated (sales ledger, purchase ledger, customer master file, supplier master file, invoice entry and so on).
3. Those individual programmes, as bracketed above. So in other words every menu choice has an equivalent routine which operates entirely separately from other routines. When a programme is terminated, the user is returned to the menu.

In the environment I'm used to, which is primarily a database, all those individual menu choices will almost always be a programme in its own right. The menu calls each programme. For example, menu option 'x' calls the customer master file maintenance screen and 'y' invokes an option to print invoices.

In a PB scenario, what are we looking at there? Are we looking at the menu calling other compiled routines, or how is this best achieved? I appreciate there are many answers to this question, but for the purposes of keeping things simple, what is a convenient way to approach it?

[mk-soft]

I don't know what the problem is.
We have only shown you how the event management of PB must look like. THERE IS ALWAYS ONLY ONE EVENT LOOP. The PB command 'WaitWindowEvent' is the interface from the user action to your program.
From here on you have to evaluate and call everything you create on the surface of your GUI. This includes opening and closing various windows that belong to your program. Trigger functions, enable and lock menus and windows, etc.

Usually you create one MainForm.pbf and several DialogForm.pbf. The DialogForm are then opened from the MainForm. THE EVENTS FROM THE DIALOG FORM ARE ALSO EVALUATED IN THE MAIN PROGRAMME AND DO NOT HAVE THEIR OWN EVENT LOOP. Otherwise you will lose the events for the main form.

There are different methods of processing events. Calling subroutines after the WaitWindowEvent to evaluate the event or linking the events with 'BindEvent' or 'BindGadgetEvent'.

In my EventDesigner I use the method BindEvent and virtual tables for the event procedures. (This only works with constants of the windows, menu and gadget objects with consecutive numbering - enumeration).

[mk-soft]

Link PureBasic Form Designer Tutorial 2022

[Oso]

Usually you create one MainForm.pbf and several DialogForm.pbf. The DialogForm are then opened from the MainForm. THE EVENTS FROM THE DIALOG FORM ARE ALSO EVALUATED IN THE MAIN PROGRAMME AND DO NOT HAVE THEIR OWN EVENT LOOP. Otherwise you will lose the events for the main form.

Thanks @mk-soft I really appreciate the extra detail on this. I'm kind of at this stage where I know a little about how it hangs together, but not the finer detail. I just wish I had more time available to devote to PureBasic I guess others find with PB that it's very addictive once you start.

Thanks for the link to the video, I see that it's 'hot off the press'. Thanks go to @TI-994A for putting that together, it's great.

[Axolotl]

... It works if you move your first EndSelect up by two lines. I guess that's what was intended anyway. ...

@Oso: yes, you are right. I corrected my example.
I hope it has become clear that this is only a basic framework. It shows how the basic structure of a program should be.
Of course, many things can be done differently, but as the above examples show, it is already best practice.

[Oso]

@Oso: yes, you are right. I corrected my example. I hope it has become clear that this is only a basic framework. It shows how the basic structure of a program should be. Of course, many things can be done differently, but as the above examples show, it is already best practice.

Thanks @Axolotl yes it's clear and I can see that the event loop is a fundamental construct.

A quick question on calling other routines - can PB routines call other PB executables (i.e. other EXEs) and return control back to the calling routine on their completion? For instance, say that we had a drop-down menu and one of the options called another EXE. I presume PB can run a shell command, but is that possible to call another EXE that creates a window, and on termination, passes control back to the caller?

The question is related to what I was asking yesterday, in that I tend to develop applications that consist of many screens, reports, batch processes etc. and putting them all into one routine probably isn't the ideal way, as there are so many of them.

[jacdelad]

RunProgram(...)

[Marc56us]

If you make your program in several EXEs, the main loop will only be able to launch the other EXEs but will not be able to manage the events of the other windows (unless you use SendMessage_ but it becomes quickly unmanageable)
Forget the "DOS" methods, code in a multi-window way: A single loop, and procedures. Not autonomous programs.

[Oso]

Forget the "DOS" methods, code in a multi-window way: A single loop, and procedures. Not autonomous programs.

Yeah, I agree, it isn't really ideal in the modern context. We're going to have a fairly big .EXE file, but I suppose that's normal anyway. Thanks for the advice, it's important to follow the best practice.

Is the usual accepted approach to put the code logic for each window into its own file and then 'xincludefile' it, or is there another way?

@jacdelad thanks for RunProgram() at least we've got something there for the outlying cases where we have a good reason for making it separate.

[Axolotl]

Hey Oso,
as an old colleague once said to me, anything is possible with software.
Seriously: My recommendations and thoughts about it:
Does it make sense to split it between different programs?
Yes, if the called program is standalone and has no significant interaction with the "caller program".
Maybe, if you can do the communication with SendMessage() and WM_COPYDATA or with TCP/UDP messages.
Note: The overhead must be worth it for some reason.
No, if you write all the programs yourself, it doesn't make sense.
If you need extensibility of the program, then you can think about add-on functionality.

Alternative to consider: Splitting functionality into DLLs.
Here the functionality is taken over in the same process. With separate programs there are always different processes, over whose boundary to communicate is at a very high level.

Before you plan something "big" like this, you should create a proper concept.
Thereby not only the creation but also the maintenance over years (if that is the plan) should be considered.

You can also create many windows in PB and call them on occasion. This functionality can be divided into individual source code files, etc.

Is the usual accepted approach to put the code logic for each window into its own file and then 'xincludefile' it, or is there another way?

Yes, from my point of view this is the best approach. Combine all codes in a <main>.pb by xincludefile. You can also call xincludefile from other "includefiles", but that becomes really confusing at some point.
Maybe you should take a look at the PROJECT options. I never use that, but it is an option.

Happy coding and stay health.

[Oso]

as an old colleague once said to me, anything is possible with software.
Does it make sense to split it between different programs?
Yes, if the called program is standalone and has no significant interaction with the "caller program".
Maybe, if you can do the communication with SendMessage() and WM_COPYDATA or with TCP/UDP messages.
No, if you write all the programs yourself, it doesn't make sense.

Yes, very true words, I've often thought that way myself, given the power that we have in languages. It's easy to just sit down and start coding, then fix the resulting problems with workarounds later on It seems more important to me now, to design correctly, but a few years ago it didn't always seem so.

The answer to those three choices is that there isn't really much interaction between, say, a menu system of icons, and the software modules that they call. For instance, we might have menu choices. Those choices are really quite independent. Once the sales invoicing module has been opened, it doesn't need to interact with the purchasing. Even so, I've quickly reached the conclusion here that the way to do it, is to wrap the entire system around a main routine, as @Marc56us has suggested and I think that's probably what others would do.

To give an example, the ubiquitous Sage accounts software, this is a well known package that consists of various modules. In the first screenshot it shows the main screen. We might regard this as traditional menu choices. Ignore the red box - it was just a screenshot I found online. The second screen shows the invoicing module, which was one of the choices from the first screen. I don't use Sage but I'm guessing it's a sub-window.

Yes, from my point of view this is the best approach. Combine all codes in a <main>.pb by xincludefile. You can also call xincludefile from other "includefiles", but that becomes really confusing at some point.

I'm leaning towards this, creating includes that contain the procedures for each window. I guess this is going to mean that the entire system consists of a lot of procedures in one code-set. They are held in separate .pbi files, but at compile time I assume they are all lumped together?

[Axolotl]

I'm leaning towards this, creating includes that contain the procedures for each window. I guess this is going to mean that the entire system consists of a lot of procedures in one code-set. They are held in separate .pbi files, but at compile time I assume they are all lumped together?

Yes, you got it.