How rreliable is the CLSID method of obtaining a file location?
in [Visual Basic]
|
Prev: problem emailing attachment with COD method
Next: Loading Excel via VB - Resize issue with over 255 characters in a
From: Tony Toews on 7 Jul 2010 22:48 Folks I'm wanting to determine the version of various DAO, MSJet, ACE and ADO DLLs. One means of doing this is by using a CSIDL to get to C:\Program Files\Common Files\system\ado\msado15.dll (or close and then adding on system\ado as requiired.) Elsewhere it has been suggested that I should use the CLSID. In this case the entire key is HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32 which I got from http://support.microsoft.com/kb/266668 Is this a relable method especially if dealing with other language OSs? Is this the best, recommended method? Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/
From: Mayayana on 7 Jul 2010 23:19 It's reliable on Win32 if the object is registered. If you can use CreateObject, that listing has to be there. That's how COM makes it possible to find the object. But if the object is out-of-process the key is LocalServer32 rather than InProcServer32. Application objects and ActiveX EXEs are in that category. Watch out for 2 things when parsing the path string, though. There could be switches in the path. (Check for " /" and snip it off if found.) The path string may also need to be expanded. (Check for "%" in the string.) I don't know how it works with a 64-bit library, but that shouldn't matter if you're running 32-bit. | I'm wanting to determine the version of various DAO, MSJet, ACE and | ADO DLLs. | | One means of doing this is by using a CSIDL to get to C:\Program | Files\Common Files\system\ado\msado15.dll (or close and then adding | on system\ado as requiired.) | | Elsewhere it has been suggested that I should use the CLSID. In this | case the entire key is | HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32 | which I got from http://support.microsoft.com/kb/266668 | | Is this a relable method especially if dealing with other language | OSs? Is this the best, recommended method? | | Tony | -- | Tony Toews, Microsoft Access MVP | Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm | Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ | For a convenient utility to keep your users FEs and other files | updated see http://www.autofeupdater.com/
From: Tony Toews on 8 Jul 2010 00:04 On Wed, 7 Jul 2010 23:19:05 -0400, "Mayayana" <mayayana(a)invalid.nospam> wrote: > It's reliable on Win32 if the object is registered. >If you can use CreateObject, that listing has to >be there. Ah, excellent. That can work although usually a reference is used for ADO/DAO within Access. >That's how COM makes it possible to find >the object. But if the object is out-of-process the >key is LocalServer32 rather than InProcServer32. >Application objects and ActiveX EXEs are in that >category. Ok, now I'm not understanding all this but then prat of that is I do not fully understand what COM means. > Watch out for 2 things when parsing the path string, >though. There could be switches in the path. (Check >for " /" and snip it off if found.) The path string >may also need to be expanded. (Check for "%" in >the string.) Switch I can handle. % maybe not. > I don't know how it works with a 64-bit library, >but that shouldn't matter if you're running 32-bit. No, that part I don't care about yet although I might given that Access 2010 comes in a 64 bit edition. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/
From: Kevin Provance on 8 Jul 2010 00:21 Have you ever thought about attempting to create the ADO object through code? If it succeeds, it's installed. If it errors out, trap the error and throw it away, not installed. -- Customer Hatred Knows No Bounds at MSFT Free usenet access at http://www.eternal-september.org ClassicVB Users Regroup! comp.lang.basic.visual.misc Bawwk! Paulie want a dingleball, bawwk! "Tony Toews" <ttoews(a)telusplanet.net> wrote in message news:esea3611q3nq5re7nnc77u7f1lk6c5bksd(a)4ax.com... : Folks : : I'm wanting to determine the version of various DAO, MSJet, ACE and : ADO DLLs. : : One means of doing this is by using a CSIDL to get to C:\Program : Files\Common Files\system\ado\msado15.dll (or close and then adding : on system\ado as requiired.) : : Elsewhere it has been suggested that I should use the CLSID. In this : case the entire key is : HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32 : which I got from http://support.microsoft.com/kb/266668 : : Is this a relable method especially if dealing with other language : OSs? Is this the best, recommended method? : : Tony : -- : Tony Toews, Microsoft Access MVP : Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm : Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ : For a convenient utility to keep your users FEs and other files : updated see http://www.autofeupdater.com/
From: Nobody on 8 Jul 2010 05:54
"Tony Toews" <ttoews(a)telusplanet.net> wrote in message news:esea3611q3nq5re7nnc77u7f1lk6c5bksd(a)4ax.com... > Folks > > I'm wanting to determine the version of various DAO, MSJet, ACE and > ADO DLLs. For ADO, you can check Version property of the Connection object. |