Desaware Home
Products    Purchase    Publishing    Articles   Support    Company    Contact    
Support
Product FAQ
Licensing System
CC Factory
Event Log Toolkit
Gallimaufry
IniFile Tool-5M
LineGraph-5M
NT Service Toolkit
OneTime Download
SpyWorks
StateCoder
StorageTools
VBX Legacy
VersionStamper
Downloads
Documentation
Professional Services

 

bluebar
Contact Desaware and order today

bluebar
Sign up for Desaware's Newsletter for the latest news and tech tips.

Legacy VBX/OCX/OS Product Support

This section includes frequently asked questions relating to older products, or use of recent products on older operating systems (for example: 16 bit issues on SpyWorks).

Frequently Asked Questions

  1. I get an "ActiveX component can't create object" error message when trying to run the SpyWorks Professional 7.0 edition of SpyUpdat.exe.
  2. Why do I get a "Path Not Found" error message when I try to update my files using SpyUpdat.exe?
  3. The SpyWorks Update utility still reports conflicts after I updated the files.
  4. An error occurred while installing the 16 bit components on an NT based system with SpyWorks 7.
  5. After installing SpyWorks Pro 6.2, I get errors when opening my Control Panel on certain systems.
  6. Installing SpyWorks Pro 6.0 causes some of my controls to display "License information for this component not found..." when I try loading them in Visual Basic.
  7. Cannot edit SpyWorks OCX event code in VB 5.0 or VB 6.0
  8. Problem upgrading SpyWorks VB 4.0 projects to VB 5.0 or VB 6.0
  9. Upgrading SpyWorks VBX to OCX.
  10. Upgrading a VB 4.0 project that uses the SpyWorks Callback control to VB 5.0 or VB 6.0
  11. Converting a project using the SpyWorks Demo controls into a project using the retail release controls.
  12. Installation problems (Out of Memory)
  13. I've installed several SpyWorks update, but if I tried to uninstall the last update, then the uninstall program seems to hang, or causes a GPF.

1. I get a Run-time error '429', "ActiveX component can't create object" error when trying to run the SpyWorks Professional 7.0 edition of SpyUpdat.exe

This problem can occur when you choose NOT to have the SpyWorks 7.0 Professional installation program create "Shortcuts" for you AND not select the VB 5 file types (installing just the VB 6 file types or .NET file types). In this scenario, the SpyWorks installation program installs the VB 5 edition of the SpyWorks Update utility to your system. It uses the VB5 edition of the SpyWorks support files which weren't installed since the VB5 file types were not selected.

To fix this problem, copy the dwvscmp6.dll file from the SpyWorks CD's "\SpyWorks70\System32" folder to your System (or System32) folder and register the file. Also, copy the SpyUpdat.exe file from the SpyWorks CD's "\SpyWorks70\VBApps\VB6" and overwrite the existing file in your "\SpyWorks\VBApps\" folder. This will copy the VB6 edition of the update utility along with one of the required VB6 run time files.


2. I ran the SpyWorks Update utility and found out that there are newer versions for several of my SpyWorks files. But when I update the files, I get a "Path Not Found" error message from the Update utility.

Under certain circumstances, this can occur if one of the files being updated is the SpyUpdat.exe file. To get around this problem, make sure you update the dwvslb5.dll file before updating the SpyUpdat.exe file. After rebooting, then you can update the SpyUpdat.exe file.


3 . I ran the SpyWorks Update utility and found out that there are newer versions for several of my SpyWorks files. After I successfully updated the files, I ran the SpyWorks Update utility again and it reports that some of the updated files are not registered.

Currently, the SpyWorks Update utility (version 6.2 and earlier) does not register files that it updates. The reason for the "File not registered" warning is that the newer files have a newer "Type Library" version number. When an ActiveX component or control is changed, it has to maintain backwards compatibility with previous versions. When newer properties, methods, or events are added, this causes the COM "interface" to change which results in an increment to the type library. These files should be registered so that the new features can be used.


4. When I run the SpyWorks Pro 7 setup program to install 16 bit components on an NT based machine, I get several error messages near the end of the installation. The error message displays that "OLE2.DLL is not a valid Windows image".

The errors are the results of a registration error during the installation. What is happening is that the SpyWorks 7.0 Pro setup program is trying to use the 32 bit registration functions to register the 16 bit OCX files. Furthermore, these files are installed in the wrong NT System folder (System32 instead of System). This problem only occurs when installing the 16 bit edition on an NT system. Here is a list of things that needs to change (you can also download a patch that does most of the work):

The following files needs to be moved from the System32 folder to the System folder.

DWSPYDLL.DLL
DWCBK16.OCX
DWEASY16.OCX
DWSDES16.DLL
DWSBC16.OCX
DWSHK16.OCX
APIGUIDE.DLL

The following files should already exist in your System folder, and these files should be the same file. You can verify the version number of these files to make sure they are identical. If so, just remove them from the System32 folder.

OC25.DLL
COMDLG16.OCX

After the files are moved, you will need to register the following files. You can do so by running the following from the Start Menu's "Run" command. This is assuming that you installed Visual Basic 4.0 16 bit edition in the "C:\VB4" folder, and your System folder is located in the "C:\WINNT\SYSTEM" folder. Otherwise, substitute the appropriate paths.

C:\VB4\CLISVR\REGSVR16.EXE C:\WINNT\SYSTEM\DWCBK16.OCX
C:\VB4\CLISVR\REGSVR16.EXE C:\WINNT\SYSTEM\DWEASY16.OCX
C:\VB4\CLISVR\REGSVR16.EXE C:\WINNT\SYSTEM\DWSBC16.OCX
C:\VB4\CLISVR\REGSVR16.EXE C:\WINNT\SYSTEM\DWSHK16.OCX

If the COMDLG16.OCX file did not exist in the System folder, then you can register that file using the same command.

C:\VB4\CLISVR\REGSVR16.EXE C:\WINNT\SYSTEM\COMDLG16.OCX

To make the SpyWorks 7.0 uninstall program correctly remove the files, you will need to edit the install.log file so that the correct paths are set. Open up the install.log file located in your main SpyWorks 7.0 folder using Notepad. Search for the names of the files that you moved and change the path. For example, you would change the following lines from:

File Copy: C:\WINNT\SYSTEM32\DWSPYDLL.DLL
File Copy: C:\WINNT\SYSTEM32\DWCBK16.OCX
File Copy: C:\WINNT\SYSTEM32\DWEASY16.OCX
File Copy: C:\WINNT\SYSTEM32\OC25.DLL
File Copy: C:\WINNT\SYSTEM32\COMDLG16.OCX
File Copy: C:\WINNT\SYSTEM32\DWSDES16.DLL
File Copy: C:\WINNT\SYSTEM32\DWSBC16.OCX
File Copy: C:\WINNT\SYSTEM32\DWSHK16.OCX
File Copy: C:\WINNT\SYSTEM32\APIGUIDE.DLL

to

File Copy: C:\WINNT\SYSTEM\DWSPYDLL.DLL
File Copy: C:\WINNT\SYSTEM\DWCBK16.OCX
File Copy: C:\WINNT\SYSTEM\DWEASY16.OCX
File Copy: C:\WINNT\SYSTEM\OC25.DLL
File Copy: C:\WINNT\SYSTEM\COMDLG16.OCX
File Copy: C:\WINNT\SYSTEM\DWSDES16.DLL
File Copy: C:\WINNT\SYSTEM\DWSBC16.OCX
File Copy: C:\WINNT\SYSTEM\DWSHK16.OCX
File Copy: C:\WINNT\SYSTEM\APIGUIDE.DLL

Finally, you would need to edit the registry to remove the entries of the shared files from the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs] key. You would remove the following "named values".

"C:\WINNT\SYSTEM32\DWSPYDLL.DLL"
"C:\WINNT\SYSTEM32\DWCBK16.OCX"
"C:\WINNT\SYSTEM32\DWEASY16.OCX"
"C:\WINNT\SYSTEM32\OC25.DLL"
"C:\WINNT\SYSTEM32\COMDLG16.OCX"
"C:\WINNT\SYSTEM32\DWSDES16.DLL"
"C:\WINNT\SYSTEM32\DWSBC16.OCX"
"C:\WINNT\SYSTEM32\DWSHK16.OCX"
"C:\WINNT\SYSTEM32\APIGUIDE.DLL"

and then add the following:

"C:\WINNT\SYSTEM\DWSPYDLL.DLL"
"C:\WINNT\SYSTEM\DWCBK16.OCX"
"C:\WINNT\SYSTEM\DWEASY16.OCX"
"C:\WINNT\SYSTEM\OC25.DLL"
"C:\WINNT\SYSTEM\COMDLG16.OCX"
"C:\WINNT\SYSTEM\DWSDES16.DLL"
"C:\WINNT\SYSTEM\DWSBC16.OCX"
"C:\WINNT\SYSTEM\DWSHK16.OCX"
"C:\WINNT\SYSTEM\APIGUIDE.DLL"

and give each of those "named values" the value of 1.

You can download a patch program that would do most of the work. You can download this patch from

ftp://ftp.desaware.com/SW70Pro16InstallProblems/16patch.exe

You can run this patch to fix the problems described above. Run this patch program from your main SpyWorks folder. The only thing this patch does not do is rename the paths in the original SpyWorks 7.0 install.log file. After running this patch, you can edit your SpyWorks 7.0 install.log file so that the correct paths are set. For example, after running the patch, you would change the following lines in the SpyWorks install.log file from:

File Copy: C:\WINNT\SYSTEM32\DWSPYDLL.DLL
File Copy: C:\WINNT\SYSTEM32\DWCBK16.OCX
File Copy: C:\WINNT\SYSTEM32\DWEASY16.OCX
File Copy: C:\WINNT\SYSTEM32\OC25.DLL
File Copy: C:\WINNT\SYSTEM32\COMDLG16.OCX
File Copy: C:\WINNT\SYSTEM32\DWSDES16.DLL
File Copy: C:\WINNT\SYSTEM32\DWSBC16.OCX
File Copy: C:\WINNT\SYSTEM32\DWSHK16.OCX
File Copy: C:\WINNT\SYSTEM32\APIGUIDE.DLL

to

File Copy: C:\WINNT\SYSTEM\DWSPYDLL.DLL
File Copy: C:\WINNT\SYSTEM\DWCBK16.OCX
File Copy: C:\WINNT\SYSTEM\DWEASY16.OCX
File Copy: C:\WINNT\SYSTEM\OC25.DLL
File Copy: C:\WINNT\SYSTEM\COMDLG16.OCX
File Copy: C:\WINNT\SYSTEM\DWSDES16.DLL
File Copy: C:\WINNT\SYSTEM\DWSBC16.OCX
File Copy: C:\WINNT\SYSTEM\DWSHK16.OCX
File Copy: C:\WINNT\SYSTEM\APIGUIDE.DLL


5. After installing SpyWorks Pro 6.2, I get errors when opening my Control Panel on certain systems.

SpyWorks 6.2 installs an older implementation for Control Panel Applets as well as the newer ones.

The existence of the older Control Panel Applets may cause problems in certain operating systems when you initially open the Control Panel.

You can just delete the Control Panel Applet files to fix this problem. The SpyWorks installation creates an install.log file in your SpyWorks directory. Open that file using Notepad and search for .cpl. Then note the directory the .cpl files were installed to - usually your System directory and delete them. The newer SpyWorks Control Panel Applet file is named dwspycpl.cpl. If you have the NT Service Toolkit light edition installed, it will also install a Control Panel Applet named dwsvcpl.cpl.


6. Installing SpyWorks Pro 6.0 causes some of my controls to display "License information for this component not found..." when I try loading them in Visual Basic.

The SpyWorks 6.0 Pro installation may cause some custom controls included with Visual Basic to fail their license check. If you had installed SpyWorks 6.0 and then get the message:

"License information for this component not found. You do not have an appropriate license to use this functionality in the design environment."

while attempting to place one of the included Visual Basic controls on your Visual Basic form, then this is an indication that the SpyWorks installation overwrote some licensing information.

What happened is that the SpyWorks Pro 6.0 installation program, while it was writing some new licensing keys to the registry, erased the "Default" data contents of the "Licenses" key. Most ActiveX control's licensing scheme would just verify that their own key exists as a sub key of the "Licenses" key, but it looks like some ActiveX controls would actually compare the "Default" data string of the "Licenses" key.

Here is what you need to do to restore the licenses for the affected Visual Basic custom controls:

Go to the start menu and select the "Run" command, then "Run" regedit.exe, open up the HKEY_CLASSES_ROOT key, and then select the "Licenses" sub key. The "Default" data for the "Licenses" sub key is probably empty. Right click on the "Default" data, a menu should popup, select the "Modify" command. Then place the following string in the "Value Data" text box:

Licensing: Copying the keys may be a violation of established copyrights.

The case must match exactly in the above string.

You can also download an EXE which restores the License key's data string to the above mentioned string. You can retrieve this EXE from:
ftp://ftp.desaware.com/SW60ProInstallProblems/sw6p_lic.exe


7. I added a SpyWorks 4.x OCX (dw???32.ocx) control to my VB 5.0 or VB 6.0 project. When I try to access one of the control's events, I get a "User-defined type not defined" error message.

Visual Basic 5.0 and 6.0 interprets internal types from OCXs differently than Visual Basic 4.0. Some of the SpyWorks event parameters that use to be interpreted as a Long type are now interpreted as an "Stdole.OLE_HANDLE" type. This type is defined in the "OLE Automation" type library. Add this reference (by using the Project -- Reference command, then select the "OLE Automation" refrence -- stdole2.tlb file) to your project in order for VB 5.0 or 6.0 to recognize the new "Stdole.OLE_HANDLE" type.


8. VB displays a "Compile error: Procedure declaration does not match description of event or procedure having the same name" in one of the SpyWorks control's event when I try running my VB 4.0 project in VB 5.0 or 6.0.

Visual Basic 5.0 and 6.0 interprets internal types from OCXs differently than Visual Basic 4.0. What use to be interpreted as a Long type is now interpreted as an "Stdole.OLE_HANDLE" type. You can still assign a Long value to a property that is expecting a Stdole.OLE_HANDLE type, but VB 5.0 and 6.0 requires that the event declaration match. One easy way to update the parameters is to add a new control to your form and then copy the event parameters to your previous control.

You also need to include the "OLE Automation" Reference in your project (stdole2.tlb file) in order for VB 5.0 and 6.0 to recognize the new "Stdole.OLE_HANDLE" type.

The VB 5.0 and 6.0 declarations for the SpyWorks MFC controls (the new ATL controls were not affected) are as follows (events that are omitted indicate that they were not affected):

dwsbc32

SubClass1_WndMessage(hwnd As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, wp As Stdole.OLE_HANDLE, lp As Long, retval As Long, nodef As Integer)

SubClass1_WndMessageX(wnd As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, wp As Stdole.OLE_HANDLE, lp As Long, retval As Long, nodef As Integer, Process As Stdole.OLE_HANDLE)

dwshk32

WinHook1_CBTProc(code As Stdole.OLE_HANDLE, wp As Stdole.OLE_HANDLE, lp As Long, nodef As Integer)

WinHook1_JournalPlayProc(code As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, paramL As Stdole.OLE_HANDLE, paramH As Stdole.OLE_HANDLE, mtime As Long, wnd As Stdole.OLE_HANDLE, delay As Long)

WinHook1_JournalRecordProc(code As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, paramL As Stdole.OLE_HANDLE, paramH As Stdole.OLE_HANDLE, mtime As Long, wnd As Stdole.OLE_HANDLE, nodef As Integer)

WinHook1_KbdHook(keycode As Stdole.OLE_HANDLE, keystate As Long, ByVal shiftstate As Integer, discard As Integer)

WinHook1_KeyDownHook(keycode As Stdole.OLE_HANDLE, ByVal shiftstate As Integer, Repetitions As Integer, keystate As Integer, ByVal ProcessID As Long, discard As Integer)

WinHook1_KeyUpHook(keycode As Stdole.OLE_HANDLE, ByVal shiftstate As Integer, Repetitions As Integer, keystate As Integer, ByVal ProcessID As Long, discard As Integer)

WinHook1_MessageProc(src As Integer, wnd As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, wp As Stdole.OLE_HANDLE, lp As Long, nodef As Integer)

WinHook1_MouseProc(wnd As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, X As Long, Y As Long, hitcode As Long, peek As Integer, nodef As Integer)

WinHook1_ShellProc(code As Stdole.OLE_HANDLE, wp As Stdole.OLE_HANDLE, lp As Long, nodef As Integer)

WinHook1_WndMessage(wnd As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, wp As Stdole.OLE_HANDLE, lp As Long, nodef As Integer)

WinHook1_WndMessageRet(wnd As Stdole.OLE_HANDLE, msg As Stdole.OLE_HANDLE, wp As Stdole.OLE_HANDLE, lp As Long, retval As Long, nodef As Integer)

dweasy32

SbcEasy1_DrawCaption(hContext As Stdole.OLE_HANDLE, lt As Long, rt As Long, tp As Long, btm As Long, nodefault As Integer)

dwcbk32

Callback1_AbortProc(hPr As Stdole.OLE_HANDLE, code As Stdole.OLE_HANDLE, retval As Stdole.OLE_HANDLE)

Callback1_CommEvent(DeviceID As Stdole.OLE_HANDLE, NotifyStatus As Integer)

Callback1_DdeCallback(wT As Stdole.OLE_HANDLE, wF As Stdole.OLE_HANDLE, hC As Long, hs As Long, h2 As Long, hD As Long, d1 As Long, d2 As Long, rv As Long)

Callback1_EnumFonts(lpLogFont As Long, lpTextMetrics As Long, nFontType As Stdole.OLE_HANDLE, lpData As Long, retval As Stdole.OLE_HANDLE)

Callback1_EnumMetaFile(hDC As Stdole.OLE_HANDLE, lpHTable As Long, lpMFR As Long, nObj As Stdole.OLE_HANDLE, lpClientData As Long, retval As Stdole.OLE_HANDLE)

Callback1_EnumObjects(lpLogObject As Long, lpData As Long, retval As Stdole.OLE_HANDLE)

Callback1_EnumProps(hWnd As Stdole.OLE_HANDLE, lpString As String, hData As Stdole.OLE_HANDLE, retval As Stdole.OLE_HANDLE)

Callback1_EnumWindows(hWnd As Stdole.OLE_HANDLE, lpData As Long, retval As Stdole.OLE_HANDLE)

Callback1_GrayString(hDC As Stdole.OLE_HANDLE, lpData As Long, nCount As Stdole.OLE_HANDLE, retval As Long)

Callback1_LineDDA(x As Stdole.OLE_HANDLE, y As Stdole.OLE_HANDLE, lpData As Long, retval As Stdole.OLE_HANDLE)

Callback1_mciYieldProc(wDeviceID As Stdole.OLE_HANDLE, dwData As Long, retval As Long)

Callback1_mmioProc(lpmmioinfo As Long, wMsg As Stdole.OLE_HANDLE, lParam1 As Long, lParam2 As Long, retval As Long)

Callback1_WinHook(ncode As Stdole.OLE_HANDLE, wParam As Stdole.OLE_HANDLE, lParam As Long, retval As Long)


9. I just upgraded my SpyWorks VBX to OCX (ActiveX) and am attempting to upgrade my VB 3.0 projects to VB 4.0. When loading a VB 3.0 project in VB 4.0, it prompts me whether I want to upgrade the SpyWorks VBX to their OCX counterparts. If I answer Yes, then I get errors when loading forms containing the SpyWorks control. The .LOG file displays something like "Class ccSubClass of control SubClass1 was not a loaded control class."

The SpyWorks VBXs do not automatically upgrade to OCXs because the controls' class names have all been changed. You need to do one additional step to upgrade your VB 3.0 projects to VB 4.0 OCX projects. Use a text editor such as NotePad, and edit the forms (.FRM files) containing the SpyWorks control. The beginning of each form file contains the descriptions of the custom controls. Look for a line like: Begin ccSubClass SubClass1 (for the SBC control) and change the ccSubClass to DwsbcLib.SubClass. The following table summarizes the class name changes:

File Name VBX Class Name OCX Class Name

cbk.vbx ccCallback Cbk.Callback

sbc.vbx ccSubClass DwsbcLib.SubClass

sbchook.vbx ccWinHook DwshkLib.WinHook

sbceasy.vbx ccSbcEasy DweasyLib.SbcEasy

sbckbd.vbx ccHookKbd DwshkLib.WinHook

After changing the class names for all the SpyWorks controls, save the file and try loading the project in VB 4.0 again.


10. Do I need to use the SpyWorks Callback control in VB 5.0 or 6.0?

Visual Basic 5.0 and later provides a new AddressOf keyword that allows you to provide function addresses for callbacks. You can use this instead of the SpyWorks Callback control unless the callback function requires a 'C' calling convention or occur in the context of a different task or at interrupt level. When converting your VB 4.0 project that uses the SpyWorks callback control to VB 5.0 to use the AddressOf keyword, the following steps are recommended:

1. Cut the code from your callback control's event and paste it in a module.

2. Change the heading of this procedure from Sub to Function and make it Public.

3. Most of the Events from the Callback control includes a retval parameter. This parameter is used to return a value to the caller. Since the new procedure will be a Function instead of a Sub, remove this parameter and set the function's return value to any retval specified.

4. For certain pre-defined callback types in the SpyWorks callback control, the retval may be automatically set to a default value (other than zero) so you do not need to set it each time. You will need to add code to set the return value within your VB 5 callback's function. For example, the SpyWorks callback's EnumWindows event automatically sets the retval to True to continue enumeration. You need to add Callback1_EnumWindows = 1 to your new procedure to duplicate the same behavior. Refer to your API documentation on the return value for other callback functions.

5. Change the API function call where you pass the Callback control's ProcAddress property to use AddressOf, for example: lres = EnumWindows(AddressOf Callback1_EnumWindows, 0)


11. How do I convert a project using the SpyWorks Demo controls into a project using the retail release controls.

Use Notepad to edit the project file and all forms that contain the SpyWorks Demo controls.

In the project file, look for the "Object=..." lines. For each reference to a SpyWorks Demo control, decrement the first digit or character of the control's guid (the first digit or character after the "{") - note that this is a hexidecimal value, then remove the "d" located just before the file extension ("." character) from the file name.

For example:

Object={C5089F43-6EDC-101C-B41C-00AA0036005A}#4.0#0; dwsbc32d.ocx

will become:

Object={B5089F43-6EDC-101C-B41C-00AA0036005A}#4.0#0; dwsbc32.ocx

Repeat this process for other "Object=..." lines that references a SpyWorks demo control. Save the project file.

In the form file's header (the beginning of the form), look for references to the SpyWorks controls. Remove the "Demo" from the control's library name.

For example:

Begin DwsbcLibDemo.SubClass SubClass1

will become:

Begin DwsbcLib.SubClass SubClass1

(Note that the demo name for the callback control is "Cbkd.Callback", in this case just remove the "d" prior to the ".").

Repeat this process for all SpyWorks controls on every form. Then open the project again - now it will use the release versions of the SpyWorks controls. You can double check by looking at the "Custom Controls" menu command to make sure none of the SpyWorks controls used has a "Demo" there.


12. When I try to install SpyWorks, I get an Out of Memory message even though there is plenty of room in the drive I am installing to.

Make sure you have room on the drive that has Windows installed on it, and that you have permission to write to it. VBXs, OCXs, and DLLs are installed in the Windows System directory which may be located on a different drive than where the other SpyWorks files are installed to.


13. I've installed several SpyWorks updates, but if I tried to uninstall the last update, then the uninstall program seems to hang, or causes a GPF.

The SpyWorks installation program creates a LOG file specifying what it did. This log file is an ascii text file saved in the main SpyWorks directory. Each subsequent SpyWorks update writes to the same LOG file. The uninstall program does not seem to handle large LOG files ( > 64 k?).

A new SWUNST.EXE uninstall program located in the ftp://ftp.desaware.com/SWUninstallProblems directory can handle large LOG files. You can replace your current copy with this file and run the uninstall again.

Note that by running the uninstall, it will also uninstall all the previous updates. You can edit the install.log file in your SpyWorks directory and cut the previous install LOG information out of the install.log file. The first installation LOG is in the beginning of the file. The last installation LOG is appended to the end of the install.log file. Each installation LOG begins with the line:

*** Installation Started <Date> <Time> ***

You can paste the cut text into another LOG file and uninstall that separately later on. Note that the uninstall program removes itself so prior to running it, you should make a copy of the swunst.exe file.


 
Products    Purchase    Articles    Support    Company    Contact
Copyright© 2012 Desaware, Inc. All Rights Reserved.    Privacy Policy