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)
Have you ever used a datastore that ran without a problem while you were
developing your application, but once you've compiled it stopped running? Let
me tell you that's a difficult bug to fix.
I remember it so well. I kept going back and forth. How in the world could
the DataWindow work at design time yet not in the executable? I remember that
I checked the return value of the datastore. I finally noticed that the
datastore returned a -1. That's such a strange thing.
The datastore returns the number of rows that were returned or a -1. The help
files used to say that a -1 was in ... (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)