Visual Basic Q&A

Symptoms
When you use the New operator or CreateObject function in Microsoft Visual Basic to create an instance of a Microsoft Office application, you may get the following error message:

Run-time error ‘429′: ActiveX component can’t create objectThis error occurs when the requested Automation object could not be created by COM, and is therefore unavailable to Visual Basic. The error is typically seen on certain computers but not others.
This article provides some troubleshooting tips to help you diagnose and resolve common problems that are known to cause this error.
Resolution
Unlike some errors in Visual Basic, there is no one cause to an error 429. The problem happens because of an error in the application or system configuration, or a missing or damaged component. Finding the exact cause is a matter of eliminating possibilities. If you encounter this error on a client computer, there are a number of things you will need to check to isolate and resolve the error.
The items later give you some practical suggestions for troubleshooting this error when you work with Office Applications. Some of this information may also apply to non-Office COM servers as well, but this article assumes you are trying to automate Microsoft Office.
Checking the CodeThe first place to begin looking for the problem is in the code. Before you can troubleshoot the error, you need to know where the error occurs. Try to narrow it down to a single line of code.
When you find the code that is failing, try to do the following:
Make sure the code uses explicit object creation. Any problem is easier to spot and identify if the problem is narrowed to a single action. For example, do not do the following:

Application.Documents.Add ‘DON’T USE THIS!!
or:

Dim oWordApp As New Word.Application ‘DON’T USE THIS!!’… some other codeoWordApp.Documents.Add Both of these methods use implicit object creation. Microsoft Word is not started until the variable is called at least once. Since the variable could be called in different parts of the program, this could make the problem hard to localize. Also, it is not clear whether the problem is with creating the Application object or the Document object.
Instead, make explicit calls to create each object separately:

Dim oWordApp As Word.ApplicationDim oDoc As Word.DocumentSet oWordApp = CreateObject(“Word.Application”)’… some other codeSet oDoc = oWordApp.Documents.Add This makes the problem easier to isolate and makes the code more readable.When creating an instance of an Microsoft Office application, use CreateObject instead of New. CreateObject more closely maps to the creation process used by most Visual C++ clients, and allows for possible changes in the server’s CLSID between versions. CreateObject can be used with both early-bound and late-bound objects.Verify that the ProgID string passed to CreateObject is correct and that it is version independent (that is, use “Excel.Application” rather than “Excel.Application.8″). It could be that the system that is failing has an older or newer version of Microsoft Office than the version you specified in the ProgID.To aid in debugging applications that cannot be run in the IDE, use the Erl command to report the line number of the line that fails. For example, the following code will tell you which Automation object cannot be created (Word or Excel):

Dim oWord As Word.ApplicationDim oExcel As Excel.ApplicationOn Error Goto err_handler1: Set oWord = CreateObject(“Word.Application”)2: Set oExcel = CreateObject(“Excel.Application”)’ … some other codeerr_handler:MsgBox “The code failed at line ” & Erl, vbCritical Use a combination of message boxes and line numbers to track down the error.Try using late binding (that is, Dim oWordApp As Object). Early bound objects require their custom interfaces to be marshaled across process boundaries. If there is a problem marshaling a custom interface during CreateObject or New, you will get an error 429. A late bound object uses a system-defined interface (IDispatch) that does not require a custom proxy in order to be marshaled. Try using a late bound object to see if this makes a difference.
If the problem occurs only when the object is early-bound, the problem is with the server application, and can typically be corrected by reinstalling the application (see later).If you are automating from ASP or an MTS component, use CreateObject instead of Server.CreateObject(). Using Server.CreateObject will instantiate the Office application under the identity of an MTS package which is known to cause problems with Microsoft Office.
Checking the Automation ServerThe most common reasons for an error with CreateObject or New are problems with the server application itself. Typically, these problems are with the configuration or setup of the application. Here are some items to check:
Verify the Microsoft Office application you want to Automate is installed on the local computer, and make sure that you can start the application from the Start and then Run dialog box. If the program cannot be started manually, it will not work through automation.Re-register the application by typing the path to the server in the Start and then Run dialog box, and then append /RegServer to the end of the line. Press OK. This should silently run the application and re-register it as a COM server. If the problem is with a missing registry key, this will typically correct it.Check the LocalServer32 key under the CLSID for the application you want to Automate. Make sure it points to the correct location for the application, and make sure the path name is in a short path (DOS 8.3) format. While it is not a requirement that a server be registered using a short path name, long path names that include embedded spaces have been known to cause problems on some systems (see later).
To check the path key stored for the server, start the Windows Registry Editor by typing regedit in the Start and then Run dialog box. Navigate to the HKEY_CLASSES_ROOT\Clsid key. Under this key you will find the CLSIDs for the registered automation servers on the system. Using the values later, find the key that represents the Office application you want to Automate and check its LocalServer32 key for the path.

+========================+=========================================+| Office Server| CLSID Key|+========================+=========================================+| Access.Application| {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9}|+————————+—————————————–+| Excel.Application| {00024500-0000-0000-C000-000000000046}|+————————+—————————————–+| FrontPage.Application| {04DF1015-7007-11D1-83BC-006097ABE675}|+————————+—————————————–+| Outlook.Application| {0006F03A-0000-0000-C000-000000000046}|+————————+—————————————–+| PowerPoint.Application | {91493441-5A91-11CF-8700-00AA0060263B}|+————————+—————————————–+| Word.Application| {000209FF-0000-0000-C000-000000000046}|+————————+—————————————–+ Does the path match the actual location of the file? Be aware that short path names can give you the impression that a path is correct when it may not be. For example, both Microsoft Office and Microsoft Internet Explorer (if installed in their default locations) will have a short path similar to “C:\PROGRA~1\MICROS~X\” where X is some number. It is not immediately obvious that you are looking at from a short path name.
You can test that the path is indeed correct by copying the value from the registry and pasting it into the Start and then Run dialog box (remove the /Automation switch before running the application). Does the application start when you select OK? If yes, then the server is registered correctly. If not, you should replace the value of the LocalServer32 key with the correct path (use a short path name if possible).Problems have been known to occur when automating Word or Excel if either the Normal.dot template (Word) or the Excel.xlb resource file (Excel) has become corrupt. To test if a corruption has occurred, search the local hard drives to find all instances of Normal.dot or *.xlb. (Please note that if you are running Windows 2000, Windows NT, or Windows 95/98 with profiles enabled, you may find multiple copies of these files, one for each user profile on the system.) Temporarily rename the Normal.dot file(s) or the *.xlb file(s), and re-run your Automation test (Word and Excel will create these files if they cannot find them). Does the code now work? If yes, then the files you renamed should be deleted since they are corrupt. If not, you should rename them back to their original names so any custom settings saved in these files won’t be lost.If you are on a Windows NT, Windows 2000, Windows XP, or Windows Server 2003 system, run the application under the Administrator account. Office servers require read/write access to the registry and disk drive, and may not properly load if your current security settings deny this privilege.
Checking the SystemSystem configuration can also cause problems with the creation of out-of-process COM servers. The following are some things to check on systems where the error occurs: Does the problem happen with any out-of-process server? If you have an application that just uses a particular COM server (for example, Word), you’ll want to test a different out-of-process server to make sure the problem is not with COM layer itself. If no out-of-process COM server can be created on that system, then a reinstallation of the OLE system files (see below) or a reinstallation of the operating system will be required to resolve the issue.Check the version numbers for the OLE system files that manage Automation. These files are typically installed as a set, and should match build numbers. An improperly configured setup utility can mistakenly install the files separately, causing them to become mismatched. To avoid problems with Automation, you should check the files to make sure the files match builds.
You will find the Automation files in the Windows\System or Winnt\System32 directory. The following is the list of files to check:

+—————+————-+—————-+| File Name|Version| Date Modified|+—————+————-+—————-+| Asycfilt.dll|2.40.4275| March 08, 1999 || Oleaut32.dll|2.40.4275| March 08, 1999 || Olepro32.dll|5.0.4275| March 08, 1999 || Stdole2.tlb|2.40.4275| March 08, 1999 |+—————+————-+—————-+ Check the file version by right-clicking on the file in Explorer and selecting Properties from the popup menu. The values most important are the last four digits of the file version (the build number) and the date last modified. You want to make sure these values are the same for all the Automation files.
Please note that the version numbers and dates given above are for example purposes only. Your values may differ. The important thing is that these values match each other, rather than this table.
If the files don’t match build numbers or modified dates, you can download a self-extracting utility that will update your Automation files. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
290887?(http://support.microsoft.com/kb/290887/) VBRun60sp6.exe installs Visual Basic 6.0 SP6 run-time filesWindows NT 4.0 has a known problem with starting Automation servers that live in a folder that contains an embedded space in the name, and/or resembles another folder whose first 8 characters are identical. For example, a server living in C:\Program Files\SomeFolder may fail to start during a call to CreateObject if there is another folder on the system called C:\Program Stuff\SomeFolder. For more information, see the following Knowledge Base article:For additional information about this problem and steps to workaround it, click the article number below to view the article in the Microsoft Knowledge Base:
185126?(http://support.microsoft.com/kb/185126/EN-US/) BUG: COM/OLE Server Fails to Start on Windows NT 4.0
Reinstalling Microsoft OfficeIf none of the preceding steps helps to resolve the problem, consider uninstalling and reinstalling Microsoft Office. Microsoft recommends that you uninstall the existing version first, and then reinstall from the original installation disks.
For a complete list of the items to be removed, please see the following Knowledge Base articles:
219423?(http://support.microsoft.com/kb/219423/EN-US/) OFF2000: How to Completely Remove Microsoft Office 2000
158658?(http://support.microsoft.com/kb/158658/EN-US/) OFF97: How to Completely Remove Microsoft Office 97

Symptoms
Subclassing intercepts messages that the operating system sends to specific windows. Subclassing allows you to process messages that are not handled natively by a control or form.
Subclassing requires that you use the AddressOf operator, which provides callback functionality. For more information about how to use this operator, visit the following MSDN Web site:
AddressOf Operator
http://msdn.microsoft.com/en-us/library/aa242738.aspx(http://msdn.microsoft.com/en-us/library/aa242738.aspx)NOTE: The AddressOf operator provides callback functionality when it calls Windows APIs that require this feature. This functionality is also known as a function pointer. The AddressOf operator was not designed or tested for subclassing purposes. Subclassing can have disastrous results if you use it incorrectly.
Microsoft supports the demonstration of subclassing in Visual Basic. Some controls may experience problems if they are made into a subclass, because their intended behavior is modified beyond the original design. Therefore, subclassing in Visual Basic does not always work. Microsoft does not guarantee that subclassing in Visual Basic will produce the results that you want.
Resolution
The limitations and risks of function pointers in Visual Basic include the following:
Debugging: If your application fires a callback function while it is in break mode, the code is executed, but any breaks or steps are ignored. If the callback function generates an exception, you can catch it, and then return the current value. Resets are prohibited in break mode when a callback function is on the stack.
Thunks: Windows enables relocatable code by using thunking. If you delete a callback function in break mode, the thunk is modified to return a zero value. This value is typically correct, but not always. If you delete a callback function in break mode, and then you type the callback function again, it is possible that some call recipients will not know about the new address.
Thunks are not used in the compiled executable. The pointer is passed directly to the entry point.
Passing a function with the wrong signature: If you pass a callback function that takes a different number of arguments than the caller expects, or if you pass a callback function that mistakenly calls an argument by using ByRef or ByVal, your application may fail. You must pass a function with the correct signature.
Passing a function to a Windows procedure that no longer exists: When you make a window into a subclass, you pass a function pointer to Windows as the Windows procedure (WindowProc). However, when you run your application in the IDE, the WindowProc function may be called after the underlying function is destroyed. This may cause a general protection fault, and may cause the Visual Basic development environment to fail.
Visual Basic to Visual Basic function pointers are not supported: Pointers to Visual Basic functions cannot be passed in Visual Basic. Only pointers from Visual Basic to a DLL function are supported.
Containing errors in a callback procedure: Any errors in a callback procedure must not be propagated back to the external procedure that initially called. Therefore, put the On Error Resume Next statement at the beginning of the callback procedure.

Symptoms
Many Visual Basic application developers are moving to Windows NT as theirdevelopment platform because of its robustness and excellent multitaskingcapabilities. This article shows by example how Visual Basic developers canuse the Windbg debugger to debug a dynamic link library (.DLL file) orcustom control (.VBX file) called from a Visual Basic application runningunder Windows NT.
CodeView for Windows doesn’t run under Windows NT because CodeView uses aVxD (Virtual Device Driver) not supported by Windows NT.
For information on how to use CodeView for Windows to debug Visual BasicCustom controls (.VBX files), please see the following article in theMicrosoft Knowledge Base:
75612?(http://support.microsoft.com/kb/75612/EN-US/): How to Use CodeView for Windows (CVW.EXE) with Visual Basic
WARNING: Using Windbg as described in this article is not supported byMicrosoft, so you should save all source files before using this procedure.Windbg should exit without hanging the system. However, you should notmodify your Visual Basic source while running under Windbg unless youalways make sure you have saved any changes before running the code. Thisprocedure has been tested on Windows NT version 3.5. Preliminary testing onWindows NT version 3.51 shows problems when switching to Visual Basic whilerunning under Windbg, so you should not use this procedure with Windows NTversion 3.51.
Resolution
This article follows the steps and contains much of the material in 75612?(http://support.microsoft.com/kb/75612/EN-US/),but it has been modified to describe how to use the Windbg debugger todebug a dynamic link library (.DLL file) or custom control (.VBX file)called from Visual Basic running under Windows NT.
Windbg is one of the debuggers supplied with the Win32 SDK. It is a Windowsdebugger but retains many of the commands of the NTSD debugger that is alsosupplied with the Win32 SDK. More information may be found for both Windbgand NTSD in the Win32 Tools Users Guide.
NOTE: You can build custom controls using the Control Development Kit (CDK)for Visual Basic. The Visual Basic CDK, formerly shipped separately as anadd-on product from Microsoft, is now shipped as part of the ProfessionalEdition of Microsoft Visual Basic for Windows.
Information on installing Windbg can be found in the Help files suppliedwith the Win32 SDK. There are several supporting .DLL files that arerequired to use Windbg, so it is not sufficient to copy just the WINDBG.EXEfile from the SDK.
How to Invoke WindbgMake sure your system is backed up and can be recovered if it should hang.This is highly unlikely because Windows NT has been designed to preventthis kind of problem.
You can invoke Windbg from the Windows Program Manager in any of thefollowing ways:
From the Windows Program Manager File menu, choose New, andspecify WINDBG.EXE as a Program Item with proper arguments. You canthen double-click the WINDBG icon to run WINDBG.EXE.From the Windows Program Manager File menu, choose Run, and enterWINDBG.EXE and its command line arguments.Invoke WINDBG with no arguments from a command prompt, and follow thesteps below to load the various files and modules required for thedebug process.
Step-by-Step ExampleThis example demonstrates how to invoke CIRC3.VBX, which comes with theMicrosoft Visual Basic Control Development Kit (CDK) or the Visual Basicprofessional edition:
Run WINDBG.EXE from the Program Manager or command prompt:
[path]WINDBG.EXE [path]VB.EXE
NOTE: You can just specify an .EXE program that was written in theVisual Basic environment instead of specifying the VB.EXE environmentitself. If you do this, skip steps 7, 8, and 9 below.
The CIRC3.VBX is not loaded from the command line along with Windbg asit is with CodeView. It will automatically be loaded by Windbg when itis added to the Visual Basic development environment. Note that the .VBXfile must be built so that it includes symbol information.If you invoked WINDBG.EXE with no command line arguments, load VB.EXEor the Visual Basic application by choosing Open from the Program menu.Choose New to bring up the Open dialog box.From the Open dialog box, locate VB.EXE or the application you want torun, and open it. Click OK when you return to the Open dialog box.
NOTE: If you are debugging a Visual Basic application rather thanloading VB.EXE, you must load the CIRC3.VBX explicitly to be able toset breakpoints. From the Options menu, choose User DLLs. Click theBrowse button and locate the CIRC3.VBX. Click OK to add it to the listof modules. Click OK again to exit the dialog box.From the File menu, choose Open to load the CIRC3.VBX source code.Locate the directory with the CIRC3.C file. Select and open this file.An MDI window will open in Windbg; it contains the source code forthe .VBX file.From the Options menu, choose Debug, and select the Separate WOW/VDMcheck box in the Debugger Options dialog box. Click OK.Press the F5 key or choose Go from the Run menu. Visual Basic starts up.You should see various system-level .DLL files loaded. This informationappears in the Command window in Windbg.From the File menu in Visual Basic, choose Add File. In the Files box,select the CIRC3.VBX file. The CIRC3 tool appears in the toolbox. Again,you should see various .DLL files loaded. These are system files thatsupport the loading of the .VBX file. You will also see the CIRC3.VBXfile loaded.Select the custom control from the toolbox, and add it to your form.You may now set a breakpoint in the CIRC3.C source code. Locate theWM_LBUTTONDBLCLK message, and set a breakpoint on the first IFstatement.
If the line turns red, this indicates that the breakpoint has been setsuccessfully. If it is purple, the breakpoint is not correctly set, soit is never triggered. This can occur if the .VBX file does not includesymbol information.Press the F5 key from within Visual Basic to run your program.Double-click the circle. When your breakpoint is encountered, focusis set to the debugger, and execution stops at your breakpoint. You cannow step through your program, set watchpoints, and so on.Press the F5 key to return to the Visual Basic program and stop thedebugging.NOTE: When you exit Visual Basic, you receive an “Assertion Failed” messagefrom within Windbg. Click OK and Windbg exits. You may get another dialogbox depending on how you have your system configured for exceptionhandling. Do not click Cancel to debug unless you have the kernel debuggeron your system, otherwise your system will appear to be hung.

Symptoms
Installation macros can be used throughout the steps of the Package andDeployment Wizard (PDW) to install files to specific locations. Thisarticle documents the available installation macros and what the macroswill equate to during the installation process.
Resolution
These macros will be used by both Setup.exe and Setup1.exe to install filesto common system directories. These macros may be modified after thedistribution set has been created by modifying the Setup.lst file createdby the PDW. See the REFERENCES section of this article for additional information regarding Setup1 files and Bootstrap files.
$(WinSysPath)
This macro installs files to the System subdirectory under the Windowsdirectory. The paths below are typical paths to the Windows\Systemdirectory. This macro can be used for both Setup1 Files and BootstrapFiles.

\Windows\System (Windows 95 or later)\Winnt\System32 (Windows NT 4.0 and later)
$(WinSysPathSysFile)
This macro installs files to the System subdirectory as well, but thefile is installed as a shared component and is not removed when theapplication is removed. The paths below are typical paths to theWindows\System directory. This macro can be used for both Setup1 Filesand Bootstrap Files.

\Windows\System (Windows 95 or later)\Winnt\System32 (Windows NT 4.0 and later)
$(WinPath)
This macro installs files to the directory where Windows is installed.The examples below are typical paths to the Windows directory. Thismacro can be used for both Setup1 Files and BootStrap Files.

\Windows (Windows 95 or later)\Winnt (Windows NT)
$(AppPath)
The application directory specified by the user, or the DefaultDir valuespecified in the Setup section. Valid only for Setup1 Files.
\path
A hard coded path, for example, “c:\mydir”. This is only available bymodifying the Setup.lst file. Valid only for Setup1 Files.$(CommonFiles)
This macro installs files to the Program Files\Common Files folder.Valid only for Setup1 Files.

\Program Files\Common Files\
$(CommonFilesSys)
Installs files to the \System folder under Program Files\Common Files.Valid only for Setup1 Files.

\Program Files\Common Files\System
$(ProgramFiles)
Installs files to the \Program Files directory. Valid only for Setup1Files.

\Program Files
$(MSDAOPath)
Installs files to the location stored in the Registry for Data Access(DAO)Components.
$(Font)
Installs to the \Font subdirectory under the Windows directory.

\Windows\Fonts

Symptoms
Attempting to access a DCOM Server from a remote client application sometimes results in the following error:

Run-time error ‘70′:
Permission Denied
This article describes the most common scenarios in which this error is raised.
Resolution
Run-time error ‘70′ is typically the result of a security or permissions issue. The following is a list of possible causes of run-time error 70 but is by no means a complete or definitive list.
DCOM Is Not Enabled If the Server machine does not have DCOM enabled, client machines will receive run-time error 70 when attempting to access the server. This scenario applies to Windows 2000, Windows NT, Windows 95, Windows 98, and Windows Millennium Edition (Me) servers:
On the Server machine, run DCOM Config (DCOMCNFG.EXE). Choose the Default Properties tab. Ensure that Enable Distributed COM on this computer is checked. This value is stored in the Windows Registry at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
The Client User Does Not Have Sufficient Permissions If the client user does not have the correct permissions, access to the DCOM Server can be denied. There are several steps to take in order to ensure your client has valid privileges.
If the Server is Windows 95, Windows 98, or Windows Me:
Run DCOM Config. Select the DCOM Server application from the list of available applications. Select the Properties button, or double-click the DCOM Server application in the list. Test the server with “Default Access Permissions.”
If run-time error ‘70′ still occurs, the default access permissions are restricting your user. If this is the case, then modify the Default Access Permissions from the Default Security tab in DCOM Config. Grant the client user access permissions.
If run-time error ‘70′ does not occur running with default access permissions, it is likely that the custom access permissions are restricting your client from accessing the DCOM Server. Choose custom access permissions and select the Edit button. Grant the client user access permissions. If the Server is Windows NT or Windows 2000:
Run DCOM Config. Select the DCOM Server application from the list of available applications. Select the Properties button, or double-click the DCOM Server application in the list. Test the server with “Default Access Permissions,” “Default Launch Permissions,” and “Custom Configuration Permissions.”
If run-time error ‘70′ still occurs, it is likely that the default access permissions are restricting your user. If this is the case, modify the Default Access Permissions from the Default Security tab in DCOM Config.
If run-time error ‘70′ does not occur, it is likely that the custom access permissions are restricting your client from accessing the DCOM Server. Choose to use Custom access permissions and choose the Edit button. Grant the client user account access permissions, or grant a group the client user belongs to access permissions. For more information regarding security groups on Windows NT see the table to follow.
There are several group accounts you will find when you configure users and groups on Windows NT and Windows 2000. The following list is a summary of who belongs to each group:

GroupDescription————————————————————————–InteractiveIncludes all users who log onto a Windows NT orWindows 2000 system locally (at the console). Itdoes not include users who connect to NTresources across a network or are started as aserver.NetworkIncludes all users who connect to Windows NT orWindows 2000 resources across a network. It doesnot include those who connect through aninteractive logon.Creator/OwnerThe Creator/Owner group is created for eachsharable resource in the Windows NT orWindows 2000 system. Its membership is the set ofusers who either create a resource (such as afile) and who take ownership of them.EveryoneAll users who access the system, whether locally,remotely, or across the network.SystemThe local operating system.
The above list includes the group accounts which are intrinsic to Windows NT and Windows 2000 systems. Your particular network may include more groups from which you may choose. In order to determine the membership of each custom group account, you must contact your network administrator.

The DCOM Server Raises Events to the Client If your DCOM server component raises events that are handled by the client application, you must configure DCOM security on the client computer to allow access, and you must configure DCOM security on the server computer. This allows the server to make callbacks to the client, so the event can be raised. If you do not configure DCOM security in this way, error 70 is generated whenever the client application calls the server. This results in an event being raised back to the client. If the server application does not raise events, you do not have to configure DCOM security on the client computers.
If the client computer is running Windows 95, Windows 98, or Windows Me, follow these steps:
Run DCOM Config (DCOMCNFG.exe). Click the Default Security tab. Click the Edit Default button. Click the Add button. Click to select The World, and then click the Grant Access button to grant permissions. Click Ok to close the Add Access Permissions dialog box. Click Ok to close the Access Permissions dialog box. Click Ok to close the DCOM Config Properties dialog box. Test the application again.
The client application successfully handles the event.
If the client computer is running Windows NT orWindows 2000, follow these steps:
Run DCOM Config (DCOMCNFG.exe).Click the Default Security tab. Click the Edit Default button. Click the Add button.Click to select the Everyone account, and then click to select Allow Access in the Type of Access box. Click Ok. Click Ok again to close the Registry Values Permission dialog box. Click Ok to close the DCOM Config Properties dialog box. Test the application again.
The client application successfully handles the event.
Attempting to Access DCOM Server Across Non-Trusted Domains If your DCOM Server resides in one Windows NT or Windows 2000 domain, and your client logs on to a second Windows NT or Windows 2000 domain that is not “trusted” by the first, you will receive run-time error ‘70′ when attempting to access the DCOM Server.

Symptoms
The Registry is used by Windows 95, Windows 98, and Windows Me to determine whatapplication programs and hardware items are installed in the computersystem. This article explains how to retrieve the name of the defaultprinter from the Registry from within a Visual Basic application program.
Resolution
Manipulating the Registry in Visual BasicThe Windows 95/98/Me Registry is a database of information containingconfiguration details about the hardware and software installed in yourcomputer system. Under Windows 3.1, this information is maintained throughinitialization (INI) files.
The Registry is comprised of keys. Each key may contain a specific value orother subkeys that in turn may contain values or other subkeys. You canexamine or modify the contents of the registration database by using theWin32 Registry API functions in a Visual Basic program or by using theRegistry Editor (REGEDIT).
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

The demonstration program below shows how to use the Win32 Registry APIfunctions to retrieve the default printer’s name from the Registry.
The first step to retrieve the printer name is to call the RegOpenKeyExfunction. This function opens the specified key in the registrationdatabase. In our case, we want to open the key that is associated withthe printer. This key is stored in the Registry as:

SystemCurrent Control SetControlPrintPrintersDefault All of the above items are keys and subkeys. We are interested in thePrinters subkey.
We also need to tell the RegOpenKeyEx function that we want to work withthe Default subkey. After calling this function, a value is returnedthat is set to zero if the function was successful.The next step is to retrieve the actual value stored for the key we areinterrogating. Because we want to retrieve the name that is assigned tothe default printer, we want to call the RegQueryValueEx function. Wemust tell this function that we want to retrieve the value that wasgiven to the Default subkey.The last step is mandatory. You must call the RegCloseKey function torelease the handle of the key you have been accessing in theRegistration database. This terminates access to the registrationdatabase and frees the handle for future use by the computer system.
How to Create the Demonstration ProgramThe demonstration program below shows how to retrieve the name of thedefault printer from the Windows 95, Windows 98, or Windows Me Registry.
Create a new project in Visual Basic. Form1 is created by default.Add the following constant and Declare statements to the GeneralDeclarations section of Form1:

Private Declare Function RegOpenKeyEx Lib “advapi32″ Alias _”RegOpenKeyExA” (ByVal hKey As Long, ByVal lpSubKey As String, _ByVal dwReserved As Long, ByVal samDesired As Long, phkResult _As Long) As LongPrivate Declare Function RegQueryValueEx Lib “advapi32″ Alias _”RegQueryValueExA” (ByVal hKey As Long, ByVal lpValueName$, ByVal _lpdwReserved As Long, lpdwType As Long, lpData As Any, lpcbData As _Long) As LongPrivate Declare Function RegCloseKey Lib “advapi32″ (ByVal hKey As _Long) As LongConst HKEY_CURRENT_CONFIG As Long = &H80000005 Add a Text Box control to Form1.Add a Command Button control to Form1.Add the following code to the Click event for Command1:

Private Sub Command1_Click()Dim PName As StringPName = GetCurrPrinter()Text1.Text = PNameEnd Sub Create a new procedure called GetCurrPrinter. Add the following code to this procedure:

Function GetCurrPrinter() As StringGetCurrPrinter = RegGetString$(HKEY_CURRENT_CONFIG, _”System\CurrentControlSet\Control\Print\Printers”, “Default”)End Function Create a new procedure called RegGetString. Add the following code tothis procedure:

Function RegGetString$(hInKey As Long, ByVal subkey$, ByVal valname$)Dim RetVal$, hSubKey As Long, dwType As Long, SZ As LongDim R As LongRetVal$ = “”Const KEY_ALL_ACCESS As Long = &H9F003FConst ERROR_SUCCESS As Long = 0Const REG_SZ As Long = 1R = RegOpenKeyEx(hInKey, subkey$, 0, KEY_ALL_ACCESS, hSubKey)If R <> ERROR_SUCCESS Then GoTo Quit_NowSZ = 256: v$ = String$(SZ, 0)R = RegQueryValueEx(hSubKey, valname$, 0, dwType, ByVal v$, SZ)If R = ERROR_SUCCESS And dwType = REG_SZ ThenRetVal$ = Left$(v$, SZ)ElseRetVal$ = “–Not String–”End IfIf hInKey = 0 Then R = RegCloseKey(hSubKey)Quit_Now:RegGetString$ = RetVal$End Function Execute the demonstration program by pressing the F5 function key. When youclick the Command Button control, the name of your default printer isdisplayed in the Text Box control.