Is anyone aware of any differences in versions of .NET/VBA/Excel etc that would cause a reference to Range.Cells to compile for most computers but not a client's new Mac ("with the error unknown data member")?
The code is:
Dim validationArr As Range
Set validationArr = Worksheets("sheet1").Range("B3:T3") 'Grab row dedicated to validation
For i = 1 To validationArr.Cells.Count
It thinks validationArr.Cells is unknown.
I'm just confused as to why it would compile and work on most computers including the client's old Mac but not on their new Mac.
I intend to replace it with validationArr.Rows(1).Cells.Count and see if it works but have yet to confirm.
Okay so for some reason the replacing it with validationRng.Count worked (I renamed the variable).
I faced similar unexplained compilation errors later on and exporting the module, deleting the module, and re-importing it fixed all compilation problems.
Bizarre.
Related
I'm having this staggering problem in creating a reference at runtime.
In short: I have an addin referenced in another addins, all created by myself and all working fine (except for some annoying popup which appears on loading Excel). As a workaround to this annoyance, I removed the existing reference to create it later, at runtime. But when I try creating the reference, it returns an "Name conflicts with existing module, project, or object library" error popup, and the reference is not created--which makes no sense, because if I create the reference at design time it works perfectly. There is no module or project with repeated name.
Now explaining a little further.
I have four kinda-complex Excel applications I'd had developed for my job. Each one is a VBA project, distributed as Excel Addins (.xlam).
Additionally, I have a fifth project with functions common to the other four. This fifth project is referenced in the other ones (via Tools -> References). So now, all I have to do is to call them as any API outside referenced function (commonProject.Function (arg1, arg2, arg3 etc)).
Unfortunately, I had some problems with a popup message (here) and the workaround seems to be referencing the fifth project in the other ones at runtime.
In order to do this, I uninstalled three of the other four Addins, remaining only one, and used the following code in its Workbook_Open event:
Private Sub Workbook_Open()
Dim strNamePath As String
Dim bolAddinIsRefered as Boolean
Dim oRef As Variant
strNamePath = "c:\etc\etc\etc\Filename.xlam"
For Each oRef In ThisWorkbook.VBProject.References
If oRef.FullPath = strNamePath Then bolAddinIsRefered = True
Next oRef
If bolAddinIsRefered = False Then ThisWorkbook.VBProject.References.AddFromFile strNamePath
End Sub
The problem is, when I used to create the reference at design time by hand, it worked mostly fine (except for the annoying popup I'm now trying to circumvent). But when I try creating the Reference at runtime, it returns an "Name conflicts with existing module, project, or object library" error popup, and the reference is not created.
I have verified the module and worksheet names and there is no duplicated one.
Does anyone have any idea how to prevent this error?
it seems after one and a half day struggling with a problem, when you ask the question on StackOverflow the solution just pops in your mind.
I'd already tried to change both projects names, even internal functions or subs resembling the same name. But I had not looked upon the FILE NAME!
As my solution is called Sisyphus, the filenames of all addins started with "Sisyphus"--"Sisyphus Common Functions.xlam", "Sisyphus DocMerge.xlam" etc.
The problem was VBA was comparing the first word in filename. I removed spaces and it worked well. Now my filenames are "SisyphusCommonFunctions.xlam", "SisyphusDocMerge.xlam" etc. and the referencing in runtime works all right.
Thank you for your time, I'll let this Question and Answer here, because it can be usefull to someone.
Our admins ran some MS Office 2016 updates (Build 11929.20838) and all of a sudden I noticed a few unexpected errors in one of my previously written Excel VBA macros. For example below error is popping up against any variable which I have not defined explicitly. It was not the case before and unless I had mentioned Option Explicit, I had never experienced anything like this.
Compile error:
Can't find project or library
I am also getting the same error against the following 2 statements of my code, whereas it used to run smoothly before the last Microsoft Office 2016 update.
' Against the following two declarations, the compiler is highlighting
' Date in parenthesis and quoting same error "Can't find project or library"
xMonth = VBA.DateTime.Month(Date)
xYear = VBA.DateTime.Year(Date)
' And showing same error as above against defining an Array variable like below
srchString = Array("invoice_number", "invoice_date", "Category_wise_code", "Bill To Customer", "consignees_address_long")
'And even here, it is giving the same error:
[A1].Font.Bold = True
Does anyone have any idea about these errors and how to resolve this issue? All of this quite unexpected. Let me tell you this macro has been in my use for over 4 years and I never ran into issues like these.
You will find something fishy here:
https://www.google.com/search?rlz=1C1CHZL_enGB838GB838&ei=EOInX-ibPMeusAXFw7z4Cg&q=%22ms+office+2016%22+%22july+updates%22+%22VBA%22&oq=%22ms+office+2016%22+%22july+updates%22+%22VBA%22&gs_lcp=CgZwc3ktYWIQAzoECAAQRzoICCEQFhAdEB46BQghEKABUOTJCljq_gtgg4UMaABwAXgAgAHzAogByiiSAQYyLTIuMTSYAQCgAQGqAQdnd3Mtd2l6wAEB&sclient=psy-ab&ved=0ahUKEwjo4_6J5f7qAhVHF6wKHcUhD68Q4dUDCAw&uact=5
Although not all links are opening, but Google window is briefly showing that some people are also facing macro crash situation.
Thanks for your time reading my post.
I have some VBA code that ran fine in Excel at my desk at work but at home it's crashtastic. Turns out all I had to do was change
Set shtObj = ThisWorkbook.Sheets(1)
to
Set shtObj = Excel.ThisWorkbook.Sheets(1)
Anyone know why? Our organization has just moved to a SharePoint platform, which I suspect is causing all manner of voodoo to creep up, but I'm just guessing.
Does it work if you change it back to ThisWorkbook?
I suspect it will, and the reason would be because the VBA recompiled itself (and didn't compile properly the first time - hence the propensity to crash).
Recompilation occurs when the version details embedded in the file differ from the version of Office/VBA in use, or there's a change from 32 to 64 bit Office. Editing the line is enough to recompile the line, so adding Excel. before ThisWorkbook was enough to make it recompile. Removing Excel. before ThisWorkbook should force it to recompile again.
The only other thing it might be is if there's a variable named ThisWorkbook, but then I'd expect you to get error 91, "Object variable or With block variable not set", or some other error, but not a crash.
ThisWorkbook is a global-scope Workbook object that you can use to refer to the workbook instance that contains the very VBA code that you're looking at.
So in theory, an unqualified ThisWorkbook is exactly the same object as Excel.ThisWorkbook or Application.ThisWorkbook.
Proof:
Sub Test()
Debug.Print ObjPtr(ThisWorkbook), _
ObjPtr(Excel.ThisWorkbook), _
ObjPtr(Application.ThisWorkbook)
End Sub
Outputs 3 times the same pointer address.
Excel.ThisWorkbook is a member (Property Get) of the hidden Excel._Global module, and Application.ThisWorkbook is a member (Property Get) of the Excel.Application class.
Not sure what's up with your file, but there's not supposed to be any difference between the two.
This appears to be a bug in my particular user/profile. Others are now using the code/workbook with no reports of trouble. Yay!!?
I am having a problem with a workbook. It works fine on my machine but when it is run by someone else it is giving a problem with an error message "Compile error can't find project or library"- thing is, it is doing it on a Mid$ string command!
Anyone know what could cause this? Is there a setting they need somewhere? The code was written in Excel 2010 and they are running Excel 2010
This is caused when you have a missing reference. Have a look in Tools > References on the machines that are throwing the error. You should see that certain references are prefixed with MISSING.
These libraries will need to be installed on the other machines in order to use them, alternatively, you could try late binding if they have an earlier version of the reference you are using.
If the above doesn't work, I have experienced this problem when there is a failed installation on the machine. None of the references are missing, but upon opening Excel a (usually unrelated) application gets stuck in a failed install loop. If this is what is happening, you'll need to rectify the failed installation.
I'm jut trying to import a spreadsheet into a table in Access 2000.
The spreadsheet is called cc-ledgcodebalances.xls with no field names.
My code is
DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel3, "tmptmp", VFileName, 0
This seemed to work once but since then I now get this;
The Microsoft Jet database engine could not find the object
''cc-ledgcodebalances$''. Make sure the object exists and that you
spell its name and the path name correctly. 3011
Google searches aren't really turning up much that is useful. I'm trying to
import the whole thing and I don't think this is to do with named ranges.
Bit stumped by this, any help?
I answered this elsewhere that you asked it:
The error you're getting often occurs when the saved import spec is out of synch with either the source data or the target table. Try starting the import with the wizard, then load the saved import spec and it will likely throw an error or reveal what's no longer accurate.
I just had a similar problem under 2007 using direct range references instead of named ranges. It seems that dollar signs in the range reference can cause this error. Using Replace() on "$" and replacing with "" solved this issue in my case.