Long ago I promised you that I would give you a series of posts about the work behind ProfilSmart. This is the first installment of this series and today I will try to give you a deeper look into Profilsmart's forms.
Usually I try to be very careful when I create a new application. I have always in my mind that what understands a user as "application" is just the user interface (UI) so I am very scholastic designing the UI.
Three years ago I found myself to spend almost half (40% - 45%) of my time creating new forms and playing with GUI controls. I don't know whether it was my laziness or the need that made me to create a "strange" form then. Playing with the colors or the controls on a form for a corporate team maybe it is a pleasant occupation but when you are the only developer in the company and you have to wear a dozen of hats every day, you have to find solutions and efficient ways to turn your development into a really rapid one.
My very first thought was to create a set of Form classes with typical GUI controls and functionality that could be inherited and used in every need. Very soon a better idea came to mind and it was then that I tested to have a single form as "skeleton" and different container objects for the specific cases. So instead to load different forms across my application I created a "Master Page" with a pleasant color scheme, the navigation controls while a "sub form" was called according the occassion.
Very Soon my application in "design mode" was looking like this:
...Hey this is an empty form! How can this be your 12 months work ???
Ok let's dive a bit deeper...
The form has a custom method called cAddPanel. The code of the method looks like the listing:
(Since Profilsmart is a commercial close source application I can't publish the exact code here but I hope you get an idea)
Function cAddPanel
Lparameters tcPanelName
IF ! VARTYPE(&tcPanelName)="O" THEN
IF VARTYPE(thisform.cfrmpanel)="C" then
lcObjectName = "thisform." + thisform.cFrmPanel
EVALUATE(lcObjectName + ".OnBeforeClose()")
ENDIF
thisform.cRemoveAll()
thisform.AddObject(tcPanelName,tcPanelName)
lcObjectName = "thisform." + tcPanelName
this.cFrmPanel = tcPanelName
WITH &lcObjectName
IF NOT .cNoResize
.top = this.xpanel_guide1.Top
.left = this.xpanel_guide1.Left
.width = this.xpanel_guide1.Width
.height = this.xpanel_guide1.Height
ELSE
.Top = .cMyTop
.Left = .cMyLeft
ENDIF
.cActivate()
.visible = .t.
IF tnKeyValue < 0 THEN
.cAddNew()
ELSE
.cPrimaryKeyValue = tnKeyValue
.cRequery()
ENDIF
.Refresh
ENDWITH
ENDIF
thisform.Refresh
As you can see the method accepts the name of the panel (container object) and then loads the container. In the form we have an xpanel_guide1 object (A simple shape obj Visible=.F.) that works as a proxy and the container takes its place.
In addition the form has a property called cFrmPanel that keeps the name of the current container.
After the new container's creation the cAddPanel function calls a couple of methods for new objects's setup.
Every container has a property called cNextPanel that holds the name of the next panel. This is easily configurable at design time while the form's Next button is clicked the cShowNext method is called.
Function cShowNext
LOCAL lcObjectName, lbCheck, lcNextPanel
IF VARTYPE(thisform.cfrmpanel)="C" then
lcObjectName = "thisform." + thisform.cFrmPanel
EVALUATE(lcObjectName + ".OnBeforeNext()")
IF PEMSTATUS(thisform,thisform.cFrmPanel,5)
WITH &lcObjectName
IF VARTYPE(.cNextPanel)="C" AND NOT EMPTY(.cNextPanel)
lcNextPanel = .cNextPanel
lbCheck = (Vartype(lcNextPanel)="C")
ENDIF
ENDWITH
ENDIF
ENDIF
IF lbCheck
thisform.cAddPanel(lcNextPanel)
ENDIF
Let's imagine that you have to code a 4 pages wizard form. All you have to do is to create a new form based on the xBaseform class and to fill 4 containers with the appropriate controls. In the first container you write in the cNextpanel property the name of the second panel, in the second the name of the third and so on...
You run the form and your wizard is ready!
Continuing to throw here listings with code I am sure that very soon you will leave this page with headache. Stand by one minute and let's see what are the benefits of this approach.
1. It is really easy to have a consinstent User interface accross the whole application.
2. Having solved basic form functionality (resize code, close buttons, navigation controls etc...) your development time is reduced many times.
3. When you want to make an application wide change (form's layout, form's colors , theme support etc.) you have to change a single point!
4. From my metrics it is faster to load a container than to call a brand new form at runtime.
5. You can have more simplistic UI elements in different containers instead of a crowded form.
In my own framework the form does not know anything about Business objects or data. I don't use form's DataEnvironment and the form's BindControls property is by default to .F.
The containers have custom methods that handle the data.
This is a typical supplier's form at runtime:
In the next post of the series we will examine the container objects.
See you!