ANSI Standard PL/B Language and Visual PL/B
GUI vs Procedural
NOTE TO OUR READERS
This web resource is written for our own use. But we feel strongly that the PL/B language should be shared with the software community. So feel free to use this at will!
BUT PLEASE...
if you find errors or omissions or have a better way to do something. TELL US! Dialog helps us all. Send e-mail to:
support@mmcctech.com
GUI vs PROCEDURAL Discussion
The following information was parts of a discussion of the
Sumbelt Computer Systems discussion group.
The question concerns when to handle various events
in a PL/B Windows environment.
People migrating from the tradition, NON-GUI world
are acoustomed to having total control over the sequence of
events as a person uses a program.
In the GUI world the user can "dance" all over the screen at will.
The discussion revolves around when we, the programmers,
do error testing and related operations.
There are two fundamental methods:
First, we can try to closely approximate the NON-GUI program control.
We might provide prompting by using the GOTFOCUS event when
a user clicks into a screen object.
We can then do our error checking via the LOSTFOCUS event
when the user clicks away.
The SECOND method is to bow to the WINDOWS conventional method
of using a SAVE button and doing all of the error checking only
when the user clicks THAT button.
The second method is by far the easiest to program. The reason
revolves around the timng of GOTFOCUS and LOSTFOCUS events.
In it's simplest explaination, the problem is that when "object a"
loses focus, "object b" gets focus. There is some question about
which of these events is reported to your program first.
Another related timing issue involves error handling itself.
If we post error messages in response to some condition,
the error message itself (depending on what type of object we use)
will GAIN then LOSE focus.
The result is that one may have to do extensive programming
to keep track of what's going on at any given time.
With that background, here are portions of the most recent
discussion of the topic.
Topic: GOT/LOST FOCUS (1 of 10), Read 53 times
Conf: Tech Support
From: John Lovelace
Date: Tuesday, September 08, 1998 11:03 AM
I have a 'concept' question. If I have a
series of EDITTEXT fields on a window, and
one is CUSTOMER number for argument sake, I
have a Customer file read routine set to
execute on the LOSTFOCUS of the edittext
field and a SETFOCUS for the next required
field. If I have several similar entry
fields operating like this on the same
window, then clicking on another field
randomly on the screen becomes 'cursor
ping-pong'. I think I confuse myself
by having so many conditions based on
GOTFOCUS & LOSTFOCUS. My question is, does
everyone use these concepts for tagging
a file read or is the a more simple
way to accomplish this task. The code is
working PERFECTLY but I end up with too
many avenues to pursue.
Topic: GOT/LOST FOCUS (2 of 10), Read 52 times
Conf: Tech Support
From: David Gabler
Date: Wednesday, September 09, 1998 11:43 AM
The concept is basically drilled down to: Do we do real-time entry checking,
as we did in DOS, or do we do a once through when they click save? In a
user-controlled, event driven environment, it's much simpler to do the
later. We're so used to top-down program design, and having the program in
control that it's hard to let go and conceptualize a user-controlled
environment. But that's the simplest way to do it. Have all the entry
checking at one location, ie. on the save button.
As far as the lost focus/got focus, if I read your above statement, you are
doing the SETFOCUS to the next required field -- don't try to control the
cursor with program logic. Control it with the properties inherent to the
EDITTEXT (ie, the TABID). If you do that, you won't inadvertently trigger an
event yourself, and you'll know that all events were triggered by the user's
actions.
The basic problem is that your program is trying to control things, and
that's how you end up with cursor ping pong. There's certainly things to do
with the SETFOCUS (ie, help bubbles, etc). On a lost-focus, you should be
able to do a file read and filling in of other edittext's based on that file
read w/o losing the TAB order. Problem comes in if you're doing error
checking and YOU trigger an event by doing a SETFOCUS (you're actually
triggering 2 events, a lost focus on the field the TABID took them to, and a
setfocus on the field you're sending them to). If you try to exercise that
much control it can lead to problems.
Now, I may have just confused you more, but I hope not!
David Gabler
Apollo Software
Topic: GOT/LOST FOCUS (3 of 10), Read 58 times
Conf: Tech Support
From: John Lovelace
Date: Wednesday, September 09, 1998 02:11 PM
David, as always I appreciate your input. I
did not mean to post too 'simple' a question
on the board, but as a 'concept' I thought
this one was worth asking. After thinking
this problem through I reached the same
conclusion that you advise. While SETFOCUS
has some great control features, I think
I Exhibited too much control rather than
allowing the TABID to allow fields to flow
from one to another naturally. It is true
that event driven programming is quite a
different creature from the top-down style
we have been used too so long. I'm still
shifting gears, but I'll adjust. Thanx
for the help.
John
Topic: GOT/LOST FOCUS (4 of 10), Read 41 times
Conf: Tech Support
From: Bill Leidy
Date: Thursday, September 10, 1998 03:26 PM
Wow!! Here we are at the heart of the GUI controversy!!
>The concept is basically drilled down
>to: Do we do real-time entry checking,
>as we did in DOS, or do we do a once
>through when they click save?
In DOS, we could have done it either way equally well. For heavy data entry
tasks, real-time entry checking is often more user-friendly.
>In a user-controlled, event driven
>environment, it's much simpler to do the
>later.
Here's the point. Can I have all the nice looking GUI features and still
have the program (not the user) in control. And real-time entry check is
event driven also.
So we are stuck with a programming interface that was designed for
spreadsheets and word processing.
If we are going to make this work for data entry, we have to find ways to do
it the way the application function (not the programming Interface)
dictates.
This means (1) that we can't settle for the simplest way, (2) that we have
to share ideas on how to accomplish our goals, and (3) push the software
vendors to make our tools more versatile.
(Obviously, this is not just a Sunbelt problem) Visual whatever from
Microsoft has the same limitations. However, Sunbelt can respond faster to
our needs).
I would like to hear from people that have tried other approaches. Besides
SETFOCUS, there is enable/disable, static= true/false, readonly=true/false.
There has to be methods of looking at a field that has just been entered and
altering the program flow based on the results.
>The basic problem is that your program
>is trying to control things.....
Not trying to rip you, David, but I have a hard time living with the
statement above. I'm just getting into the GUI thing, and this is the very
heart of what I'm wrestling with.
Let's hear from some more people on this!
Bill Leidy
Chickasaw Telephone Co.
Topic: GOT/LOST FOCUS (5 of 10), Read 45 times
Conf: Tech Support
From: John Lovelace
Date: Thursday, September 10, 1998 04:54 PM
Bill, after swimming with the GUI alligators
for a while, I have finally become a true
supporter. It's not that GUI is any more
difficult than DOS, but it is a challenge
to alter one's mindset to the GUI WAY OF
DOING THINGS. In a nutshell, in DOS we had
complete control at a KEYIN point including
where the user went after the keyin was
satisfied. Now the user has the ability to
'dance' anywhere on the screen at will
(and WE must compensate for that).
David's assessment was correct that we must
now SHIFT that heralded control to a
different location because of this user
ability. We have not lost any control, in
my opinion. I think we have gained by
leaps and bounds. But it does force us to
program by EVENT DRIVEN ideals rather than
TOP DOWN. To state it bluntly, the entire
screen has become a keyin, but the power we
have gained as a result is astronomical!
Don't laugh at me for saying this, but the
class that Sunbelt holds for GUI is probably
the main reason for our move to conversion.
Many of the questions you asked are answered
quickly and easily in the course. Had I been
forced to learn this on my own, we would
have been delayed greatly. This Web Board
has also been a true LIFE SAVER!
Topic: GOT/LOST FOCUS (6 of 10), Read 42 times
Conf: Tech Support
From: David Gabler
Date: Thursday, September 10, 1998 07:16 PM
Actually, 'stuck' is not the word I would have used. Sunbelt has adapted
PLB for windows in the most natural way I could have imagined.
I have not seen
any other windows program where you can use the ENTER and ARROW KEYS to
move between fields the way we can in PLB. Of course, you have to program
for it, but the results are a very user friendly program!
What John was struggling with in his message was cursor ping pong and
having to control so many different avenues.
Of course, even in a GUI event driven environment you can exercise as much
control as you want if you are willing to do the work. This means: 1) For
every event YOU generate with a SETFOCUS, you must be willing to either set
a flag that will cause that event to be ignored, or use the internal event
manipulating commands in PLB to delete those events from the event stack.
2) You have to be willing to use the EVENTREG a lot in order to set up
events for different scenarios. 3) You have to be willing to use the other
properties you mentioned (STATIC, TABID, etc) with the SETPROP based on
different scenarios.
In other words, you must adapt based on conditions just like you would in a
DOS environment. Think about a program where the SAVE button is only ACTIVE
if there is data to save. Well, your program must do the checking to see if
there is data to save and ACTIVATE that button based on the results. Of
course you could just leave that button active, but then the first course of
events at the ACTIVATE routine for 'CLICK' would have to check if there was
valid data to save, inform the user if not, and SETFOCUS back to an
available EDITTEXT to let them key in the valid data.
My statement to John was that it's just not worth the hassle in MOST
programs (ie. they are entering criteria for a search or a printed list). I
have programs that DO exercise that type of control. I have one program
where I exercise just about every event and property available, including
the KEYPRESS so I can see if they hit the INSERT key and change the OVERTYPE
PROPERTY of the edittext accordingly, and let them use the arrow keys to
mosey through the edittext fields (for some reason, my users hate to pick up
the mouse!)
I agree that we have to be willing to share our ideas! I've been sharing
MANY of mine.
David Gabler
Apollo Software
Topic: GOT/LOST FOCUS (7 of 10), Read 43 times
Conf: Tech Support
From: Bill Leidy
Date: Friday, September 11, 1998 12:32 AM
David:
I am most appreciative of all of the time spent by you, Harry, John, and the
others in sharing your expertise - you(all) have saved me literally hundreds
of hours over the past year or so that this board has been in Existence.
I also am most appreciative of Sunbelt (always have been, always will be) -
they well understand who they are developing for, and do a first rate job.
They are so much more responsive than the Visual Whatever ++ people.
However -
1. I am still convinced that field editing is more appropriate for heavy
data entry applications than full screen editing (Is anyone else old enough
to remember CICS?).
2. PL/B programmers understand data processing (as opposed to office
automation) much better than the VBE or even C programmers (unless they are
converts like Bud). It is up to us to carry the flag.
3. The language (especially in the hands of responsive people like Sunbelt)
can be made to work in whatever way we choose.
The bottom line is that I want to make decisions about processing flow based
on what I feel is most logical without being restricted by the capabilities
of the language. Am I alone here?
Again I am most appreciative of all you have to say, David, and I hope I
have not offended.
Bill Leidy
Chickasaw Telephone Co.
Topic: GOT/LOST FOCUS (8 of 10), Read 46 times
Conf: Tech Support
From: Harry Rathsam
Date: Friday, September 11, 1998 02:41 AM
Dear Bill,
In keeping with the GETFOCUS, LOSTFOCUS, here's another thing to consider in
the "top to bottom" method vs. the GUI method.
We also have several "older" clients that want strictly data entry WITHOUT
moving the mouse.
Several steps to take to accomplish the same thing (I know...It's a long one
again!!)
1) Do not have the "DEFAULT" option set to TRUE for any of the BUTTONS (i.e.
OK). This will allow your user(s) to press the ENTER key if they so choose
to move from field to field.
2) Remember...In GUI vs. Top Down...You are probably NOT too concerned about
which field receives the FOCUS so much as which field LOSES the FOCUS. For
example, in a Top Down program, you are WAITING until they press enter, and
then you verify the keyin or read a record, etc. Keeping this in mind, you
can then perform a CALL to your routine(s) that you would normally check in
a top down program.
3) If you do indeed setup a routine that checks ALL of the fields for their
integrity, simply perform a call when each field LOSES FOCUS. If the OK
Button is pressed, you can then call a routine called "CHECKALL" that will
process each of the above CALLS to make certain that somebody didn't "jump
the gun" and move down to the OK button.
(Whew...almost done!!)
For example, think of a simple customer maintenance screen that has both a
zip code and city field. You want to make certain that both fields are
entered before adding this customer. If the user enters the CITY edittext
field, when he leaves the field (i.e. ENTER key, mouse movement, etc.), you
can then retrieve the objects information and determine if the field is
blank. If it is, simply reset the FOCUS back to the CITY field.
What if we only wanted to enter a ZipCode and have the city automatically
filled in based upon what zipcode is entered. Once again...If the ZipCode
field gains FOCUS at some point, it will also "LOSE" FOCUS as well (get the
picture).
At this point...Retrieve the info in the ZipCode edittext field, read your
ZipCode/City file and set the City edittext based upon the Zip Code.
(For Bonus points)....
What if the city field was already entered and THEN you enter the ZipCode
(Let's say somebody used the mouse to "skip" fields)
How 'bout a dialog box asking/verifying asking if we should override the
City field with our City (based on the ZipCode).
Harry Rathsam
(Coming up for air now...Sorry for the long explanation...Hope it helps)
Topic: GOT/LOST FOCUS (9 of 10), Read 45 times
Conf: Tech Support
From: Bill Leidy
Date: Friday, September 11, 1998 11:47 AM
Thanks, Harry!
I think the thing to do is take one of my existing file maintenance programs
- one that is fairly simple but has two fields that are interdependent (as
in your example), and try applying your techniques.
Bill Leidy
Chickasaw Telephone Co.
(Programmers do it top down)
Topic: GOT/LOST FOCUS (10 of 10), Read 43 times
Conf: Tech Support
From: John Shrimski
Date: Friday, September 11, 1998 10:25 PM
I've been Sitting on the side-line monitoring this discussion and it really
is a very interesting one.
I've had full GUI PLBWIN systems in the field for over 2 years now and I
must say I'm absolutely delighted (and my users are too), with the
flexibility of Sunbelts' implementation that has allowed me to :-
1. Provide very visual data entry ( using mouse clicks)
2. Have totally blind high-speed data entry (using only the numeric key
pad)but still GUI via EDITTEXTs
3. Have some editting at a field level
4. Have other editting at a form level
... and to have all of this in the one entry form.
I mean, its really up to you to skin the cat any way you like ....you can
mix and match... i.e.,provide 1 set of tools for novice entry personnel and
provide a different set for experience users .....and allow the users the
choice.
If I sound pleased with the product and the whole GUI environment... you're
right...I am.
John Shrimski
v1.10