outlook 10 COM, mailitem.move to (nested) folder

[Herman Kieskamp]

Hi all,

Has anyone worked with the outlook.mailitem.move to a (nested)outlookfolder COM interface?

I can enumerate all the folders, traverse through them, so basic functioning an COM calls are valid and working, but when I
try to compile using a outlookmapifolder as destination for mailitem.move, it(compile) errors with: Data type mismatch

This is the declare in outlook.inc
[source]
INTERFACE DISPATCH OutlookMailItem
MEMBER CALL Move<&H0000F034>(IN DestFldr AS OutlookMAPIFolder<&H00000000>) AS VARIANT


Example:
LOCAL voutpfolder AS DISPATCH
or LOCAL voutpfolder AS outlookmapifolder

SET voutpfolder = oOl_folder 'oOl_folder is valid because i can request a oOl_folder.getname() to vVar

and then the move command:

OBJECT CALL ool_Curitem.Move(vofolder) TO voutpfolder
GIVES: Compile error: data type mismatch

When I use a variant inputfolder, it compiless, but then it errors with a com error "No valid type" &h0008006.

Example
LOCAL voutpfolder AS variant
SET voutpfolder= oOl_folder 'oOl_folder is valid because i can request a oOl_folder.getname() to vVar
I get the run error "No valid type" &h0008006 as com error. (in Dutch 'Typen komen niet overeen'

Now the thing is, I cant use PBwin9, because PB is not supporting mailitem.SenderEmailAddress anymore in 9.x version, and its a major important function in this application.
So it has to work in PBwin8.

Anyone that can give a hint or has source how to solve this?

Thnx in advance.

Herman.

[Michael Mattias]

>OBJECT CALL ool_Curitem.Move(vofolder) TO voutpfolder
>GIVES: Compile error: data type mismatch

vOutpFolder is defined as DISPATCH. Member wants to return VARIANT.

> cant use PBwin9, because PB is not supporting mailitem.SenderEmailAddress
> anymore in 9.x version


That does not make sense. COM is COM. Allegedly failing code not shown.

[Herman Kieskamp]

Oke, thats a typo, sorry, what i wanted to type was.

OBJECT CALL ool_Curitem.Move(voutpfolder) TO vVar

ofcouse.

> cant use PBwin9, because PB is not supporting mailitem.SenderEmailAddress
> anymore in 9.x version


That does not make sense. COM is COM. Allegedly failing code not shown.

Sorry to say, but the new PBROW does not export this function anymore.
And when I declare it myself, the translation PB->COM doen not allow/see this. Doesn't matter what version Outlook, its the PBROW thats hiding it.
Try it out yourself.
I thought I'd seen some info on this, where it said that for security reasons, they hide this, and the only way to get this now, is by doing a reply first and than read the newmailitem.to That is all too much hassle.

Considering my problem, to me it seems a translation/interpretion or interface declaration what is the culprit. All VB and C examples I saw where just using a folder name. i.e. would translate like
OBJECT CALL ool_Curitem.Move("foldername") TO vVar
and nested like this:
OBJECT CALL ool_Curitem.Move("foldername\nested") TO vVar
or sometimes
OBJECT CALL ool_Curitem.Move("\\root\foldername\nested") TO vVar

So i'm still puzzled.

But hey, thanks for your input.

B.T.W. I noticed another typo: COM error is: &h80020005 and not 0006
Cra. spectacles, need stronger every half year.

B.T.W.2 MCM Considering your massive amount of time you spend out here to help people, I wonder, how do you manage next to a normal job and a privatelife? :applaus: One of the latter must be under presure, or you never sleep.

[Michael Mattias]

>Sorry to say, but the new PBROW does not export this function anymore

If you think it should be including this property in the interface definition, then send your problem to PB Support.

However, my guess based on your comments is, the COM Browser is doing exactly what it is supposed to be doing based on the properties exposed by the interface publisher. But that's only a guess.

I believe Jose Roca has his own typelib browser. Maybe you could try that one and see what it finds? (I have no clue what that might cost or where you can get it.) OR maybe use the VB or other commercial typelib browsers and see what they can find.

Or, you could follow the recommended procedure with the "reply" thing.

MCM

[Michael Mattias]

You must be doing something different because COM Browser 2.0 shipped with my PB/WIN 9.0 includes that member...

' Generated by: PowerBASIC COM Browser v.2.00.0070
' Date & Time : 8/5/2009 at 5:13 PM
' ------------------------------------------------
' Library Name: Outlook
' Library File: C:\Program Files\Microsoft Office\OFFICE11\MSOUTL.OLB
' Description : Microsoft Outlook 11.0 Object Library
' Help File : C:\Program Files\Microsoft Office\OFFICE11\VBAOL11.CHM
' Help Context : 0
' GUID : {00062FFF-0000-0000-C000-000000000046}
' LCID : 0
' Version : 9.2
....

' Interface Name  : Int__MailItem
' Class Name      : MailItem
' ClassID         : $CLSID_Outlook_MailItem
Interface Int__MailItem $IID_Outlook_Int__MailItem 
    Inherit IDispatch

    Property Get Application <61440> () As Int__Application
    Property Get Class <61450> () As Long
... anout 150 lines....
    Property Get AutoResolvedWinner <64186> () As Integer
    Property Get Conflicts <64187> () As Conflicts
[B]    Property Get SenderEmailAddress <3103> () As String[/B]  
    Property Get SenderEmailType <3102> () As String
    Property Get EnableSharedAttachments <64196> () As Integer
    Property Set EnableSharedAttachments <64196> (ByVal EnableSharedAttachments As Integer)
    Property Get Permission <64198> () As Long
    Property Set Permission <64198> (ByVal Permission As Long)
    Property Get PermissionService <64203> () As Long
    Property Set PermissionService <64203> (ByVal PermissionService As Long)
End Interface

... but that "version 9.2" thing might be the difference here.

MCM

[José Roca]

No need to send reports to anybody. The PB COM Browser or any other tool won't "export" the SenderEmailAddress property because it isn't supported by Outlook 10, aka Outlook 2002. This property was introduced in Outlook 11, aka Outlook 2003.

When used with Outlook 11, it will "export" it:

   Member Get SenderEmailAddress <3103> () As String

So, don't try to use it with Outlook 10 because it isn't supported.

And regarding the comments about "[...] for security reasons, they hide this [...]", it is not exact. They don't hide it, but when you try to use it will show an annoying message:

Microsoft Outlook blocks code that attempts to access the SenderEmailAddress property for security reasons. If you run a third-party add-in, custom solution, or other program that uses the SenderEmailAddress property in Microsoft Office Outlook 2003, you may receive the following warning:

A program is trying to access e-mail addresses you have stored in Outlook. Do you want to allow this? If this is unexpected, it may be a virus and you should choose "No".

http://msdn.microsoft.com/en-us/library/aa171942%28office.11%29.aspx

Please, don't try to use an include file generated for an specific version of Outlook (or any Office application, for that matter) with another version or you will have many problems. M$ has broken all his own COM rules with these applications, and the only reliable way is to use late binding.

[Michael Mattias]

Ah, ye olde backwards-compatibility thing.

ADO has a method you can ask if a certain property or method is supported ("supports" I think). Maybe there is also such an animal in the Outlook Library somewhere?

[José Roca]

ADO's Supports method allows you to request if a Recordset object supports a particular type of functionality (for example, a forward-only recordset will not support methods such MovePrevious). This is not the same as if the version of ADO installed in a given computer implements a given method or not.

[Herman Kieskamp]

So, don't try to use it with Outlook 10 because it isn't supported.

Oke, just checked the sources and versions.
Indeed it seems the COM-include file is from version 11, but the weird thing is,
I use Outlook 10(HATE SECURITY NAGSCREEENS introduced since 11.0 updates, which I think are so very misplaced for us developers). So for some reason this is a hidden property in outlook10 COM, or it should not work. (SenderEmailAddress)
To me there is not much difference in version 10 to 11. They seem very compatible. And the MailItem.move is valid and will export in both versions.
All needed functions work in this application, except the MailItem.move, which is a core function, and the last to make the application do what is supposed to do.
So I'll be looking for a solution.

Herman.

[Michael Mattias]

I got confused on that supports thing. It's using *ODBC* you can query if a particular API function, or option for a function, is supported by the driver; and/or Driver Manager will return "unsupported" in response to calls if the driver does not support. Gotta learn to stop thinking ODBC when working with OLE.

> So I'll be looking for a solution.

Upgrade Outlook on target system?

Come to think of it... there simply has to be a "version" property somewhere. Query that and react accordingly.

[José Roca]

So for some reason this is a hidden property in outlook10 COM, or it should not work. (SenderEmailAddress)

I will repeat it: It is not hidden, it doesn't exist. It was added for the first time in Outlook 11. If you are going to use Outlook 10, then generate an include file for it, instead of using the one for Outlook 11, or use late binding.

[Herman Kieskamp]

You guys are sidetracking, the problem is not the senderemailaddress, its the mailitem.move that is bugging me.
To be precise I'm using Outlook 2002 (version 10.6838.6845) SP3. (No Nag screens)
and SenderEmailAddress works flawlessly. Like I said before, everything works, except for the mailitem.move.
It should work, as it is valid for both(10 & 11) versions.

Herman.

[Michael Mattias]

> its the mailitem.move that is bugging me.

????

Answer in post #2. Your call used the wrong variable type in the TO clause.

MCM

[Herman Kieskamp]

> its the mailitem.move that is bugging me.

????

Answer in post #2. Your call used the wrong variable type in the TO clause.

MCM

3rd posting (my 2nd) in this thread.

Oke, thats a typo, sorry, what i wanted to type was.

OBJECT CALL ool_Curitem.Move(voutpfolder) TO vVar

ofcouse.

Herman.

[Michael Mattias]

OBJECT CALL ool_Curitem.Move(vofolder) TO voutpfolder
GIVES: Compile error: data type mismatch

Corrected to

OBJECT CALL ool_Curitem.Move(voutpfolder) TO vVar

or maybe it was to

LOCAL voutpfolder AS DISPATCH
or LOCAL voutpfolder AS outlookmapifolder

SET voutpfolder = oOl_folder 'oOl_folder is valid because i can request a oOl_folder.getname() to vVar

and then the move command:

OBJECT CALL ool_Curitem.Move(vofolder) TO voutpfolder
GIVES: Compile error: data type mismatch

qualified by

When I use a variant inputfolder

Inputfolder? That's a new twist in this saga.

I think it's time we ask you to "show code sample which you think should compile but doesn't. "

We can't tell how anything is defined or used from these scattered snippets. At least I certainly can't.

MCM