Connecting Forms to Data-Layer (part 4)

 Now we will finish out our frmMain or our Application Desk Top 

Scrolling down our Control loop we get to the section with out List of Galaxies, and our Create, Modify, Delete Buttons.

Our first change will be to the List, specifically we want the default behavior of Double-Clicking an Item in our list to be "Modify". To accomplish this, we insert a PostEvent command which will Left-Click the the Modify Button for us.


          Case #Gadget_frmMain_liList
            Select EventType()
              Case #PB_EventType_LeftDoubleClick
                PostEvent(#PB_Event_Gadget, #Window_frmMain, #Gadget_frmMain_btModify, #PB_EventType_LeftClick)
              Default
            EndSelect

Next we Come to the Create Button, Here we want to call our GalaxyCreate Method.


          Case #Gadget_frmMain_btCreate
            Select EventType()
              Case #PB_EventType_LeftClick
                GalaxyCreate()
              Default
            EndSelect

Here is our FIRST Reference to the View Code, or Code Behind the Form, I'll Jump to that code in a moment. First let us finish the Code here in the Control-Loop.  We have the Modify and Delete Buttons:


            Select EventType()
              Case #PB_EventType_LeftClick
                Index = ListEx::GetState(#Gadget_frmMain_liList)
                If Index > -1
                  ID = ListEx::GetItemData(#Gadget_frmMain_liList, Index)
                  GalaxyDelete(ID)
                Else
                  MessageRequester("Blog", "Please select a Galaxy to MODIFY!")
                EndIf
              Default
            EndSelect

In the Modify, we first need to make sure that the User has selected a Record, If Not then tell them of their mistake, If they Have selected a Record then we retrieve the Record ID from the ItemData Property of the selected record and once again call our View Code GalaxyModify Procedure passing it the ID.


          Case #Gadget_frmMain_btDelete
            Select EventType()
              Case #PB_EventType_LeftClick
                Index = ListEx::GetState(#Gadget_frmMain_liList)
                If Index > -1
                  ID = ListEx::GetItemData(#Gadget_frmMain_liList, Index)
                  GalaxyDelete(ID)
                Else
                  MessageRequester("Blog", "Please select a Galaxy to DELETE!")
                EndIf
              Default
            EndSelect

In the Delete, we ance again need to make sure that the User has selected a Record, If Not then tell them of their mistake, If they Have selected a Record then we retrieve the Record ID from the ItemData Property of the selected record and once again call our View Code GalaxyDelete Procedure passing it the ID.

And finally, we have the Power Button.


          Case #Gadget_frmMain_btPower
            Select EventType()
              Case #PB_EventType_LeftClick
                 quitfrmMain = #True
              Default
            EndSelect

So here is to Complete Code of the Desktop Form. We will picup the next Post on the Galaxy View Code.

++++++++++++++++++++++






Comments

Post a Comment

Popular posts from this blog

Connecting the Forms to the Data-Layer (part 1)

Image
Completing this series of Entries can not be complete until we connect the data-Layer with the Forms, and the is the goal of these next few entries. As methodical as my approch was with the Data-Layer, will be my approach to Forms. Now regardless, of what tool, if any, you use to develop your forms; Forms serve only Two Purposes. The first being, to present data, from the database, to the users, and Secondly to input all changes the user makes back into the Database. I will pick up where we left off, and build out our Galaxy/SolarSystem Example with the following Forms: Galaxy Form: Solar System Form: And here is the Code that generates these forms. Procedure.i Window_frmSolarSystem() If OpenWindow(#Window_frmSolarSystem,0,0,430,186,"Solar System",#PB_Window_SystemMenu|#PB_Window_ScreenCentered|#PB_Window_Invisible,WindowID(#Window_frmMain)) TextGadget(#Gadget_frmSolarSystem_lbName,40,10,150,25,"Name: ",#PB_Text_Right) SetGadgetFont(#Gadget_
Read more

Module DB, the foundation of any Data Layer.

 At the heart of any application is the database. Therefore, this segment of the application should be bulletproof.  To prevent repeating code, it should start with the module I call DB.  Module DB it the bottom most module, it is the actual module which interacts with the database.  If later you decide to migrate your database from SQLite to say Postgres, then all you will need to do is tweak THIS Module.  This module will also contain the Enumeration of "STATE".  By this I mean the current state of the record, is it: New - Created but not yest saved to the database. Clean - The Record is "Untouched". It is Identical to the record saved in the Database. Dirty - The record was loaded from the database, but it has been changed in some manner. DeleteRec - The record has been marked for deletion, but the user has yet to commit the delete to the database. NewDirty - The record is new, but the User is changing something, or the new record is being modified but has never
Read more

Defining Database Tables (part 1)

 Welcome back! In this blog entry we will begin the definition of a Table DB Module, which will be built on top of our DB Module. As you will remember the DB Module is the lowest level Module in our Database Layer. He is the only module who interacts with the database, no other module in your application should directly touch the database. Now I will begin the definition of the Modules who sit atop DB. There are three distinct table Structures that have to be considered.  Single, or stand-alone, Table - examples of this the bottom Module of the Parent Child Structure, or and Class which has No Children.  A Static list of Values, a List of Error Codes. This is often referred to an "is a" paradigm. if an object is a ErrorType, where ErrorType is Not a child. Parent-Child Table - A great example of this would be Galaxy, a Galaxy has Many SolarSystems, each SolarSystem has many Planets, Each Planet has Many Factories.  As you can see the Parent Child Table Structure is best desc
Read more