Where are OCX files on my machine? - Level Extreme

Plateforme Level Extreme

Abonnement

Profil corporatif

Produits & Services

Support

Légal

English

Where are OCX files on my machine?

Message

De

30/04/1999 18:24:38

Ed Rauh
Trumbull, Connecticut, États-Unis

À

30/04/1999 13:57:27

Chaim Caron
Cleveland, Ohio, États-Unis

Information générale

Forum:

Visual FoxPro

Catégorie:

Contrôles ActiveX en VFP

Titre:

Re: Where are OCX files on my machine?

Divers

Thread ID:

00213739

Message ID:

00214154

Vues:

29

>Hi Ed,
> <>>> Could you either post the code for me or give me the date and section and I'll find the message. Thanks.

Try:

DECLARE INTEGER GetSystemDirectory IN Win32API ;
	STRING  @cLocation, ;
	INTEGER nSize
LOCAL cLocation, nSize

cLocation = SPACE(256)
nSize = GetSystemDirectory(@cLocation, 256)

IF nSize > 0
   *
   * Got it - it's the size of the return
   *
   cLocation = LEFT(cLocation,nSize)
ELSE
   *
   *  An error occurred when retrieving the value - return the null string
   *
   cLocation = ''
ENDIF

> I'm interested to know about the System vs. System32 subdirectory because if an OCX is missing, I will need to register it via program code. I believe that in order to do that, I have to place the ocx file into the appropriate subdirectory. So I need to know which is the appropriate subdirectory--System or System32. It's confusing because there are ocx's in both.

As I said, it doesn't matter a bit; the sole advantage to putting things in the System directory as returned by the API (under Win9x, typically C:\WINDOWS\SYSTEM; under NT, C:\WINNT\SYSTEM32) is that (1) for .DLLs that aren't registered, it's on the Windows search path, and (2) there's a standard way to find the directory (the API call). If everyone plays nice and puts common components in the same directory, it makes version updating easier, since the installation API can check date/time stamps and version numbers when deciding whether or not to replace an existing file with a possibly newer one. Unfortunately, not everyone does - the worst offenders are the terminally stubborn who believe that copying files should be enough to fully install a WinApp. They're the ones who scatter .DLL versions all over creation and bitch about installing runtime components on each machine locally. And whose installs inevitably have problems...

> Also, as per Doug Hennig, if an OCX is not registered, I have to check for the situation where the ocx physically exists but is not registered, so I have to know where to look for it.

That's a decision for your installation software - I use a common central repository of components which each client station can look to for the latest versions of executables and other components, along with a database that tells how to install them on the local system - copy to the local app dir, copy to a common component directory, and whether or not it needs to be registered. I'm also careful to make sure that things get put in place in a particular order, since it may be necessary for common components to be locatable and/or registered before another component can be registered (case in point - ODBC and DAO need to be in place before some of my automation servers that rely on their services will register.)

Yet another reason to check at startup - if you load an old version of a .DLL, it may prevent you from replacing it (at least trivially, without using delayed copy and registration) with the newer version that your application might need. And my experience is that if an OCX hasn't been installed and registered properly, the odds are great that neither have some of the things it is dependent on...

EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater

NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys

Click here to load this message in the networking platform