[arty]

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

Archived from group: microsoft>public>outlook>program_forms

[Sue Mosher [MVP-Outlook]]

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 @s19g2000prg.googlegroups.com...
> 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
>

[arty]

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 message@s19g2000prg.googlegroups.com...
> > 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

[arty]

...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 message@s19g2000prg.googlegroups.com...
> > > 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