I'm developing an application in MS Access, using VBA.
The application already exists but I have to add a button and a piece of code in a form.
The problem is that, when I add the button and try to show the form, I don't receive an error but the form isn't visible.
I'm sure that the form is open, because, if I try to delete it, I receive an error that tells me that is not possible to delete an opened form.
Can anyone tells me the solution?
Edit: I still have the same problem on another form in my application. The form worked since i add a piece of code in it. Now, also deleting the code it doesn't work... I've also tried to decompile the application but nothing changed...
The following function has several arguments for show/hide etc. With the correct parameters you should be able to get that form to be visible:
OpenForm(FormName, View, FilterName, WhereCondition, DataMode, WindowMode, OpenArgs)
All the argument options can be found here.
Related
I seem to be having a problem that looks an awful lot like it could be a bug in MS Access. I have a form which enumerates all the rows in a table and lets you edit them in a subform. Upon clicking save in the subform (standard save button converted to VBA), I want to update the list of records in the main form. I seem to have done just that with this code:
Parent!List0.Requery
Parent!List0.Refresh
Parent!List0.SetFocus
However, the list of records only seems to update with the changes upon clicking somewhere in the box, giving it focus.
Has anyone run across this, or does anyone have any suggestions as to how to solve this?
I cannot reproduce the issue, at least not in Access 2010. I had to comment out the Parent!List0.Refresh statement because that was causing a run-time error ("Object doesn't support this property or method"), but once I did that the List Box was correctly updated as soon as I clicked the button on the subform. There must be something else at play here. Could you possibly have error handling in place that is "swallowing" the run-time error I received?
Set a breakpoint at the beginning of the Button_Click() code and follow it through. Perhaps your code is not executing the way you think it is.
Get rid of the Refresh statement, it's not necessary. You'll probably get a run-time error right there because that property isn't supported.
I am working on a modal popup form in access and I have the following problem:
When I incidentally open my form in "form view" instead of "design view" It causes a VB script error (which is normal, because it tries to get information from another form which is not open).
So VB tells me there's an error, I tell the VB debugger to stop the execution of the code, and thus the form does not open, but then access is not re-enabled.
I can't regain any form of control, and it's not an endless loop or something like that, because Access is still running correctly according to my task manager.
So far the only solution I found was to close access through the task manager, but it doesn't seem normal to me.
Here are a few suggestions:
http://www.pcreview.co.uk/forums/control-location-screen-form-opens-t4041436.html
You can also try to modify a bit of your form, move it to a new/good position, and saving it. I have had this happen to me in the past.
Got a weird problem. I was debugging some code for a form and everything was working as intended for the most part when suddenly I began to get a "Method or Data Member Not Found" for every event of my form. It's like my form suddenly does not recognize any of my controls or events. I have all of my methods properly closed and did not rename any controls.
Any ideas on what would be the root of "Method or Data Member Not Found" for every single control with an event?
Thanks
Importing into a fresh database as talbright suggested gave me more descriptive error messages.
A fresh import, compact&repair, and renaming of appropriate control fixed the problem from occuring. As Remou suggested, regular maintenance can help prevent these sorts of problems.
edit for future readers: This problem occurred while using a shared front end file. So don't do that if possible.
I've found that any MISSING: reference can make the simplest of code fail.
Check in the visual basic window
Menu Tools -> References
look down the checked refences to see if any are MISSING
I just fixed the same error by renaming text and combo boxes something not so close to a concatenated Table & Field string. Actually just prepended those names with "tbx" and "cbx".
We have an MS Access 2007 database with a simple form displaying table data. We use the Find dialog (click the binoculars on the Home ribbon) to locate records we want. This can cause an error under specific circumstances.
Steps to reproduce the problem:
Open the form.
Open the find dialog.
Edit some field within the record.
The record is now in update mode
(you'll see the pencil in row's
"gutter" area).
Without saving the record, click on
the ALREADY open Find dialog.
Search for a record that can't be
found.
Click on the form again. The record
is still in edit mode (i.e. the
pencil still shows). Attempt a save
or edit some other field.
This message box will display
"Update or CancelUpdate without
AddNew or Edit." You can click OK or
Help buttons.
Clicking the Help button shows:
You tried to call Update or CancelUpdate or attempted to update a Field
in a recordset without first calling AddNew or Edit. (Error 3020)
On a Microsoft Access database engine database, you called the Update or
CancelUpdate method but did not use the AddNew or Edit method before writing
data to a record.
On an ODBCDirect database, this error occurs when you attempt to write data
to a record without first calling AddNew or Edit.
We’ve reproduced this in a new database where there is no VBA code. So the problem is solely within MS Access, and you should be able to reproduce it easily.
If you save the record before doing the find, the problem doesn’t happen. Unfortunately, we have users doing a find while the record is still in edit mode.
We’ve tried setting up form-level, data-field-level, and Access application level events and error handling. Nothing can detect or catch this situation. There is no way within VBA to detect if the Find dialog is active.
Does anyone have any ideas for preventing the error or a way to save the record before the find occurs? Our best thought right now is to create an AutoHotkey or AutoIt script that waits for the Find dialog to have focus. We’ll then send a Ctrl+S to save the current record to force a save.
#CodeSlave's answer suggests a possibility to me:
Instead of simply removing the binoculars from the toolbar/ribbon, instead change what the binoculars do. That is, have it call code that saves the current record if it's dirty and then launches the FIND dialog.
Now, there'd need to be some code to check that a form was open, and that it had a recordsource (testing the .Dirty property errors if there's no recordsource), and that a field has the focus, but all of those things are doable. Likely many of them (except the last) would be taken care of by showing the toolbar/ribbon only when the form is loaded, or by editing the default toolbar/ribbon when the form opens.
But this would be much less crazy than using an out-of-process solution, and your users wouldn't know any difference.
I'd suggest that you've found a bug that was introduced in MS-Access 2007. However, I have not been able to duplicate it on my copy. I presume we're both up to date on our patches, so perhaps there is something more subtle happening.
If you're wanting to force the record to be saved, use one of the the following - not a CTRL-S
if me.dirty then Me.Dirty = false ''(n.b. often the preferred method)
Docmd.RunCommand acCmdSaveRecord
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70 ''(n.b. deprecated)
The problem as I understand it, is that if they edit the form after the "find" is already open and then do the "find" the get the error.
I'd try one of two things:
Find a way to close the built in find form, and do so whenever you make the current record dirty (On Dirty)
Add your own "find" button to the form (not opening the built in find form), and hide the one on the ribbon.
The hack, work-around we came up with was to write an AutoIt script which can watch for when the Find dialog gains focus and save the record if it has changed.
We didn't want to distribute the script separately from the database, so the the script was added to a database table as a Blob. The database's AutoExec macro runs some VBA code that pulls the script out of the Blob table and starts the script.
When the script detects that the Find dialog has focus, the script runs a VBA macro in the database. The macro checks to see if the current record is dirty. If dirty, the macro forces a save. Also, the AutoIt script is stopped when the database is closed.
This is all pretty awkward, but it works.
I am working on an Access 2007 application that was created by someone else. It has a strange, intermittent bug in which it prompts the user for query parameters when the main form is opened. The query parameters are clearly not necessary, because the error does not always occur.
The very strange "fix" to this problem is to open and close a particular module before opening the main form. Then the form opens without parameter prompts. However, of course I can't ask end users to open and close modules.
I tried using a macro to open and close the module when the database is opened. That fixes the bug, but leaves the VBA code window open, so that's no good.
Has anyone run into anything like this before? Any suggested solutions, workarounds, debugging tips, etc?
If you use the "Database Documenter" feature and check "yes" to all the options, you will obtain an exhaustive report that should let you trap your problem parameter. Export this report as an .rtf or .pdf document, so it is searchable. Identify a keyword from the dialog prompt, and search on that.
Once you check the query objects using the Documenter, check your VBA code. You'll do this by stepping through code in the IDE. If the main form has subforms, they are opened with (within) the main form. And they load before the main form.
Identify those subforms.
Sprinkle
breakpoints in their code modules
(if you find a Load function, that
is highly relevant).
If the main form has a
code module, do the same there.
Have a look for global variables in the module that needs to be opened and closed or any variable that is referenced in the module belonging to the form.
Access displays the Enter Parameter Value dialog box when you open an object that contains an identifier or expression that Access cannot interpret. You need to determine the source object. Here's a step-by-step guide:
http://office.microsoft.com/en-us/access-help/why-does-access-want-me-to-enter-a-parameter-value-HA010274377.aspx