All Things New

Digg This!

Page 1 of 2   next page »

As I was reviewing my previous "state of the application" and began to work toward a basic application shell, I realized that there was some additional code that I needed to write.

Missing Pieces
First, I realized that I could add a default SetTransObject() call on my u_dw and n_ds objects in the framework to automatically assign SQLCA to the object. This is a convenience to anyone using the framework since SQLCA is utilized 99% of the time as the application transaction object. I added this into the constructor event of both u_dw and n_ds. However, I needed to remember to do this by calling of_SetTransObject() to ensure that we keep track of the transaction object (please refer to my previous article "Standards and Frameworks" [PBDJ, Vol. 12, issue 9] to review the reasons). So, the constructor event becomes:

this.of_SetTransObject(SQLCA)

Second, and much more important, I had neglected to create a framework-level frame window and menu. It's fairly difficult to write an MDI application without a frame, last time I checked. So, w_frame and m_frame were created.

W_frame is just that...a frame. At the present there is no generic functionality that is coded into the frame window. It does, however, have a menu associated to it.

M_frame (see Figure 1) contains basic, generic functionality that can be used in almost all applications, including:

• Exit: Closes the MDI frame, which closes the application
• Cut, Copy and Paste: These options do not have any code at the framework level since there is no default, application-agnostic way of determining what to cut or copy from or paste to. This could be built into your framework by tracking the current control that has focus and using that control as the driver for the cut/copy/paste functionality. Perhaps we'll revisit this in a later article. For now, we have simply defined the menu options with no default implementation.

The window items for arranging the open sheets are framework functions since this is not application-specific functionality, but useful for almost all applications. PowerBuilder provides the ArrangeSheets() function to provide five variations. I have chosen to implement all five in my framework.

Application Basics
Following our naming and inheritance conventions, I now create the following objects in my application .pbl:

• w_cs_frame inherited from w_frame
• m_cs_frame inherited from m_frame
• w_cs_sheet inherited from w_sheet
• n_cs_tr inherited from n_tr

In order for elements of the framework to work properly and be able to use SQLCA as our default transaction object, we need to ensure that SQLCA is retyped from being an object of type transaction to being an object of type n_cs_tr. We specifically want to use the application-level class, n_cs_tr, instead of the framework class n_tr since the transaction really only has meaning at the application level. If we define RPCFunctions to the transaction object, we need to do that at the application level, for example. We can change the variable type of SQLCA by opening the application object, clicking on the Additional Properties command button on the application properties list, selecting the Variable Types tab, and replacing "transaction" with "n_cs_tr" for SQLCA (see Figure 2).

The only other necessary step to take at this point in the application object is to open the frame window:

Open (w_cs_frame)

We can, at this point, run the application (see Figure 3). Not very functional or exciting, but it does run.

Adding Application Specifics
For this application, we are going to create five maintenance screens to manage Contacts, Controls, Menus, Messages, and Users. Our functional requirements tell us that each of these maintenance screens will be an MDI sheet and only a single instance of each type of sheet can be open at the same time. It doesn't make functional sense to have multiple contact sheets open for this application since all contacts will be maintainable from the single screen.

The first thing to do for each screen is create the sheet window:

• inherit from w_cs_sheet to create w_cs_contacts
• inherit from w_cs_sheet to create w_cs_controls
• inherit from w_cs_sheet to create w_cs_menus
• inherit from w_cs_sheet to create w_cs_messages
• inherit from w_cs_sheet to create w_cs_users

The next thing to do is add menu items for each sheet type. I create a new menu item on m_cs_frame and set the text to Maintain. Notice that this new item is at the end of the menu (see Figure 4). Not exactly where we want it. We would like it to be in between Edit and Window. How do we get it there? One of the general properties of a menu item is ShiftToRight. When this property is checked for a menu item, the menu item will shift to the right of, or below (for submenu items), any menu items added in the descendant menu. The interesting thing to note about this property is that even though you are affecting ancestor menu items, you can set it on the descendant menu itself - it does not have to be set at the ancestor menu. Notice in Figure 4 that the ShiftToRight property is set for the Window menu item. It's also set for the Help menu item. When we run the application, we therefore see the Maintain menu item right where we want it (see Figure 5).

Under the Maintain menu item, we create menu subitems for Controls, Users, Menus, Messages, and Contacts. The script for each one will look very similar:

OpenSheet (w_cs_controls, w_cs_frame, 0, Original!)

The OpenSheet function will default the position and arrangeopen values, however, I like to be explicit in setting the argument values, especially when determining how the sheet will be arranged when opened. Notice that I did not specify a windowtype value. The only time you must specify a windowtype is when the reference variable you are using is of an ancestor type. This allows for polymorphism, which we will discuss in another article.

I also didn't use a reference variable for the first argument; I used the window class name as the reference variable instead. When the window class name is used in this way, PowerBuilder will ensure that only one instance of the window class specified will be opened at any time. OpenSheet calls that use the same window class name will activate the currently open sheet, but will not create a second sheet. In order to allow multiple sheets of the same type to be opened, say for Users, the following code would be required:

w_cs_users lw_Users
OpenSheet (lw_Users, w_cs_frame, 0, Original!)

If we run the application now (see Figure 6), we can open each type of sheet, but only once each, as per our functional requirements. Still not too exciting, but it's something.

Code Refactoring and Code Promotion
Recalling the subject of code duplication from Larry Cermak's last article ("Avoiding Code Duplication" [PBDJ, Vol. 12, issue 10]) and keeping in mind the concepts of code refactoring and code promotion, I had to move and adjust some very basic code that was needed for my application and, in fact, for almost all applications.

Before I discuss the specifics of what I moved and why, let's define and discuss the importance of code refactoring and code promotion. Technically, the definition of code refactoring is restructuring code in order to improve its internal structure without altering its external behavior (restatement of Martin Fowler's definition). Typically, we apply the concept of refactoring to code that has "been around a while." But, I've found that it can just as easily apply to newly written code as well. Say you've just coded a bit of complex logic. You might find that it does exactly what it's supposed to do, but looking at the code brings tears to your eyes and rumblings to your stomach. It's a mess - or at least it's not nearly as neat as you'd like to make it. So, you do a bit of code mapping, tracing the execution lines, looking for patterns that can be pulled out of in-line code and made reusable. Most times this is done by creating a function and passing in the necessary arguments. Sometimes you may even create a new class and several methods. Sometimes you may keep the code in-line, but find other ways to simplify the flow and logic.

Page 1 of 2   next page »