Shamil Salakhetdinov
shamil at users.mns.ru
Thu Oct 27 11:01:57 CDT 2005
<<< are we lucky that you thought to mention it? >>> We are all unlucky because of these problems - but this is COM heritage and nothing can be done with it except carefully handling it manually in custom code. Have a look at google using e.g. "GC.Collect automation problem" as a search expression. It looks like GC.Collect(), which worked for me because I was rather careful will not always work in general case - Marshal.ReleaseCOMObject(...) could be also needed... Here is KB article, which have a sample Automation code with System.Runtime.InteropServices.Marshal.ReleaseComObject(...) as well as GC.Collect(): http://support.microsoft.com/Default.aspx?kbid=306682 Shamil ----- Original Message ----- From: "Jim DeMarco" <Jdemarco at hudsonhealthplan.org> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Thursday, October 27, 2005 7:23 PM Subject: Re: [AccessD] Preventing Extra Excel instances SOLVED > Shamil, > > Is that garbage collection issue in VSTO documented or are we lucky that you thought to mention it? > > Thanks, > > Jim DeMarco > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Shamil > Salakhetdinov > Sent: Thursday, October 27, 2005 11:16 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Preventing Extra Excel instances SOLVED > > > Jim, > > This is a feature by design(default(implicit) MS Excel instance creation) + > COM inevitable/unavoidable problems (getting GPF sometimes when you quitting > MS Access with hanging background default MS Excel instance(s)). > > If you assume that this is only you who are creating default instances on PC > running your programs then you can try to reconnect them explicitly before > quitting MS Access and kill/quit them. You can use CreateObject(...) to > reconnect to them. > > Other tricky way to reconnect to them is by using Running Objects Table > (ROT) - but it can't be done directly from within VBA. Or I'd better say I > have never seen somebody connects to running COM objects(servers) from > within VBA using ROT. > > VBA is getting dead - no any chances MS will do something with that. > > Moreover when you program using Visual Studio Tools for Office you may get > similar problems if you do not call explicitly GC.Collect() after you set to > Nothing/null MS Excel/Word objects' references... > > HTH, > Shamil > > ----- Original Message ----- > From: "Hale, Jim" <Jim.Hale at FleetPride.com> > To: "'Access Developers discussion and problem solving'" > <accessd at databaseadvisors.com> > Sent: Thursday, October 27, 2005 5:39 PM > Subject: Re: [AccessD] Preventing Extra Excel instances SOLVED > > > > OK. How? > > Jim > > > > -----Original Message----- > > From: John Colby [mailto:jwcolby at colbyconsulting.com] > > Sent: Wednesday, October 26, 2005 6:43 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Preventing Extra Excel instances SOLVED > > > > > > You need to report this one to Microsoft. > > > > John W. Colby > > www.ColbyConsulting.com > > > > Contribute your unused CPU cycles to a good cause: > > http://folding.stanford.edu/ > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence > > Sent: Wednesday, October 26, 2005 7:24 PM > > To: 'Access Developers discussion and problem solving' > > Subject: Re: [AccessD] Preventing Extra Excel instances SOLVED > > > > > > Hi Jim: > > > > Excellent deduction. I have been annoyed by that issue for years. Truly a > > piece of brilliance. > > > > Jim > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Hale, Jim > > Sent: Wednesday, October 26, 2005 8:09 AM > > To: 'Accessd (E-mail) > > Subject: [AccessD] Preventing Extra Excel instances SOLVED > > > > As I have commented on several occasions, I've had a pesky problem with > > orphan Excel instances that are not destroyed when the program finishes. > As > > several of you pointed out all object variables must explicitly be set to > > nothing. While this cured some cases I have continued to have Excel > > instances that refuse to die. I have finally traced the cause to the > > following code fragments: > > > > Public Function UpdateLoan(appXcel As Excel.Application) > > Dim rng(1 To 2) As Range > > With appXcel > > Do While Not IsEmpty(ActiveCell) > > ............. > > Set rng(1) = .Range(Cells(2, intCopycol), Cells(47, intCopycol)) > > > > The following code fragments are the culprit: > > isEmpty(ActiveCell) and > > .Range(Cells(2, intCopycol), Cells(47, intCopycol)) > > > > The code works fine but leaves the Excel instance in memory. a period (.) > > before ActiveCell and Cells solves the problem, ie.: > > isEmpty(.ActiveCell) > > .Range(.Cells(2, intCopycol), .Cells(47, intCopycol)) > > > > Apparently global members of the Excel application object such as > ActiveCell > > and Cells must be explicitly qualified with the Application object for > them > > to be properly destroyed when they go out of scope. Even though the > program > > will run correctly without them being qualified, they are not cleaned up > > properly when used this way. Exactly what is happening internally wiser > > heads than I may want to comment. > > > > Jim Hale > > > > *********************************************************************** > > The information transmitted is intended solely for the individual or > entity > > to which it is addressed and may contain confidential and/or privileged > > material. Any review, retransmission, dissemination or other use of or > > taking action in reliance upon this information by persons or entities > other > > than the intended recipient is prohibited. If you have received this email > > in error please contact the sender and delete the material from any > > computer. As a recipient of this email, you are responsible for screening > > its contents and the contents of any attachments for the presence of > > viruses. No liability is accepted for any damages caused by any virus > > transmitted by this email. > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > *********************************************************************** > > The information transmitted is intended solely for the individual or > > entity to which it is addressed and may contain confidential and/or > > privileged material. Any review, retransmission, dissemination or > > other use of or taking action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. > > If you have received this email in error please contact the sender and > > delete the material from any computer. As a recipient of this email, > > you are responsible for screening its contents and the contents of any > > attachments for the presence of viruses. No liability is accepted for > > any damages caused by any virus transmitted by this email. > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > > **************************************************************************** ******* > "This electronic message is intended to be for the use only of the named recipient, and may contain information from Hudson Health Plan (HHP) that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately, either by contacting the sender at the electronic mail address noted above or calling HHP at (914) 631-1611. If you are not the intended recipient, please do not forward this email to anyone, and delete and destroy all copies of this message. Thank You". > **************************************************************************** ******* > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com