It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
So I have an MS Access application originally in a 2002-2003 format. Developed on a production network image, and when the image pushed the office upgrade, it became office 2007. So this is used in a very non traditional way...reps take it with them on company laptops enter data, and it automates complex ppt presentations, and excel worksheet for them (they love it....they need it). Data is not held in this like a database repository, just long enough to produce the automation they need and it works....saves them time. So Access is limited, and in the use case, really limited since i am using it in a way it certainly wasn't intended to be used. I get that, but like I said so far, its working pretty well.....
The one bump I have run into is if someone has to use another computer for whatever reason (doesn't happen often but it got me thinking), and say they have a version of 2002-2003 access, the tool will run, but once we get to the code routines/modules for ppt & outlook, the object libraries show MISSING because working on this tool seems to automatically cause the libraries to go up to the next available version, but not down to find the version.....
so originally when I made this....it used MS PowerPoint 11.0, and MS Outlook 11.0, and then when I had to start working in 2007 it became 12.0 for both, some instances I see it bumped up to 14.0, and none of the ups are a problem, but now since I have an image with Office 2007 out, and new files version I try to give them has the libraries defaulted to 12.0 and if they run into a scenario where they would take the file on a disc and use it on a computer that has office 2003, those libraries just come up missing and it doesn't recognize the appropriate 11.0 object libraries anymore.
So finally my question....any suggesions (save the obvious and build a real app...lol...would love to....no $) to handling this? Is there code that can/will evaluate what libraries need to be set on opening the file using vba? Is that possible?
There is Remove Method which you could use to remove a reference, then AddFromFile Method or AddFromGuid Method to add a reference.
The AddFromFile approach was offered in answers to this recent StackOverflow question: Add references programatically However, make sure to read Tony's answer ... if you're distributing your application as an MDE, you're SOL.
Consider switching to late binding for your PowerPoint and Outlook stuff. That way you won't have to fiddle with references (no reference required for late binding). A drawback from late binding is you lose the benefit of IntelliSense during development. However, you can develop with early binding, then switch to late binding for deployment. Substitute the values where you used any named constants from the referenced library ... debug will highlight any you overlook.
A frequent counter-argument is that late binding imposes a "performance penalty". However, I've yet to encounter a use case where the "slow-down" was large enough to be noticeable by a human observer.
In any case I've been using late binding for years specifically to avoid the type of deployment issue you're struggling with now.
Edit: Here is an example which uses the Excel type library. I have it set to use early binding. To convert it to late binding, comment out the declarations under '* early binding ... , and uncomment those under '* late binding ...
Also notice the 2 lines which include the named constant, xlAutomatic.
Public Sub EarlyVsLateBinding()
Dim strFullPath As String
'* early binding requires reference to Excel type library *'
Dim objExcel As Excel.Application
Set objExcel = New Excel.Application
Dim objBook As Excel.Workbook
Dim objSheet As Excel.Worksheet
'* late binding; no reference required *'
' Dim objExcel As Object '
' Dim objBook As Object '
' Dim objSheet As Object '
' Set objExcel = CreateObject("Excel.Application") '
strFullPath = CurrentProject.Path & Chr(92) & "foo.xls"
Set objBook = objExcel.Workbooks.Open(strFullPath)
Set objSheet = objBook.Worksheets("bar")
objSheet.Range("B1").Select
With objExcel.Selection.Font
.Name = "Arial"
.FontStyle = "Regular"
.Size = 10
.ColorIndex = xlAutomatic 'named constant available with reference set '
'.ColorIndex = -4105 'substitute xlAutomatic value so we drop reference
End With
objBook.Close SaveChanges:=True
objExcel.Quit
Set objSheet = Nothing
Set objBook = Nothing
Set objExcel = Nothing
End Sub
Related
I was just wondering how do we have to declare "ie" from the following code?
Dim objShell As Object
Set objShell = CreateObject("Shell.Application")
Set ie = objShell.Windows(x)
Thank you :)
You can just use Object but it's easier if you enable the Microsoft Internet Controls library as it creates more specific objects. This allows you to use intellisense while coding which makes it much less of a guessing game of what properties and actions are available. Here's some sample code once you have it enabled.
Dim ieobject As InternetExplorer
Set ieobject = New InternetExplorer
ieobject.Visible = True
ieobject.navigate Url:="https://www.StackOverFlow.com"
'get the HTML document for the page.
Dim ieDOCUMENT As HTMLDocument
Set ieDOCUMENT = ieobject.document
This site covers it well (along with a lot of other VBA topics)
If you get the error User-defined Type not defined, you haven't enabled the Microsoft Internet Controls library.
Place a breakpoint (F9) in your procedure, then bring up the Locals toolwindow (View /> Locals) when the breakpoint is hit.
The runtime data types will appear under the "Type" column1:
If you are not referencing the type library where these classes and interfaces are defined, the type to use at the declaration site is Object, or Variant - because there is no compile-time reference to the library, the compiler cannot bind the types at compile-time, so you would get a compile error if you tried to declare the object variables otherwise.
With a reference to the appropriate type library, you can still use late binding and declare everything As Object, but that would be silly with the library right there waiting to be used.
In your particular example (as provided anyway), the type of ie is... Object, and the reference is Nothing, so expect any member call against ie to throw error 91:
1Unless user interfaces are involved... that's a bug in the VBE, unlikely to ever see a fix.
This question is a stumper, for experts only.
We are using Visual Studio 6 to develop a complex COM Add-In for Access. When compiled, the Add-In works fine. But, when we use Ctrl-F5 to put the VB6 IDE in debug mode, Access throws a
Run-time error 13: Type mismatch
error when it tries to assign the Access Application.COMAddIns("AddInName").Object reference to an early-bound VBA variable of a type exposed in the AddInName type library.
Further information:
The Access application uses objects created by calls to the Add-In
The Add-In DLL also serves as a type library that is included in Access VBA References
The type Access requests from the Add-In is defined in the AddInName type library
In Access VBA, the failing code looks like this:
Public Function GetAddInRef As AddInName.SomeClass
Dim objSomeClass As AddInName.SomeClass
' .Object is set to a SomeClass instance in IDTExtensibility2_OnConnection
Set objSomeClass = Application.COMAddIns("AddInName").Object ' => Error 13!
Set GetAddInRef = objSomeClass
End Function
If you change the type of objSomeClass to Object, the assignment works. If you set a break on the offending line, you can do things like this in the Immediate window:
? TypeName(objSomeClass)
AddInName.SomeClass
? TypeOf objSomeClass Is AddInName.SomeClass
False
So it is saying that the class name of objSomeClass is "AddInName.SomeClass", but it is not of type AddInName.SomeClass. Madness!
Further, if you put in code that exposes the CLSID for the Access-side reference and the Add-In originated object, they both return the same GUID! So why does VBA complain that the types are different?
Does anyone have any insight into what is happening here? I would be very grateful for any help.
I'm guessing (I am no expert) it's because AddInName.SomeClass is not an object, it is of type AddinName.SomeClass. Drop the .Object off of Application.COMAddIns("AddInName").Object and I think it will work just fine. If you need it as an object for somewhere else in your code, then change your AddInName.SomeClass types to Object and leave the .Object on Application.COMAddIns("AddInName").Object and it should work.
So a colleague of mine stumbled upon the answer: Set Access and VB6 permissions to administrator! I tried it, and VoilĂ , debugging works.
For each of the following executable files, Right-click, Properties, Configuration, then check Run this program as an administrator:
Office path:
MSACCESS.EXE (or EXCEL.EXE or WINWORD.EXE ...)
C:\Program Files (x86)\Microsoft Visual Studio\VB98\
VB6.EXE
LINK.EXE
Notes:
It probably helps to develop VB6 apps using an administrative login, too.
This makes sense, because VB6 had its start in the Windows 95 era, when users were pretty much the king of their OS instance.
Caveat: this may not be a perfect solution for very complex Access forms with lots of DLL interaction, but it is much better than nothing!
I have an Access app, developed in Access 2013 in multi-user env, uses Excel automation to export and format an Excel file.
The normal Office/Excel 2013 (15.0) references have been made and all works well on Office 2013 machines. Does not play nicely on 2010 machines.
Using a 2010 machine, I replaced the 15.0 references with 14.0 references, and the app is happy on 2010 and 2013 machines. Upon next edit/update on my 2013 machine the 15.0 references return.
Any suggestions to more conveniently develop/operate in this multi-version environment?
Thanks!
The overall solution to this issue is to use late binding. The downsides to late binding are
Dim xlApp As Object means that we don't get any IntelliSense for xlApp, and
related constants like xlEdgeTop are not defined without the associated Reference
These issues can be mitigated by using conditional compilation in the VBA project. For development, add the required Reference to the project and define a conditional compilation argument
which you can use in your code like this
Option Compare Database
Option Explicit
Public Sub WorkWithExcel()
#If LateBinding Then
Dim xlApp As Object
Set xlApp = CreateObject("Excel.Application")
#Else
Dim xlApp As Excel.Application
Set xlApp = New Excel.Application
#End If
Debug.Print xlEdgeTop
End Sub
To avoid clutter, I would be inclined to keep the constants in a separate Module like this
Option Compare Database
Option Explicit
#If LateBinding Then
Public Const xlEdgeTop = 8
#End If
When the code tweaking is complete, remove the Reference, set the LateBinding argument to "True" (LateBinding = -1) and compile the project. Add any constants you've missed (there always seems to be one or two) and when it compiles without the Reference you should be good to deploy.
For the next development session, set LateBinding back to "False" (LateBinding = 0) and add the Reference back in.
Several frameworks and languages seem to have lnk file parsers (C#, Java, Python, certainly countless others), to get to their targets, properties, etc. I'd like to know what is the general approach to reading lnk files, if I want to parse the lnk in another language that does not have said feature. Is there a Windows API for this?
There is not an official document from Microsoft describing lnk file format but there are some documents which have description of the format. Here is one of them: Shortcut File Format (.lnk)
As for the API you can use IShellLink Interface
Simply use lnk file parser at J.A.F.A.T. Archive of Forensics Analysis Tools project.
See lnk-parse-1.0.pl at http://jafat.sourceforge.net
There seems no have no dependencies. Syntax is simple and link file becomes a simple text in standard output and to be usable on Linux.
This is an old post, but here is my C# implementation for lnk processing that handles the entire spec, more info and command line tool on this blogspot page.
Using WSH-related components seems the most convenient option to read .lnk files in most languages on a post-XP windows system. You just need access to the COM environment and instantiate the WScript.Shell Component. (remember that on win, references to the Shell usually refer to explorer.exe)
The following snippet, e.g. does the thing on PHP: (PHP 5, using the COM object)
<?php
$wsh=new COM('WScript.Shell'); // the wsh object
// please note $wsh->CreateShortcut method actually
// DOES THE READING, if the file already exists.
$lnk=$wsh->CreateShortcut('./Shortcut.lnk');
echo $lnk->TargetPath,"\n";
This other one, instead, does the same on VBScript:
set sh = WScript.CreateObject("WScript.Shell")
set lnk = sh.CreateShortcut("./Shortcut.lnk")
MsgBox lnk.TargetPath
Most examples in the field are written in VB/VBS, but they translate well on the whole range of languages supporting COM and WSH interaction in a form or another.
This simple tutorial may come handy, as it lists and exemplifies some of the most interesting properties of a .lnk file other than the most important: TargetPath. Those are:
WindowStyle,
Hotkey,
IconLocation,
Description,
WorkingDirectory
here's some C# code using the Shell32 API, from my "ClearRecentLinks" project at https://github.com/jmaton/ClearRecentLinks
To use this your C# project has to reference c:\windows\system32\shell32.dll
string linksPath = "c:\some\folder";
Type shell32Type = Type.GetTypeFromProgID("Shell.Application");
Object shell = Activator.CreateInstance(shell32Type);
Shell32.Folder s32Folder = (Shell32.Folder)shell32Type.InvokeMember("NameSpace", System.Reflection.BindingFlags.InvokeMethod, null, shell, new object[] { linksPath });
foreach (Shell32.FolderItem2 item in s32Folder.Items())
{
if (item.IsLink)
{
var link = (Shell32.ShellLinkObject)item.GetLink;
if (link != null && !String.IsNullOrEmpty(link.Target.Path))
{
string linkTarget = link.Target.Path.ToLower();
// do something...
}
}
}
#Giorgi: Actually, there is an official specification of lnk files, at least it is claimed so.
However, for some reason, the link seems to be dead, and after downloading the whole (45 MB) doc package (Application_Services_and_NET_Framework.zip), it appears that it does not include the file MS-SHLLINK.pdf.
But is this really surprising ?
Once you got the file format, shouldn't be too hard to write code to read it.
I am using VBA (in Access 2003) and I'd like to use the IFilter mechanism to extract the textual contents of files. I found some some nice C++ sample code which makes it look relatively easy, but at the moment I can't even get the DLL call to LoadIFilter to work:
Declare Function LoadIFilter Lib "query.dll" (ByVal pwcsPath As String, _
ByVal pUnkOuter As Object, ByRef ppIFilter As Object) As Integer
Public Sub DocEx()
Dim ifilter As Object
Dim hresult As Integer
hresult = LoadIFilter("C:\temp\test.txt" & Chr(0), Nothing, ifilter)
Debug.Print hresult
End Sub
hresult is always E_FAIL (= 16389).
Is it my syntax for the DLL that is incorrect, or something else?
EDITED TO ADD: In the end I didn't solve this problem. But since my only purpose is to hack up an internal script, it is sufficient for me to to just call the FiltDump.exe tool that comes bundled with the Microsoft Platform SDK and parse its output. (A bit clunky though, especially since FiltDump.exe insists on printing error messages to stdout instead of stderr!)
LoadIFilter() is meant to do a lot of work - it looks up the registry to find which IFilter to load, then loads it (most likely calls CoCreateInstance() for just found class id). Anything could go wrong - there could be no mapping in the registry from .txt extension to the class id or the COM server for that class id could fail to load.
Your best bet is to use Process Monitor to see if it finds what IFilter to load and if at least it tries to load it.