List boxes in Microfocus Dialog System/Net Express?

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.

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

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.

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.

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.

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.

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.

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 doe
s
>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

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.

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).
>

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...

Never mind. Wrong group.