I am following some of Kevin's menu mangling vicariously and trying to grok various VA docs. This pdf on kernel config seems pertinent to Screenman alternative to scroll at page 45-46
http://www.va.gov/vdl/VistA_Lib/Infrastructure/Kernel/krn8_0ig.pdf
Regarding the menus that eventually lead a user to field editing/input, can I ask on this thread:
Where does the actual text of menus reside in the globals?
Do the text items of a menu (along with its ? and ?? supplements) reside in consistently adjacent array space?
Is there a text reference posted anywhere as a Menu tree with the full text of each menu item arranged in outline heirarchy?
Thanks Rusty
Kevin Toppenberg wrote:
Nancy,
There are MANY fields that one would not want to have to wade through when entering registration data. I think Norman Dodd mentioned to me that he set up a template or used screenman to ask just relevant questions.
Thus you don't want to depend on Fileman to decide which fields you do and don't want to ask. It would probably be better to figure out what you want, and then create an interface of some kind to get that information.
Kevin
--- "Nancy E. Anthracite" <[EMAIL PROTECTED]> wrote:
Now that you guys have got this all figured out,
suppose you wanted fields to be conditionally displayed to the registration
clerk? Say you have a child under two and you would like to know the date the
child was due to be born so that it can be used in calculations of prematurity
and postmaturity - it is called the EDC or estimated date of confinement, but
you don't care to display that as a registration question any more
after age two? What determines if an item is displayed at all?
On Sunday 12 December 2004 06:14 am, Kevin Toppenberg wrote:
Thanks Steven,
Comments below:
--- steven mcphelan <[EMAIL PROTECTED]>
wrote:
A required field is just that. When you get to
that
field in roll-n-scroll mode you must enter a
value.
OK, I think I understand. Required fields are required in the roll-n-scroll mode. But they are
not
required when using the UPDATE^DIE method of
creating
the records. As per our other post, we were able
to
create a record with just the .01 field specified
An identifier has multiple purposes and
interactions. You can mark a field an
identifier
using the Fireman Utility option. Identifiers
can
be set up two ways, to display when lookups are
done
or to not display when lookups are done. In
either
case, when a new entry is added to a file using
the
roll-no-scroll method, Fileman will prompt the
user
for values for all fields marked as identifiers.
If
a field is also required, then in that
roll-n-scroll
method you must enter a value for that
identifier
field in order to create a new record. Required identifiers was a way to historically provide
key
functionality in the roll-n-scroll days.
Thanks. I found the Identifier menu option and
played
with it. Another thing learned about fileman. Thanks!
Since then Fileman has actually implemented KEY
on a
file that is in a more like file KEYS in other databases. There are pro and con arguments as
to
whether a file record should have KEYS or
required
identifiers depending upon what you want to do.
If
you have a few fields in a file where the
combination of those fields should ALWAYS be a
unique combination among all the records in that
file then using Fileman KEYS is the way to go.
But
for any file that is KEYed, you must always
provide
all those field values when creating a new
record.
If you process involves setting up a stub record that will populate those "key" fields later,
then
you cannot use Fileman KEY. It you want the
DBMS to
manage uniqueness for you, use KEY. If your
process
is going to manage uniqueness, then you may not
want
the file to have KEYs.
I hadn't noticed the "Key Definition" menu option before, but I see now that one can create a key
for a
file this way.
Thanks again!
Kevin
----- Original Message ----- From: Kevin Toppenberg To: [EMAIL PROTECTED] Sent: Saturday, December 11, 2004 7:31 AM Subject: Re: [Hardhats-members] Are "required" fields really required?
Thanks for both of your replies. I still have much to learn about Fileman. I don't know the difference between a required field and a
required
identifier. I also don't know how to explore
about
keys. I can't find a menu option that discusses keys--just cross-references.
Also, is seems that UPDATE^DIE can create a
record
that doesn't have required fields. But the
stimulus
for this question was the error I was getting
about
missing required fields (see other post). So
does
UPDATE check for these missing requirements or
not?
I have been trying to figure out how I can
learn
this stuff without bugging you guys all the
time.
I'm going to try reading the fileman manual
again.
I don't think I could understand what I was
reading
last time, but maybe I could get farther this
time.
Thanks again Kevin
steven mcphelan <[EMAIL PROTECTED]>
wrote:
Is it true about that wrinkle for Required fields or is it only a valid statement for Required Identifiers? UPDATE should not care about REQUIRED fields unless a field is either an
identifier or
that field is included in the FDA array.
----- Original Message ----- From: "Greg Woodhouse" To: Sent: Friday, December 10, 2004 10:05 PM Subject: Re: [Hardhats-members] Are
"required"
fields really required?
> First of all, a field may be required in a
subfile, which means that
> you have to enter a value when creating a
subrecord. Normally,
> "required" means that Fileman won't let
you
just hit and skip
> the field. The DBS calls add a new
wrinkle,
because UPDATE^DIE won't
> let you omit a required field (you get an
error). However, "Classic" &! gt; Fileman only allows you to edit a
record
field by field (in most
> cases), so it actually possible to create
a
record with a required
> field not valued. As a result, in some
applications, you will see
> fields that are required when they should
only
=== message truncated ===
__________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
