On the *receiving* end in your form? Or as returned by your store? What si
your code?
What I am getting at is that Outlook does not necessarily give your form the
same IMessage that you returned from your store. Outlook can create a fake
IMessage that pretends to be fully Unicode enabled.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
It is PT_TSTRING AND we compile ansi

"Dmitry Streblechenko" wrote:

Did you validate that the SPropValue.ulPropType property type is really
PT_STRING8 and not PT_UNICODE?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...

Hi Dmirty,

Of course I know about marshalling mostly because I have been doing COM
development since it was called OLE.

Here is what is going on. We have a custom Message store that
implements a
few custom string properties. Each string is ANSI and this is a
non-unicode
store and transport. I can set a break point in the Message class in my
message store and the property is found, allocated and copied
successfully
into PropValue structure. I have verified all of the functionality
within
the Message Store and everything works wonderfully.

Now when we get the form server (ATL DLL) and I set a break point where
the
property is being requested from the Message Interface and the
Value.lpszA
shows one character - and yes it is the proper first character of the
text.
So I decided to do an experiment and create one of my custom string
properties and change it to PT_BINARY. After doing that the entire
string
is
transferred successfully. So I believe that we to do something special
for
strings and I am not sure.
BTW - I can see all these properties successfully within Outlook 2003.
So
that makes believe that I am missing something.

Thanks,
Tom

"Dmitry Streblechenko" wrote:

Are you sure the strings are comign ns ANSI strings and not Unicode?
What marshalling do you mean? An in-proc form server does nto need any
marshalling.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
Hi All,

Well I have got my DLL up and running. The only problem is I cannot
transfer
strings that are longer than one character. So aftter trying to
marshall
and
a few other experiments I decided to transfer my strings as
PT_BINARY
until I
figure out what the deal is with the PT_TSTRING.

"Tom at GSD" wrote:

Okay I solved that issue by deleting the following lines. However I
am
still
NOT able to get my string property data. It actually crashes now
instead
of
giving me marshalling error. So I guess I off to determine what
else I
need.


REMOVE - file=MyForms.dll
REMOVE - registry=InprocServer32 = %d\MyForms.dll



"Tom at GSD" wrote:

Hi Dmitry,

I move everything to an ATL DLL and bluntly Outlook will not load
my
DLL.
Outlook does find and successfully load my configuration file via
my
addin.
However when I try to open my message (custom open message form)
it
does not
find my dll. Outlook gives me the typical message "Custom Form
Could
not be
opened". When I set a break point in my DLL it never get hit -
thus
meaning
the Outlook did not load it. I think I am missing a line in my
configuration
file. This is what I have in the pertinent secttions of my config
file.

[Description]
MessageClass=IPM.Note.MyCustomClass
Clsid={73F9C5BF-D47F-4B7C-B1B9-7AA13EED59F3}
DisplayName=Open Message Form
LargeIcon=32x32.ico
SmallIcon=16x16.ico

[Platforms]
Platform.1=NTx86

[Platform.NTx86]
CPU=Ix86
OSVersion=WinNT4.0
file=MyForms.dll
registry=InprocServer32 = %d\MyForms.dll


Any suggestions?

Thanks,
Tom



"Dmitry Streblechenko" wrote:

You can create your form server in a dll rather than an exe.
The CFG file will still be the same; it is just under the
covers
Outlook
will be creating your form as an in-proc COM object. Of course
your
dll must
conform to all the usual COM rules, but ATL should be able to
handle
that
with no effort on your part.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in
message
...
Hi,

I have created a custom form ATL local server that interfaces
with
Outlook
and my message store for one of our customers. The form
server
supplies a
custom form for the open message form of my private message
class.
I have
run
into a unique problem that obviously requires marshalling.
Since
it
is a
local ATL server I am unable to get string properties from my
IMessage
interface within my message store. I get the standard COM
errors
for
unable
to retrieve the data. I have a couple questions that I am
hoping
someone
may
shed some light on.

1. Can we create the Form Server as an inproc server and do
away
with the
local server? If so how do I denote that within the CFG file?
I
have read
a
couple old articles that say that this is not possible.
2. Does anybody have any sample marshalling code necessary
for
the
MAPI
Message store?

Thanks,
Tom -

I get the same type. I have anaylzed the actual debug memory in Visual Studio
and there is only one byte returned. I also tried an experiment of creating a
unicode string and i get one unicode character also.

My code in the Outlook addin uses IMAPIFormMgr to open the personal forms
library (IMAPIFormContainer). Once we get the interface we isntall our form
(cfg file). When the user clicks on the message in our message store inbox
our form DLL is instantiated. Within the Form DLL I am querying the (In
IMAPIForm interface)message properties which consist of custom strings. In
the form DLL is where I have the problem - the strings are one character long.

I was wondering if that was the real IMessage. That explains a lot just
knowing that the IMessage might be a replication.


"Dmitry Streblechenko" wrote:

On the *receiving* end in your form? Or as returned by your store? What si
your code?
What I am getting at is that Outlook does not necessarily give your form the
same IMessage that you returned from your store. Outlook can create a fake
IMessage that pretends to be fully Unicode enabled.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
It is PT_TSTRING AND we compile ansi

"Dmitry Streblechenko" wrote:

Did you validate that the SPropValue.ulPropType property type is really
PT_STRING8 and not PT_UNICODE?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...

Hi Dmirty,

Of course I know about marshalling mostly because I have been doing COM
development since it was called OLE.

Here is what is going on. We have a custom Message store that
implements a
few custom string properties. Each string is ANSI and this is a
non-unicode
store and transport. I can set a break point in the Message class in my
message store and the property is found, allocated and copied
successfully
into PropValue structure. I have verified all of the functionality
within
the Message Store and everything works wonderfully.

Now when we get the form server (ATL DLL) and I set a break point where
the
property is being requested from the Message Interface and the
Value.lpszA
shows one character - and yes it is the proper first character of the
text.
So I decided to do an experiment and create one of my custom string
properties and change it to PT_BINARY. After doing that the entire
string
is
transferred successfully. So I believe that we to do something special
for
strings and I am not sure.
BTW - I can see all these properties successfully within Outlook 2003.
So
that makes believe that I am missing something.

Thanks,
Tom

"Dmitry Streblechenko" wrote:

Are you sure the strings are comign ns ANSI strings and not Unicode?
What marshalling do you mean? An in-proc form server does nto need any
marshalling.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
Hi All,

Well I have got my DLL up and running. The only problem is I cannot
transfer
strings that are longer than one character. So aftter trying to
marshall
and
a few other experiments I decided to transfer my strings as
PT_BINARY
until I
figure out what the deal is with the PT_TSTRING.

"Tom at GSD" wrote:

Okay I solved that issue by deleting the following lines. However I
am
still
NOT able to get my string property data. It actually crashes now
instead
of
giving me marshalling error. So I guess I off to determine what
else I
need.


REMOVE - file=MyForms.dll
REMOVE - registry=InprocServer32 = %d\MyForms.dll



"Tom at GSD" wrote:

Hi Dmitry,

I move everything to an ATL DLL and bluntly Outlook will not load
my
DLL.
Outlook does find and successfully load my configuration file via
my
addin.
However when I try to open my message (custom open message form)
it
does not
find my dll. Outlook gives me the typical message "Custom Form
Could
not be
opened". When I set a break point in my DLL it never get hit -
thus
meaning
the Outlook did not load it. I think I am missing a line in my
configuration
file. This is what I have in the pertinent secttions of my config
file.

[Description]
MessageClass=IPM.Note.MyCustomClass
Clsid={73F9C5BF-D47F-4B7C-B1B9-7AA13EED59F3}
DisplayName=Open Message Form
LargeIcon=32x32.ico
SmallIcon=16x16.ico

[Platforms]
Platform.1=NTx86

[Platform.NTx86]
CPU=Ix86
OSVersion=WinNT4.0
file=MyForms.dll
registry=InprocServer32 = %d\MyForms.dll


Any suggestions?

Thanks,
Tom



"Dmitry Streblechenko" wrote:

You can create your form server in a dll rather than an exe.
The CFG file will still be the same; it is just under the
covers
Outlook
will be creating your form as an in-proc COM object. Of course
your
dll must
conform to all the usual COM rules, but ATL should be able to
handle
that
with no effort on your part.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in
message
...
Hi,

I have created a custom form ATL local server that interfaces
with
Outlook
and my message store for one of our customers. The form
server
supplies a
custom form for the open message form of my private message
class.
I have
run
into a unique problem that obviously requires marshalling.
Since
it
is a
local ATL server I am unable to get string properties from my
IMessage
interface within my message store. I get the standard COM
errors
for
unable
to retrieve the data. I have a couple questions that I am
hoping
someone
may
shed some light on.

1. Can we create the Form Server as an inproc server and do
away
with the
local server? If so how do I denote that within the CFG file?
I
have read
a
couple old articles that say that this is not possible.
2. Does anybody have any sample marshalling code necessary
for
the
MAPI
Message store?

Thanks,
Tom -

Hmmm... I don't know, sorry. You might be better off opening a support case
with MS.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
I get the same type. I have anaylzed the actual debug memory in Visual
Studio
and there is only one byte returned. I also tried an experiment of
creating a
unicode string and i get one unicode character also.

My code in the Outlook addin uses IMAPIFormMgr to open the personal forms
library (IMAPIFormContainer). Once we get the interface we isntall our
form
(cfg file). When the user clicks on the message in our message store inbox
our form DLL is instantiated. Within the Form DLL I am querying the (In
IMAPIForm interface)message properties which consist of custom strings. In
the form DLL is where I have the problem - the strings are one character
long.

I was wondering if that was the real IMessage. That explains a lot just
knowing that the IMessage might be a replication.


"Dmitry Streblechenko" wrote:

On the *receiving* end in your form? Or as returned by your store? What
si
your code?
What I am getting at is that Outlook does not necessarily give your form
the
same IMessage that you returned from your store. Outlook can create a
fake
IMessage that pretends to be fully Unicode enabled.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
It is PT_TSTRING AND we compile ansi

"Dmitry Streblechenko" wrote:

Did you validate that the SPropValue.ulPropType property type is
really
PT_STRING8 and not PT_UNICODE?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...

Hi Dmirty,

Of course I know about marshalling mostly because I have been doing
COM
development since it was called OLE.

Here is what is going on. We have a custom Message store that
implements a
few custom string properties. Each string is ANSI and this is a
non-unicode
store and transport. I can set a break point in the Message class in
my
message store and the property is found, allocated and copied
successfully
into PropValue structure. I have verified all of the functionality
within
the Message Store and everything works wonderfully.

Now when we get the form server (ATL DLL) and I set a break point
where
the
property is being requested from the Message Interface and the
Value.lpszA
shows one character - and yes it is the proper first character of
the
text.
So I decided to do an experiment and create one of my custom string
properties and change it to PT_BINARY. After doing that the entire
string
is
transferred successfully. So I believe that we to do something
special
for
strings and I am not sure.
BTW - I can see all these properties successfully within Outlook
2003.
So
that makes believe that I am missing something.

Thanks,
Tom

"Dmitry Streblechenko" wrote:

Are you sure the strings are comign ns ANSI strings and not
Unicode?
What marshalling do you mean? An in-proc form server does nto need
any
marshalling.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
Hi All,

Well I have got my DLL up and running. The only problem is I
cannot
transfer
strings that are longer than one character. So aftter trying to
marshall
and
a few other experiments I decided to transfer my strings as
PT_BINARY
until I
figure out what the deal is with the PT_TSTRING.

"Tom at GSD" wrote:

Okay I solved that issue by deleting the following lines.
However I
am
still
NOT able to get my string property data. It actually crashes now
instead
of
giving me marshalling error. So I guess I off to determine what
else I
need.


REMOVE - file=MyForms.dll
REMOVE - registry=InprocServer32 = %d\MyForms.dll



"Tom at GSD" wrote:

Hi Dmitry,

I move everything to an ATL DLL and bluntly Outlook will not
load
my
DLL.
Outlook does find and successfully load my configuration file
via
my
addin.
However when I try to open my message (custom open message
form)
it
does not
find my dll. Outlook gives me the typical message "Custom Form
Could
not be
opened". When I set a break point in my DLL it never get hit -
thus
meaning
the Outlook did not load it. I think I am missing a line in my
configuration
file. This is what I have in the pertinent secttions of my
config
file.

[Description]
MessageClass=IPM.Note.MyCustomClass
Clsid={73F9C5BF-D47F-4B7C-B1B9-7AA13EED59F3}
DisplayName=Open Message Form
LargeIcon=32x32.ico
SmallIcon=16x16.ico

[Platforms]
Platform.1=NTx86

[Platform.NTx86]
CPU=Ix86
OSVersion=WinNT4.0
file=MyForms.dll
registry=InprocServer32 = %d\MyForms.dll


Any suggestions?

Thanks,
Tom



"Dmitry Streblechenko" wrote:

You can create your form server in a dll rather than an exe.
The CFG file will still be the same; it is just under the
covers
Outlook
will be creating your form as an in-proc COM object. Of
course
your
dll must
conform to all the usual COM rules, but ATL should be able
to
handle
that
with no effort on your part.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in
message
...
Hi,

I have created a custom form ATL local server that
interfaces
with
Outlook
and my message store for one of our customers. The form
server
supplies a
custom form for the open message form of my private
message
class.
I have
run
into a unique problem that obviously requires marshalling.
Since
it
is a
local ATL server I am unable to get string properties from
my
IMessage
interface within my message store. I get the standard COM
errors
for
unable
to retrieve the data. I have a couple questions that I am
hoping
someone
may
shed some light on.

1. Can we create the Form Server as an inproc server and
do
away
with the
local server? If so how do I denote that within the CFG
file?
I
have read
a
couple old articles that say that this is not possible.
2. Does anybody have any sample marshalling code necessary
for
the
MAPI
Message store?

Thanks,
Tom -

Hi Dmitry,

I want to thank you for your input - it is greatly appreciated.

I ended up passing our custom data as PT_BINARY. That seems to work for what
we need at this moment.

As far as opening a case with Microsoft - well I have not had too much
success with that in the past few years. In fact I am batting about 0 percent
with that lately. I usually get more issues solved by newsgroups.

"Dmitry Streblechenko" wrote:

Hmmm... I don't know, sorry. You might be better off opening a support case
with MS.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
I get the same type. I have anaylzed the actual debug memory in Visual
Studio
and there is only one byte returned. I also tried an experiment of
creating a
unicode string and i get one unicode character also.

My code in the Outlook addin uses IMAPIFormMgr to open the personal forms
library (IMAPIFormContainer). Once we get the interface we isntall our
form
(cfg file). When the user clicks on the message in our message store inbox
our form DLL is instantiated. Within the Form DLL I am querying the (In
IMAPIForm interface)message properties which consist of custom strings. In
the form DLL is where I have the problem - the strings are one character
long.

I was wondering if that was the real IMessage. That explains a lot just
knowing that the IMessage might be a replication.


"Dmitry Streblechenko" wrote:

On the *receiving* end in your form? Or as returned by your store? What
si
your code?
What I am getting at is that Outlook does not necessarily give your form
the
same IMessage that you returned from your store. Outlook can create a
fake
IMessage that pretends to be fully Unicode enabled.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
It is PT_TSTRING AND we compile ansi

"Dmitry Streblechenko" wrote:

Did you validate that the SPropValue.ulPropType property type is
really
PT_STRING8 and not PT_UNICODE?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...

Hi Dmirty,

Of course I know about marshalling mostly because I have been doing
COM
development since it was called OLE.

Here is what is going on. We have a custom Message store that
implements a
few custom string properties. Each string is ANSI and this is a
non-unicode
store and transport. I can set a break point in the Message class in
my
message store and the property is found, allocated and copied
successfully
into PropValue structure. I have verified all of the functionality
within
the Message Store and everything works wonderfully.

Now when we get the form server (ATL DLL) and I set a break point
where
the
property is being requested from the Message Interface and the
Value.lpszA
shows one character - and yes it is the proper first character of
the
text.
So I decided to do an experiment and create one of my custom string
properties and change it to PT_BINARY. After doing that the entire
string
is
transferred successfully. So I believe that we to do something
special
for
strings and I am not sure.
BTW - I can see all these properties successfully within Outlook
2003.
So
that makes believe that I am missing something.

Thanks,
Tom

"Dmitry Streblechenko" wrote:

Are you sure the strings are comign ns ANSI strings and not
Unicode?
What marshalling do you mean? An in-proc form server does nto need
any
marshalling.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in message
...
Hi All,

Well I have got my DLL up and running. The only problem is I
cannot
transfer
strings that are longer than one character. So aftter trying to
marshall
and
a few other experiments I decided to transfer my strings as
PT_BINARY
until I
figure out what the deal is with the PT_TSTRING.

"Tom at GSD" wrote:

Okay I solved that issue by deleting the following lines.
However I
am
still
NOT able to get my string property data. It actually crashes now
instead
of
giving me marshalling error. So I guess I off to determine what
else I
need.


REMOVE - file=MyForms.dll
REMOVE - registry=InprocServer32 = %d\MyForms.dll



"Tom at GSD" wrote:

Hi Dmitry,

I move everything to an ATL DLL and bluntly Outlook will not
load
my
DLL.
Outlook does find and successfully load my configuration file
via
my
addin.
However when I try to open my message (custom open message
form)
it
does not
find my dll. Outlook gives me the typical message "Custom Form
Could
not be
opened". When I set a break point in my DLL it never get hit -
thus
meaning
the Outlook did not load it. I think I am missing a line in my
configuration
file. This is what I have in the pertinent secttions of my
config
file.

[Description]
MessageClass=IPM.Note.MyCustomClass
Clsid={73F9C5BF-D47F-4B7C-B1B9-7AA13EED59F3}
DisplayName=Open Message Form
LargeIcon=32x32.ico
SmallIcon=16x16.ico

[Platforms]
Platform.1=NTx86

[Platform.NTx86]
CPU=Ix86
OSVersion=WinNT4.0
file=MyForms.dll
registry=InprocServer32 = %d\MyForms.dll


Any suggestions?

Thanks,
Tom



"Dmitry Streblechenko" wrote:

You can create your form server in a dll rather than an exe.
The CFG file will still be the same; it is just under the
covers
Outlook
will be creating your form as an in-proc COM object. Of
course
your
dll must
conform to all the usual COM rules, but ATL should be able
to
handle
that
with no effort on your part.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Tom at GSD" wrote in
message
...
Hi,

I have created a custom form ATL local server that
interfaces
with
Outlook
and my message store for one of our customers. The form
server
supplies a
custom form for the open message form of my private
message
class.
I have
run
into a unique problem that obviously requires marshalling.
Since
it
is a
local ATL server I am unable to get string properties from
my
IMessage
interface within my message store. I get the standard COM
errors
for
unable
to retrieve the data. I have a couple questions that I am
hoping
someone
may
shed some light on.

1. Can we create the Form Server as an inproc server and
do
away
with the
local server? If so how do I denote that within the CFG
file?
I
have read
a
couple old articles that say that this is not possible.
2. Does anybody have any sample marshalling code necessary
for
the
MAPI
Message store?

Thanks,
Tom -