Tracy writes:

> I've also had the pleasure of working with at least two quite similar sets
>  of character-mode screen drivers, which are not only very easy to code, but
>  produce _phenomenal_ performance on an MPE box due to very tiny
transactions
>  - literally hundreds of users running the same program see NO perceptible
>  delay, even on a small slow box.

That's been our experience as well.


Tracy also asks:

>  Unfortunately, using character mode greatly reduces your chances of
>  converting your user interface to web pages, which are essentially block
>  mode; so much so in fact that I'm considering re-engineering about a
hundred
>  char-mode programs to run VPLUS (or some other blockmode) as an interim
>  step.  (anybody got a better BLOCKMODE system than VPLUS?)

I think we have something that coming in QCTerm forms that's going to be
relatively spectacular, but you're going to have to use your imagination for
the moment to see it in its full glory. It's completely torn up at the moment
and in transition, but it does work. Sort of.

The forms mode for QCTerm has been languishing for nearly a year now simply
because we've been wholly consumed with other obligations, but it's time has
come and we expect to finish it up by about Christmas.

What I want to show you is some work that Frank Smith, an occasional poster
on this list, has been doing. Using a relatively new version of QCTerm,
telnet to 67.41.4.238 and sign on as:

     :hello demo.qcterm
     :basic
     >run formdem2

What you will see is a very preliminary form that is an exact duplicate of
the first VPLUS screen in NMMGR. This form was converted completely
automatically from its original FORMSPEC file into QCTerm's forms structure
through the use of a program that Frank is putting together. Frank will later
offer this VPLUS-to-QCTerm forms conversion as either a product or a service.
Which he chooses will be determined later.

A great deal doesn't work on this form right at the moment. To move around
the screen, use the TAB key. Later, the RETURN key will also move you from
field to field, as will the arrow keys. Although they used to work, the
RETURN and arrow keys do *not* work in the current versions of QCTerm.

Use your mouse to click on the "EXIT" box to exit the form. At the moment,
this is the only way out of the form, shy of killing the terminal emulator or
doing a hard reset.

The basic rules of QCTerm's forms mode are:

    o You cannot get out of an active entry point, as compared to VPLUS where
the cursor may be placed anywhere on the screen. You will always some sort of
active entry object (text entry box, radio button, pulldown menu, etc.)

    o You can define the TAB order of the active objects you would like the
TAB key to stop on. That TAB order list can be a subset of the total number
of objects on the screen so that you only stop on the most important fields.
The RETURN key acts like a forward TAB key when on text entry boxes but acts
like a mouse click ("select") when on pull-down menus, buttons, check boxes
and radio buttons. Arrow keys will allow you to go to any object. In Frank's
form, the arrow keys are how you would key down to the simulated "function
keys". The RETURN key is how you would press them, if you never wanted to
have your fingers to leave the keyboard.

     o Every active object (entry box, radio button, checkbox, etc.) has a
user-given name. In Frank's forms, that name is taken directly from the
FORMSPEC file.

     o QCTerm forms mode operates in "field mode" rather than the page mode
that you are familiar with in VPLUS forms. In VPLUS's page mode, when the
ENTER key is pressed, all of the field values on a screen are bundled
together into a long string, separated by "record separators" and terminated
with a "unit separator." This string has to be parsed by the HP3000 into its
relative constituents. In QCTerm, the "page mode" goes away. Instead, we
operate on only a "field mode" basis. We measure the current value when we
first enter a field. If, when we leave the field, the value is changed, we
transmit just the contents of that changed field as a very short string to
the host:

      fieldname:fieldvalue

...which might be, as an example:

      lastname:Prather

Each transmission is terminated by a CRLF. Similarly, transmission from the
host to the form is absolutely identical. The colon separates the field name
from the field value, in either direction. If QCTerm receives
"lastname:Prather", it will insert the value "Prather" into the field named
"lastname." Although it is expected that the host will be echo-suppressed,
this symmetrical design allows the form to work even if it's not. Having the
same transmission echo back to us does nothing but waste bandwidth and
processing time. However, the user will not notice it.

The intention of this design is to make (i) the form exceptionally responsive
and (ii) the process completely platform agnostic. All we require of the host
computer is that if have the capacity to read and write.

To parse the received data, the host program would be required to do the same
thing that QCTerm is doing. It would receive a bit of input, look for a colon
in the string, and then parse the string into its two constituent components:
the fieldname and fieldvalue. The program would then compare the received
fieldname and then assign the fieldvalue to the proper internal variable. In
BASIC, the code might look like this:

     .
     .
     if N$="LASTNAME" then do
         A$=UPS$(V$)
     doend
     .
     .

In QCTerm's design, all of the intelligence is meant to be on the host, thus
it will possible in a host code segment -- not unlike that above -- to check
the acceptability of the received value and possibly reformat it before
actually assigning it to an internal variable. If a value falls outside of
the acceptable range, an error message can be instantly transmitted back to
the QCTerm form, and the cursor put back on the offending field, in this
manner:

     error:The value you specified is outside the range of acceptable values
     goto:lastname

...rather than display that error later, only when the ENTER button is
pushed. Indeed, in this design, the ENTER button simply disappears. It's no
longer necessary. Even more interesting, because the forms mode works only in
field mode, other values on the screen can be updated instantly based on your
last input. This will be very valuable for designing forms such as tax entry
tables, where Line 20 is the sum of Line 17, Line 18, and Line 19. It will
also allow us to reload pull-down menus, such as perhaps a list of counties,
once you've entered a state further up on the form.

All of this is also being designed for maximum ease of migration. If the
vendor of the next platform you move to just decides to quit, this design
will allow you to move your front ends, along with the bulk of your code,
with amazing ease and grace.

If you've run the program above and want to see your input data, type:

     >e (to exit BASIC)
     :print testdat1

You will see your entries written into the file TESTDAT1, possibly with those
of other previous users. That's all the program does, but you can simulated
coming back to a field, editing it, and seeing the sequence of what got
transmitted to the host. In my case, the file looks like:

:print testdat1
DOM:nmmgr.config.pub.sys
BAK:nmmgrbackup.config.pub.sys
DIR:myfirstdirectoryfile
password:verysecret
BAK:nmmgrbackup.pub.sys
f8
f6
f7
f8
:

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *