After resizing Custom Task Pane "BeforeFolderSwitch" Event handler stopps being called

Status
Not open for further replies.
E

escamoteur

Hi,

a strange behaviour. I Developed a Custom Task Pane and want to be it visible when the user moves to a certain folder.

This works fine:

private void InitGlobalEvents()

{

Application.ActiveExplorer().BeforeFolderSwitch += new

Microsoft.Office.Interop.Outlook.ExplorerEvents_10_BeforeFolderSwitchEventHandler(Explorer_BeforeFolderSwitch);

}

Here is the handler:

void Explorer_BeforeFolderSwitch(object NewFolder, ref bool Cancel)

{

Cancel = false;

Outlook.Folder newFolder = (Outlook.Folder)NewFolder;

if (newFolder.EntryID == Config.boFolder.EntryID)

{

BO_SummeryPane.Visible = true;

}

else

{

BO_SummeryPane.Visible = false;

}

}

BUT after I resize the Custom Task Pane once, my Eventhandler no longer gets called.

Any idea? (Outlook 2007, C#, COM-AddIn)

Best

Tom
 
K

Ken Slovak - [MVP - Outlook]

If ActiveExplorer().CurrentFolder is changed, or the garbage collector runs

you wouldn't get that event again. I'd eliminate those possibilities first

before thinking it's due to the CTP (which is still possible).

Declare an Explorer object at a class scope so it doesn't go out of scope or

get garbage collected. Add the event to that object. Then see if you still

have a problem.

"escamoteur" <mail@burkharts.net> wrote in message

news:15792A89-067B-413E-B983-FAF795CD5758@microsoft.com...
> Hi,

> a strange behaviour. I Developed a Custom Task Pane and want to be it
> visible when the user moves to a certain folder.

> This works fine:

> private void InitGlobalEvents()
> {

> Application.ActiveExplorer().BeforeFolderSwitch += new
> Microsoft.Office.Interop.Outlook.ExplorerEvents_10_BeforeFolderSwitchEventHandler(Explorer_BeforeFolderSwitch);
> }

> Here is the handler:

> void Explorer_BeforeFolderSwitch(object NewFolder, ref bool Cancel)
> {
> Cancel = false;
> Outlook.Folder newFolder = (Outlook.Folder)NewFolder;
> if (newFolder.EntryID == Config.boFolder.EntryID)
> {
> BO_SummeryPane.Visible = true;
> }
> else
> {
> BO_SummeryPane.Visible = false;
> }

> }

> BUT after I resize the Custom Task Pane once, my Eventhandler no longer
> gets called.

> Any idea? (Outlook 2007, C#, COM-AddIn)

> Best
> Tom

>
 
E

escamoteur

Hi Ken,

you solved the problem. Although I'm curious why Outlook would delete the main Explorer Object that I referenced before.

And it happened defenetly always after resizing the the CTP, perhaps this triggered the new Explorer object.

Best

Tom
<kenslovak@mvps.org> schrieb im Newsbeitrag news:OAzSd5qeKHA.2188@TK2MSFTNGP04.phx.gbl...
> If ActiveExplorer().CurrentFolder is changed, or the garbage collector runs
> you wouldn't get that event again. I'd eliminate those possibilities first
> before thinking it's due to the CTP (which is still possible).

> Declare an Explorer object at a class scope so it doesn't go out of scope or
> get garbage collected. Add the event to that object. Then see if you still
> have a problem.

> >

>

> "escamoteur" <mail@burkharts.net> wrote in message
> news:15792A89-067B-413E-B983-FAF795CD5758@microsoft.com...
> > Hi,
>

>> a strange behaviour. I Developed a Custom Task Pane and want to be it
> > visible when the user moves to a certain folder.
>

>> This works fine:
>

>> private void InitGlobalEvents()
> > {
>

>> Application.ActiveExplorer().BeforeFolderSwitch += new
> > Microsoft.Office.Interop.Outlook.ExplorerEvents_10_BeforeFolderSwitchEventHandler(Explorer_BeforeFolderSwitch);
> > }
>

>
>> Here is the handler:
>

>
>> void Explorer_BeforeFolderSwitch(object NewFolder, ref bool Cancel)
> > {
> > Cancel = false;
> > Outlook.Folder newFolder = (Outlook.Folder)NewFolder;
> > if (newFolder.EntryID == Config.boFolder.EntryID)
> > {
> > BO_SummeryPane.Visible = true;
> > }
> > else
> > {
> > BO_SummeryPane.Visible = false;
> > }
>

>> }
>

>> BUT after I resize the Custom Task Pane once, my Eventhandler no longer
> > gets called.
>

>> Any idea? (Outlook 2007, C#, COM-AddIn)
>

>> Best
> > Tom
>

>>

>
 
K

Ken Slovak - [MVP - Outlook]

You had no explicit Explorer object that would retain scope, your

intrinsically declared Explorer object that was assigned the event was going

out of scope as soon as that method ended, it was only a matter of time

before the GC ran and destroyed your event handler references.

"escamoteur" <mail@burkharts.net> wrote in message

news:9D3BE9A1-92DB-43E4-B4CE-68102586DA2B@microsoft.com...
> Hi Ken,

> you solved the problem. Although I'm curious why Outlook would delete the
> main Explorer Object that I referenced before.

> And it happened defenetly always after resizing the the CTP, perhaps this
> triggered the new Explorer object.
> Best
> Tom
 
E

escamoteur

Is this because the ExplorerObjects are in reallty only COM-Proxies and not the real Explorer?

Tom
<kenslovak@mvps.org> schrieb im Newsbeitrag news:eqjVB03eKHA.3792@TK2MSFTNGP02.phx.gbl...
> You had no explicit Explorer object that would retain scope, your
> intrinsically declared Explorer object that was assigned the event was going
> out of scope as soon as that method ended, it was only a matter of time
> before the GC ran and destroyed your event handler references.

> >

>

> "escamoteur" <mail@burkharts.net> wrote in message
> news:9D3BE9A1-92DB-43E4-B4CE-68102586DA2B@microsoft.com...
> > Hi Ken,
>

>> you solved the problem. Although I'm curious why Outlook would delete the
> > main Explorer Object that I referenced before.
>

>> And it happened defenetly always after resizing the the CTP, perhaps this
> > triggered the new Explorer object.
> > Best
> > Tom

>
 
K

Ken Slovak - [MVP - Outlook]

No, it would be the case with COM or managed objects, especially when you

use compound dot operators.

For example, take this simple expression inside a procedure:

Outlook.Explorer _exp = _olApp.Explorers[1];

That creates behind the scenes an an Explorers collection as well as the

explicit Explorer object. You can't explicitly release that Explorers

collection, it will go out of scope when that procedure goes out of scope.

It may linger however until the garbage collector finally runs. You have no

control over it. The same would apply to any managed objects declared the

same way, however COM objects are more prone to have problems and cause

memory leaks.

If you were to explicitly declare an Explorers collection and an Explorer

object at class level the objects would retain scope as long as the class

has scope. You can then be confident they will be alive, as will any event

handlers, and you can release the objects when you choose to release them.

This also becomes important in loops where if you let the compiler create

internal variables like that they don't get released within the loop and you

can easily exceed the RPC channel limits when working with Exchange objects.

Then you get memory errors from MAPI.

"escamoteur" <mail@burkharts.net> wrote in message

news:97A79EB8-C847-4140-84B9-4D9729387B12@microsoft.com...
> Is this because the ExplorerObjects are in reallty only COM-Proxies and
> not the real Explorer? Tom
 
E

escamoteur

So all the Objects that I access from managed code are not the REAL Outlook Objects but they get created as stubs/proxies to

communicate with the Outlook internal objects?

I always thouht that _olApp.Explorers[1] would always return the same object as long as this explorerwindow is open.

Hmm Good to know. So better not use method().object.method() expressions at all

Best

Tom
<kenslovak@mvps.org> schrieb im Newsbeitrag news:eCfa3XMfKHA.5228@TK2MSFTNGP06.phx.gbl...
> No, it would be the case with COM or managed objects, especially when you use compound dot operators.

> For example, take this simple expression inside a procedure:

> Outlook.Explorer _exp = _olApp.Explorers[1];

> That creates behind the scenes an an Explorers collection as well as the explicit Explorer object. You can't explicitly release
> that Explorers collection, it will go out of scope when that procedure goes out of scope. It may linger however until the garbage
> collector finally runs. You have no control over it. The same would apply to any managed objects declared the same way, however
> COM objects are more prone to have problems and cause memory leaks.

> If you were to explicitly declare an Explorers collection and an Explorer object at class level the objects would retain scope as
> long as the class has scope. You can then be confident they will be alive, as will any event handlers, and you can release the
> objects when you choose to release them.

> This also becomes important in loops where if you let the compiler create internal variables like that they don't get released
> within the loop and you can easily exceed the RPC channel limits when working with Exchange objects. Then you get memory errors
> from MAPI.

> >

>

> "escamoteur" <mail@burkharts.net> wrote in message news:97A79EB8-C847-4140-84B9-4D9729387B12@microsoft.com...
> > Is this because the ExplorerObjects are in reallty only COM-Proxies and not the real Explorer? Tom

>
 
K

Ken Slovak - [MVP - Outlook]

All COM objects are accessed either from a PIA or by reflection

(late-binding). That has nothing to do with where you declare your objects

and what scope you give them or how dot operators work.

The rules of scope would apply equally to purely managed objects. If you set

up a managed class that fires events and instantiate it with a local

variable inside a procedure, that object goes out of scope when the

procedure ends and the event stops firing then. That's exactly the same as

with COM objects.

The problem of multiple dot operators is both a memory problem and a problem

of providing explicit objects you can directly reference (for releasing or

for other reasons). In the case of Exchange objects the internal, implicitly

created objects work. It's just that you can't explicitly reference them to

release them, so they just keep increasing until the RPC channel limit is

exceeded and your code fails.

_olApp.Explorers[1] will always return the same Explorer object as long as

it's not closed, but that has nothing to do with creation of an implicit

Explorers collection you have no control over.

"escamoteur" <mail@burkharts.net> wrote in message

news:OtC8z5MfKHA.5292@TK2MSFTNGP06.phx.gbl...
> So all the Objects that I access from managed code are not the REAL
> Outlook Objects but they get created as stubs/proxies to communicate with
> the Outlook internal objects?

> I always thouht that _olApp.Explorers[1] would always return the same
> object as long as this explorerwindow is open.

> Hmm Good to know. So better not use method().object.method() expressions
> at all

> Best
> Tom
 
E

escamoteur


> _olApp.Explorers[1] will always return the same Explorer object as long as
> it's not closed, but that has nothing to do with creation of an implicit
> Explorers collection you have no control over.
>


Now I'm a bit confused. If the explorer object is not deleted as long as the Explorer is not closed, why is

Application.ActiveExplorer()

destroyed by the garbage collector if the explorer window is still open?

Best

Tom


> >

>

> "escamoteur" <mail@burkharts.net> wrote in message
> news:OtC8z5MfKHA.5292@TK2MSFTNGP06.phx.gbl...
> > So all the Objects that I access from managed code are not the REAL
> > Outlook Objects but they get created as stubs/proxies to communicate with
> > the Outlook internal objects?
>

>> I always thouht that _olApp.Explorers[1] would always return the same
> > object as long as this explorerwindow is open.
>

>> Hmm Good to know. So better not use method().object.method() expressions
> > at all
>

>> Best
> > Tom

>
 
K

Ken Slovak - [MVP - Outlook]

That is not an object variable, it is a reference to a specific object.

Completely different things.

If you add your event handler to an object variable it has scope and lives

as long as that object has scope. After that it gets garbage collected.

Application.ActiveExplorer() will always exist as long as there is at least

one Explorer and one is active. However that does not mean that you can just

attach event handlers and expect them to survive unless you explicitly

instantiate an Explorer object variable to that ActiveExplorer() object.

There must be hundreds of posts mentioning loss of event handlers and why

they are going out of scope if not explicitly assigned to objects or if the

objects go out of scope. All I can suggest is taking a look at the scoping

rules for c#.

"escamoteur" <mail@burkharts.net> wrote in message

news:OG%238RmNfKHA.1112@TK2MSFTNGP04.phx.gbl...

>
> > _olApp.Explorers[1] will always return the same Explorer object as long
> > as it's not closed, but that has nothing to do with creation of an
> > implicit Explorers collection you have no control over.
> >


> Now I'm a bit confused. If the explorer object is not deleted as long as
> the Explorer is not closed, why is
> Application.ActiveExplorer()

> destroyed by the garbage collector if the explorer window is still open?

> Best
> Tom
 
E

escamoteur

Thanks Ken I understood now. I'm coming from c++, so I'm still not used to the thing tht someone else may free my ressources.

Best

Tom
<kenslovak@mvps.org> schrieb im Newsbeitrag news:OPHu3#OfKHA.1592@TK2MSFTNGP06.phx.gbl...
> That is not an object variable, it is a reference to a specific object.
> Completely different things.

> If you add your event handler to an object variable it has scope and lives
> as long as that object has scope. After that it gets garbage collected.

> Application.ActiveExplorer() will always exist as long as there is at least
> one Explorer and one is active. However that does not mean that you can just
> attach event handlers and expect them to survive unless you explicitly
> instantiate an Explorer object variable to that ActiveExplorer() object.

> There must be hundreds of posts mentioning loss of event handlers and why
> they are going out of scope if not explicitly assigned to objects or if the
> objects go out of scope. All I can suggest is taking a look at the scoping
> rules for c#.

> >

>

> "escamoteur" <mail@burkharts.net> wrote in message
> news:OG%238RmNfKHA.1112@TK2MSFTNGP04.phx.gbl...
>

>>
> >> _olApp.Explorers[1] will always return the same Explorer object as long
> >> as it's not closed, but that has nothing to do with creation of an
> >> implicit Explorers collection you have no control over.
> >>

>

>> Now I'm a bit confused. If the explorer object is not deleted as long as
> > the Explorer is not closed, why is
> > Application.ActiveExplorer()
>

>> destroyed by the garbage collector if the explorer window is still open?
>

>> Best
> > Tom

>
 
K

Ken Slovak - [MVP - Outlook]

Understanding the operation and limitations of the garbage collector,

especially for COM objects, is difficult to figure out at first.

"escamoteur" <mail@burkharts.net> wrote in message

news:BAC55F00-D6A3-46B9-BDB3-6C337748CD8A@microsoft.com...
> Thanks Ken I understood now. I'm coming from c++, so I'm still not used to
> the thing tht someone else may free my ressources.

> Best
> Tom
 
Status
Not open for further replies.
Similar threads
Thread starter Title Forum Replies Date
E After resizing Custom Task Pane "BeforeFolderSwitch" Event handler stopps being called Outlook VBA and Custom Forms 11
D Resizing issue for message field Outlook VBA and Custom Forms 0
S Picture/Image/Attachment Resizing Outlook VBA and Custom Forms 5
F Resizing arrows unavailable only in Outlook Using Outlook 3
J ol2021 custom form not displaying pics Outlook VBA and Custom Forms 28
N "Perform a Custom Action" Outlook VBA and Custom Forms 0
cbufacchi Outlook 365 Populate custom Outlook Appoint form Outlook VBA and Custom Forms 2
C Create Meeting With Custom Form Outlook VBA and Custom Forms 2
FryW Need help modifying a VBA script for in coming emails to auto set custom reminder time Outlook VBA and Custom Forms 0
J custom form not displaying pictures Outlook VBA and Custom Forms 7
I Button PDF in Outlook Contact custom form Outlook VBA and Custom Forms 1
K Font Sizing in Custom Form Regions for Contacts Outlook VBA and Custom Forms 1
V Update new custom field Outlook VBA and Custom Forms 5
D Anyone tell me where custom view settings are stored? Outlook VBA and Custom Forms 9
S Outlook 2016 Arrange tasks by date, additional custom sorting, but still use friendly terms like Today, Tomorrow, This week? Using Outlook 1
K can't get custom form to update multiple contacts using VBA Outlook VBA and Custom Forms 3
H Custom Outlook Contact Form VBA Outlook VBA and Custom Forms 1
S Custom Field Cannot Be Displayed In Views Outlook VBA and Custom Forms 2
D Custom Search Folders not refreshing/updating automatically Using Outlook 0
F Validation on custom task form after task acceptance Outlook VBA and Custom Forms 1
K UDF with formula not showing on Calendar custom view. Outlook VBA and Custom Forms 0
S Create a clickable custom column field Outlook VBA and Custom Forms 0
I Error saving screenshots in a custom form in outlook 2016, outlook 365 - ok in outlook 2013, outlook 2010 Outlook VBA and Custom Forms 5
M VbScript for Command Button on Contacts Custom Form Using Outlook 1
G Other users can't see P.2 with custom fields in Form Outlook VBA and Custom Forms 0
O Create a custom contact form - questions before messing things up... Outlook VBA and Custom Forms 4
S Reference Custom Fields with VBA Outlook VBA and Custom Forms 2
L Custom Form Tutoral? Outlook VBA and Custom Forms 6
D Lost Access to Custom Form Outlook VBA and Custom Forms 4
M vCard does not have user-defined fields from my custom contact form (365) Using Outlook 1
S Outlook Custom Form Scripting only working when clicking on "Run this form" Outlook VBA and Custom Forms 2
A Custom VBA to sort emails into folders Outlook VBA and Custom Forms 0
Victor_50 Outlook 2013 Custom Contact Form starts with "E-mail 2" Outlook VBA and Custom Forms 2
C Custom Form (seperate layout pages and message reading pane) Outlook VBA and Custom Forms 0
C Reading Pane for Custom Form Outlook VBA and Custom Forms 2
M Custom Calendar Print Suggestions? Using Outlook 0
K Custom Category Colors Using Outlook 2
N Custom Form Controls Not Visible To Recipient Outlook VBA and Custom Forms 3
E To convert imported data to custom fields in Task list Outlook VBA and Custom Forms 1
Randy Redekopp How To Merge Contact Info to Email Custom Form Template Using Outlook 2
D Problem with custom form including _DocSiteControl1 Outlook VBA and Custom Forms 0
C Custom Outlook Form - Populate Information from Radio Button / Check Box Using Outlook 0
H Custom Signature Not Displayed When Account Selected Outlook VBA and Custom Forms 10
E Custom formula for columns Using Outlook 3
W Message class changes of a custom form changes to the default form Using Outlook 2
A Possible to hide ribbon with custom appointment form? Outlook VBA and Custom Forms 3
S Custom Form, copy user field data to message body Outlook VBA and Custom Forms 12
Andrew Quirl Custom form to route requests based on input criteria Outlook VBA and Custom Forms 1
D Using a VBA Custom Form to Send Reoccurring Email Upon Task Completion Outlook VBA and Custom Forms 4
W Setting up a custom form Outlook VBA and Custom Forms 2

Similar threads

Top