v1.10
509 Center
Bay City, Michigan
Sales (989) 892-9242 Support (989) 686-8860
|
v1.10 |
509 Center Bay City, Michigan Sales (989) 892-9242 Support (989) 686-8860 |
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 |
Send e-mail to MMCC. |