Bogus Parameter Prompt When Close Form (AXP/WIN XP

Topic

New Reply

When using database created in A2K in Access 2002 (aka AXP), using Access 2000 file format, when I close form using command button event procedure (a simple DoCmd.Close), I get bogus “Enter Parameter Value” prompt if there are any controls on form, such as a listbox or combo box, whose Row Source is a query or SQL statement that references the form in question as part of its criteria, e.g., Forms!ThisForm!SomeControl. If I close form with the Close Window “X” in upper right corner or the System Menu “Close” command in upper left corner this does not occur. It’s as if the DoCmd.Close command is somehow forcing a requery of the list or combo box. There’s no other code that runs when form is closed.

This is really more of an annoyance than anything else, because problem does not occur at work when running same program in A2K (we are still using A2K with WIN 98/WIN 2K); I can make modifications in AXP with no problems when program runs in A2K/WIN 98 environment. But would still like to know if anyone else has eXPerienced this bug & knows what is cause & how to fix it??

Reply | Quote

Replies

This is purely a guess and not an educated one at that (I don’t have XP).
Would you have to enter the arguments of the DoCmd.Close?

eg, DoCmd.Close acForm, “Form name”

Pat (cheers]

Reply | Quote

I did try that by specifying acForm and name of form after the DoCmd.Close but did not work – still got bogus prompt….

Reply | Quote

Do you have any code running in the Form_Close event?

Reply | Quote

No Form Close event. But even if there were, wouldn’t it be triggered regardless of which method you used to exit form – command button or close window menu item? Also bogus prompt occurs even if you open form & immediately close w/o updating any records, so don’t think form After Update event is at fault. I think it’s just some kind of bug when running an A2K database in AXP.

Reply | Quote

You’re right, but I missed that in reading your earlier post. AXP forms have some additional properties that A2k forms lack, so you may be running into something that doesn’t exist in A2k and only becomes apparent when run in AXP. I don’t have AXP on this machine, only at work, so I can’t check to see what possibilities exist.

Reply | Quote

I have encountered the same problem a couple of times with Access2k, but without using XP.
From recollection, it happened when I had a subform with two combo boxes, the second using the first as a criterion. When I removed the criterion from the query behind the second combo box the problem went away.
I didn’t find a solution other that to reorganise things to do things a different way.

Reply | Quote

In fact with one form the queries used to populate several combo boxes refer to another combo box (or two) on the form. On another form I fixed problem by replacing a listbox with a subform, but that will not work with the form with all the combos. Still think it’s odd that problem only occurs when running program in AXP, not A2K, and only when using DoCmd to close form.

Earlier today went ahead and installed recently released Office XP Service Pack 2 (SP-2), which purportedly, allegedly fixes various bugs in Access 2002, among other things. This particular bug, however, was not among them…

Anyone interested in more info re: OXP SP-2 & Access 2002, see the following MSKB article:

ACC2002: Issues Fixed in Access 2002 by Office XP Service Pack 2

Be advised, checking latest issue of WOW, “Woody” has not yet given the “green light” for SP-2. Install at own risk….

Reply | Quote

Mark,

I would like to know if that bogus parameter value problem (pops up when exiting a form) has been resolved (by the sp)?

Thanks

Reply | Quote

No, I installed the SP-2 update & still get the bogus parameter prompt when working with A2K format database in AXP (we still use A2K at work so converting to AXP is not an option). And it is still very annoying…. if anyone knows solution for this I’d like to know too!!

Reply | Quote

For unrelated reasons, earlier today I decrypted the .MDB file where this problem occurred (I needed to create zip file; it had been encrypted by default by the user-level security wizard). Testing the unencrypted file, suddenly the bogus prompt no longer occurred with one “problem” form, but still occurred with another. This was progress, anyway. So I tried something I didn’t think of before – hiding form before closing:

Private Sub Exit_button_Click()
Me.Visible = False
DoCmd.Close acForm, Me.Name
End Sub

This worked – no more bogus parameter prompt!! Only problem, hiding form using this method resulted in perceptible (& funky looking) delay in form closing. As noted previously, using the Windows “Close” button (the “X” button) or System Menu “Close” command closed form w/o bogus prompt. So the obvious solution (obvious now, anyway) is to replace DoCmd.Close command with API equivalent of clicking the Windows “X” Close button, using the Windows PostMessage API function. Modified event procedure:

Private Sub Exit_button_Click()
Dim lngResult As Long
‘ Send msg to close window:
lngResult = apiPostMessage(Me.hwnd, WM_CLOSE, 0&, 0&)
End Sub

API declarations:

Declare Function apiSendMessage Lib “User32” Alias “SendMessageA” _
(ByVal hwnd As Long, ByVal wMsg As Long, _
ByVal wParam As Long, ByVal lParam As Any) As Long

Declare Function apiPostMessage Lib “User32” Alias “PostMessageA” _
(ByVal hwnd As Long, ByVal wMsg As Long, _
ByVal wParam As Long, ByVal lParam As Any) As Long

‘ Windows Message (WM) Constants:
Public Const WM_CLOSE = &H10

The obvious choice of API would seem to be SendMessage, not PostMessage, but when tested with SendMessage the bogus prompt still popped up. (The SendMessage function sends a message immediately by calling the Windows function for the specified window directly; while the PostMessage function posts a message to the window’s message queue to be processed.) With PostMessage, the form closed with no visible delay, and with no bogus prompts. I posted both functions as it may be necessary to experiment to see which one works best in a specific case. These functions may also be useful in any case where a form seems to close in a sluggish manner; calling the API directly rather than the VBA equivalent can sometimes be a more efficient way to accomplish a task.

HTH all one or two other persons who may have experienced this bug….

Reply | Quote

(Edited by charlotte on 02-Mar-03 07:35. to activate link)

Mark,

Are you running Windows XP? There’s a knowledgebase article here on a bug that sounds a lot like what you’re seeing.

Reply | Quote

Yes, I am running AXP on WIN XP. Problem does not occur running same program on WIN 98 or WIN 2K. Thanx for link to MSKB article. I see there’s an acknowledgement, but no explanation, for bug, and recommends using Windows Close (“X”) button as workaround (not sure what “Restore Down” refers to). Back when I first came across bug (was still 3-star Lounger at time!) first thing I did was search MSKB, nothing relevant found at time & in subsequent searches. It appears the article cited was posted only recently – the “Last Reviewed” date is 2/25/2003. Presumably bug will be fixed in a future Office XP SR or SP or whatever they are calling them now….

PS: You have been found guilty of the citable offense of posting a non-active hyperlink – I think one of the URL tags is misspelt…. as you guys like to say, plz refer to Quick Guide for more info…. …(joke)

PPS: I know, it’s the kitty again…

Reply | Quote

Thanks for pointing out the bad link, Mark. I was in a hurry and forgot to preview before posting. The kitty is a big cat now and no longer inclined to chase my fingers while I’m typing. I can only blame old age now.

Reply | Quote