TWilbert
asked on
ActiveX Error 429: ActiveX component can't create object
I've developed a very simple project in VB6. All it does is look at a certain directory every 10 seconds and kicks off a process if a file exist. The only component on the form is a timer control, that's it! The application runs fine on my workstation but gives the above error on an NT workstation that doesn't have VB installed. I've tried to resolve it by using the Package wizard and still no luck. The error appears at the exact time that the timer event should execute. If I have the timer set for 10 seconds it occurs after 10 seconds, etc.
What is the problem? It's just a simple application, no database.
What is the problem? It's just a simple application, no database.
AzraSound
http://vbaccelerator.com/insprob.htm
From your Packaging and Deployment Wizard.. Packaging Icon.. Select the Dependency Files option, rather than the Standard.Exe. In running the Dependency File Option.. VB will gather ALL required files and place them nto a list. When you are Finished with the dependency file list.. take the Packaging option again, and this time run the Standard.Exe option. Your program will now be ready to be deployed with everything it needs from soup to nuts. Now.. when you run the program Setup on the client machine.. all will be taken care of.. <smile>.
<< Your program will now be ready to be deployed with everything it needs from soup to nuts. >>
Someone skip their lunch break today?? =)
Someone skip their lunch break today?? =)
Hi,
What command are you using to do the file check ?
The VB native command would be the DIR command.
- or -
The File System Object ??
Late bound ...
Set fso = CreateObject("Scripting.Fi
or its early bound syntax
--------------------------
The FSO is not part of the VB runtime environment and will need to be copied and registered on the client machine in order not to produce the error that you described. Check for a referance to the FSO object under the menu option PROJECT|REFERANCES to see what file you need to add and register on the client machine.
Hope this helps
Ed
PS: You may want to check out the FileMonitor sample at: http://www.braem17.yucom.be/FileMonitorFrame.htm This technique will generate an event when the file changes/Added/Deleted instead of the polling method.
What command are you using to do the file check ?
The VB native command would be the DIR command.
- or -
The File System Object ??
Late bound ...
Set fso = CreateObject("Scripting.Fi
or its early bound syntax
--------------------------
The FSO is not part of the VB runtime environment and will need to be copied and registered on the client machine in order not to produce the error that you described. Check for a referance to the FSO object under the menu option PROJECT|REFERANCES to see what file you need to add and register on the client machine.
Hope this helps
Ed
PS: You may want to check out the FileMonitor sample at: http://www.braem17.yucom.be/FileMonitorFrame.htm This technique will generate an event when the file changes/Added/Deleted instead of the polling method.
The Packaging and Deployment Wizard will include the File System Object (SCRRUN.DLL) and register it on the client's computer if it is a component required by the application.. <smile>.
Are you certain that you ran the Setup correctly on the NT machine?
Did it complain about being unable to register any DLL's or OCX's?
Did it complain about being unable to register any DLL's or OCX's?
I think u are just running the exe alone without running an installation program . right. Do make an installation setup using Package and deployment wixard as wsh2 says and everything would be fine
Timer is in Intrinsic Controls of VB executable, only cause may be in Your problem its You haven't install Msvbvm60.dll at all. Post Your error code and description plz.
Ah. Sorry You send error as topic. Ok then, You haven't install properly COM or OCX used in timer event. Can You send Source for time event, which references or compoents used there?
ASKER
Ask Ed...I'm using the DIR command.
OshokKumar...I'm positive I'm running an installation program. I created dependencies and verified that the NT workstation had the same version and byte size that my Win95 machine had. I developed the application on a Win95 machine if that helps at all.
qcs001...No complaints while installing.
ATM....(Sample of Source)
Timer1.Interval = 10000
Private Sub Timer1_Timer()
flbReady.Refresh
flbWorking.Refresh
flbArchived.Refresh
lblReady.Caption = flbReady.ListCount & " Ready"
lblWorking.Caption = flbWorking.ListCount & " Working"
lblArchived.Caption = flbArchived.ListCount & " archive"
If fWork_in_Process = False Then
Process_Files
End If
End Sub
OshokKumar...I'm positive I'm running an installation program. I created dependencies and verified that the NT workstation had the same version and byte size that my Win95 machine had. I developed the application on a Win95 machine if that helps at all.
qcs001...No complaints while installing.
ATM....(Sample of Source)
Timer1.Interval = 10000
Private Sub Timer1_Timer()
flbReady.Refresh
flbWorking.Refresh
flbArchived.Refresh
lblReady.Caption = flbReady.ListCount & " Ready"
lblWorking.Caption = flbWorking.ListCount & " Working"
lblArchived.Caption = flbArchived.ListCount & " archive"
If fWork_in_Process = False Then
Process_Files
End If
End Sub
TWilbert I have some additional questions:
1 - Have You instantiate any COM-OCX in Process_files sub?
2 - whats the flbReady (as type)?
3 - are You use English W95? Or its in german or any other language? Please check what the Default language in Your Regional settings. Is it US-English (machine where you prepare setup)?
4 - have You installed SP3 for VS60?
5 - When prepare setup, are you sure you haven't deleted any dlls or ocxs which in your references and components list.
1 - Have You instantiate any COM-OCX in Process_files sub?
2 - whats the flbReady (as type)?
3 - are You use English W95? Or its in german or any other language? Please check what the Default language in Your Regional settings. Is it US-English (machine where you prepare setup)?
4 - have You installed SP3 for VS60?
5 - When prepare setup, are you sure you haven't deleted any dlls or ocxs which in your references and components list.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ahhhhh.. the missing piece of the mystery.. ATM.. flb is short for File Listbox.. <smile>. Twilbert.. I've attached some things you should know about this control below. Long story short.. lose the FileListbox and convert over to APIs or FSO - File System Objects. I think you will find FSO easier to use.. much more powerful than what you presently have.. and cleaner in implementation.. If you need to know more on how to use it.. please let us know.. <smile>.
Note: To add FSO to your project.. Vb Menu -> Project -> References -> and check the "Microsoft Scripting Runtime" box (SCRRUN.DLL).
From MSDN:
--------------------------
PRB: Problems Using Intrinsic File System Controls
The information in this article applies to:
Microsoft Visual Basic Learning, Professional, and Enterprise Editions for Windows, versions 5.0, 6.0
SYMPTOMS:
When you are using the intrinsic Visual Basic file system controls (for example, DriveListBox, DirListBox, FileListBox), some or all of your files are not listed. This usually occurs when you are trying to access files on a network server, but can occur locally under some circumstances.
CAUSE:
The following statement is copied from the Visual Basic 5.0 Programmer's Guide (page 67) and you can also find it in the File System Controls section of the Forms, Controls, and Menus topic in Books Online:
Note: These controls are provided primarily for backward compatibility with applications created in earlier versions of Visual Basic. The common dialog control provides an easier method of working with file access.
For more information on common dialog control, see "Miscellaneous Controls" later in this chapter.
These controls are old technology. They were not designed for, nor tested with, some of the new operating and network system software. Specifically, these controls rely on the existence of 8.3 file and directory names. Any set of circumstances that result in the unavailability of 8.3 names will cause problems. For example, you can disable the creation of 8.3 file or directory names on a Windows NT Server. If this happens, the intrinsic controls will only see those directories or files that have 8.3 names.
RESOLUTION:
As stated in the Visual Basic 5.0 Programmer's Guide, the best resolution is to use the CommonDialog control. Not only is it more likely to work, it also makes your application's user interface consistent with other Windows applications.
Even if you do not want to use the CommonDialog, it can help you determine the specific nature of the problem you are experiencing. To demonstrate this, try using the CommonDialog to access the directories or files that are causing the problem when you are using the intrinsic controls. If the CommonDialog can display these files, the problem is most likely the result of the limitations of the intrinsic controls. If the CommonDialog fails, the problem is most likely located in the computer or network file system configuration.
STATUS:
This behavior is by design.
--------------------------
BUG: FileListBox Display Inconsistent Between Win95 and NT 4
The information in this article applies to:
Microsoft Visual Basic Professional and Enterprise Editions for Windows, versions 5.0, 6.0
SYMPTOMS:
When a FileListBox has its Pattern property set to "*." there is a discrepancy between how Win95 and other versions of Windows display the files. On Windows 2000, Windows NT and Windows 98, only files without extensions are displayed. However, on Win95, all files are shown.
STATUS:
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.
MORE INFORMATION:
Steps to Reproduce Behavior
Create a standard EXE project. Form1 is created by default.
Place a FileList box (File1) on Form1.
Place a CommandButton on Form1 and place the following code in the click event:
File1.Path = "c:\" ' folder that contains files without extensions.
File1.Pattern = "*."
Press the F5 key to run the application on Win95 and note that all the files are displayed in the FileListBox. Run the same application on NT 4 or Windows 2000 and note that only files without extensions are displayed in the FileListBox.
Note: To add FSO to your project.. Vb Menu -> Project -> References -> and check the "Microsoft Scripting Runtime" box (SCRRUN.DLL).
From MSDN:
--------------------------
PRB: Problems Using Intrinsic File System Controls
The information in this article applies to:
Microsoft Visual Basic Learning, Professional, and Enterprise Editions for Windows, versions 5.0, 6.0
SYMPTOMS:
When you are using the intrinsic Visual Basic file system controls (for example, DriveListBox, DirListBox, FileListBox), some or all of your files are not listed. This usually occurs when you are trying to access files on a network server, but can occur locally under some circumstances.
CAUSE:
The following statement is copied from the Visual Basic 5.0 Programmer's Guide (page 67) and you can also find it in the File System Controls section of the Forms, Controls, and Menus topic in Books Online:
Note: These controls are provided primarily for backward compatibility with applications created in earlier versions of Visual Basic. The common dialog control provides an easier method of working with file access.
For more information on common dialog control, see "Miscellaneous Controls" later in this chapter.
These controls are old technology. They were not designed for, nor tested with, some of the new operating and network system software. Specifically, these controls rely on the existence of 8.3 file and directory names. Any set of circumstances that result in the unavailability of 8.3 names will cause problems. For example, you can disable the creation of 8.3 file or directory names on a Windows NT Server. If this happens, the intrinsic controls will only see those directories or files that have 8.3 names.
RESOLUTION:
As stated in the Visual Basic 5.0 Programmer's Guide, the best resolution is to use the CommonDialog control. Not only is it more likely to work, it also makes your application's user interface consistent with other Windows applications.
Even if you do not want to use the CommonDialog, it can help you determine the specific nature of the problem you are experiencing. To demonstrate this, try using the CommonDialog to access the directories or files that are causing the problem when you are using the intrinsic controls. If the CommonDialog can display these files, the problem is most likely the result of the limitations of the intrinsic controls. If the CommonDialog fails, the problem is most likely located in the computer or network file system configuration.
STATUS:
This behavior is by design.
--------------------------
BUG: FileListBox Display Inconsistent Between Win95 and NT 4
The information in this article applies to:
Microsoft Visual Basic Professional and Enterprise Editions for Windows, versions 5.0, 6.0
SYMPTOMS:
When a FileListBox has its Pattern property set to "*." there is a discrepancy between how Win95 and other versions of Windows display the files. On Windows 2000, Windows NT and Windows 98, only files without extensions are displayed. However, on Win95, all files are shown.
STATUS:
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article.
MORE INFORMATION:
Steps to Reproduce Behavior
Create a standard EXE project. Form1 is created by default.
Place a FileList box (File1) on Form1.
Place a CommandButton on Form1 and place the following code in the click event:
File1.Path = "c:\" ' folder that contains files without extensions.
File1.Pattern = "*."
Press the F5 key to run the application on Win95 and note that all the files are displayed in the FileListBox. Run the same application on NT 4 or Windows 2000 and note that only files without extensions are displayed in the FileListBox.
Hi TWilbert,
Do you know on exactly which statement it is that you're getting the error message?
If it's on the first .Refresh, i.e. flbReady.Refresh, then chances are that the setup is not installing all the necessary files.
Have you checked (manually) that each of the files listed in the setup.lst and the actual project's .PDM file is actually installed and registered correctly on the user's machine?
If you find one that is missing try to copy and register it manually.
If this does not work try creating a separate package just with the missing files.
Regards,
Grant.
Do you know on exactly which statement it is that you're getting the error message?
If it's on the first .Refresh, i.e. flbReady.Refresh, then chances are that the setup is not installing all the necessary files.
Have you checked (manually) that each of the files listed in the setup.lst and the actual project's .PDM file is actually installed and registered correctly on the user's machine?
If you find one that is missing try to copy and register it manually.
If this does not work try creating a separate package just with the missing files.
Regards,
Grant.
qcs001:
flb is the common prefix for a File Listbox. As both this and the timer are built in VB controls they reside in MSVBVM60.DLL. The fact that VB even loads on the other machine.. is evidence that this essential component has been installed on the NT computer. Sadly, the File Listbox is only compatable with short (8v3) File Names.. File Names that are NOT always required on an NT system.
flb is the common prefix for a File Listbox. As both this and the timer are built in VB controls they reside in MSVBVM60.DLL. The fact that VB even loads on the other machine.. is evidence that this essential component has been installed on the NT computer. Sadly, the File Listbox is only compatable with short (8v3) File Names.. File Names that are NOT always required on an NT system.
Did you upgrade your VB6 with Service Pack 3 ?
.. install DCOM95 on Your 95 machine if haven't ýnstalled it yet.
ASKER
If the File Listbox is only compatable with short file names how come I'm able to display and work with long file names using the File listbox?
I'm currently working with SP3.
I'm going to try some of your suggestions now that I'm back at work, but I'm really concerned about the way most of you are slamming the File Listbox control. Is it just a fluke that I'm able to use it with long filenames?
I'm currently working with SP3.
I'm going to try some of your suggestions now that I'm back at work, but I'm really concerned about the way most of you are slamming the File Listbox control. Is it just a fluke that I'm able to use it with long filenames?
No.. its not a fluke.. its just that the File Listbox is a 16bit control.. and as such uses the old 16bit directory structure as its method for retrieving directory entries.
If you will read above.. Microsoft has chosen to no longer support that control (ie.. there are no plans to make it compatable with 32bit architectures) and Microsoft only provides it for legacy/old program compatability. As such.. don't get mad at us.. write Bill Gates a letter.. <smile> and a <wink>.
The current Microsoft recommended way of doing File Directory stuff, is to use File System Objects (FSO). If you don't care for FSO, you can also use APIs to accomplish what you need. APIs are fast, but somewhat complex and do not always port from O/S to O/S in a friendly fashion. As I recommended above.. and still recommend.. as you want to run on both Win9x and NT.. FSO would be my way to go.. <smile>.
If you will read above.. Microsoft has chosen to no longer support that control (ie.. there are no plans to make it compatable with 32bit architectures) and Microsoft only provides it for legacy/old program compatability. As such.. don't get mad at us.. write Bill Gates a letter.. <smile> and a <wink>.
The current Microsoft recommended way of doing File Directory stuff, is to use File System Objects (FSO). If you don't care for FSO, you can also use APIs to accomplish what you need. APIs are fast, but somewhat complex and do not always port from O/S to O/S in a friendly fashion. As I recommended above.. and still recommend.. as you want to run on both Win9x and NT.. FSO would be my way to go.. <smile>.
ASKER
After placing msgbox statements in various locations as suggested by Ask ED and determined that it was the DriveLetter property of VB that was causing the problem. Once I removed it everything was ok. Thank all of you for your assistance. I wish I could spread the points around but the simple suggestion by Ask Ed wins the points.