Microeye com addin problem

  • Thread starter Thread starter John Carlier
  • Start date Start date
J

John Carlier

I have a written a com addin based on the Microeye example. This addin
handles two extra custom properties that I have added to the, renamed
(p.2) tab in an customised appointment form. These two properties
specify additional time before and after a meeting. In the
objApptItem_Write event I have added code to generate/modify two extra
appointment items, 1 before and 1 after the 'Main' appointment item.

All of this works fine. I have even added code for the Explorer events
etc etc.

The problem is when a user opens an existing item, modifies the
contents on before and after controls and then CANCELs the action.
i.e. presses the [X] and then answeres No to "Do you want to save
changes?". This appears to work ok until you open the item again and
look at the contents of the controls. Here I find the values I entered
just before I cancelled.

Looking in the code I see in the colInsp_NewInspector event that the
object objApptItem is assigned the value of the current item. This I
think is part of the problem as this is not set to Nothing, and seems
to be holding the bad values. I can not see where/how/if I should set
this to nothing.

Is this a known problem?
Ideas?

John.
 
Are you setting the Inspector and AppointmentItem = Nothing in the
Inspector.Close event handler? Are you sure that if you look at the
item in the UI that somehow the revised properties aren't being saved
anyway?
 
Ken,

I have not changed the objInsp_Close event code.

'Call UnInitHandler in objInsp_Close event
Private Sub objInsp_Close()
On Error Resume Next
If m_olApp.ActiveExplorer Is Nothing And _
m_olApp.Inspectors.Count <= 1 Then
UnInitHandler
End If
End Sub

Should it be changed? I understand from the documentation that you can not
see which item is attached to the closing inspector i.e. objInsp.currentitem
is nothing.

I will of course try setting objApptItem to nothing in this routine and post
the results here.

By the way has anyone else experienced this situation?

John

Ken Slovak - said:
Are you setting the Inspector and AppointmentItem = Nothing in the
Inspector.Close event handler? Are you sure that if you look at the
item in the UI that somehow the revised properties aren't being saved
anyway?




John Carlier said:
I have a written a com addin based on the Microeye example. This addin
handles two extra custom properties that I have added to the, renamed
(p.2) tab in an customised appointment form. These two properties
specify additional time before and after a meeting. In the
objApptItem_Write event I have added code to generate/modify two extra
appointment items, 1 before and 1 after the 'Main' appointment item.

All of this works fine. I have even added code for the Explorer events
etc etc.

The problem is when a user opens an existing item, modifies the
contents on before and after controls and then CANCELs the action.
i.e. presses the [X] and then answeres No to "Do you want to save
changes?". This appears to work ok until you open the item again and
look at the contents of the controls. Here I find the values I entered
just before I cancelled.

Looking in the code I see in the colInsp_NewInspector event that the
object objApptItem is assigned the value of the current item. This I
think is part of the problem as this is not set to Nothing, and seems
to be holding the bad values. I can not see where/how/if I should set
this to nothing.

Is this a known problem?
Ideas?

John.
Click to expand...
Click to expand...
 
Ken,

I can't justify setting objApptItem to nothing, it could be another item
that is closing, and indeed the value of objInsp.currentitem is nothing!

I did it anyway as a test and does appear to solve the problem in that the
values in the controls are correct when I reopen the item. However a second
test crashes Outlook. It is now 24:00 and snowing here so I am calling it a
night and try again in the morning.

I will hope for new ideas in the morning too.

John.
 
The way I do Inspector wrappers is to declare each possible item type
I intend to handle in that wrapper class module using WithEvents. When
I instantiate the Inspector public property in the class the code
there instantiates the correct item. Then I can handle various events
for the item such as Close. Something like this:

Private WithEvents m_oInspector As Outlook.Inspector
Private WithEvents oAppt As Outlook.AppointmentItem
'more for other item types if I want to handle them

Public Property Let Inspector(oInspector As Outlook.Inspector)
Set m_oInspector = oInspector 'now can handle Inspector events
If m_oInspector.CurrentItem.Class = olAppointment Then
Set oAppt = m_oInspector.CurrentItem
End If
End Property

Private Sub oAppt_Close(Cancel As Boolean)
'Can handle things here
End Sub

In the class module's Init and Terminate event handlers I set all
module level objects = Nothing. In the code that kills the Inspector
class in the wrapper collection I set that instance of the class
module to Nothing.
 
Ken,

Are you saying that the Microeye template is not 100% or do you just use
something else?

Looking at the Microeye template the connect.DSR handles the
IDTExtensibility2 and instantiates an OutAdddIn. The OutAddIn then declares
everything (Explorers, Inspectors, etc etc), WithEvents, and contains all
the code too e.g. objApptItem_Open.

What I think you are saying is that there needs to be an additional level
between these,
i.e. a wrapper. This I assume would apply to both Inspectors and Explorers.

This has started some bells ringing with me and I have dug up an old Com
add-in I wrote a few years ago (I don't write these too often). In that I
have found code to wrap the Explorers. That too was based on the Microeye
example, but where did I get that wrapper class?

Does anyone have a template or example which handels all these points?

Regards

John.
 
I was a little too quick sending that last item. I have found the ExplWrap
in the
ItemsCB sample at http://www.microeye.com/resources.

It is a pity that the ExplWrap and an InspWrap are not in the template
project. However I have now be warned for the future.

John
 
ItemsCB is the template project.

While ItemsCB is a wonderful starting point and addresses a whole host
of Outlook issues and best practices it doesn't address every possible
issue. For example there's something called AddInMon, which is also
available from the MicroEye Web site, that addresses the issue of a
user starting Outlook with a UI (Explorers) after something like
ActiveSynch starts Outlook with no UI.

The Explorer wrapper in ItemsCB is excellent but can stand to be
modified as I mentioned. ItemsCB doesn't include an Inspector wrapper
but that is often needed. In some of my addins I also use other types
of wrappers, such as Items collection wrappers and button wrappers if
I need to handle dynamic lists of menu items in a toolbar or menu.

In my own code I use a highly modified version of ItemsCB that
includes the things I've learned in working with Outlook COM addins.
 
Back
Top