message on screen (Access/2000 VBA)

Topic

New Reply

Another novice question. . . When I put an error message on the screen ([err-msg] = “Bad Entry”) it shows on the screen when I single step with the de######. When I clear all the break points it does not show on the screen even though the debug.print said it went through the same routines as when I was in debug mode. (I have the same message in both before update and after update for the field.) Neither of them shows.

Anybody know where I am messing up?

TIA
ElDinosaurio

Reply | Quote

Replies

I think you want to use MsgBox. MsgBox = “Bad Entry”. Search help for more details on MsgBox.

hth,
Jack

Reply | Quote

You can’t *see* the immediate window unless you’re in the VBE, but debug.print commands will go on printing to the immediate window regardless. If you want the user to see a message, you follow Jack’s suggestion and use the MsgBox function, which will pop up a message box with the information in it in the user interface.

Reply | Quote

Carlotte,
The answer to my question is that the software does things in the next tabstop field before it recognizes that I want to stop. I have developed a way of controlling these forays into uncharted waters without my knowledge. Thanks for answering.

ElDinosaurio

Reply | Quote

I’m not sure I understand, but you need to get familiar with the form events and their sequence … and then be prepared to be surprised by them because it happens to all of us, no matter how experienced we are. *Where* you put the break or the messagebox, that is, in which event procedure, is just as important and *what* you put in there. If you need the code to break or pop a message before the cursor leaves a control, you need to explore the BeforeUpdate, AfterUpdate, LostFocus and Exit events of the control.

Reply | Quote

Thanks for the thoughts. I have more or less decided that all my code for unbound forms should be in (control) Keypress or Keydown, I haven’t quite come to a resolution of that one yet and (control) Exit. I seem to have the most luck being able to setfocus and know where the cursor is. I then have to test in the following control to see if I (M$) got too far ahead of myself.

Bound forms are still a problem. I will work on those next.

ElDinosaurio

Reply | Quote

Oy!!! Don’t do that if you want to write efficient code. That will fire the routine every time a key is pressed while the cursor is in that control.

The BeforeUpdate event of the control is usually the one you use to validate information in a specific control because if you cancel the update by setting Cancel = True, the change isn’t saved and the cursor stays in that field rather than moving to the next in tab order. Keypress and keydown are very useful, but they fire every time a key is pressed while the cursor is in that control. If you have a text field, that means you’re firing the event over and over. BeforeUpdate happens when the user tries to save the record or move to another field. In VB, the Validate event usually serves the same purpose, but in Access we’re gifted with the BeforeUpdate event.

Reply | Quote

The keypress/keydown is to find out if the user had pressed the tab, arrow key or enter key. All the editting and validation is done in the exit. I have not been able to keep the cursor in the control with using before update so I have to setfocus and backtab where I can. This seems to work. I have not been able to use the standard methodology because the user is using the enter key ONLY.

Thanks
ElDinosaurio

Reply | Quote

You did try the *control* beforeupdate event, right, not the form beforeupdate? On my machine, if I create a BeforeUpdate event procedure for a control, it works whether the user presses the enter key or the tab key or just tries to close the form from that control. It will *not* trap the arrow keys if the user doesn’t actually change the value of the control. If you post the code that you’re trying to make work, it will be easier to help you get it going.

Reply | Quote