Disable warning: You copied a large amount of data onto the clipboard - ms-access

While debugging queries written in MS Access 2007 (problem was the same in all previous versions too), I'll run the query and then copy the results into Excel. Depending on results, I switch batch to Access to refine the results and go back into design mode of the query. At this point, I get an annoying warning: you copied a large amount of data onto the clipboard. ...Do you want to save this data on the clipboard? I have never wanted to do this.
The MS Office clipboard is disabled so this function is happening with the standard Windows clipboard. Is there a way to disable the warning and assume No as the default?

There is a very easy solution to this. The warning message only happens if there is a LARGE amount of stuff on the clipboard. Therefore - make sure there is only a small amount of stuff there before you close.
For example, in a macro I wrote I do this:
Selection.PasteSpecial Paste:=xlPasteValues, Operation:=xlNone, SkipBlanks _
:=False, Transpose:=False
Windows("iostatZd15.1").Activate
ActiveWindow.WindowState = xlNormal
ActiveSheet.Range("A1").Copy
ActiveWindow.Close
The second-last line (immediately before the close) is a "dummy" - a command to simply replace the current (BIG) clipboard with a very small amount of data. It works.

I think you may have to disable the MS clipboard. Try this:
Quit any programs that are running.
Click Start, and then click Run. Type regedit and click OK.
In the Registry Editor, click to select the following subkey (folder): HKey_CURRENT_USER\Software\Microsoft\Office\9.0\Common\General
On the Edit menu, point to New and click DWORD Value. With New Value #1 selected, type AcbControl, and then press ENTER.
On the Edit menu, click Modify. In the Edit DWORD Value dialog box, click Decimal under Base. Type 1 in the Value data box. Click OK and quit the Registry Editor.
NOTE: You cannot disable (or enable) the Office Clipboard for only a single Office program by modifying the registry.
Here's the MS KB article

You could set the OnClose event of the form up to clear the clipboard.
Put the below code into a module in your database.
Private Declare Function apiOpenClipboard Lib "User32" Alias
"OpenClipboard" (ByVal hWnd As Long) As Long
Private Declare Function apiEmptyClipboard Lib "User32" Alias
"EmptyClipboard" () As Long
Private Declare Function apiCloseClipboard Lib "User32" Alias
"CloseClipboard" () As Long
Function EmptyClipboard()
If apiOpenClipboard(0&) <> 0 Then
Call apiEmptyClipboard
Call apiCloseClipboard
End If
End Function
Then in the Close event of your form use:
EmptyClipboard

In my experience, you only get this message when you close an application. Are you closing Excel before returning to Access? If so, don't close it and see if you no longer get the message.
EDIT after trying instructions for producing the error:
The only way to avoid the error message is to turn off notifications before entering design view, as in:
DoCmd.SetWarnings False
And you'd want to turn it back on after you are done with your editing.
But there's no place to run this code, since you're just using the Access UI to edit a query.
I don't quite understand why this warning is considered a problem. Maybe you're pasting, going back to design view, changing criteria, running again, pasting again? If so, turning SetWarnings off might do the trick.
If you wanted it to happen automatically, you could conceivably use the Screen.ActiveDatasheet object to do this. What you'd want to do is write a function:
Public Function ChangeWarnings(bolSetting As Boolean) As Boolean
DoCmd.Setwarnings bolSetting
End Function
...then when you open your query in datasheet view, in the Immediate window, type these two lines:
Screen.ActiveDatasheet.OnActivate = "=ChangeWarnings(False)"
Screen.ActiveDatasheet.OnDeactivate = "=ChangeWarnings(True)"
You could also certainly write code that sets this up for you.
One note -- it doesn't "stick" for the Screen.ActiveDatasheet object when opening or closing a different one. It applies only to the Datasheet that is active when you assign the event actions.

For Excel:
Fexcel = New Microsoft.Office.Interop.Excel.Application
Fexcel.DisplayAlerts = False
Do same for Access

Application.CutCopyMode = False

I run into this problem all the time. It seems silly to have to do this, but the following solution kills it dead.
' Copy something small into the clipboard
Range("A1").Copy
' Turn off CutCopyMode i.e., the "crawling ants"
' Application.CutCopyMode = False solves a lot of problems, I do it as a precaution after I copy anything
Application.CutCopyMode = False
CutCopyMode = FALSE does not turn off the all clipboard copying (as stated by another poster)

Related

Trouble with Access 2010 .SetFocus command syntax

Extremely puzzling:
Upon opening a simple form from another form by vba, the cursor moves to a particular field.
However, when this field is Null there is each second time Error 2110. The syntax to be used changes every time as shown below.
Even more puzzling:
Upon clicking "Debug", the error proves to be imaginary: on the corresponding code line, one can simply continue with F5 or F8 and the procedure ends correctly with the focus where desired.
I found a provisory workaround which does not generate the error message but would like if possible to avoid such limping coding:
'…
Debug.Print Me![MyTextField].Enabled ' always True
Debug.Print Me.Name ' always correct form
Me.Repaint
On Error Resume Next
[MyTextField].SetFocus ' without Me!
Me![MyTextField].SetFocus
' Forms![MyForm]![MytextField] : same result as with Me!]
' one time error with Me! but not without Me!,
' next time vice versa, and so forth…
On Error GoTo 0
'…
When [MyTextField] is not Null, both syntaxes work fine without generating an error.
What is wrong with this .SetFocus command ? "Repairing" the database didn't help.
You can't set focus to the control that has focus. It would give you a very easy way to set up a infinite loop.
You would have to set focus to another control first.
Minty's right. An easy workaround is doing it in an if statement or create a bool to see if IsNull(fieldhere) = true then exit sub or your action here. Or more simply maybe try:
if MyTextField.gotfocus = true then
do something
else
MyTextField.setfocus
I recently ran into this issue in something similar and had to create a public bool function and test it on load events. Please note that I'm a beginner in access so there's probably many better ways to complete this :)

MS Access 2010 VBA: mysterious compile error on custom LostFocus sub

In a data validation form, I have a subroutine checking previously-entered data on a LostFocus event by ensuring that the release time (TimeReleased in table; Me.txtTimeReleased on form) is after the capture time (ObservationTime in table; Me.txtObservationTime on form). I'm using LostFocus rather than BeforeUpdate because the data were bulk-imported into the db and are now being error-checked.
My users keep getting a compile error (Compile Error: method or data member not found) upon tabbing out of the field this sub is attached to but I cannot reproduce the problem locally. The error occurs on this line:
If (Me.txtTimeReleased) <= (Me.ObservationTime) Then
and the part highlighted is '.txtTimeReleased'
Full code block:
Private Sub txtTimeReleased_LostFocus()
Dim badData As Variant
Dim resp As Variant
'Also check that time released is after time captured
If Not IsNull(Me.txtObservationTime) And Not IsNull(Me.txtTimeReleased) Then
If (Me.txtTimeReleased) <= (Me.ObservationTime) Then
resp = MsgBox("Release time must be after capture time." & vbCrLf & "Please double check this field's value: is it correct?", _
vbYesNo + vbExclamation + vbDefaultButton2, "Release Time Before Capture Time")
If resp <> vbYes Then badData = True
End If
End If
If badData = True Then
Me.cmbTaxonId.SetFocus 'set focus away so can set focus back
With Me.txtTimeReleased
.SetFocus
.SelStart = 0
.SelLength = 10
End With
End If
End Sub
Other things to note:
Both the table field and form control are formatted as 'Short Time' (24-hour time)
There is an input mask on that form control for 24-hour time; I use input masks very rarely and thus aren't familiar with them--perhaps the input mask could be causing the problem?
There are similar LostFocus subs on most of the other controls which do not produce this (or any other) error
Things I've tried:
Checking spelling
Fully decompling and recompiling the code: starting with shift, compact and repair with shift, open with /decompile flag while holding shift, compact and repair with shift, re-open with shift, and finally compile (without error)
Replacing the form in their database with one that works fine for me on the same data
Google
Things that seem odd to me:
I can't reproduce the error locally.
The error is triggering on the second instance of
Me.txtTimeReleased rather than the first: it has already passed a Not
IsNull(Me.txtTimeReleased) check.
The fact that it's a compile error: could that be masking something else?
Thanks for your time, and please let me know if there's any additional information that would be useful. Any thoughts are most welcome!
You checked for Null txtObservationTime and txtTimeReleased, but compare then txtTimeReleased and ObservationTime. Maybe solution is:
If Not IsNull(Me.txtObservationTime) And Not IsNull(Me.txtTimeReleased) Then
If (Me.txtTimeReleased) <= (Me.txtObservationTime) Then
Opening the .mdb with the /decompile flag is one of the first things I would have suggested, but you said you already tried that.
Here's another undocumented trick to deal with "hidden" compile problems that get baked in by VBA behind the scenes:
First, make a backup copy of your .mdb just to be safe (this is, after all, an undocumented technique).
Then, save your form to a text file using SaveAsText:
SaveAsText acForm, "MyFormName", "C:\MyFormName.txt"
Finally, re-load your form using the equally undocumented LoadFromText:
LoadFromText acForm, "MyFormName", "C:\MyFormName.txt"
Compile.
Compact.
Repair.
Hope for the best.
Good luck.
I suggest you use variables:
intThat = Me.txtTimeReleased
If intThis <= intThat Then
Try using ! instead of a dot:
intThat = Me!txtTimeReleased
If intThis <= intThat Then
And now, the answer that worked for me last week:
Comment out the offending line.
Run a compile that is successful.
Restore the offending line.
The compile may work now. Don't ask me why.

access to oldValue for control in continous form generates error 3251 in beforeUpdate when a checkbox on form is updated

This is one of the stranger issues I have seen in MS Access. I have the following code in a continuous form:
Private Sub thisForm_BeforeUpdate(Cancel As Integer)
If Not Cancel Then
Debug.Print "pre-logging data changes..."
' here we need to doublecheck to see if any values changed.
' we simply iterate through the whole list, re-setting oldValue
' and newValue.
For Each control In thisForm.Section(acDetail).controls
If control.ControlType = acTextBox Or _
control.ControlType = acComboBox Or _
control.ControlType = acListBox Or _
control.ControlType = acOptionGroup Or _
control.ControlType = acCheckBox Then
Debug.Print control.Name
oldValues(control.Name) = control.oldValue
newValues(control.Name) = control.value
End If
Next
End If
End Sub
oldValues and newValues are Dictionary objects (although likely not related to the issue).
My form has 3 textbox controls, and a checkbox control. One of the text box controls is disabled, and is populated via the results of a simple inner join (to get the human readable name associated with a foreign key). The data source comes from the form's recordsource (no DLookup or anything is used).
If I edit one of the other two textbox controls, this code runs absolutely fine. HOWEVER, if I toggle the checkbox on the form, i get a runtime error 3251. In the watches window, I get the error again when i try to view the properties of "control". It shows the value of oldValue for the disabled control to be "Reserved Error".
If it did this consistently, I would think it was due to the control being disabled; but since it works without a problem when the other textboxes receive edits, and only breaks when the checkbox is toggled; I am stumped. I'm almost inclined to believe I found a bug in access, but I could use some extra input.
Anyone else every encounter an issue like this?
EDIT: Upon digging further, I found that in actuality only one of the 3 editable fields will not trigger this error. It holds string data. The other two controls hold a date value, and a yes/no value. Now I am even more confused.
i've got two ideas to that issue.
First one: If the RecordSource of your Form is an ODBC-Table thats linked to a SQL-Server then you should set a standard value for the CheckBox-Column. Otherwise it will try to set NULL to False and throw an error saying that somebody else edited the current record.
Second idea: Sometimes Access just has a little "hiccup" when it compiles the code. You could make a backup of your database and then try to decompile it using "C:\Program Files\Microsoft Office 2007\Office12\MSACCESS.EXE" "C:\yourFolder\yourDatabase.accdb" /decompile in the Run... Window (of course you have to insert the Path as it is on your machine). That often helps solving strange Problems.

How can I check if an instance of a Access 2010 form is still open?

Preface
I have a need to create multiple copies of a search form (in Access 2010) that returns a value to the calling (which is also the form that created the instance of the form).
As mentioned these forms could and will have multiple copies running at the same time for example a user could want to add a company to something so they:
Click "select company" and open an instance of the company search screen
Then open the company editor (leaving the original company search/selection screen open) as they notice the company has a parent company that hasn't been added yet.
They then click the "Select Parent Company" button that opens ANOTHER instance of the search and select screen
They find the parent company
Select it which closes the second search screen and the parent company is added to the first company.
The user then selects the modified company using the original search screen which again closes the original search screen and returns the selected company to what ever form they originally initialised the first search...
This all allows the users to update and correct data as and when they find error which reduces the likelihood of them forgetting and makes it much quicker!
MOST of this is fine now but I have had a lot of problems with instances of a form not being able to open as a "acDialog" thus stopping the calling code running until the search was done (see this question for more info) and the solution I have gone with is to simulate the pausing of the calling code by using a endless loop and checking if the search screen instant is still visible. Then when the user selects something on the search screen instant it puts the value in a hidden field in the search screen and hides it's self (not closed). The calling function then sees it's hidden grabs the value from the hidden field and unloads the instant.
Problem
I can check if the form is hidden using FormInstant.Visable but if the user closes the form this causes an error and the code I would normally use to check if the form exists requires a form name and as it's an instant of a form all the forms have the same name! I do have a reference to the form as it is stored in a local "form" object... The code I would normally use is:
CurrentProject.AllForms("FormName").IsLoaded
So how can I check for a instant of a form being loaded still?
An old question but here's what experience taught me: If One, Two, ... instances of FormDefn opened then user closes One (Master which is the only one that can be designed), Forms(FormName) gives an error, Forms(Form) gives wrong object,
but Forms(NumberIndex) does still exist with .Name = FormName!
OpenForm creates the Forms(FormName) object. Once closed Forms(FormName) gives an error. Any "Set xForm = New Form_xxx" creates forms in the forms collection that can only be accessed by the collection number index, and cant be designed.
So to later find a multi-instance form use something like:
Dim FormIdx As Integer
Dim lForm As Access.Form
For FormIdx = 0 To Application.Forms.Count - 1
Set lForm = AccessFunc.Appl.Forms(FormIdx)
If lForm.Name = pFormName Then
IsFormOpened = True
Set rForm = lForm
GoTo IsFormOpened_Exit
End If
Next
LOL I just realised while re-reading my msg that I can likely trap the error to work out if the form is open or not!
I have quickly written this and it seems to work fine:
Public Function IsFormLoaded(ByRef FormToTest As Form, _
Optional ByRef bIsVisable As Boolean = False) As Boolean
Dim lErrorNum As Long
bIsVisable = False
On Error Resume Next
bIsVisable = NewFormClone.Visible
lErrorNum = Err.Number
On Error GoTo 0
If (lErrorNum = 0) Then
IsFormLoaded = True
Else
IsFormLoaded = False
End If
End Function
Guess it doesn't really mater who answers the question as long as it is answered and the next guy/gal can use it! :)
I will leave this open for a bit and if nobody finds a better answer I will mark this as it...
I like your answer. As for the loop/wait idea? A better way is to always include a reference in each form. I useally declare form module variable called frmPrevious.
Create instance of form
Instance.frmPrevious = me
So now we have the form "call" some code when the form is closed in place of some "visible" + looping code setting.
So in the close code of the form we have:
frmPrevious.FunctionCodeToRun
The above solves a good many issues, but one is you don't need dialog (which as you note cannot use) And you also dump the need for writing "loop + wait" code from the calling code.
This does however mean that your code continues in a new function in the calling form. I thus usually place that function right below the calling code in the calling form. I also tend to use a standard name for that function. I find this trade off worth it as opposed to loop/wait and continuing in the same code routine (I do agree this "continue" in code is often preferable, but then again having to write looping and wait code is not really that clean).
Try this also
Function IsLoaded(strFrmName As String) As Boolean
' Determines if a form is loaded.
Const conFormDesign = 0
Dim intX As Integer
IsLoaded = False
For intX = 0 To Forms.Count - 1
If Forms(intX).FormName = strFrmName Then
If Forms(intX).CurrentView <> conFormDesign Then
IsLoaded = True
Exit Function ' Quit function once form has been found.
End If
End If
Next
End Function
You can call the above function it in your project like so
If Not isLoaded("MyForm") Then
MsgBox "MyForm is Not Loaded"
End If

Disabling msgbox in access

I am trying to make a small form in MS Access 2003 SP3, I use some function that some other people made and these function has msgbox in it. I would like to disable msgbox while I am running the form. Is it possible in Access to disable msgbox?
I created my finction called msgbox. Seems like its working. Thanks everyone for your help.
Public Function MsgBox(Prompt, Optional Buttons As VbMsgBoxStyle = vbOKOnly, Optional Title, Optional HelpFile, Optional Context) As VbMsgBoxResult
If myProcedureisRunning then
VBA.MsgBox Prompt
else
debug.print prompt
endif
End Function
If in fact these message boxes are produced from VBA code, then comment them out. However, if they are Access generated, such as the message box when inserting or updating records, you need to use the command DoCmd.SetWarnings False in order to suppress them. Just make sure to turn warnings off only when needed, then turn them back on. Otherwise, ALL message boxes from Access will be off, even in "design mode".
Do a CTRL-F and find for MSGBOX and comment it. I guess that's the only way you can do it.
Press Alt+F11 to open the Visual Basic IDE, then press CTRL+F to search. Type msgbox into the find, select "Replace" and type'msgbox into the "replace with" box (note the apostrophe). This will comment out all msgbox statements in the project.