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

 So now we are down to just the SolarSystem Code Sheet.

This is NOT a rubberstamp of the Galaxy. The MAIN reason is that the Galaxy Records are Sourced directly from the Database, As you will recall our SolarSystem is Sourced from the Galaxy Record's Solar System Collection NOT the Database.

This makes for a VERY Significant difference between in the code.

Our Procedure are the save ALL the Steps are the same, the differences are in the details.

Starting once again at the top, we have our declares:


Define quitfrmSolarSystem

Declare SolarSystemCustom()
Declare SolarSystemSetScreen()
Declare SolarSystemCreate()
Declare SolarSystemModify()
Declare SolarSystemDelete()
Declare SolarSystemSetData()
Declare SolarSystemSave()
Declare SolarSystemClose()

And then, as before the SetScreen Procedure, and Control-Loop.


Procedure SolarSystemSetScreen()
  Protected String$, x, y, w, h, i, ID
  Shared WorkSolarSystem
  Protected EventID, MenuID, GadgetID, WindowID, Index 
  Shared quitfrmSolarSystem
  quitfrmSolarSystem = #False
  If Window_frmSolarSystem()
    
    SolarSystemCustom()
    SetActiveWindow(#Window_frmSolarSystem)
    ;Set Screen Data
    SetGadgetText(#Gadget_frmSolarSystem_txtName,  WorkSolarSystem\Name)
    SetGadgetText(#Gadget_frmSolarSystem_txtGrow, Str(WorkSolarSystem\GRow))
    SetGadgetText(#Gadget_frmSolarSystem_txtGCol, Str(WorkSolarSystem\GCol))
   
    SetActiveGadget(#Gadget_frmSolarSystem_txtName)
    Repeat
      EventID =WaitWindowEvent()
      MenuID =EventMenu()
      GadgetID =EventGadget()
      WindowID =EventWindow()
      Select EventID
        Case #PB_Event_CloseWindow
          Select WindowID
            Case #Window_frmSolarSystem
              SolarSystemClose()
          EndSelect
        Case #PB_Event_Menu
          Select WindowID
          EndSelect
        Case #PB_Event_Gadget
          Select GadgetID
            ;*************************************
            ;**** Start frmSolarSystem
            ;*************************************
            Case #Gadget_frmSolarSystem_lbName
            Case #Gadget_frmSolarSystem_txtName
              Select EventType()
                Case #PB_EventType_Focus
                  
                Default
              EndSelect
            Case #Gadget_frmSolarSystem_lbGRow
            Case #Gadget_frmSolarSystem_txtGrow
              Select EventType()
                Case #PB_EventType_Focus
                  
                Default
              EndSelect
            Case #Gadget_frmSolarSystem_lbGCol
            Case #Gadget_frmSolarSystem_txtGCol
              Select EventType()
                Case #PB_EventType_Focus
                  
                Default
              EndSelect
           
            Case #Gadget_frmSolarSystem_btSave
            Select EventType()
              Case #PB_EventType_LeftClick
                SolarSystemSave()
            EndSelect
            Case #Gadget_frmSolarSystem_btCancel
            Select EventType()
              Case #PB_EventType_LeftClick
                SolarSystemClose()
            EndSelect
            
          EndSelect
        EndSelect
      Until quitfrmSolarSystem = #True
      CloseWindow(#Window_frmSolarSystem)
    EndIf

EndProcedure

After the call to Create the form, we call the Custom Form Procedure. Next, we Load the Form Gadgets from the Variable or Object. Then we enter into the Form Control-Loop. 

There is, honestly, not a lot here. There are three StringGadgets for the User to fill out, and the standard two Buttons of SAVE and CANCEL.


            Case #Gadget_frmSolarSystem_btSave
            Select EventType()
              Case #PB_EventType_LeftClick
                SolarSystemSave()
            EndSelect
            Case #Gadget_frmSolarSystem_btCancel
            Select EventType()
              Case #PB_EventType_LeftClick
                SolarSystemClose()
            EndSelect

These as you can see are pretty much the same as before. The Save Button call the Solar System Save Procedure and Cancel Calls the Solar System Close as we would Expect.

Moving on to the Create, here we again see virtually the same code as Before:


Procedure SolarSystemCreate()
  Shared WorkSolarSystem
  DisableWindow(#Window_frmGalaxy, #True) 
  SOLARSYSTEM::Init(@WorkSolarSystem)
  SolarSystemSetScreen()
EndProcedure

The Variable is Initialized an NEW and then we call the SetScreen Procedure, just as before.

Now lets have a look at the Modify Procedure, Here the changes beging immediatly, we No Longer expect the passed in Table Key. This is because these records are not being pulled out of the database, but rather the Galaxy's SolarSystemCollection. 

The Records in the WorkGalaxy\SolarSystemCollection(), are simply displayed to the user in the Galaxy Form ListEx Gadget. The are in an identical order. Therefore, we know that the user has selected A Record in that ListEx Gadget to Modify. So the Index on the list Matches the Index in the Collection.


Procedure SolarSystemModify()
  Protected Index 
  Index = GetGadgetState(#Gadget_frmGalaxy_liSolarsystems) 
  Shared WorkGalaxy
  Shared WorkSolarSystem
  DisableWindow(#Window_frmGalaxy, #True) 
  If Index > -1
    SelectElement(WorkGalaxy\SolarSystemCollection(), Index) 
    WorkSolarSystem = WorkGalaxy\SolarSystemCollection()
    If WorkSolarSystem\State = DB::#New Or WorkSolarSystem\State = DB::#NewDirty
      WorkSolarSystem\State = DB::#NewDirty
    Else
      WorkSolarSystem\State = DB::#Dirty
    EndIf
    SolarSystemSetScreen()
  EndIf
EndProcedure

Our first order of business is to get tat Index, , we will doubly insure a record is selected then Using that Index we will Select the Collection Item in the WorkGalaxy\SolarSystemCollection()

Once Selected we will set our Global WorkSolarSystem to the Collection Instance.

New, we MUST interrogate the Status of the Record Selected.  Remember in the SAVE Procedure we Insert a Record back into the List if It is DB::#New, We Must Account for a NEW Record being MODIFIED. Thus Enter the Status of DB::#NewDirty. That is what this whole IF is testing For. 

With the Record's Status handled we now can Proceed Forward and call the SetScreen Pricedure.

Now let us look at the SolarSystemDelete Procedure.  Once again no Passed in Key, once Again we Retrieve the ListEx Index of the chosen record to Delete. We Confirm we have a Valid Index, then we can Select the WorkGalaxy\SolarSystemCollection() matching record and Confirm the Users intention to delete the Record.  If confirmed, we can begin the "process" of deleting it.

Procedure SolarSystemDelete()
  Protected Index, Result
  Shared WorkGalaxy
  Shared WorkSolarSystem
  DisableWindow(#Window_frmGalaxy, #True) 
  Index = ListEx::GetState(#Gadget_frmGalaxy_liSolarsystems)
  If Index > -1
    Result = MessageRequester("Delete Confirmation", "Are you SURE you want To DELETE this Record ?", #PB_MessageRequester_YesNo) 
    If Result = #PB_MessageRequester_Yes 
      SelectElement(WorkGalaxy\SolarSystemCollection(), Index)
      WorkSolarSystem = WorkGalaxy\SolarSystemCollection()
      DeleteElement(WorkGalaxy\SolarSystemCollection())
      If WorkSolarSystem\State <> DB::#New And WorkSolarSystem\State <> DB::#NewDirty
        AddElement(WorkGalaxy\DeleteSolarSystemCollection())  
        WorkGalaxy\DeleteSolarSystemCollection() = WorkSolarSystem
      EndIf
    Index = ListEx::GetState(#Gadget_frmGalaxy_liSolarsystems) 
    EndIf 
    DisableWindow(#Window_frmGalaxy, #False) 
  EndIf 
EndProcedure  

We set our Global WorkSolarSystem Variable to the Selected Collection Instance. Then we can Delete the COLLECTION Instance; Note NOT the Database Instance. Next.  We see If the Status of the Record to Delete is DB::#New or DB::#NewDirty if they are deleting a NEW record, then it is NOT IN the Database, and We're done. Otherwise, we then Insert the Record to delete into the WorkGalaxy\DeleteSolarSystemCollection() and set its status to DB::#Delete.

And this brings us to the  SetData Procedure, once again as we expect. It is identical to our first, in that it simply moves the User input back into our Object or Variable.


Procedure SolarSystemSetData()
  Protected Index
  Shared WorkSolarSystem
  WorkSolarSystem\Name = GetGadgetText(#Gadget_frmSolarSystem_txtName) 
  WorkSolarSystem\GRow = Val(GetGadgetText(#Gadget_frmSolarSystem_txtGrow)) 
  WorkSolarSystem\GCol = Val(GetGadgetText(#Gadget_frmSolarSystem_txtGCol)) 
EndProcedure


Next, let us examine the Save Procedure. I want to Point Out that the SAVE Procedure really does not Save the record to the Database. None of the SolarSystem Procedure actually touch the Database.  These Procedures ONLY Manages the List of SolarSystem int the WorkGalaxy\SolarSystemCollection().  Should the user Decide to NOT SAVE the Galaxy Record with all its Changes then All the Changes are thrown away. If on the other hand, they Click Save on the Galaxy Record then ALL the Changes will be committed to the Database.


Procedure SolarSystemSave()
  Protected Index, State
  Shared WorkGalaxy
  Shared WorkSolarSystem
  Index = GetGadgetState(#Gadget_frmGalaxy_liSolarsystems)
  State = WorkSolarSystem\State
  SolarSystemSetData()  
  If SOLARSYSTEM::Validate(WorkSolarSystem)
    If State = DB::#New or State = DB::#NewDirty
      ;ADD to Collection 
      LastElement(WorkGalaxy\SolarSystemCollection())  
      AddElement(WorkGalaxy\SolarSystemCollection())  
      WorkGalaxy\SolarSystemCollection()=WorkSolarSystem
      ListEx::AddItem(#Gadget_frmGalaxy_liSolarsystems,-1, GALAXY::ListIconItemSolarSystem(@WorkSolarSystem), "", 0)
      ListEx::SetState(#Gadget_frmGalaxy_liSolarsystems , ListEx::CountItems(#Gadget_frmGalaxy_liSolarsystems)-1)
    Else
      ListEx::SetItemText(#Gadget_frmGalaxy_liSolarsystems, Index, GALAXY::ListIconItemSolarSystem(@WorkSolarSystem), 0)
      SelectElement(WorkGalaxy\SolarSystemCollection(), Index) 
      WorkGalaxy\SolarSystemCollection()=WorkSolarSystem
    EndIf
    SolarSystemClose()
  EndIf 
EndProcedure

So lets do an deep dive into the Save and what it is doing. The fact is this Save does everything the other did, with the single change of calling VALIDATE instead of SAVE. Another thing to comment on is the LastElement() Command called on the collection. This command ensures that the Collection pointer it at the last Record, this way we Ensure our ADDElement() Occurs there and no other place.

Then the Close Procedure. Here there is No Change from our other Close.


Procedure SolarSystemClose()
  Shared quitfrmSolarSystem
  If IsWindow(#Window_frmGalaxy)
    SetActiveWindow(#Window_frmGalaxy)
    DisableWindow(#Window_frmGalaxy, #False)
  EndIf
  quitfrmSolarSystem = #True
EndProcedure

And finally, the Form Custom Procedure. In this form we are not customizing anything.


Procedure SolarSystemCustom()
  

EndProcedure

The next Entry is the Whole View Sheet.

This entire Solution id available to download on my website.

PAHLabs.com



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