Jim DeMarco
Jdemarco at hudsonhealthplan.org
Thu Oct 27 10:23:39 CDT 2005
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". ***********************************************************************************