So, I built a form in Access 2007, and put a subform on it. Then I went to the Property Sheet for one of the controls on the subform and used the builder to point to Code Builder for the OnClick event. This opened the VBA editor & inserted a sub skeleton. I added code here (just a freakin' MsgBox, so far), saved & tried running (opening) the form. It looks good, but clicking the control that has event code yields this, immediately:
The expression On Click you entered as the event property setting produced the following error: A problem occurred while Microsoft Access as communicating with the OLE server of ActiveX Control.
The so-called Help on the error notification is completely useless. It reads:
This error occurs when an event has failed to run because Microsoft Office Access cannot evaluate the location of the logic for the event. For example, if the OnOpen property of a form is set to =[Field], this error occurs because Access expects a macro or event name to run when the event is fired.
Access knew what was going on at design time, since it dropped me into VBA. The Property Sheet entry does read "[Event Procedure]". Is there a secret ninja trick to handling events from a subform, or is it just not possible?
I deleted the problem subform & created a new one. This one seems to work as expected. Go figure....
Related
I set a form "frmMain" to automatically display when the database is opened by naming it in: Access Options, Current Database, Display Form: frmMain.
In a lapse of judgement of enormous proportion, I included the statement me.requery at the beginning of the class object module Form_frmMain's Private Sub Form_Current() routine.
Now, whenever the database opens, it starts requerying over and over until after a second or so it displays a message: "Run-time error '3420': Object invalid or no longer set." Selecting End or Debug both have the same effect: me.requery is highlighted in yellow and a new "Object invalid or no longer set." message is displayed.
I've tried multiple Ctrl-Breaks, and Escapes, and can't get the console to return any control to me. I can kill the process with the Task Manager, but that of course doesn't let me get into the VBA code to remove my ridiculous me.requery.
Can someone help me out here? Thank you! Dave
After you kill your program from task manager, open your db file(I assume it is .accdb) by pressing down the shift+enter keys.
After you open your file you`ll see your database screen in front of you. Just double click a module to open the VBA editor or simply press ALT+F11. Then, youll be able to find your function.
I have taken 2 sample databases from online - one for a calendar and one for drag and drop functions - and pulled some code together for a result that is ALMOST functioning as I had hoped.
There is a function to build/refresh the calendar, which works perfectly.
The drag and drop functions work perfectly. (The item is updated in the table to reflect the new date.)
When I drag and drop, the calendar doesn't automatically refresh. If I click next month then last month (which call the refresh function with a new date), the changes are reflected as expected.
The problem is when I try to automatically call the refresh function after a drag/drop event. Access crashes every time I call for a refresh in the code after drag/drop, regardless of where I put the call.
The error says:
Microsoft visual C++ Runtime Library
Runtime Error!
Program: C:...
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information.
I have tried:
I thought it might be trying to refresh too fast, so I added a pause
function and had the program wait 10 seconds after dropping before
refreshing. Still crashed.
I did a compact and repair on the database.
I ran /decompile from the command-line on my accdb file.
I exported the relevant form, tables, query and module to a new accdb
file.
I have tried to re-register the libraries checked under references.
(RegSvr32 "Path to library file") The only one that succeeded was
vbe7.dll. The "MS access 14.0 object library", "OLE automation", and
"MS Office 14.0 Access Database Engine Object" don't contain a
DllRegisterServer method, so regsvr32 did not succeed with those. There are no other
references checked. Still crashes.
I have tried countless places to insert the call to refreshcalendar()
I have stepped through the code and verified the exact place that the
crash happens. It is commented in the code.
Here is a link to the database.
To reproduce the problem:
Open frmsubCalendar.
There are 2 entries in May 2014 that can be dropped to other days on the calendar. I can then click the prev/next month buttons on the form, and when May reloads, the change has been made. But if I go into mod_drag_drop under the sub dropdetect() and uncomment the lines noted in the comments, the refresh will crash access at the end of the dropdetect() sub.
I cannot figure out how to make the calendar refresh automatically after a drag/drop event without access crapping the bed.
I realize this is a bit outdated, but I had a similar issue and didn't see this one being answered, I figured I'd add this answer for posterity. :) I discovered it was caused by a reference to a function by the form name. I had the following call in a module:
lContractCt = Form_Census.lContractCt_f(bIsMembers)
Where lContract is a Long, there is a form named Census and a public function in that form called lContractCt_f.
I moved the function to a module (so the Form_Census reference wasn't necessary any more). And changed the call to:
lContractCt = lContractCt_f(bIsMembers)
This fixed the error. So, I would check if you have any public function references going from a module to a form and move those public functions into a module. I also saw a similar thread with a different form reference, via Forms![Census], for example.
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.
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 created an application in Access 2003 and continued to work on it on another computer with Access 2007. I created a report with a method that loads data from a recordset to some unbound fields on the report. This method takes three parameter values from three fields on the report. The report's data source is a query.
I call the method in the report's Load() event, like LoadSummary([field1],[field2],[field3]) and works fine in Access 2007.
I switched back to Access 2003 and the Load event is unavailable. I've tried calling the method using the Open, Page and Activate events but all fail because it seems like when these events fire, the fields have not been populated with the data yet.
Please help. How can I get this to work in Access 2003? Any eye openers are welcome. Thanks.
Try the OnFormat event of the report header section. If that doesn't work try the detail sections OnFormat event but but in a report level boolean variable so it only does it once.