The PowerBASIC Forms generated code may be edited freely, but in order to preserve the ability to reopen the files in PowerBASIC Forms, editing and additions should be limited to code that is not within a named block.
If a project contains multiple dialogs, PowerBASIC Forms initially generates the source code so that the project's dialogs are launched in sequential order. This is usually acceptable for proof-of-concept testing, however, few real-world applications are likely to function this way. Therefore, in this chapter we describe how to customize code in a new project to create a basic parent and child dialog relationship between two or more MODAL dialogs.
By way of example, lets assume that we have created a new project consisting of three dialogs (DIALOG1, DIALOG2, and DIALOG3), and each of the dialogs contains an arbitrary selection of child controls. In addition to those controls, we have also added a Button control captioned "Process Data" to DIALOG1, and we'll give it the ID Name %IDC_PROCESSDATA. Note that the Button's actual ID Value is not particularly relevant in this example, although it must still be unique among the controls in DIALOG1.
If we were to examine the source code that was initially generated for this project by PowerBASIC Forms, we should find it contains a PBMAIN function looks something like this:
FUNCTION PBMAIN()
...
ShowDIALOG1 %HWND_DESKTOP
ShowDIALOG2 %HWND_DESKTOP
ShowDIALOG3 %HWND_DESKTOP
...
END FUNCTION
As this code stands, the PBMAIN code will successively launch the three dialogs as it runs: When the app starts, PBMAIN calls ShowDIALOG1 and that launches DIALOG1. When the user closer that first dialog, the PBMAIN code continues and launches DIALOG2, and so on. In all three cases, the parent window of each MODAL dialog has been specified as the desktop window (%HWND_DESKTOP).
While this program will run, the problem with this design is that it is not possible to see more than one dialog at a time because the current dialog must be closed before the next one can be displayed. For example, let's imagine that the main dialog is being used to display a customer record. It would make no sense if that dialog had to be closed before we could display a "Delete record?" confirmation dialog because the user would not be able to see which record is to be deleted!
Therefore, the weakness of an application that successively launches dialogs is that the context of the current dialog could depend on the content of the previous dialog. Obviously, it would be a significant improvement in the application design if the main dialog could remain visible while the confirmation dialog was displayed.
The good news is that we can achieve this result by making a couple of minor changes to the generated code! Going back to our three-dialog project we described earlier, let's say that we want to display the second dialog (DIALOG2) when the user clicks the "Process Data" Button on the first dialog (DIALOG1).
This change in the DIALOG1 Callback Function would then look like this:
CASE %WM_COMMAND
SELECT CASE CBCTL
CASE %IDC_PROCESSDATA
IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
ShowDIALOG2 %HWND_DESKTOP
END IF
CASE ...
END SELECT
One further change is necessary to complete the parent/child relationship between DIALOG1 and DIALOG2 - the %HWND_DESKTOP parameter needs to be replaced with the handle of DIALOG1, otherwise DIALOG2 will continue to use the desktop window as its parent.
If that was allowed to occur, the user could continue to interact with DIALOG1 even when DIALOG2 was displayed. However, this code is using MODAL dialogs, so the parent dialog is automatically disabled until the modal dialog is closed.
Since the child dialog (DIALOG2) is being launched from within the Callback of DIALOG1, we can completely avoid using global variables to track the handle of DIALOG1 because the DDT Callback Function automatically provides the handle in the DDT system variable CBHNDL. Therefore, we simply need to substitute CBHNDL for %HWND_DESKTOP. For example:
...
IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
ShowDIALOG2 CBHNDL
END IF
...
Similar changes should be applied to all other child dialogs in the project file.
From this point, the computational/functional code can begin to be added to the code framework. If the guidelines above for placing new code are followed, the project can be reopened in PowerBASIC Forms for further GUI design changes. This is discussed in-depth in the next topic, Opening existing PowerBASIC Forms code.
See Also
Handling new vs. existing files