Jim Phillips after Gopi writes:
>>> Jim Phillips <[log in to unmask]> 05/15/97 05:55am
>>>
>The following requirements will be met by the implementation of this
>enhancement.
>
> 1. The pop-up window should be able to overlay a part of the screen.
> 2. The pop-up window should display text on several rows and allow
the user
> to select the text on any row.
> 3. The window should provide a facility for scrolling so that additional
> rows of text can be displayed.
> 4. The display and interaction with the window should be in block
mode.
Sounds good so far!
> We propose to bundle this functionality into an intrinsic. The intrinsic
> will be similar in structure to existing intrinsics in VPLUS. This
> intrinsic can be called by applications in languages supported by
VPLUS.
Hmmmm. I think I agree with Lee. Couldn't the pick list just be another
field type? With the list parameters coded into the Processing Specs?
> When this intrinsic is callled by an application, a window pops up on
> the screen. Up and Down arrow keys may be used to position the
cursor on
> the text to be selected. Function keys (or Enter key) will be used to
> scroll the text in the window. Function keys and/or Enter key will be
> provided to either select the text at the cursor position or quit. The
> location and size of the window can be specified through the intrinsic
call.
Well, if it has to be in an intrinsic, where (what sequence) would the
intrinsic be called? Before/after VSHOWFORM? Before/after
VREADFIELDS?
Some other sequence?
> This functionality will be supported for DTC-connected HP 700/9X
> terminals.
No, as Chris said, you absolutely must support NSVT connections.
> Proposed intrinsic sketch:
<snip>
> Text to be displayed in the pop-up window is read from the file
> HPPOPUP.PUB.SYS and selected text is returned in this
parameter.
No way! This is just too inflexible! Pop-up window text must be
variable and may even be unknown prior to run time.
I think the "best" solution (at least, for me) would be a new field type
with all the parameters specified in either the Processing Specs or "hard
coded" some where (as is done with field length, etc. today).
Additionally,
the pop-up window text may be specified in the Processing Specs as
either
straight text, or a file name that would be read when a VINITFORM is
done
(that saves I/O by doing it once per form), and may be changed on the fly
by the VCHANGEFIELD intrinsic (to either new text or a new file name).
I would like the pop-up window field to act just like it does in Windows,
but that is only a wish, and not a requirement.
I realize this is probably asking for a lot, so if the quick and easy way
is to handle pop-up windows via an intrinsic, I guess I could live with
that. But you *must* make it easy to change the pop-up window text as
needed.
----------------------------------------------------------------------------------------
<massive plug alert>
With all of the discussion of HP's version of pop-up windows and their
severe limitations, I would like to tell about an alternative.
Infowin/ix from Silton Information Systems (213) 846-9823
Infowin address all the above issues and does considerably more.
1. Pop-up windows can be done in VPLUS or in character mode.
2. Pop-up windows can be done on DTC or VT connections.
3. Pop-up windows can be done on terminals or terminal emulators.
4. The data that appears in the window can be gotten from an Image
data set, Ksam(XL or V) file, or MPE flat file. Infowin comes with a
data engine that you use to build your custom picklist at window
execution time, just like MS-windows. No fixed file name is used.
5. After the window is up, you can scroll through multiple pages, or
even print the contents of the window, or the entire picklist to the
printer of your choice or do nothing and return to your application.
6. When you select a line in your window, only the fields you have
selected with the data engine will be returned to the application, not
the entire line.
7. The data engine supports TPI (imsam level), field mapping to new
data type, substrings of fields, date formats, sort designation and
order, computational fields (numeric and string), designation of key
and match fields with either preassignment or runtime assignment
of key and match values, edit masks for data returned.
8. If the data layout is too complicated for Infowin to do, you can use
your own data engine that will be invoked at window pop-up time
and use our display and selection mechanism.
9. Infowin supports radio buttons to allow selection of hard coded
values.
10.Infowin supports multi-page help text that is entered in a WYSIWYG
fashion.
11.Infowin supports short messaging at run-time with auto-centering
and no pre-setup.
12.Infowin supports screen printing within your application.
13.All features of Infowin are done from within your application code.
No changes need be done to any form file, or any VPLUS intrinsic
call sequencing.
14.Infowin is callable from any MPE/ix language that can do native
mode intrinsic calls.
Mike Berkowitz - co-developer of Infowin/ix
</ massive plug alert>
|
