You will probably view this as a big step, but I'm still lost.

I put a button and your code on the popup/not in list combo box form and
"forced" the ID. Fed frmEmployeeSetup via open args. Got the same results.
So . . .

I went to frmEmployeeSetup and commented out the OnLoadEvent and open args
and "forced" a valid (unused) code using an AddNew Command Button.

The behaviour was what I want. But, now what do I do to get
frmEmployeeSetup to test for a unique EmployeeID and add the record? I was
given that combo box/popup/not in list event stuff from an MVP a while back,
but I am not wedded to it.

I don't really care where EmployeeID is assigned or the record created as
long as its entered, saved, and returns to frmEmployee.

Thanks for your patience.
--
Thanks for your help,
Chris


"Albert D.Kallal" wrote:

The code I provided earlier representing the close of frmEmployeeSetup is
the point at which frmEmployee vanishes

Yes, I understood that. And, that close code of frmEmployeeSetup does a
re-query of frmEmployee. If this is happening if you are STILL IN the not in
list code when you launched frmEmployeeSetup, then that why we got a
problem....

For a test to clear this up, put a button beside the combo box to "add new".
Now run your normal code, and you will likely find that things work.

(in other words, lets take out the not in list code, and simple run some
"test" code behind a button.

dim strText as string

strText = inputbox("what new value for comb box")

..... you SAME code goes here that adds the new record, and calls up form
frmEmployeeSetup.

Try the above...and eliminate the combo box from the equation, and see what
happens...

On the other hand, if you are NOT actually launcing frmEmployeeSetup from
the not in list code, then likely I am wrong. (however, either you are
halting the not in list code so you can ADD THE NEW record, or you are
letting the not in list code finish? (which is it?) However, if you let the
not in list code finish, then we have to assume the new record is already
added at this point. The after update code of that combo box will now but
the user will still be in frmEmployeeSetup at this point if you do not HALT
the code. (If you are not halting the code, I can't see how this will
work??).


However...the NotInList event code is completed by way of OnLoad event of
[frmEmployeeSetup].

Is it? Are you sure the not in list event is done? As I mentioned above, are
you telling me that frmEmployeeSetup is not opened in acdialog mode? If that
is the case, then the combo box code is NOT waiting, you added the new
record, and the combo box after update event code will now try to run. (ie:
frmEmployee will begin to try and move to the new record, and you are still
in frmEmployeeSetu?). Perhaps you don't have any code in the comb box after
update event then?

All is good except frmEmployee vanishes along with frmEmployeeSetup proper
closing.

It is possible I missing something else here, but then try placing a button
beside the combo box, and use that in place of the not in list event....
does it work?
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

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