Dear write on:

I'm at home today, and can't really respond appropriately to your message,
but I will post back tomorrow from work (where I have Zoomtext and can try
to reproduce the example you mention...). Chat more tomorrow!

Fred

"write on" wrote in message
...
Dear Fred,

Wow! That's pretty cool!

I use ZoomText for screen magnification, and I love it. The downside is,
it
doesn't play well with my graphics card (or visa versa), so mouse control
can
be a hassle. The mouse can be difficult to position exactly where I need
it;
it's hard to control highlighting of text, and may not stop highlighting
when
I let go of the mouse button; mouse pointer may jump around the screen
out-of-control.

This has led me to learn and use keyboard shortcuts as much as I can. But
that presents its own set of challenges. First of all, There are cases
where
the ZoomText hotkeys conflict with Microsoft shortcuts. ZoomText always
wins.
Then I have to do the MS function another way--usually ALT+menu keys. But
even that doesn't always work. (Case in point: If I open a new message
window
in Outlook Express, there is an address book icon next to the "To:" box
label. The idea is, you click that icon to open your address book and
select
an address to put in the "To:" field. I cannot find a way to open that
icon
without a mouse. I cannot even get it to receive focus so I can try to
open
it. And this function can't be done with ALT+menus either. Do screen
readers
have a way around this?)

Receiving focus is often a problem when trying to navigate. ZoomText has a
function that lets me ALT+TAB through all open windows, until I get to the
one I want. But the window I stop at doesn't always receive focus the way
it
should, so that my next keyboard command will work there. I particularly
have
trouble with Outlook in this regard.

Navigating within a window is usually a pain. The F6 key doesn't work most
of the time (to move between panes) the way MS shortcut key lists say it
is
supposed to, and I don't even know why. I can't even find ZoomText
conflicts
to explain that. There are certain areas of the Outlook main window, for
example, that just can't be had without a mouse.

Internet Explorer is a nightmare without a mouse. I can't even TAB or F6
out
of the menu bar/toolbar area, into the actual web page. This is where MS
MouseKeys comes in handy. I can use keys to move and click the mouse; once
you get used to it, control is much better than handling the mouse,
although
it's slower. (See Accessibility Wizard in Control Panel. You can also
adjust
the thickness and blink rate of the cusor.) ZoomText does have the Web
Finder
feature that works with IE. That is useful, if I am determined to use the
keyboard just on principle, but it is more cumbersome and time-consuming
than
using the mouse.

As for Access and keyboard shortcuts--well, I haven't even gotten that far
yet. Just getting comfortable with Access itself is all I can handle right
now. The shortcut learning curve will have to wait. And I'm leary of it,
because I supsect all the navigating between multiple objects and views
will
be really hairy. Again, the ALT+TAB does help for switching windows. But
receiving focus...? I don't know.

Do you work with ZoomText much? Got any tips for me?

write on
P.S. Should we change the subject, and/or move this discussion to a
different forum? Can we? Will "Notify me of replies" work if we do?


"Fred Boer" wrote:

Dear "write on":

It caught my eye that you say you are visually impaired. I teach at a
school
for blind and visually impaired students. I have taught computer courses
involving Access to totally blind and low vision students. If you have
problems with Access related to your vision, perhaps I might be of
assistance; or, perhaps I can learn from you!

Fred Boer

"write on" wrote in message
...
Thanks for the response.

You wrote,
As others mentioned, the WHOLE idea of relational database system is
hat
you
only need to store the id field, and then the rest of the fields
(like
supple name) can then be viewed.

First, viewed how? I find subdatasheets to be too cumbersome. (I am
visually
impaired, so the less I have to scan through and pick out the better.)
Is
there a better way to link to the Supplier Table that I'm missing? I
guess
my
reasoning went something like this: Queries and reports are useful for
sorting or displaying data in a format that's not readily available in
a
table (especially using fields from more than one table). But if I can
set
up
a table to show exactly what I want to see, why not do that, rather
than
bothering to write a query, which I then have to go to and run just to
see
what I want? Put another way, why duplicate the table with a query, if
I
can
just have the table show what I want in the first place? (Answer:
Because
that ain't so easy after all!)

But it turns out that I apparently have to write a query anyway to put
the
info in the table the way I want it. Still, that saves navigating to
and
running another object every time I want to see the info. But then, I
could
just open the query, rather than even opening the table, which I guess
is
the
point after all. Sorry I'm rambling; I'm "thinking out loud" here.

You say:
The way the northwind works is that the id is stored, but the form
(or
sub-form) is based on a query. When you set the id, then the name
etc
magically will appear!. Those queries need to be left join queries..

I'm sorry, but I have to ask: If the normal and recommended way is to
store
and display the [Supplier] ID# in the [Products] table, WHY is the
sample
database written to display [Supplier] Names in the [Products] tables,
which
is the ABnormal and NOT recommended way? This is confusing to us
newbies
(at
least this newbie), who presumably use the sample to help us
understand
the
normal way to use a database.

Also, I'm afraid I don't quite follow. 1) Are you implying that I
should
be
looking at the form within the table somehow? 2) Are you saying that
the
combo box in the form, which displays Supplier Names to choose from
for
data
entry, but stores the ID in the table, is itself a kind of query? 3) I
don't
understand what you mean by "set the ID." 4) I guess I'm not clear yet
on
join queries, and I'm not sure which queries you are referring to
here.

You asked:
Also, it is not clear:
I want the combo box
to show me a list of names (not ID#s), AND I want to store
Supplier
NAMES
(not ID#s) in the Products table.

what do you mean list of names? do you mean suppler names? or do you
look up
a name..and what the suppler name to appear? (I guess you are not
clear
on
name vs product name...or do you mean one and the same?).

Sorry I wasn't clear. What I had in mind was this:
I would use a Products Form for data entry, to feed a Products Table.
The
Products Table would have a Supplier field. The corresponding field on
the
Products Form
would be a combo box (or list box, if you prefer). In order to enter
the
Supplier to go with a particular product, I would use this combo/list
box
(on
the Products Form) to choose the Supplier Name (so I don't have to
memorize
all Supplier ID#). I understand the norm is to then store the Supplier
ID
in
the Supplier field, in the Products Table. What I originally intended,
however, was to store, or at least display, the Supplier Name (rather
than
ID) in the Products Table, as well as displaying it in the form. My
thinking
was, "If I view the data in the Products Table, what good is the
Supplier
ID
to me, unless I have memorized which Supplier belongs to which ID?"
But I
guess I'm SUPPOSED TO view the data either one record at a time in a
form,
or
in a query, or in a report. The table is apparently not MEANT for
viewing;
it's just a storage closet from which to pull out whatever I want to
view
somewhere else. Did I finally get it?

I guess most of this is a moot point if I just stick to the normal way
of
doing things. Thanks again for your help.



"Albert D. Kallal" wrote:

As others mentioned, the WHOLE idea of relational database system is
hat
you
only need to store the id field, and then the rest of the fields
(like
supple name) can then be viewed.

The way the northwind works is that the id is stored, but the form
(or
sub-form) is based on a query. When you set the id, then the name
etc
magically will appear!. Those queries need to be left join queries..

Also, it is not clear:
I want the combo box
to show me a list of names (not ID#s), AND I want to store
Supplier
NAMES
(not ID#s) in the Products table.

what do you mean list of names? do you mean suppler names? or do you
look up
a name..and what the suppler name to appear? (I guess you are not
clear
on
name vs product name...or do you mean one and the same?).


When I look at the table, I want that info
(Supplier NAME) to just be there, without having to fish through
subdataforms, separate queries, or reports.

Yes...you build query to do this. You then build combo box on the
form
that
displays that returns the id..and this comb box can search/display
by
any
column you want..but you always still store the id.


Is there a REASONABLE way for a non-programmer to accomplish this?

You can use a query to do the above. Just make the combo box return
the
"id"...and make sure the query has as many (or all) fields from the
other
table. once done, then no code at all needs to be written here...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal