Chris
Thanks for taking my suggestion about using this forum for non-standard uses of EZGUI.
As you know, we use our own Data Dictionary software to generate program code - it's a sort of Designer++. Not only does it generate GUI code and things like include files for common functions, but it also creates a large percentage of the application code too. Most programs have 80% generated code, and some even have 100%. For example, the nucleus of the Data Dictionary package consists of about 50,000 lines of handwritten Power Basic code that does the actual code generation. The database portion of the Data Dictionary contains the program specs of the different packages that we produce. The Data Dictionary generates itself in the form of an EXE and about 80 DLLs - about 400,000 lines of code.
The generated code is much the same as someone would code without benefit of OOP. It gets the job done, but requires a lot of housekeeping code to keep track of everything. So, when PB introduced classes and other OOP features into the language, we began looking into re-writing the Data Dictionary to generate code that makes heavy use of OOP techniques. Not just for the GUI, but for all aspects of the code. As a result, we figure that we can reduce the amount of generated code by at least 60%, possibly more.
We're beginning with the GUI - and that's where EZGUI comes into the picture. What we're doing is creating classes for the various types of forms and controls that we use, and embedding the EZGUI code into them. The generated application code won't actually contain any EZGUI statements. All the action takes place under the hood.
Here's a working example of what our code will look like. I've removed a lot of comments and code to make it easier to read.
'===============================================
'
' pkgDVS00DD.bas
'
'===============================================
'
' This is the main form for the DVS Data Dictionary package.
'
'===============================================
'
' Power Basic compiler directives:
'
#Compile Exe "dvs00dd.exe" ' create an exe file
#Compiler Pbwin 10 ' Power Basic version 10
#Debug Error Off ' certain errors trapped only when executing via the debugger
#Dim All ' all data must be explicitly declared
#Option Version5 ' executable file requires a minimum of WinXP
#Register Default ' use default register allocations
#Stack 4194304 ' 4 Mb maximum stack size
#Tools Off ' disable integrated development tools
'
'===============================================
'
' Include Files
'
'-----------------------------------------------
'
' primary equates, structures, and third party software
'
#Include "H:\DvsData\DVS\PB\modConstant.bi" ' Global Constants
#Include "H:\DvsData\DVS\PB\modUdt.bi" ' Global Structures
#Include "H:\DvsData\DVS\PB\include\ezgui50.bi" ' EZGUI 5 Declares Include File
#Include "H:\DvsData\DVS\PB\include\ezwmain50.bi" ' EZGUI 5 Winmain Include File
'
' classes
'
#Include "H:\DvsData\DVS\PB\clsApplication.bi" ' Application Class
#Include "H:\DvsData\DVS\PB\clsPanel.bi" ' Panel Class
'
'===============================================
'
' EZGUI procedures
'
'===============================================
'
Sub EZ_Main(ByRef briEzVerNum As Long)
Dim proApp As Global objApplication ' application object
proApp = Class "clsApplication"
Dim proMainForm As Global objPanel ' application form
proMainForm = Class "clsPanel"
proApp.exiAppStyle = %iAPP_STYLE_SPLITTER
proApp.exiLeftPanelPercent = 20
proMainForm.exoAppRoot = proApp
proMainForm.exsPanelName = "MainForm"
proMainForm.exiBackgroundColour = %iCOLOUR_EZ_WHITE
proMainForm.exiForegroundColour = %iCOLOUR_EZ_BLACK
proMainForm.exsCaption = "DVS Data Dictionary"
proMainForm.exiStartLocation = %iPANEL_LOCATION_CENTRE
proMainForm.exgEzWidth = 1280
proMainForm.exgEzHeight = 800
proMainForm.exiPanelStyle = %iPANEL_STYLE_APP
proMainForm.exvCPtrDesign = CodePtr(subMainFormDesign)
proMainForm.exvCPtrStart = CodePtr(subMainFormStart)
proMainForm.exvCPtrStop = CodePtr(subMainFormStop)
proApp.subAttachPanel(proMainForm)
End Sub
'
'===============================================
'
Sub EZ_DesignWindow(ByRef brsEzForm As String)
proApp.subDesign(brsEzForm)
End Sub
'
'===============================================
'
Sub EZ_Events(ByRef brsEzForm As String, _
ByRef briEzCId As Long, _
ByRef briEzCMsg As Long, _
ByRef briEzCVal As Long, _
ByRef briEzCancel As Long)
proApp.subEvents(brsEzForm, briEzCId, briEzCMsg, briEzCVal, briEzCancel)
End Sub
'
'===============================================
'
' MainForm procedures
'
'===============================================
'
Sub subMainFormDesign()
End Sub
'
'===============================================
'
Sub subMainFormStart()
End Sub
'
'===============================================
'
Sub subMainFormStop()
End Sub
'
'===============================================
' end of dvs00dd.bas
'===============================================
We're currently using the standard EZ_Form structure. So you'll see that we pass all design and event requests to the Application class. The Application class contains a PB Collection of Panel (Form/Page) references, and the Panel class contains a PB Linked List of Control references for each control on the panel. When a design or event request is issued by EZGUI it first goes to the Application class, which locates the object reference for the Panel, then calls the Panel's design or event handler. The Panel in turn processes the EZGUI command, or does a lookup into the Linked List and passes the request on to the Control.
All the EZGUI stuff goes on inside the classes, and control only goes into user code if design or event handlers are specified. We've found that this dramatically reduces the amount of source code that needs to be generated. It also allows us to fine tune the various classes to give us the features that we need.
In our programs, only the application's main form is a regular form. On it resides a horizontal Splitter control that has two page forms for the left and right panels. All the other forms are page forms linked together in various ways to these two panels. The left panel holds a Treeview that acts as the main menu - rather than have a menu bar. And the right panel is where all the action takes place.
All this leads to my question.
In the help file you describe how using EZ_FormEx is more efficient than using EZ_Form. And EZ_FormEx would certainly save us the step of identifying the form in the Application class and passing control to the correct Panel.
However, you then go on to say that Page forms should be created using the EZ_form command. Why is this?
Do the Page forms still act as if EZ_FormEx was used and have their own design and events routines? Or do the Page forms get their messages via the parent form's Event routine?
Thanks
Rod
