T
Tom Lavedas
I've spent months on and off looking for a solution to a problem we have with
the OWC object used to put a Chart into an Excel Userform. The chart is
updated through VBA code to stay in synch with the changing data being keyed
into the form. When it works, its neat -- but when it fails, it brings down
the whole workbook application.
The issue is that we have a very in-homogeneous deployment environment with
hundreds of users. AFAIK, the OWC.Chartspace must be inserted into the
Userform manually, at design time, which causes a static reference to the
object to be inserted into the workbook. If the user's working environment
differs from the development environment, it crashes the application. This
occurs because the referenced dll's can be either in the "Program
Files\Microsoft Office\Office", "Program Files\Microsoft Office\Office10",
or wherever folder on different machines.
As I said, the problem seems to arise because Excel does NOT use the
registry information to find the object files, but rather uses it's static
stored reference. I surmiss this from a peeking into a test XLS file using
Wordpad. I have searched ngs and googled myself blind, but have not yet
found a solution. BTW, a picture (bitmap) of a chart, per the excel/tip66,
is not really an acceptable solution. It would slow down the data entry
process too much, since the chart is updated every time the user tabs from
one entry box to the next (up to five years of monthly entries - 60 boxes -
on the userform).
I have tried to instantiate the ChartSpace in the Userform's Initiate()
routine with no success. A CreateObject("OWC.Chart") does indeed instatiate
the object, but it does not connect it to the userform's display space, so
any subsequent attempts to use its methods or properties are met with 'not
supported' errors. Can anyone shed some light on this?
Thanks
Tom Lavedas
===========
the OWC object used to put a Chart into an Excel Userform. The chart is
updated through VBA code to stay in synch with the changing data being keyed
into the form. When it works, its neat -- but when it fails, it brings down
the whole workbook application.
The issue is that we have a very in-homogeneous deployment environment with
hundreds of users. AFAIK, the OWC.Chartspace must be inserted into the
Userform manually, at design time, which causes a static reference to the
object to be inserted into the workbook. If the user's working environment
differs from the development environment, it crashes the application. This
occurs because the referenced dll's can be either in the "Program
Files\Microsoft Office\Office", "Program Files\Microsoft Office\Office10",
or wherever folder on different machines.
As I said, the problem seems to arise because Excel does NOT use the
registry information to find the object files, but rather uses it's static
stored reference. I surmiss this from a peeking into a test XLS file using
Wordpad. I have searched ngs and googled myself blind, but have not yet
found a solution. BTW, a picture (bitmap) of a chart, per the excel/tip66,
is not really an acceptable solution. It would slow down the data entry
process too much, since the chart is updated every time the user tabs from
one entry box to the next (up to five years of monthly entries - 60 boxes -
on the userform).
I have tried to instantiate the ChartSpace in the Userform's Initiate()
routine with no success. A CreateObject("OWC.Chart") does indeed instatiate
the object, but it does not connect it to the userform's display space, so
any subsequent attempts to use its methods or properties are met with 'not
supported' errors. Can anyone shed some light on this?
Thanks
Tom Lavedas
===========