Recently i´m getting the following errors in an application written in VB6:
"Failed to load control 'ctClientData' from . Your version of may be
outdated. Make sure you are using the version of the control that was
provided with your application."
I'm getting this error on several forms containing user controls.
Also the error seems to occur when the user is running the application for a
few hours. I have not managed to reproduce the problem.
Once the error occurs the user gets this error for all other forms he tries
to load that contain user controls.
He then closes the application and starts it again, then it works fine again
for a few hours.
Thanks in advance for any tips. I'm getting alot of these errors and i dont
have any clue how to solve it.
We are porting the application to .NET but it will be at least a year before
thats done so i have to fix it somehow...
Regards,
David.
The fact it does run for awhile, precludes the usual reason:
"This can occur when the user running the application is logged on under a
different user account than the user account who installed the application,
and the installation package installed the application on a per user basis."
Or having incorrectly complied against a OCA.
The next possiblitity is that this control has encountered an error with a
component it relies on. The 'loader' only reports the error for the
component the client is attempting to load - it doesn't track or bubble up
subsquent errors.
eg, ObjectA depends on ObjectB, which depends on ObjectC. Instantiating
ObjectC creates an error - the client is told ObjectA can not be loaded.
Which is quite true.
Related to this (as that might be the reason ObjectC fails) is the component
is running out of resources. Some components are dependent on shared items
which limit the number that be invoked at one time. A simple memory leak
might be the culprit. The fact that it happens over time strongly indicates
the latter.
Endlessly re-using the same Recordset or Command object can lead to this
error. (re-opening with different data for example) While a mild time-saver
within brief routines. It is usually best to periodically destroy them and
start anew.
Last but not least is 'bad data'.
So something is accumulating or getting scarce the longer the application
runs. (Duh! lol) This is often difficult to track down without debugging
within the live environment. But the first thing to do is re-examine your
controls for how they are using resources. Look closely to the life-times of
related objects. And especially closely to any code you know for a fact is
performing flawlessly. lol
hth
-ralph
Hello David, may I know whether you are launching the VB6 app in Windows
Vista? If yes, the following report might be helpful to you:
Problem Description
=======================
After installing an application to a Vista machine the following error is
generated when the application is launched by an account other than that of
the user who installed the application:
Runtime Error: 372 - Failed to load control <controlName> from <blank> .
Your version of <blank> may be outdated. Make sure you are using the
version of the control that was provided with your application
CAUSE:
=======================
The application had been installed for just the user who had installed the
application.
If the UAC was turned off and a member of the Admin group had attempted to
run the application with elevated privileges, the application would fail
with the same error.
While this action would have been permissible in previous versions of
Windows, the way we handle COM components has been dramatically changed
with Windows Vista. When an application is installed for a specific user,
the COM components referenced in the application are registered in the
HKEY_CURRENT_USER section of the registry. When UAC is turned on and an
Admin attempts to run the application we read these entries and prompt the
Admin to allow the action. When UAC is turned off, we are not able to
prompt the Admin for permission so we do not read the HKEY_CURRENT_USER
section because of the security risk involved.
When we install for All Users, the entries are made to the
HKEY_LOCAL_MACHINE section and the Admin user is able to read these values
when the application is launched. Note that the User account is limited to
Read permission on the HKEY_LOCAL_MACHINE section whereas they have Read
and Write on the HKEY_CURRENT_USER section hence the security risk.
The following website has further information on User Account Control:
http://technet.microsoft.com/en-us/windowsvista/aa906021.aspx
Resolution
=======================
It is recommended that any Visual Basic 6 application be installed by a
member of the Admin Group for All Users.
Have a very nice week!
Regards,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
MSDN Managed Newsgroup support offering is for non-urgent issues where an
initial response from the community or a Microsoft Support Engineer within
2 business day is acceptable. Please note that each follow up response may
take approximately 2 business days as the support professional working with
you may need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations that require urgent,
real-time or phone-based interactions. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
I'll provide some more details to make the situation a bit clearer;
1. The user controls are NOT compiled as ".ocx" files. They are simply user
controls added to the project itself and are compiled "inside" the .exe file.
So i have not installed/registered any user controls on the workstations the
application runs on.
2. I'm running the application on Windows 2003. The users running the
application are connecting through Terminal services/remote desktop client.
The application is not being used on Vista.
3. I have now implemented more detailed error logging in my application and
after analyzing the errors i found out that just before the "usercontrol"
error occurs i always get this error:
"Failed to load control 'ImageList' from MSCOMCTL.OCX. Your version of
MSCOMCTL.OCX may be outdated. Make sure you are using the version of the
control that was provided with your application."
This error always occurs in "Sub UserControl_Initialize()". The imagelist in
this control is in most cases attached to the toolbar.
It doesn't matter whether i attach the imagelist to the toolbar
programmatically or do it in design time, i'm getting the error in both cases.
This error is obviously the reason my usercontrols can not load. If i can
prevent this error from occurring my problem is probably solved.
So the question is: Why am i gettig this error...why can't the Imagelist be
loaded...?
Regards,
David.
You have run out of GDI resources.
I had exactly this error 2 days ago when my app hit 10K GDI objects.
Mind you, this was ~200 forms (it's a CCTV app) with an imagelist and
toolbar on each using about 45 objects per form.
I found this tool very useful to identify what they were:
http://msdn.microsoft.com/en-gb/magazine/cc188782.aspx?ppud=4
--
Dean Earley (dean....@icode.co.uk)
i-Catcher Development Team
iCode Systems
I've double checked and you are right. I'm using about 9999 GDI objects when
the error occurs.
Thank you all for your time and for posting your thoughts, you've been very
helpfull.
Regards,
David.
Thanks,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Hello Jiliang and thanks for that.
I have to say that that is why I stay in these newsgroups.
I just hope there is someone that can help on the rare occasion I get
stuck... :o)
The message was "Failed to load control 'ImageList' from MSCOMCTL.OCX", etc,
etc when trying to start the application from a Remote Desktop session.
In our case, the image list control contained an icon with 24-bit colour
depth. It had recently been added alongside older, 8-bit colour icons.
When using a Remote Desktop session, the application failed to start because
the server display properties had a 'Color quality' setting of 'Medium (16
bit)'.
(Note that by connecting locally we could start the application, and then
make a remote connection and use the program, but some of the toolbar icons
were mangled.)
We could fix it by increasing the setting (there's a registry hack which
enables 'Highest (32 bit)' over remote desktop. But for us, it was easier
simply to change the offending icon down to 8-bit colour depth.
Thanks
Dave
Circular references or the forms not actually unloading
Try using the short sample on this page to see which forms are still loaded:
http://hashvb.earlsoft.co.uk/End
--
Dee Earley (dee.e...@icode.co.uk)