The Application Object needs to have a script at its Open event.  It's also where Global Variables can be defined.  

A Function such as parseline is added as a PB Function Object since it needs to be available from any of the application's other events.

The 'Database Connection Script'  is the first thing you'll need: 

This hooks your PB application up to your newly created ASA database when it runs.  This 'database connection syntax' is provided for you in the properties of any installed ODBC connection.  

In the Database Painter, right-click on the icon for your database and choose Properties.  Look at the Preview tab and the connection syntax is selected, ready for you to Copy to your clipboard.  Click the Copy button and it's done for you.

With your clipboard loaded, Click on the Open Object icon in the Powerbar to open the Application Painter, choosing Objects of Type Application from the DDList & double-click your Application's icon when you've navigated to its folder.  There not much to an Application Object and its Script window should be prominent among your views.

Make sure that the Script window has selected your application (mine is gs9191) in the Left DDList and click in its Open event.  Paste the connection script into place using Ctrl-V to moVe or a menu choice.

Add a commented line, //open(w_main_panel), now if you'd like, since this will be required shortly, but it won't compile now since w_main_panel doesn't exist quite yet.  So, you can leave it out now & put the statement in after w_main_panel has been built.  

Right Click in the script window to compile the database connection sequence and investigate any error that results. 

Add the Global declarations to the Application Object.  Go to the Scripts page on the website, find & copy the Global variables to your clipboard with Ctrl-C or a menu choice.  

In PB, select the Declarations area of the script window & choose Global.   Click in the script window & use ctrl-V to paste the declarations into place.  These should also Compile cleanly with Right-Click:

Add the Function parseline next.  Click the New Object icon, PB Object Tab, and double-click Function to get into the Function Painter.  

It is important to get the Header for the function filled in correctly as below so that the function will work with the prototype's scripts.  

Copy the script for parseline from the website into the script window.  When this is complete as below, a Right-Click & Compile should get a clean compilation.  

The Main Panel is a Window that handles the reading of the enterprise.def file, setting of the window's Title property with what it finds there, and it forms the UI where the user clicks on a button to start a process, or tabs to a button & hits Enter to start the process.  

Start the New Object dialog by clicking on the New Object button in the PowerBar,  choose the PB Object tab, and double-click Window to launch the Window Painter.  

Here, I've made a smallish main panel & added two buttons to make a quick demo, no need to put scripts in the buttons yet.  But the script for the Open event script needs to be copied from the website to the script window.  When done, your main panel should look much better than this:

X out of the Window painter and name the Window w_main_panel.

The script at the Open event of the Application Object needs to be rigged to open(w_main_panel) just after it handles the database connection.  

Use the Open Object icon and navigate to the Application Object, then get to its Open Event pane and either remove the // from before  the open(w_main_panel) statement or key the statement in, depending on what you did the last time in this script.  

Right-Click & Compile should show no errors.

X out of the Application painter and click on the Run icon in the top Powerbar.  It's a little running man, streaming drops of sweat. 

If you've done everything right you'll be rewarded with your application's Main Panel, and it will display your Enterprise Id# and Name in the Title Bar.

If there's anything wrong, you'll have to exercise your God-given talents of debugging.

Before you start on the 'outside' of a Table Maintenance Window make sure all it's internal objects have been constructed: Before starting a new Window, make sure that all the DataWindows,  DDDWs, DDDLs, Edit Styles, & Validation Rules have already been built & tested.  

Ticking off what's required to be inside w_gs_maint, I come up with: dw_gs_lookup which will be used in dwc_lookup; dw_ledacc_lookup which will be used to lookup ledger accounts for ledacc_purch & ledacc_sale; and dw_gs_maint that's used to add new records and update existing ones.  Of these, dw_ledacc_lookup was already built & installed into the DDDW edit-style where it's required so it's already in place.  

This leaves dw_gs_lookup & dw_gs_maint needing to be built for this window.  Each of the other Table Maintenance Windows needs similar DataWindows, too, so make a list and get these components built before you start inheriting the first Table Maintenance Window.

In the prototype, all the _lookup DataWindows are Tabular style data windows with the rows sorted by id, name, or description as is appropriate for the table where a record is being looked up.  The _lookup Windows should be placed in a DataWindow Control which is large enough to show the full width of the columns and display at least several records at a time (6 or more is ideal).

All the _maint DataWindows are FreeForm & need to have a Retrieval Argument installed in them which is referenced on the WHERE tab of the SQL/Data view of the DataWindow.  

Their Retrieve method is called whenever Row Focus changes in the _lookup DataWindow Control and the id passed as a Retrieval Argument along with the Retrieve (in parentheses) so that the _main window is synchronized with the _lookup window.  

Each dw_some_maint DataWindow and each dwc_maint needs to be large enough on each of the Table Maintenance Windows to show all the fields in the record _without_ the user needing a scroll bar to navigate among fields.

Build dw_gs_lookup:

This DataWindow is made the same as dw_ledacc_lookup, which was built in the Database Steps.  

Click on the New Object button, DataWindow tab, and double-click Tabular style to launch the dialog.  For Data Source choose SQL Select & always leave 'Retrieve on Preview' checked.

In the 'Select Tables' dialog, choose gs (or whatever you've named your Goods & Services table).  The Cancel button on this window lets you click on columns in the little table in the Table Layout window to place them in the Selection List at the top of the window.  Here, I've chosen Description first & id 2nd & Sorted the list by Description -- this makes sense since the user will be looking at an alphabetic list & shouldn't be concerned with the item's id#.

Hit the 'Return' button in the bottom Powerbar to get out of this SQL/Data view and into the GUI DataWindow Painter where you can work on the appearance of the UI.  Here, I've pushed the detail band a bit snugger to pack more items in the lookup list, and have set the Headers' Font properties to Bold.  Please take care with these steps and size & align objects for a professional effect.

When you're pleased with the DataWindow's appearance, X out of it and name it.  This one is dw_gs_lookup.  

In the Workspace Window you can see that your pbl is growing.  As needed, you can open an object with its painter by double-clicking on the object's icon under the pbl in the workspace.  

Click the New Object button, choose FreeForm, SQL Select, and get your Goods&Services table in the Table Layout window.

Highlight all the rows except Quantity On Hand, which should not be editable during table maintenance, and which should be set to allow null data in the column's definition.  A column object will be placed into the Details band of the new DataWindow for each one that is in the Selection List.

Choose Design -> Retrieval Arguments and add a Retrieval Argument to the new DataWindow.  Here, I've called it id2get and left the data type as Number.  Click OK when you've done similar:

Choose the WHERE tab at the bottom of the painter and right-click on each of it's columns and choose so that the first line says "gs"."id" = :id2get. 

This adds a WHERE clause to the SQL statement and sets this DataWindow to prompt for a Retrieval Argument whenever it is launched without being passed an argument -- as when it is opened in its painter.  Click on the SYNTAX tab and you'll see the SQL statement that the GUI has built up to populate this window.   

Hit the Return button to leave the SQL view when your pleased with your SQL/Data window and get to the GUI DataWindow Painter.  You'll encounter your first clue that this new DataWindow has a Retrieval Argument defined for it. If there's no argument supplied as it would be from a script PB will prompt you for one using a dialog like this:  

Just enter the id # for one of the few Goods & Services records placed in the table during the Database Steps and click OK.  The Preview Pane should be displaying the fields for the record whose id you supplied for the Retrieval Argument.

In the Design window you can drag columns around, change their size, change font styles on prompts, and otherwise impress your style into the UI.  Take care to align objects perfectly by using the Format -> Align menu choice -- tiny errors give a sloppy, unprofessional look to the UI. 

Here's a dw_gs_maint, just ready to be Xd out of and named:

Build w_gs_maint, doing the GUI Programming first:

Click the New Object Icon, choose the PBObject Tab, and double-click Window to launch the Window Painter.  Drag the panes around so you can  see your new Window, and drag the right & lower edges of the Window in the Layout pane to make an appropriate-sized window.  Please note that windows in my demos must fit in a 640 X 480 resolution projector so they're a bit smaller than they need to be on most desktops.  

Make the windows large enough to provide enough room for at least several rows displayed in the lookup. (10+ is better, a DDDW is even better than that, a lookup that works like the Index in PS's Help dialog is the best).  Make the _maint window large enough to show all the fields in a record without scroll bars or or the DataWindow shifting around.  

Use the schematic as a guide and place the controls on the new Window.  Controls come from the toolbox, which is in the 2nd row of PowerBar buttons and usually starts out displaying a Command Button.  Unlike some other toolboxes, it only displays the last-selected control.  If another control needs to be selected, click the DropDown arrow and selected it. 

After selecting a Control from the toolbox, the mouse pointer becomes a + mark.  Clicking on the Window places the control at the spot clicked & selects it so that it can be stretched to the right size and moved to exactly the right place.

We need to place 6 Command Buttons, a Static Text control, and two DataWindow Controls.  Make sure to name everything according to the schematic since the prototype's scripts depend on the objects being named properly.  Get everything arranged according to your style and better looking than my demos:

Work carefully on this window to impress a favorable style into it since it will be inherited to make the other windows in the Table Maintenance series.  

Take care to provide a user with a consistent interface: use the same style box everywhere you expect input; make prompts clear & don't settle for using the column name in each place; make the Data Windows, Column Objects, and DataWindow Controls large enough to display any data & edit styles that appear in them. 

When you've got the GUI put together, it's time to test it.  Go back to 2_main_panel and add the line open(w_gs_maint) to its Clicked event.  Click the Running man and you should be able to get to your new window by clicking on the button for it in your main panel.

Procedural Programming -- Get the Scripts into it:

Copy the variables & scripts from the website into the correct places in the new Window.   Start with the section marked "The rest of these scripts are for the first Table Maintenance Window" and continue down the webpage, copying and pasting the scripts. 

The scripts for the GetFocus event of nearly every Command Button need to have This.Default = True and update stHelper.Text so that the application complies with the requirement for 'keyboard data entry' without a mouse, using the Tab & Enter keys, and so that it provides continuous, context sensitive prompts for the user.  

The Instance Variables go into the Declare -- Instance Variables script window:

After the Instance Variables, it's easiest to copy each script from the webpage to your clipboard & double-click on the control where the script will be placed, make sure that the proper event is selected in the DDList to the right, click in the script window, and Ctrl-V (or Right-Click & choose Paste) to paste the script into the window.  

For example, double-clicking on the Window gets to the script window for the Window's Open event & the script from the website can be pasted there:

Right-click on each script as it's pasted into place and make sure that it will compile before going back to the website to get the next script.

Finish copying all the event scripts from the website, then X out of the New Window's painter and name it.  This one is w_gs_maint.  

Now it's time to test the window and make sure it works.  If it hasn't already been done, visit w_main_panel with the Window Painter and put open(w_gs_maint) in the Clicked Event script for cb_gs (or whatever you've called it):

Where are we?

We still need 3 more table maintenance windows, for: Ledger Accounts, Business Entities, and Activity Codes; named to support what I've named my tables they would be: w_ledacc_maint, w_be_maint, and w_activity_maint.  

These will each require DataWindows for _lookup & _maint similar to dw_gs_lookup & dw_gs_maint above.  dw_ledacc_lookup, created earlier to support the DDDW edit style can be 'reused' so it doesn't have to be built again.  

Now, it's time to build DataWindows that correspond to: dw_ledacc_maint; dw_activity_lookup & dw_activity_maint; and dw_be_lookup & dw_be_maint.  Make sure to choose Tabular style with 2 columns in it for each of the '_lookup' windows & FreeForm + a Retrieval Argument & WHERE tab filled in for each of the '_maint' windows.