Problem with keyboard input being locked in a form

[David W. Fenton]

I have a *very* weird problem (Access 97) that first developed
sporadically a couple of days ago while working, and that now
happens all the time.

The symptom is this:

When I try to edit the controls on the form, keyboard input is
ignored.

It's not the keyboard, because in the Immediate Window I can still
type.

It's not a record lock, because I can open the table and edit the
record without problems.

The controls are not locked if I check the .Locked property in the
Immediate window.

The underlying recordsource is not uneditable because I can change
values in the underlying fields or the controls by assigning them
through the immediate window.

And certain keystrokes still work -- I can select text in a control
with the mouse and hit the DELETE key and the selection is deleted.
It seems to be blocking the shift keys and the alphanumeric keys (as
well as BACKSPACE).

Some things that couldn't be the problem:

- There are no form timers used anywhere in this form.

- KeyPreview is set to NO by default.

AAARRRGGGHH!!! I just tried setting KeyPreview, and wrote a KeyPress
event but left KeyPreview off by mistake, and then it worked again!
When I turn KeyPreview on, it still works, and now I can't get it to
*not* work!

The form is a very, very complex form (it's original OnCurrent event
long ago grew too large for a single event procedure!), and has a
lot going on. A couple of days ago I added a web browser control to
it, and yesterday added a procedure that writes to a temp database
within a transaction and then rolls back the transaction after
pulling out the data. Those are the big changes in this form from
last week, and the problem in its sporadic form predated the
addition of the temp database rollback. It seems to have come up
around the same time as I added the web browser control.

I've decompiled and compacted and all that, but have not yet rebuilt
the form with SaveAsText (that's next on the agenda). I rewrote the
code that locks and unlocks controls (using methods similar to what
Tony Toews describes in
http://www.granite.ab.ca/access/locking_fields_on_a_form.htm, though
I use a custom collection so as not to have to walk the .Controls
collection but once -- I've been doing that in apps for nearly a
decade, so it's tested code that has been working in many apps for a
very long time).

Any ideas at all what might be the cause of this?

- it's not the keyboard, because the Immediate Window still takes
input.

- other forms are not affected by it, so far as I can tell.

- it has nothing to do with the underlying locking or uneditability
of either the tables, recordsources or controls involved.

What could be happening to my keyboard input?

 

[David W. Fenton]

I have a *very* weird problem (Access 97) that first developed
sporadically a couple of days ago while working, and that now
happens all the time.

OK, I just discovered something.

If I open the form and use the first tab page (with most of the
important editing controls), I can edit, and load new records and
edit and have no problems.

As soon as I view the tab page with the web browser control on it,
when I go back to the first page, the keyboard input is being lost.
That is, I put in a KeyPreview event to write out the
ActiveControl.Name and the keystroke entered, and once I view the
tab with the web browser control on it (it's actually in a subform),
all keyboard input is gone -- it doesn't make it to the KeyPreview
event.

My first thought was that perhaps when the web browser control got
the focus, it did something weird, so I tried set it to last in the
tab order on its tab page.

AND IT WORKED!

I was able to type in the fields on the web browser control's tab
page, as well as go back to the first page and type there.

But as soon as I clicked on the web browser control, then all
keyboard input was discarded. It's as though the web browser control
never gives up focus, and I tested it and found that's it's
absolutely true! If I click on the web browser control, then click
in an editable field, then hit Ctrl-A, the text in the web browser
control is selected! It doesn't matter where the cursor is if the
web browser control is visible -- Ctrl-A selects the text in the
browser control.

So, what I'll do is put a transparent command button over it, with a
ToolTip that says "click to copy all to clipboard", since that's the
only reason the users need to be able to get to the tab control.

Oh, no, that won't work! They've got to be able to scroll! Clicking
the scroll arrows doesn't cause a problem, but dragging the scroll
thumb does the same as giving it the focus.

What am I going to do here?

Does anyone have any ideas on what to do?

Remember, this is Access 97.

BTW, has anyone used the Gecko ActiveX control?

http://www.iol.ie/~locka/mozilla/control.htm

It gives you the Mozilla/Firefox rendering engine in an ActiveX
control that has the exact same interface as the IE control. I'm
downloading it right now to see if it can be used and if it has the
same problems.

Interestingly, the last time I checked that site, they didn't have a
binary version available! Nice that they finally do. I do wonder,
though, if I need to match the control version to the Mozilla
version on my client's PC (the client for whom this app is written
uses Mozilla as their main browser, though I don't know which
version -- probably an old one).

I'll report back on this, as I don't think the IE control is going
to work (because of the scrollbar getting the focus).

If anyone else can replicate the problem (in Access 97), I'd be
interested to hear about it. What you need is a form with two tabs,
a couple of editable fields on each tab, and a web browser control
on the second tab that is last in the tab's tab order. If you can
put that together and get the same result, then it's not just my
app's weirdness. Once I try Gecko, I'll then go back and see if I
can replicate it as described above.

 

[David W. Fenton]

I'll report back on this

Well, the Gecko control doesn't seem to want to work in A97 (I'm
actually not too surprised). The object browser shows all the
correct properties/methods, but when the properties just don't show
up on the OTHER page of the control's properties sheet.

I also tried it in Access 2000, where it didn't work.

But it *did* work in 2002! Maybe I can get it to work in the older
ones, as well. Well, strangely enough, the one I created in A2K2 (in
an A2K MDB) works now in A2K. I tried exporting to A97, but it
doesn't work there, either. *sigh*

The other thing I discovered was that the IE control instantiates
itself in Access *above* the Access window's controls. That is, if I
put a transparent command button on top of it to try to prevent it
from getting focus, it doesn't work -- you can just click on it and
it gets the focus.

So, at this point, unless anyone has any suggestions, I'm at a loss
as to how to fix the problem, other than converting to A2K or higher
and using the Gecko web browser control. That's a poor option, as
the client may not have licenses (maybe -- possible for A2K and
A2K2, but I don't know for sure -- they'd hate having it look
different on the different machines, and they hate *all* change!).
I'll have to do some testing to see if their app converts well to
A2K format.

And I would love to hear any other suggestions on getting the thing
to work in A97.

 

[David W. Fenton]

So, at this point, unless anyone has any suggestions, I'm at a
loss as to how to fix the problem

Well, I now have good news and bad
1. the IE control does not steal focus in A2K.

2. but it errors out with:

The expression SetSecureLockIcon you entered as the event
property setting produced the following error: There was an
error loading an ActiveX control on one of your forms or
reports.

*The expression may not result in the name of a macro, etc.
etc.

and then it gives the same error with "FileDownload" instead.
Needless to say, I'm setting none of these properties, as I'm doing
no downloads, and don't actually have a status bar to display the
security padlock.

3. the same errors pop up in A2K, but the IE control steals the
keyboard focus, so it's no better than A97.

4. the Gecko control works fine in A2K and A2K2 and doesn't steal
focus in either one.

5. unfortunately, on first try, for some reason it's not honoring
the stylesheets.

So, I have no good solution -- my client has, at best, A2K for one
machine and A2K2 for another. I wouldn't be bothered by installing
A2K on two machines because of the legal full A2K2 license.

But that doesn't get me anywhere! If I use the IE control, I have
the error *plus* the stolen focus.

On the other hand, if I upgrade and put A2K2 on both and use the iE
control, I get rid of the keyboard fucus stealing, but then have to
figure out how to get rid of the error in #2 above (Googling turns
up nothing for it in VBA, and very little elsewhere, either).

So, looks like Gecko is the choice, since it works in both A2K and
A2K2, but I'll have to figure out why it's failing to honor the
stylesheet declarations (something IE is *not* having a problem
with).

Well, after some digging around on Google Groups, I found this:

http://groups.google.com/group/alt.html/msg/b8394909038b2f04

and it says:

Well, for what it's worth, I found the reason for this. I
discovered that it only happens after I add a <!DOCTYPE...> .
Mozilla then requires that the MIME type for the css be
"text/css", and will not load if the MIME type is presented as
"text/plain", which is what my localhost server is apparently
serving up.

Unless I can figure out a way to set a MIME type in Windows (without
running an HTTP server, that is), this is going to be a problem with
Gecko. I guess I can read the CSS stylesheet into a string variable
and write it in as an inline style declaration in the header of the
file I'm loading. Very messy, but better than nothing.

My choices are not too good:

1. figure out how to make the Gecko control work in A97 -- not
bloody likely.

2. figure out how to get rid of the IE errors in A2K2 -- not bloody
likely.

3. use Gecko in A2K or A2K2 and bring all the style definitions
inline.

So, I guess I can see what I have to do! But I'll have to convince
the client first.

Anyway, I did a demo of the bug in A97. The MDB writes an HTML file
to the same folder it's in, and I am not including the CSS files, so
you won't see the pretty styling (Ha!). I've uploaded it here:

http://dfenton.com/DFA/download/Access/WebBrowserBug.zip

Others can check it out, but you'll see that the fields are
completely editable until such time as you put the focus on the web
browser control, which time you can't type into the fields any more.

 

[David W. Fenton]

Anyway, I did a demo of the bug in A97. The MDB writes an HTML
file to the same folder it's in, and I am not including the CSS
files, so you won't see the pretty styling (Ha!). I've uploaded it
here:

http://dfenton.com/DFA/download/Access/WebBrowserBug.zip

Others can check it out, but you'll see that the fields are
completely editable until such time as you put the focus on the
web browser control, which time you can't type into the fields any
more.

Well, I've now found out that if I embed the web browser control
directly in my tab control, I have no problems with focus stealing.

However, I have another problem that seems to be specific to my CSS
and HTML:

When I use the web browser control directly embedded in the tab
control, it shrinks or grows every time the .Navigate method is
invoked. This may be because of workarounds in my CSS to avoid
problems that IE has with displaying horizontal scrollbars when
there is not need for it. I need the space so I can't turn on the
horizontal scrollbar all the time (as is the suggested preferred
solution), so instead I use the trick of setting negative margins,
like this:

BODY{right: -15px; margin-right: 20px

That gives you a net margin of 5 pixels.

But it seems that when I do that my web browser control shrinks or
grows by several pixels every time I load new content.

But I can't recreate it!

I've tried setting the size before or after each navigation
operation, but that has no effect -- it stills shrinks/grows with
each document load.

OK, I think there's something really weird about this ActiveX
control. When I recreated the control from scratch (instead of
cutting and pasting it from the existing control on the subform) the
growing/shrinking behavior has gone away.

So, I've solved my problem *in Access97* (knock wood!).

The focus stealing was apparently something caused by being embedded
in a subform.

The shrinking/growing was apparently a leftover behavior/property
from yesterday for some reason.

So, I'm done! No conversion to a newer version of Access needed!

Of course, now that I've posted that, I'm sure it will go kaflooey.

But, I hope this monologue is now finished!