View previous topic :: View next topic
|
Author |
Message |
Ravishankar_SAT
New User
Joined: 10 May 2007 Posts: 9 Location: Chennai
|
|
|
|
Hi,
We have a DC screen with editable fields formatted with 3 columns and 10 rows.Now when TAB key is pressed,the cursor moves horizontally from 1st of 1st column to 1st row of 2nd column.
But we need to handle the cursor Vertically,i.e.the cursor should move from 1st of 1st column to 2nd row of 1st column.Moreover once the last row of 1st column is reached it should move to 1st row of second column.
kindly anyone help me out to handle the cursor Vertically.
Thanks
Ravishankar |
|
Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
|
|
|
|
If you need to edit the horizontal fields, there is no way to do it - unless something new has been invented. Unprotected fields go from left to right and then down - just like and IMS database. Why do you need to handle vertically? You could do it by protecting all fields in the columns that are not being entered. Then reinsert the screen after each column is entered and edited - which would be a lot of overhead and very messy. The big question in my mind is WHY? |
|
Back to top |
|
|
Ravishankar_SAT
New User
Joined: 10 May 2007 Posts: 9 Location: Chennai
|
|
|
|
Hi,
Thanks for your replay
We are extracting data from IMS database and displaying it in the DC Screen for user modifications.consider that first column has following Data
CUST INFO
NAME
FIRST NAME _________
MIDDLE NAME _________
LAST NAME _________
ADDRESS
CITY _________
...............
Similarly other two columns has similar group variables.so in such scenario once the user enters the FIRST NAME the cursor should position to MIDDLE NAME and respectively.once after all the fields in the screen edited,it will be updated in to database.
so Once the last row of first column reached it should go to first row of second column.so kindly tell me, how the screen can be reinserted if the tab key is pressed and it should work on the other way also SHIFT + TAB.
Regards,
Ravi. |
|
Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
What about a redesign of your screens? |
|
Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
|
|
|
|
Ravi - hate to tell you, but you should redesign the screen to go across and not up and down. Tell me if I am correct in my understanding of what you are saying. Are you inserting multiple customers to the same screen? On one pass? In other words, are you going thru the database and when you have multiple customers - you put up the screen? What criteria are you using to put these customers on the screen for modifications? When you insert the screen, are you positioning the cursor at the first modifiable field? Or, in the case of an error, the first field that is incorrect? How are updating multiple customers in the database with one pass? I hope I am not confusing you, because I certainly am scratching my head. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
The infamous "phone book" scroll. . .
A few places i've been implemented this by defining a tab-forward and a tab-backward pf-key. This allowed the users to "tab" down the left side column and continue with the top field of the second column and so forth.
If an entry was deleted, the code automagically shifted the remaining entries up and to the left. If an insert was needed, the entry to the bottom right was removed (if the screen was full) and space for a new entry was made at the point where the entry was to be placed.
It actually performed ok as there was no database activity or other i/o when tabbing around on the screen. |
|
Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
Hi Dick,
This is the IMS forum; did you really do this in IMS |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hi George,
No, it was done in a couple of CICS apps and one app that used a home-grown terminal manager.
Was thinking more of the logistics than the environment |
|
Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
Nice talking to you tonight and to Sandy as well. Now downstairs for a coffee followed by a Hole 19 Talk to you later this evening. |
|
Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
|
|
|
|
Dick - how very clever! George, I think Ravi needs to tell everyone what he really wants to accomplish. Such as - who designed the screen that way. This must be a new application? |
|
Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
Well, let's just wait till Ravi reacts.........until then we're just having fun and guessing. |
|
Back to top |
|
|
Ravishankar_SAT
New User
Joined: 10 May 2007 Posts: 9 Location: Chennai
|
|
|
|
Hai all,
Sandy,here we are not updating multiple customer information in one pass.
kindly find the brief flow.
Intially a call to the IMS database is been issued based on a key,which will fetch us all the information for a particular customer(single customer) all those information are shown in the screen but only few of those fields should be editable to the user.
Once after the editing is complete,the changed fileds are updated in the Database.More over the Screen is a NEW,and it is designed in such away that the look and feel of the screen is good.
i feel we will face one more constarint when we handle TAB key through program.Considering if last row of first column has an editable field of length 6 characters,once the user fills all the six characters,now the user neither Press Enter nor TAB key but the cursor automatically moves to the first row of first column which is not suppose to happen.
So Redesign of Screen will solve this complexity, but when we redesign the screen the look and feel of the screen is not up to the user Expectations. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
What is the problem with having the cursor automatically positioin to the "next" unprotected field (even if it is at the top)?
If the user has keyed data, they will most likely press Enter or a FunctionKey to interact with the program. When the requested action completes, the program should re-position the cursor wherever it should be. Having the cursor briefly on a field not just entered should be no problem.
Who dictates that this
Quote: |
but the cursor automatically moves to the first row of first column which is not suppose to happen.
|
is actually a problem?
Even if you re-design the screen, when you fill the last field on the screen the cursor will go to the "next" unprotected field (uness IMS does not process 3270 screens cointrols the same as tso/cics/vm-xedit/etc). I would caution against taking away the acceptable touch&feel for this "last field" situation. |
|
Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
|
|
|
|
Yes, Dick, this is the way IMS processes the screen. That screen needs to be re-designed because it will never work the way that Ravi wants.
I always did "full screen" editing - in other words the screen was fully edited until ALL unprotected fields on the screen were correct. When the user presses enter and all fields are correct, the screen should come back with all edited fields are the screen PROTECTED. A message should appear - "Update Y/N" or whatever. If the user enters "y", then the database is updated and an empty screen is presented. If the user enters "n", then the screen is presented with the data again unprotected.
The "tab" key should not even be an option. The cursor should always position at the first edited field and once that field is entered, continue to the next. Another good thing to do is position the cursor at the first field in error on multiple passes with the field highlighted. Ravi, if this were the ONLY fields to be updated, then the cursor will go down - your problem is that you have fields on the right side of the screen. Please consider something like this?
CUST INFO
First Name Middle Name Last Name
__________________ ___________ _________________________
ADDRESS
CITY State Zip
______________ ______________ _____ ____ |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
If there is a requirement that all fields be entered before an interrupt key is pressed, that sounds like a design flaw. If 4 of 10 fields are filled and Enter is pressed, the code should validate the fields with input data and place the cursor on the "first error" (personal favorite is that as errors are found, they are highlighted from the bottom-right to the top-left), leaving the cursor on the first error nearest the top-left. If there are no errors, but not all required fields are entered, the cursor would be placed on the "first" field that needed input before proceeding.
All of that is "style". My previous post was about the 3270 terminal. All of the application screens i've ever seen auto-tab when an unprotected field is filled. . . On the revised screen, how do you get to "middle name" from "first name" when "first name is not filled? I'd guess tab would be used.
Maybe i'm just really slow this morning. . . |
|
Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
|
|
|
|
No, I am slow this morning. Of course, if no changes to a field, then definitely use the "tab" key. Of course, you need not re-enter all fields on the screen. If you just have a change to the name, press enter or PF after your change and then the fields should come back protected - with the question "update?". |
|
Back to top |
|
|
|