Service objects were introduced for PowerBuilder at about the same time as
the PowerBuilder Foundation Classes. Much like the PFC, most programmers
found reasons not to use them. In this article we will reduce the complexity
of these objects and in so doing perhaps open a new world of efficient
objects that are easily maintained and understood.
This article is going to create a service object for the DataWindow. The idea
behind this object and others like it is to minimize the footprint of the
DataWindow. We want to minimize the amount of memory that the DataWindow
requires and thus provide the greatest responsiveness that we can.
One of the most used areas of functionality for a PowerBuilder programmer is
row selection for the DataWindow. How many times have you gone to the Clicked
event of a DataWindow control and typed something like the following?
This article provides a means of automating the sorting of DataWindows... not
just grid DataWindows as discussed in last month's article, but all
DataWindows, regardless of display format.
Bear in mind that we are writing programmer tools. When writing for
programmers we want to give the programmer the maximum number of options
while minimizing the programmer effort. In other words, default as much as
possible but allow the programmer to move beyond the defaults.
We have several action items to implement:
Do the housekeeping to get an application going Create a window for sorting.... (more)
Security is a must for most corporate applications. This article will give
you a starting point to designing and implementing your own. We will do it
with a table that is added to the example database and implement it in
ancestor code. The idea is that you should only have to add rows to a table
to implement your security.
The security table will provide a means to turn on and off controls and menu
items as our inherited objects are constructed.
Login_name varchar(20) PK
Application varchar(20) PK
Item_type varchar(10) PK
Item_name varchar(20) PK
Priviledge ... (more)
Every programmer knows about the IF command. It's pretty much a fundamental
part of the syntax of every computer language that has ever existed. I don't
need to explain how it works.
The DataWindow can't use the IF command though. It does, however, support an
IF(expression, TRUE, FALSE)
In its simplest form this means that if the expression evaluates to TRUE,
then whatever statement you supply for the TRUE part is executed. If not then
the FALSE part is.
Let's begin with a simple example. Let's create a DataWindow that will show
employee information. Here is the SQ... (more)
Normally I try to write applications on the DataWindow or Appeon but every
now and then I get a question that makes me sit back and say, "Huh?"
In this case the question concerns the PostOpen event. I've seen that event
named different things: ue_post_open, postOpen, post_open, ue_postOpen, etc.
It has, as far as I can see, always had post and open in the name of the
event. Further, just about every framework that I've ever seen has had that
event in the base window.
The question that I was asked was, "Why is that event there?"
The programmer wanted to know why there was code in t... (more)