Hi everyone!

We do publishing of new message classes (in order to assign extended
properties and icons for that class of items). In theory we just need
to make a call to FormDescription::PublishForm(), and, since that call
is synchronous and there is no other implications in OOM
documentation, we might expect that it is legal to create items of
published message class just after the call was issued.

Well, in reality things are not so sweet. Creation of items of such
message class is not successful when issued immediately after the
PublishForm()-call. Moreover, in 2007/Vista this may easily break
Outlook form cache so you won't ever be able to create items of such
message class (I believe due to Vista's "sophisticated" file history
tracking). We had some weak workaround here (which looked much like a
hack for us, but we left it just because there was no other solution):
we pumped Windows messages (GetMessage/DispatchMessage) and that
helped! While in 2003 it was sufficient to place exit-pump message
into queue just before the actual pumping, in 2007 it didn't work. So,
we pumped for 50-100 ms (sorry, this is really stupid, but, what had
we do?). Obviously, this does not work all the times.

What we need is a strong guarantee that after some detectable
execution point it is safe to create items of a published message
class.

We tried a few another approaches like:
* Wait until published form will appear in registry (under HKCR/CLSID)
but this does not work, since Outlook Forms Cache will put information
in registry only after successful creation of an item;
* Wait until correspondent item will appear in Common View/associated
contents mapi folder - it appeared, that this does not make a
guarantee at all;
* Seek for some magic message in main thread's message queue - we
could not find the proper one...

Does anyone know, if there any solution to this?

thank you,
Artem Gevorkyan

Where are these forms being published? What is the mail profile configuration?

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54


"arty" wrote in message ...
Hi everyone!

We do publishing of new message classes (in order to assign extended
properties and icons for that class of items). In theory we just need
to make a call to FormDescription::PublishForm(), and, since that call
is synchronous and there is no other implications in OOM
documentation, we might expect that it is legal to create items of
published message class just after the call was issued.

Well, in reality things are not so sweet. Creation of items of such
message class is not successful when issued immediately after the
PublishForm()-call. Moreover, in 2007/Vista this may easily break
Outlook form cache so you won't ever be able to create items of such
message class (I believe due to Vista's "sophisticated" file history
tracking). We had some weak workaround here (which looked much like a
hack for us, but we left it just because there was no other solution):
we pumped Windows messages (GetMessage/DispatchMessage) and that
helped! While in 2003 it was sufficient to place exit-pump message
into queue just before the actual pumping, in 2007 it didn't work. So,
we pumped for 50-100 ms (sorry, this is really stupid, but, what had
we do?). Obviously, this does not work all the times.

What we need is a strong guarantee that after some detectable
execution point it is safe to create items of a published message
class.

We tried a few another approaches like:
* Wait until published form will appear in registry (under HKCR/CLSID)
but this does not work, since Outlook Forms Cache will put information
in registry only after successful creation of an item;
* Wait until correspondent item will appear in Common View/associated
contents mapi folder - it appeared, that this does not make a
guarantee at all;
* Seek for some magic message in main thread's message queue - we
could not find the proper one...

Does anyone know, if there any solution to this?

thank you,
Artem Gevorkyan

We use "Personal Registry" to publish forms.
No Exchange sync is involved in simplest case, though we tried OST -
exactly the same results there.

On 7 ÆÅ×, 19:19, "Sue Mosher [MVP-Outlook]"
wrote:
Where are these forms being published? What is the mail profile configuration?

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54

"arty" wrote in ...
Hi everyone!

We do publishing of new message classes (in order to assign extended
properties and icons for that class of items). In theory we just need
to make a call to FormDescription::PublishForm(), and, since that call
is synchronous and there is no other implications in OOM
documentation, we might expect that it is legal to create items of
published message class just after the call was issued.

Well, in reality things are not so sweet. Creation of items of such
message class is not successful when issued immediately after the
PublishForm()-call. Moreover, in 2007/Vista this may easily break
Outlook form cache so you won't ever be able to create items of such
message class (I believe due to Vista's "sophisticated" file history
tracking). We had some weak workaround here (which looked much like a
hack for us, but we left it just because there was no other solution):
we pumped Windows messages (GetMessage/DispatchMessage) and that
helped! While in 2003 it was sufficient to place exit-pump message
into queue just before the actual pumping, in 2007 it didn't work. So,
we pumped for 50-100 ms (sorry, this is really stupid, but, what had
we do?). Obviously, this does not work all the times.

What we need is a strong guarantee that after some detectable
execution point it is safe to create items of a published message
class.

We tried a few another approaches like:
* Wait until published form will appear in registry (under HKCR/CLSID)
but this does not work, since Outlook Forms Cache will put information
in registry only after successful creation of an item;
* Wait until correspondent item will appear in Common View/associated
contents mapi folder - it appeared, that this does not make a
guarantee at all;
* Seek for some magic message in main thread's message queue - we
could not find the proper one...

Does anyone know, if there any solution to this?

thank you,
Artem Gevorkyan

...this can be represented on a clean outlook profile with only one
pst and without any mail accounts configured.

On 8 фев, 09:03, arty wrote:
We use "Personal Registry" to publish forms.
No Exchange sync is involved in simplest case, though we tried OST -
exactly the same results there.

On 7 ÆÅ×, 19:19, "Sue Mosher [MVP-Outlook]"
wrote:

Where are these forms being published? What is the mail profile configuration?

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54

"arty" wrote in ...
Hi everyone!

We do publishing of new message classes (in order to assign extended
properties and icons for that class of items). In theory we just need
to make a call to FormDescription::PublishForm(), and, since that call
is synchronous and there is no other implications in OOM
documentation, we might expect that it is legal to create items of
published message class just after the call was issued.

Well, in reality things are not so sweet. Creation of items of such
message class is not successful when issued immediately after the
PublishForm()-call. Moreover, in 2007/Vista this may easily break
Outlook form cache so you won't ever be able to create items of such
message class (I believe due to Vista's "sophisticated" file history
tracking). We had some weak workaround here (which looked much like a
hack for us, but we left it just because there was no other solution):
we pumped Windows messages (GetMessage/DispatchMessage) and that
helped! While in 2003 it was sufficient to place exit-pump message
into queue just before the actual pumping, in 2007 it didn't work. So,
we pumped for 50-100 ms (sorry, this is really stupid, but, what had
we do?). Obviously, this does not work all the times.

What we need is a strong guarantee that after some detectable
execution point it is safe to create items of a published message
class.

We tried a few another approaches like:
* Wait until published form will appear in registry (under HKCR/CLSID)
but this does not work, since Outlook Forms Cache will put information
in registry only after successful creation of an item;
* Wait until correspondent item will appear in Common View/associated
contents mapi folder - it appeared, that this does not make a
guarantee at all;
* Seek for some magic message in main thread's message queue - we
could not find the proper one...

Does anyone know, if there any solution to this?

thank you,
Artem Gevorkyan

YES !!!!!!

We've found the solution!!!

This snippet must be issued in order to commit published form:

IMAPISessionPtr mapi_session = ol-Session-MAPIOBJECT;
IMAPIFormMgrPtr form_manager;
IMAPIFormInfoPtr fi;

::MAPIOpenFormMgr(mapi_session, &form_manager);

form_manager-ResolveMessageClass(message_class, MAPIFORM_EXACTMATCH,
0, &fi);
form_manager-PrepareForm(0, 0, fi);

where 'message_class' is a name of published form's message class.


On 8 фев, 10:31, arty wrote:
...this can be represented on a clean outlook profile with only one
pst and without any mail accounts configured.

On 8 фев, 09:03, arty wrote:

We use "Personal Registry" to publish forms.
No Exchange sync is involved in simplest case, though we tried OST -
exactly the same results there.

On 7 ÆÅ×, 19:19, "Sue Mosher [MVP-Outlook]"
wrote:

Where are these forms being published? What is the mail profile configuration?

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54

"arty" wrote in ...
Hi everyone!

We do publishing of new message classes (in order to assign extended
properties and icons for that class of items). In theory we just need
to make a call to FormDescription::PublishForm(), and, since that call
is synchronous and there is no other implications in OOM
documentation, we might expect that it is legal to create items of
published message class just after the call was issued.

Well, in reality things are not so sweet. Creation of items of such
message class is not successful when issued immediately after the
PublishForm()-call. Moreover, in 2007/Vista this may easily break
Outlook form cache so you won't ever be able to create items of such
message class (I believe due to Vista's "sophisticated" file history
tracking). We had some weak workaround here (which looked much like a
hack for us, but we left it just because there was no other solution):
we pumped Windows messages (GetMessage/DispatchMessage) and that
helped! While in 2003 it was sufficient to place exit-pump message
into queue just before the actual pumping, in 2007 it didn't work. So,
we pumped for 50-100 ms (sorry, this is really stupid, but, what had
we do?). Obviously, this does not work all the times.

What we need is a strong guarantee that after some detectable
execution point it is safe to create items of a published message
class.

We tried a few another approaches like:
* Wait until published form will appear in registry (under HKCR/CLSID)
but this does not work, since Outlook Forms Cache will put information
in registry only after successful creation of an item;
* Wait until correspondent item will appear in Common View/associated
contents mapi folder - it appeared, that this does not make a
guarantee at all;
* Seek for some magic message in main thread's message queue - we
could not find the proper one...

Does anyone know, if there any solution to this?

thank you,
Artem Gevorkyan