acConstants

[Amy Blankenship]

Where can I find a list of the constants you can put in the Response
variable of a notinlist event?

Thanks;

Amy

 

[fredg]

Where can I find a list of the constants you can put in the Response
variable of a notinlist event?

Thanks;

Amy

An 'official' list of Access constants (and their meaning)?
You gotta be kidding!

Response =
acDataErrContinue ' Don't display the built-in error message
acDataErrAdded ' New data has been added, don't display the
built-in error message
acDataErrDisplay ' Display the built-in error message

The above are also used in the Form's error event.

 

[Marshall Barton]

Where can I find a list of the constants you can put in the Response
variable of a notinlist event?

I get them from Help in A97 for NotInList :-(

Here's a copy of it.

acDataErrDisplay (Default)
Displays the default message to the user. You can use this
when you don't want to allow the user to add a new value to
the combo box list.

acDataErrContinue
Doesn't display the default message to the user. You can use
this when you want to display a custom message to the user.
For example, the event procedure could display a custom
dialog box asking if the user wanted to save the new entry.
If the response is Yes, the event procedure would add the
new entry to the list and set the Response argument to
acDataErrAdded. If the response is No, the event procedure
would set the Response argument to acDataErrContinue.

acDataErrAdded
Doesn't display a message to the user but enables you to add
the entry to the combo box list in the NotInList event
procedure. After the entry is added, Microsoft Access
updates the list by requerying the combo box. Microsoft
Access then rechecks the string against the combo box list,
and saves the value in the NewData argument in the field the
combo box is bound to. If the string is not in the list,
then Microsoft Access displays an error message.

 

[Amy Blankenship]

Thanks, both.

Here's my next question: if in your NotInList procedure opens a form to
allow entry of other pertinent data, how do you pass acDataErrAdded back to
the sub on the form's close event?

Thanks;

Amy

 

[Douglas J. Steele]

There are a number of techniques you can use to pass a value back to the
calling form. They include having a public property in the calling form that
you set in the maintenance form, have the maintenance form write to a hidden
field on the calling form or use a public variable. Based on whether or not
the maintenance form was successful, you set the Response in the calling
form.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

Thanks, both.

Here's my next question: if in your NotInList procedure opens a form to
allow entry of other pertinent data, how do you pass acDataErrAdded back
to the sub on the form's close event?

Thanks;

Amy

 

[Graham Mandeno]

Hi Amy

You should open the second form in dialog mode (set the WindowMode argument
to acDialog in the OpenForm method). That way, the calling code (your
NotInList event) is suspendeduntil the dialog form is either closed or made
invisible.

Where you go from there is largely a matter of chouce. Doug has given you a
couple of good ideas. What I do is have two buttons, OK and Cancel, on my
called form. The Cancel button undoes any changes (Me.Undo) and closes the
form, while the OK button simply makes the form invisible
(Me.Visible=False).

The calling code then checks to see if the dialog form is still open. If it
is closed, then cancel was clicked, so your NotInList procedure should
return acDataErrContinue. If the form is still open, then OK was clicked,
so your NotInList proc should close it and then return acdataErrAdded.

I also pass the Newdata value to the dialog form via the OpenArgs property,
and it can then pre-populate the appropriate field with the new data in its
Load event.

Also, it's possible that the user has changed that data while the dialog
form was open - maybe corrected some spelling or somesuch - so the record
saved in the table no longer matches the text typed into the combo box.
Under normal circumstances, this would cause the NotInList event to fire
again. To avoid this, before closing the dialog form, the NotInList code
can check the value in the appropriate control on the still-open form, and
update NewData if necessary before returning.
--
Good Luck!

Graham Mandeno [Access MVP]
Auckland, New Zealand

Thanks, both.

Here's my next question: if in your NotInList procedure opens a form to
allow entry of other pertinent data, how do you pass acDataErrAdded back
to the sub on the form's close event?

Thanks;

Amy

 

[tina]

hi Amy. don't know if you're using A2003, but if so...
the constants for the NotInList event procedure *are* in Help, just more
cumbersome to get to. if you open the form in design view, go to the
NotInList event and press F1 on the event "line", it'll open Help to the
Propery's topic - no help there. but once there you can click the AppliesTo
option right below the topic title, and click on the ComboBox Object option.
in that topic, click the Events option below the topic title, and select the
NotInList option from the droplist.

at long last, you're at the NotInList Event topic in Help, and there are the
Constant descriptions. it's a silly roundabout method to get to an object's
event, but i haven't figured out a quicker way to do it yet - so often in
A2003, using the Search option gets me nowhere (but maybe i'm just not smart
enough to enter the "right" key words <g>).

hth

 

[Marshall Barton]

Here's my next question: if in your NotInList procedure opens a form to
allow entry of other pertinent data, how do you pass acDataErrAdded back to
the sub on the form's close event?

While Doug provided good ideas for the general issue of
communicating between forms, for NotInList situations, I use
the acDialog approach that Graham outlined.

One important point that can save you a lot of trouble is to
do as Graham says and use OprnArgs to pass the NewData
string to the dialog form. Aftr you set the user's value in
the dialog form's text box, set the text box's Lock property
to True to prevent the user from changing it. If you let
the user edit the value that was entered in the combo box,
the new entry will trigger the NotInList event again,
vreating all kinds of confusion.

A different idea for dealing with the NotInList scenario is
to not do anything in the NotInList event. Instead, provide
a button that opens the form to add/edit the combo box's
list. This way, managing the list is a completely separate
operation that doesn't confuse either situation.