Replies

Yesterday the Null assignment was generating the error shown (It really was). Today it’s working as it should. I didn’t even re-boot. I’m confused. But, thank you for getting me where I am. (Now if I can just stay here.)

John

Sorry, same error message.

John

Hans,
I put quote Me!cboName = Null unquote immediately in front of the RowSource assignment and Dropdown statements. I received the exact same error message as I reported above.

Thanks, John

Thanks guys. I’ll run with your ideas.

John

Thank you for your replies. Your thoughts work in the simplistic table and form I created for this question but not in my real world application. I’m trying to figure out the difference.

Scenario 1a) As described above, the table has two fields: a primary key and a data field. On cmdCancel_Click has the following single statement: “DoCmd.Close acForm, “frmTable1″, acSaveNo”. I enter a key field (no further keys, that is I do not hit Enter or Tab or anything) then click cmdCancel. The record is written and must be manually deleted. Boo hiss.

Scenario 1b) As in 1a but the statement “Me.Undo” is added in front of the “DoCmd.Close

Thanks for your response. I got out my original Office xp Professional cd and reinstalled the Access help section. The three topics I mantioned earlier still had no help text. (ie. the text from the last topic that did have text remained on the screen) Then I got out sp1 and sp2 but found no mention of any help text update. Do you have any ideas where I can turn now.

John

The problem is solved; it was caused by KeyPress. KeyPress changed each lower case character internally (<< significant word) to upper case. The procedure was defined "Sub Form_KeyPress(KeyAscii As Integer)" and the statement doing the conversion was "KeyAscii = KeyAscii And &HDF". This casued no problems when the data tables were all in upper case (left over from a main frame system). Some months ago the data was converted to lower case and the problem must have started then. Why the combo box key matching worked for the first two keys but failed with the third, I have no idea. But now that I've stopped the case conversion it's fine.

Thank you for all your suggestions. John

As you suggested, I set the Key Preview form property to No. Now the listbox sellection by keystrokes works as it should. Of course, also now the facilities provided by the disabled procedures do not work. (Executing routines upon identifying Cntl-A and Cntl-R key combinations.) Any ideas why Key Preview is sabotaging my list and combo boxes? And any ideas on how to work around it?

Thanks, John

Thank you HansV and MarkLiquorman for your replies. Your questions have led me to discover patterns: There are three forms. The one that contains no keystroke interceptions is working correctly. The other two forms contain a KeyDown at the form level with the Key Preview property set to Yes. All listboxes and comboboxes on these forms are exhibiting the deviant behavior described in my initial communication. A Pattern! However, sticking an Exit Sub statement at the top of their KeyDown Subs shows that the logic contained in those procedures has no bearing. One (only) of these two forms also contains a KeyPress routine that simply forces every key entered to upper case. Finally, no Timers or input masks are used.

I look forward to more of your questions as I am again stumped. John

Thank you for your replies. I have just completed doing what HansV suggested (single control listbox in a simple popup form). Charlotte’s tab suggestion sounds so different that I’m going to try doing that just to see if I can.

Thanks again, John

Thank you HansV and Marld_iquorman. Turning off the report property pop-up solved the problem. Further, turning off pop-up in the report requesting form also solved the problem of the form remaining visible in front of the report (which now that I think of it makes sense).

John, Oregon

Chris, Your explanations and code samples were clear and easy to understand. I got the progress bar up and running in a matter of minutes. Thanks so much for your help. (I got my start in compluters in Bedford in the mid ’60. Good luck in your career.)

John

Chris, Greetings from the Oregon Pacific coast. Thanks for your ideas. Your mention of a progress bar sounds intriguing. By following the toolbar’s “more controls” link to a humongous list of other controls I discovered the following: 1) Microsoft ProgressBar Control, version 5.0 (sp2), and 2) Microsoft ProgressBar Control, version 6.0. Are you refering to one of these? If so, can you point me to somewhere that will teach me how to use it?

Thanks again for your help, John

Hans, Your Repaint statement worked beautifully. Any idea why I had to use it?

Thanks, John

Charlotte,
Thank you also for your coded answer. Since I am trying to break into ADO, your code will be studied. Incidentally, as my background in Access is Versions 1 and 2 (a few years ago), can you recommend a book with which I can learn ADO as it applies to Access?