How to build this without writing Code

I'm not sure if I should do this now, because I have not explained a number of additional aspects to the code, but for those of you who are interested.  The foundation of what I shown you here, IS the foundation of code my PBXClassBuilder-Standard generates for you. 

And I truly mean generates for you. You can have all this code generated for you without writing a single line of it yourself. Now PBXClassBuilder-Standard is not perfect, it is approximately 90=95% accurate. And I am constantly tweaking it edging this number ever higher.

To use PBXClassBuilder-Standard, You should start with Forms already laid out and built.  Within PBXClassBuilder-Standard you use intuitive screens to define your table structure, while linking the Table Fields to their intended form Fields.  Then link the Tables together as Parent Child, and finally you simply click buttons to generate the code, Including the SQL Code to create the tables. The Whole development process, post Forms, is only a few minutes.

I do not want to do this on the blog using still images and text. I'd rather do this in a couple Videos. The first will be the installation and Configuration of PBXClassBuilder-Standard. The second, and maybe third, will be complete development of our whole Galaxy/Solar System Code Example, including Table creation, I will clip the Form Creation and start with forms completed, after all that is truly NOT the Focus of this. 

Iwill be recording these Videos in the coming few days. I'll create a Blog Post about them when I release them.

For those brave souls willing to try do it on their own, the steps will be to download PBXClassBuilder from my site.  Install it on your computer. For Configuration download and install your Supported File Comparison tool of choice, configure it on the Configuration Screen.  Then Create your Project "Blog", or "Galaxy" whatever you want to call it. Use the manual and create our two tables, link them as Parent Child add see how far you can get. 

Galaxy Table,  FormName frmGalaxy, FormParent frmMain, and the List is on Parent liList

  • ID, Integer, Key & Auto-Increment, 
  • Name, String
Solars System Table, FormName frmSolarSystem, FormParent frmGalaxy and the list is on Parent, liSolarSystem
  • ID, Integer, Key, Auto-Increment
  • GalaxyID, ForeignKey to Table Galaxy
  • Name, String
  • GRow, Integer
  • GCol, Integer

You can use the Example Code on my site to crossreference FormName, and FieldNames.

GoodLuck

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