Cobol - List boxes in Microfocus Dialog System/Net Express?

Author

List boxes in Microfocus Dialog System/Net Express?

TofuTheGreat

2004-09-13, 3:55 am

I've got a legacy system with all GUI's built with Dialog System. I
needed to add a "status" field to the client record (pic 9(1) with
valid values of 1-6). I then added a drop-down listbox to the GUI so
the users wouldn't be required to remember 6 codes for data entry.
The listbox shows the acceptable choices for the field (1-Not
Applicable, 2-In Assessment, 3-Recommended, 4-Not Recommended,
5-Enrolled, and 6-Not Enrolled).

When the user selects an item from the list I correctly capture the
item's row number and store it in the client record's status field.
However when I go back and bring up a client's record I can't get the
listbox to "jump" to the listbox row that matches the value in the
record's status field. In other words if the status field holds a
value of 3 then I want the GUI list box to be positioned to
"3-Recommended").

I've tried using the SET-LIST-ITEM-STATE (Set a list item state to
selected or unselected) and SET-TOP-LIST-ITEM (Set a specified
occurrence of a group data item to be the first visible item of a list
box) functions when the record is retrieved and the window is
refreshed. Examples:

SET-LIST-ITEM-STATE CBO-DRUG-COURT 1 MCS-DC-STATUS(1)
SET-TOP-LIST-ITEM CBO-DRUG-COURT MCS-DC-STATUS(1)

Instead of positioning the listbox to the row that I want a new row is
always added to the bottom of the list with the text of the row being
the numeric value of the field. What am I doing wrong? The
documentation and examples for Dialog System is absolutely ZERO help.
In fact I've found that Microfocus' documentation just flat sucks.

docdwarf@panix.com

2004-09-13, 8:55 am

In article <uv84k0p0qs59fdo7cl9kegh2bdl8fi8vd3@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>Not being a Dialog user, I don't know the answer, but here's the
>approach I'd take.
>
>Numbers were invented for the convenience of IT, to abbreviate reasons
>down to one digit.

Ah yes, I remember the meeting of the Great IT Cabal that decided this...
it was some time around MDCLXVIII or so.

>From the users' point of view, numbers don't add
>any information, they're just noise. I'd hide numbers from the user
>and Dialog.

(note - please pardon the errors I will make in terminology in my
following suggestion; I am not as familiar with GUI interfaces as I am
with greenscreen)

Mr Wagner, it is my experience that those who speak of 'the user' are
about to offer a one-size-fits-none solution; from what I have seen there
are many different kinds of users and programmer of competence will
consider that when writing an interface. This was an approach used even
by IBM in the 1970's for ISPF... menu-driven or command-line, the choice
was the user's.

Another view, then... there are times when using a drop-down box that one
can enter text; this is a feature I've seen on web-form where one has to
fill in, say, a state-code; one can type in one's code or drop down a list
of the whole state-code table. With the table highlighted one can then,
say, type an 'M' and the first 'M' entry - MA - will be highlighted and
ready for selection, a second M will bring you down to the next one - MD -
, a third tap and you're at ME. During times when I have sat and watched
people use systems I have seen users apply all three approaches... some
would type in ME, some would click, drag down and highlight and some would
click to highlight and then tap M three times. I will leave it to the
self-important to argue about which method is 'right'... from what I saw
different folks were comfortable with different methods and all three
allowed for a level of productivity with which their managers were
comfortable.

>Describe the screen field as 20 bytes long. In your
>software, translate the number to a description and send that to the
>screen. On the way back, translate the description to a number.
>
>The screen should come up with a description supplied by you, not
>supplied by the drop-down. You could fancy it up by color-coding the
>matching drop-down entry different from the others.

One size fits none *and* 'make sure the users know whose choices are
paramount', it seems... for what reasons is this method superior to
defaulting to an 'Reason code here' description, a drop-down that shows
the numbers followed by the descriptions and a mechanism as noted above
which will position the selection to the number pressed?

That way some can select by text and others will type a digit and move on.
Whatever the method the first character of the field will contain a
number... or it will contain an 'R' from the default 'Reason code here'
description and can be the reason to throw an error.

DD

TofuTheGreat

2004-09-13, 3:55 pm

Hmmm.. Apparently I wasn't quite clear enough in my description. The
listbox is question is called a "Selection Box" in Dialog System and
it's optional type is a "drop down list". If you're familiar with VB
it should be analogous to a "ComboBox" drop-down (but isn't proving to
be). The actual values of the list items are (in order) the static
text entries of:
Not Applicable
In Assessment
Recommended
Not Recommended
Enrolled
Not Enrolled

There aren't actually numbers in the visible text of the choices.
What you see above is exactly what's shown to the user. The numbers
are the row indexes of the drop-down and that's the value that's
written to file. Dialog System's listbox rows start at 1.

I don't have room in the file to make the field bigger without
ballooning the size of the file. The system still uses indexed
sequential files (definitely NOT BY MY CHOICE!). Talk to the
powers-that-be and you'll see why.

Back to the problem at hand, the ordering of the items is indeed in
the order of most frequent use. The picture string for the box is pic
9(1) (see where the row number comes in to play?). The idea is that
the user can ONLY choose those items from the list.

The interface works quite well for choosing the status from the list
and storing it in the client's record. However these status values
change over time and need to be updated and that's where my
interface's problems are starting. When I bring up a client's record
to change their status (i.e. from In Assessment to Recommended, from
Recommended to Enrolled, etc.) that's when I encounter the problems
described in my previous post.

I want the interface to reflect what the client's current status is,
in text form, when I pull up the record from the file. This is not
occuring and that's what I'm trying to solve.

There isn't enough screen real estate to move to radio buttons or
check boxes. The data-entry flow isn't conducive to the addition of
yet another window to the process (this window is for a small sub-set
of the clientele).

> Which reminds me - Mr. Tofu - have you done a thorough check against the
> Dialog System manual on ComboBoxes. There *just HAS TO BE * a demo on
> Droplists. It wont necessarily be apparent from the demo project titles
> - you will probably have to confirm by reading the accompanying
> readme.txt for each demo project. The following (Gotcha !) is from the
> GUI class on-line help :-

I have gone through the Master Index multiple times. I've read
through the knowledge base on MicroFocus' website. I've posted to the
forums they host on their supportline website.

The only documentation and examples that I've been able to locate show
how to:
1- Add items to the list using groups
2- Add items using Dialog
3- Add items using a delimited string
4- How to delete items from the list

None of the examples I've found show how to accomplish what I'm trying
to accomplish. Mr. Gavan's reference to the selectionBox object DOES
NOT apply here. Dialog System is very much a beast of its own.

Robert Wagner

2004-09-13, 3:55 pm

You said you were able to add an item to the bottom of the list by
calling SET-TOP-LIST-ITEM with "1". I'd try calling with "In
Assessment" to see what happens. There's a fair chance it will
recognize an exact match.

On 13 Sep 2004 07:12:17 -0700, cswearingen@co.wood.wi.us
(TofuTheGreat) wrote:

>Hmmm.. Apparently I wasn't quite clear enough in my description. The
>listbox is question is called a "Selection Box" in Dialog System and
>it's optional type is a "drop down list". If you're familiar with VB
>it should be analogous to a "ComboBox" drop-down (but isn't proving to
>be). The actual values of the list items are (in order) the static
>text entries of:
> Not Applicable
> In Assessment
> Recommended
> Not Recommended
> Enrolled
> Not Enrolled
>
>There aren't actually numbers in the visible text of the choices.
>What you see above is exactly what's shown to the user. The numbers
>are the row indexes of the drop-down and that's the value that's
>written to file. Dialog System's listbox rows start at 1.
>
>I don't have room in the file to make the field bigger without
>ballooning the size of the file. The system still uses indexed
>sequential files (definitely NOT BY MY CHOICE!). Talk to the
>powers-that-be and you'll see why.
>
>Back to the problem at hand, the ordering of the items is indeed in
>the order of most frequent use. The picture string for the box is pic
>9(1) (see where the row number comes in to play?). The idea is that
>the user can ONLY choose those items from the list.
>
>The interface works quite well for choosing the status from the list
>and storing it in the client's record. However these status values
>change over time and need to be updated and that's where my
>interface's problems are starting. When I bring up a client's record
>to change their status (i.e. from In Assessment to Recommended, from
>Recommended to Enrolled, etc.) that's when I encounter the problems
>described in my previous post.
>
>I want the interface to reflect what the client's current status is,
>in text form, when I pull up the record from the file. This is not
>occuring and that's what I'm trying to solve.
>
>There isn't enough screen real estate to move to radio buttons or
>check boxes. The data-entry flow isn't conducive to the addition of
>yet another window to the process (this window is for a small sub-set
>of the clientele).
>
>
>I have gone through the Master Index multiple times. I've read
>through the knowledge base on MicroFocus' website. I've posted to the
>forums they host on their supportline website.
>
>The only documentation and examples that I've been able to locate show
>how to:
>1- Add items to the list using groups
>2- Add items using Dialog
>3- Add items using a delimited string
>4- How to delete items from the list
>
>None of the examples I've found show how to accomplish what I'm trying
>to accomplish. Mr. Gavan's reference to the selectionBox object DOES
>NOT apply here. Dialog System is very much a beast of its own.

Barry Harris

2004-09-13, 3:55 pm

I would guess that the problem is with initial value in the master field
associated with the selection box.

The Dialog System default behaviour is if the value in the master field does
not match the value of any row in the selection box it is then added to the
end of the list.

It sounds like the numeric value rather than the associated text is being
entered into the master field and as this does not match any of the rows it
is then added to the end of the list.

"TofuTheGreat" <cswearingen@co.wood.wi.us> wrote in message
news:5cd073b7.0409130612.744633ff@posting.google.com...
> Hmmm.. Apparently I wasn't quite clear enough in my description. The
> listbox is question is called a "Selection Box" in Dialog System and
> it's optional type is a "drop down list". If you're familiar with VB
> it should be analogous to a "ComboBox" drop-down (but isn't proving to
> be). The actual values of the list items are (in order) the static
> text entries of:
> Not Applicable
> In Assessment
> Recommended
> Not Recommended
> Enrolled
> Not Enrolled
>
> There aren't actually numbers in the visible text of the choices.
> What you see above is exactly what's shown to the user. The numbers
> are the row indexes of the drop-down and that's the value that's
> written to file. Dialog System's listbox rows start at 1.
>
> I don't have room in the file to make the field bigger without
> ballooning the size of the file. The system still uses indexed
> sequential files (definitely NOT BY MY CHOICE!). Talk to the
> powers-that-be and you'll see why.
>
> Back to the problem at hand, the ordering of the items is indeed in
> the order of most frequent use. The picture string for the box is pic
> 9(1) (see where the row number comes in to play?). The idea is that
> the user can ONLY choose those items from the list.
>
> The interface works quite well for choosing the status from the list
> and storing it in the client's record. However these status values
> change over time and need to be updated and that's where my
> interface's problems are starting. When I bring up a client's record
> to change their status (i.e. from In Assessment to Recommended, from
> Recommended to Enrolled, etc.) that's when I encounter the problems
> described in my previous post.
>
> I want the interface to reflect what the client's current status is,
> in text form, when I pull up the record from the file. This is not
> occuring and that's what I'm trying to solve.
>
> There isn't enough screen real estate to move to radio buttons or
> check boxes. The data-entry flow isn't conducive to the addition of
> yet another window to the process (this window is for a small sub-set
> of the clientele).
>
>
> I have gone through the Master Index multiple times. I've read
> through the knowledge base on MicroFocus' website. I've posted to the
> forums they host on their supportline website.
>
> The only documentation and examples that I've been able to locate show
> how to:
> 1- Add items to the list using groups
> 2- Add items using Dialog
> 3- Add items using a delimited string
> 4- How to delete items from the list
>
> None of the examples I've found show how to accomplish what I'm trying
> to accomplish. Mr. Gavan's reference to the selectionBox object DOES
> NOT apply here. Dialog System is very much a beast of its own.

Robert Wagner

2004-09-13, 3:55 pm

You said you were selecting a line with:

SET-LIST-ITEM-STATE CBO-DRUG-COURT 1 MCS-DC-STATUS(1)

The Dialog manual gives this syntax in 17.4.1:

SET-LIST-ITEM-STATE SALES-LB 1 $REGISTER

where 1 appears to be the selected status (MCS-DC-STATUS(1)) and
$REGISTER is the line number you're selecting. Looks like you got the
parameters backwards and are likely to have a type mismatch on the
rightmost. Try putting line number into the predefined $REGISTER.

On 13 Sep 2004 07:12:17 -0700, cswearingen@co.wood.wi.us
(TofuTheGreat) wrote:

>Hmmm.. Apparently I wasn't quite clear enough in my description. The
>listbox is question is called a "Selection Box" in Dialog System and
>it's optional type is a "drop down list". If you're familiar with VB
>it should be analogous to a "ComboBox" drop-down (but isn't proving to
>be). The actual values of the list items are (in order) the static
>text entries of:
> Not Applicable
> In Assessment
> Recommended
> Not Recommended
> Enrolled
> Not Enrolled
>
>There aren't actually numbers in the visible text of the choices.
>What you see above is exactly what's shown to the user. The numbers
>are the row indexes of the drop-down and that's the value that's
>written to file. Dialog System's listbox rows start at 1.
>
>I don't have room in the file to make the field bigger without
>ballooning the size of the file. The system still uses indexed
>sequential files (definitely NOT BY MY CHOICE!). Talk to the
>powers-that-be and you'll see why.
>
>Back to the problem at hand, the ordering of the items is indeed in
>the order of most frequent use. The picture string for the box is pic
>9(1) (see where the row number comes in to play?). The idea is that
>the user can ONLY choose those items from the list.
>
>The interface works quite well for choosing the status from the list
>and storing it in the client's record. However these status values
>change over time and need to be updated and that's where my
>interface's problems are starting. When I bring up a client's record
>to change their status (i.e. from In Assessment to Recommended, from
>Recommended to Enrolled, etc.) that's when I encounter the problems
>described in my previous post.
>
>I want the interface to reflect what the client's current status is,
>in text form, when I pull up the record from the file. This is not
>occuring and that's what I'm trying to solve.
>
>There isn't enough screen real estate to move to radio buttons or
>check boxes. The data-entry flow isn't conducive to the addition of
>yet another window to the process (this window is for a small sub-set
>of the clientele).
>
>
>I have gone through the Master Index multiple times. I've read
>through the knowledge base on MicroFocus' website. I've posted to the
>forums they host on their supportline website.
>
>The only documentation and examples that I've been able to locate show
>how to:
>1- Add items to the list using groups
>2- Add items using Dialog
>3- Add items using a delimited string
>4- How to delete items from the list
>
>None of the examples I've found show how to accomplish what I'm trying
>to accomplish. Mr. Gavan's reference to the selectionBox object DOES
>NOT apply here. Dialog System is very much a beast of its own.

Robert Wagner

2004-09-13, 3:55 pm

Not being a Dialog user, I don't know the answer, but here's the
approach I'd take.

Numbers were invented for the convenience of IT, to abbreviate reasons
down to one digit. From the users' point of view, numbers don't add
any information, they're just noise. I'd hide numbers from the user
and Dialog. Describe the screen field as 20 bytes long. In your
software, translate the number to a description and send that to the
screen. On the way back, translate the description to a number.

The screen should come up with a description supplied by you, not
supplied by the drop-down. You could fancy it up by color-coding the
matching drop-down entry different from the others.

Generally, talk to users in their own language. They're not appendages
to IT and have no investment in its codes. Don't rely on Dialog to do
the translation, do it yourself.

On 10 Sep 2004 08:30:04 -0700, cswearingen@co.wood.wi.us
(TofuTheGreat) wrote:

>I've got a legacy system with all GUI's built with Dialog System. I
>needed to add a "status" field to the client record (pic 9(1) with
>valid values of 1-6). I then added a drop-down listbox to the GUI so
>the users wouldn't be required to remember 6 codes for data entry.
>The listbox shows the acceptable choices for the field (1-Not
>Applicable, 2-In Assessment, 3-Recommended, 4-Not Recommended,
>5-Enrolled, and 6-Not Enrolled).
>
>When the user selects an item from the list I correctly capture the
>item's row number and store it in the client record's status field.
>However when I go back and bring up a client's record I can't get the
>listbox to "jump" to the listbox row that matches the value in the
>record's status field. In other words if the status field holds a
>value of 3 then I want the GUI list box to be positioned to
>"3-Recommended").
>
>I've tried using the SET-LIST-ITEM-STATE (Set a list item state to
>selected or unselected) and SET-TOP-LIST-ITEM (Set a specified
>occurrence of a group data item to be the first visible item of a list
>box) functions when the record is retrieved and the window is
>refreshed. Examples:
>
> SET-LIST-ITEM-STATE CBO-DRUG-COURT 1 MCS-DC-STATUS(1)
> SET-TOP-LIST-ITEM CBO-DRUG-COURT MCS-DC-STATUS(1)
>
>Instead of positioning the listbox to the row that I want a new row is
>always added to the bottom of the list with the text of the row being
>the numeric value of the field. What am I doing wrong? The
>documentation and examples for Dialog System is absolutely ZERO help.
>In fact I've found that Microfocus' documentation just flat sucks.

James J. Gavan

2004-09-13, 3:55 pm

Barry Harris wrote:

>I would guess that the problem is with initial value in the master field
>associated with the selection box.
>
>
>
>The Dialog System default behaviour is if the value in the master field does
>not match the value of any row in the selection box it is then added to the
>end of the list.
>
>
>
>It sounds like the numeric value rather than the associated text is being
>entered into the master field and as this does not match any of the rows it
>is then added to the end of the list.
>
>Chris,
>
>

Barry is still on the same tack as me - although he refers to it as a
Dialog System default - think either GUIs or Dialog System they are
following the Win API defaults. Take the following '^' means spaces :-

you make a list (presumably in your Data block) which becomes the
contents of the DropdownList when displayed. :

"Not Applicable^^^^^^"

For an existing record you have say the code "NA" in your file. When
trying to show the meaningful name in your TEXT AREA of the Droplist
(which is a separate object), then you must pick up the same entry from
the Dropdown Collection and display in the TEXT AREA. - alternatively
you can build a separate object - but that's really not required.

If you only try to enter "Not Applicable" into your Text Area, sure
enough, the next time you display the dropdown list it will show :-

"Not Applicable^^^^^^"
"Not Applicable"

Pursue this one through Answer Exchange.

Jimmy, Calgary AB

Richard

2004-09-13, 3:55 pm

cswearingen@co.wood.wi.us (TofuTheGreat) wrote

> Hmmm.. Apparently I wasn't quite clear enough in my description. The
> listbox is question is called a "Selection Box" in Dialog System and
> it's optional type is a "drop down list". If you're familiar with VB
> it should be analogous to a "ComboBox" drop-down (but isn't proving to
> be). The actual values of the list items are (in order) the static
> text entries of:
> Not Applicable
> In Assessment
> Recommended
> Not Recommended
> Enrolled
> Not Enrolled
>
> There aren't actually numbers in the visible text of the choices.
> What you see above is exactly what's shown to the user. The numbers
> are the row indexes of the drop-down and that's the value that's
> written to file. Dialog System's listbox rows start at 1.
>
> I don't have room in the file to make the field bigger without
> ballooning the size of the file. The system still uses indexed
> sequential files (definitely NOT BY MY CHOICE!). Talk to the
> powers-that-be and you'll see why.
>
> Back to the problem at hand, the ordering of the items is indeed in
> the order of most frequent use. The picture string for the box is pic
> 9(1) (see where the row number comes in to play?). The idea is that
> the user can ONLY choose those items from the list.
>
> The interface works quite well for choosing the status from the list
> and storing it in the client's record. However these status values
> change over time and need to be updated and that's where my
> interface's problems are starting. When I bring up a client's record
> to change their status (i.e. from In Assessment to Recommended, from
> Recommended to Enrolled, etc.) that's when I encounter the problems
> described in my previous post.

I have never used MF Dialog so I can't be specific.

I generally don't use comboboxes very much. For that specific
functionality I would probably put the status up as a text, with a
default for new records, and have a 'change status' button or function
key to bring up a specific change status dialog. This would be a list
box or radio button group or similar with a 'confirm' and 'cancel'
button.

It would seem to me that a change of status may be a rather important
step and doing it this way gives an opportunity to validate the change
and to log it in a audit list or similar (along with the login user
name and date/time so you know who did it and when).

I would also tend to avoid using the 'frequency' as being the status
code. I would probably use A - Z as status codes, perhaps space as
'not applicable', and have these in my 'decode file' which is a
general holdall for various codes identified by field name and value
(ie an isam file with a key of 'field' (in this case 'STATUS') and
'code'. This would hold the descriptions and the current ranking
value to sort to before adding to the list.

However, I would tend to have the list ordered by logical step so that
it would be normal to move just one along the list, which is roughly
what your list seems to be.

JerryMouse

2004-09-13, 8:55 pm

James J. Gavan

2004-09-14, 3:55 pm

TofuTheGreat wrote:

>Hmmm.. Apparently I wasn't quite clear enough in my description. The
>listbox is question is called a "Selection Box" in Dialog System and
>it's optional type is a "drop down list". If you're familiar with VB
>it should be analogous to a "ComboBox" drop-down (but isn't proving to
>be). The actual values of the list items are (in order) the static
>text entries of:
> Not Applicable
> In Assessment
> Recommended
> Not Recommended
> Enrolled
> Not Enrolled
>
>There aren't actually numbers in the visible text of the choices.
>What you see above is exactly what's shown to the user. The numbers
>are the row indexes of the drop-down and that's the value that's
>written to file. Dialog System's listbox rows start at 1.
>
>I don't have room in the file to make the field bigger without
>ballooning the size of the file. The system still uses indexed
>sequential files (definitely NOT BY MY CHOICE!). Talk to the
>powers-that-be and you'll see why.
>
>Back to the problem at hand, the ordering of the items is indeed in
>the order of most frequent use. The picture string for the box is pic
>9(1) (see where the row number comes in to play?). The idea is that
>the user can ONLY choose those items from the list.
>
>The interface works quite well for choosing the status from the list
>and storing it in the client's record. However these status values
>change over time and need to be updated and that's where my
>interface's problems are starting. When I bring up a client's record
>to change their status (i.e. from In Assessment to Recommended, from
>Recommended to Enrolled, etc.) that's when I encounter the problems
>described in my previous post.
>
>I want the interface to reflect what the client's current status is,
>in text form, when I pull up the record from the file. This is not
>occuring and that's what I'm trying to solve.
>
>There isn't enough screen real estate to move to radio buttons or
>check boxes. The data-entry flow isn't conducive to the addition of
>yet another window to the process (this window is for a small sub-set
>of the clientele).
>
>
>
>
>I have gone through the Master Index multiple times. I've read
>through the knowledge base on MicroFocus' website. I've posted to the
>forums they host on their supportline website.
>
>The only documentation and examples that I've been able to locate show
>how to:
>1- Add items to the list using groups
>2- Add items using Dialog
>3- Add items using a delimited string
>4- How to delete items from the list
>
>None of the examples I've found show how to accomplish what I'm trying
>to accomplish. Mr. Gavan's reference to the selectionBox object DOES
>NOT apply here. Dialog System is very much a beast of its own.
>
>
Chris,

Understand you can't exceed pic 9(01) - because that's how the file is
set up. However I don't buy your bit about 'real-estate'. Like you I
prefer to put it all in one window/dialog - however, there's always the
option of using child windows/dialogs.

Now I'm floundering because I don't know Dialog System - but I did take
a cursory look when it became 'active' again within Net Express - it
wasn't in its predecessor VISOC.

Go take a look at :\Dialog System\Demo\Objects - which contains quite a
number of controls. Check the source and from the IDE do a search "ALL"
getting you a reference to selbox.gs. You probably want to take a look
at selbox.cpb as well. The sub-menu demo for SelectionBox/ComboBox
contains all three lists, SimpleCombo, DropCombo and DropListCombo - the
latter being the one you are interested in. Somewhere tucked in one of
the 'support files', is the table for the 12 months.
Note the demo uses an ORDERED Collection to contain the month objects,
and it is the OrderedCollection you are seeing in the DropDownList, the
months being sequenced 1 to 12..

So when you select from the DropDowList say "May", it is using Index
Position 5 to put the ''OBJECT' into the displayable TEXT AREA
associated with the ComboBox. Now here's where you have to do some
sleuthing. I know, but can't remember, that you can 'Animate' the Dialog
System code contained in 'object' or 'data' whatever it is called.. So
using the Animator PAUSE as appropriate you have got to follow the
sequence when you have selected a month - see how it extracts the month
object from the dropdown list and puts the same object into the
displayable text area. (From memory I think you can do a separate
'Animate' testing the GS code, letting it flow through the Dialog System
'internal' code).

Let's go back to your list -

Not Applicable
In Assessment
Recommended
Not Recommended
Enrolled
Not Enrolled

You said they were static 'cast in stone'. Fine - Your can produce
either an Ordered or Sorted Collection to go into the droplist
(providing you don't subsequently introduce a new 'Partially Enrolled)".
If above is how you want them to appear, make the 'table' wherever it is
stored (just like the Months in the demo) an Ordered list. As you select
'Recommended' (Index # 3) from the Collection it is the object for #3
which appears in the Text Area and you store '3' in your file record.
When you come to display a previously stored record, say 'Not
Recommended' which should be #4 above, then again using the Ordered
Collection pick up the object for Index # 4 and display it in the Text
Area. But you'll have to follow the original GS code for 'Months' to see
how they extracted the Collection entry to appear in the Text Area.

Some droplists are 'cast in stone'. I have a droplist for Vessels at
oil/gas plants (think of the hot water tank in your basement with pipes
going in at the top and pipes flowing out of the bottom) - historically
they are static categories, going back decades - (1) Active, (2)
Inactive - not currently used in the production process and (3) Shutin -
equipment removed and probably concreted over.

So I can set my file record as :-

01 VesselRecord.
05 PrimeKey pic x(?)
05 Activity pic 9.
88 Active value 1.
88 Inactive value 2.
88 Shutin value 3.
88 ValidActivity value 1 thru 3.
05 etc........

I can even do a Validity check using 'ValidActivity'.

So good luck - that's the nearest I can get for you.

Jimmy, Calgary AB

LX-i

2004-09-16, 3:55 am

JerryMouse wrote:
>
> Heck, even I tried it. Here's what I did:
>
> I fired up Word and, using the default settings, Times Roman 11.5pt, I typed
> the memo and printed it. I then scanned the printed copy back in to a GIF
> file at 600dpi.
>
> The comparison was... was...

yes? .... YES??????

> Never mind. Wrong group.

shucks.... ;)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Robert Wagner

2004-09-16, 3:55 am

On 10 Sep 2004 19:02:08 -0400, docdwarf@panix.com wrote:

>In article <uv84k0p0qs59fdo7cl9kegh2bdl8fi8vd3@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
[color=darkred]
>
>(note - please pardon the errors I will make in terminology in my
>following suggestion; I am not as familiar with GUI interfaces as I am
>with greenscreen)
>
>Mr Wagner, it is my experience that those who speak of 'the user' are
>about to offer a one-size-fits-none solution; from what I have seen there
>are many different kinds of users and programmer of competence will
>consider that when writing an interface. This was an approach used even
>by IBM in the 1970's for ISPF... menu-driven or command-line, the choice
>was the user's.

I've never seen a command line on a GUI screen. When something like
that is needed, for instance entering a search key, the convention is
to put it in a pop-over window.

>Another view, then... there are times when using a drop-down box that one
>can enter text; this is a feature I've seen on web-form where one has to
>fill in, say, a state-code; one can type in one's code or drop down a list
>of the whole state-code table. With the table highlighted one can then,
>say, type an 'M' and the first 'M' entry - MA - will be highlighted and
>ready for selection, a second M will bring you down to the next one - MD -
>, a third tap and you're at ME. During times when I have sat and watched
>people use systems I have seen users apply all three approaches... some
>would type in ME, some would click, drag down and highlight and some would
>click to highlight and then tap M three times. I will leave it to the
>self-important to argue about which method is 'right'... from what I saw
>different folks were comfortable with different methods and all three
>allowed for a level of productivity with which their managers were
>comfortable.

A picklist for State is one of my peeves. How long does it take to
type two letters? With some controls, M takes you to MA, the following
E takes you to FL.

For this style of selection to work, the list must be sorted. Did you
ever see a Country list on a Web site that gets 98% of its business
from United States, but makes you scroll through hundreds of countries
to find US? In that case, the most commonly-used countries should be
at the top.

>
>One size fits none *and* 'make sure the users know whose choices are
>paramount', it seems... for what reasons is this method superior to
>defaulting to an 'Reason code here' description, a drop-down that shows
>the numbers followed by the descriptions and a mechanism as noted above
>which will position the selection to the number pressed?

My method is superior because it answers the question that was asked.

When displaying an existing client, Tofu wants a status description to
appear in the box. "Reason code here" is a Title, not data. It belongs
above the box, not inside.

docdwarf@panix.com

2004-09-16, 3:55 pm

In article <t6r6k0djfp0og6fa4fvmj57rcbdv80uf4h@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 10 Sep 2004 19:02:08 -0400, docdwarf@panix.com wrote:
>
>
>
>I've never seen a command line on a GUI screen.

That might be a reason why I mentioned it as being in mainframe ISPF, Mr
Wagner.

>When something like
>that is needed, for instance entering a search key, the convention is
>to put it in a pop-over window.

The implementation might vary over platforms, then, but the intention
appears to be similar... a multitude of ways to separate a feline from its
pelt, as it were.

>
>
>A picklist for State is one of my peeves. How long does it take to
>type two letters?

As long as is needed, Mr Wagner.

>With some controls, M takes you to MA, the following
>E takes you to FL.
>
>For this style of selection to work, the list must be sorted.

Sorting is something that a competent programmer has been known to force a
computer to do, Mr Wagner... are you surprised?

>Did you
>ever see a Country list on a Web site that gets 98% of its business
>from United States, but makes you scroll through hundreds of countries
>to find US?

No, Mr Wagner, I've never seen such a thing... but I will admit to having
limited experience.

>In that case, the most commonly-used countries should be
>at the top.

Or it might be that work is batched and parcelled out among the operators,
in which case it might be wiser to leave the equivalent of WS-PREV-COUNTRY
in the field.

>
>
>My method is superior because it answers the question that was asked.

Your method is inferior because it relies on someone else supplying the
proper question instead of the programmer taking responsibility for
knowing the proper answer... see how easy it is to make assertions?

>
>When displaying an existing client, Tofu wants a status description to
>appear in the box.

After learning something new what is wanted might change, Mr Wagner; not
everyone is stagnant.

DD

Robert Wagner

2004-09-16, 3:55 pm

On 11 Sep 2004 21:33:32 -0400, docdwarf@panix.com wrote:

>In article <t6r6k0djfp0og6fa4fvmj57rcbdv80uf4h@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

>
>After learning something new what is wanted might change, Mr Wagner; not
>everyone is stagnant.

Sounds line an enigmatic Zen answer .. perhaps found in a fortune
cookie.

James J. Gavan

2004-09-17, 3:55 am

JerryMouse

2004-09-17, 8:55 pm

Robert Wagner

2004-09-17, 8:55 pm

LX-i

2004-09-18, 3:55 pm

Robert Wagner wrote:
>
> A picklist for State is one of my peeves. How long does it take to
> type two letters? With some controls, M takes you to MA, the following
> E takes you to FL.

Yes, but what do you do when they type "MZ"?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Sponsored Links