M
Mike Thomas
I have written a VB6 COM add-in for Project, which uses both the
Application.InformationDialog and Application.UpdateTasks methods,
called from various places in the add-ins own forms.
This appears to work fine and enables the user to edit tasks or
resources using MSP's familiar forms, however users have been
experiencing occasional and sporadic abends of the add-in in various
other places, all of which seem to indicate that the add-in has
somehow become 'disconnected' from the active project (stored data in
the add-in no longer matches data in the activeproject)
After extensive testing to replicate these problems, I have noticed
(duh!) that the forms displayed by these two methods are actually
non-modal, and appear to 'break' the modality of the add-in. (As you
probably know, forms within a COM add-in MUST be modal).
Using these methods seems to leave the add-in in an indeterminate
state, with both a modal thread for the add-in and a non-modal MSP
thread for the informationdialog - I believe this problem is the root
cause of the abends which may then happen anytime after the
application enters this state.
I can't find any way to 'enforce' modality on using these methods, and
my conclusion is that these methods should not be used from a form in
a COM add-in because of this modality issue - the only way I can
imagine they might work is if the application ends immediately after
calling these methods, thereby returning control to MSP with e.g. the
information dialogue active, however this would not be an appropriate
action in my case.
I believe the only clear solution is that I will have to create my own
modal forms which have equivalent functionality to these methods, and
display these modally within my add-in instead of using these methods.
Alternatively I imagine it might be possible to try and enforce
modality within my app, e.g. using WinAPI I might be able to loop
until the informationdialog window has been closed after calling the
method, but could I then trust the application to behave properly,
because the basic rule of add-ins and modality has been 'got around'
via these methods?
I can't find anything on this issue on Google or MSDN, and on scanning
the COM object model for MSP I believe the same problem would occur
with using the custom form method (application.form), although this is
more obviously an incorrect thing to do in an add-in.
Any thoughts or suggestions?
Cheers,
Mike T.
Application.InformationDialog and Application.UpdateTasks methods,
called from various places in the add-ins own forms.
This appears to work fine and enables the user to edit tasks or
resources using MSP's familiar forms, however users have been
experiencing occasional and sporadic abends of the add-in in various
other places, all of which seem to indicate that the add-in has
somehow become 'disconnected' from the active project (stored data in
the add-in no longer matches data in the activeproject)
After extensive testing to replicate these problems, I have noticed
(duh!) that the forms displayed by these two methods are actually
non-modal, and appear to 'break' the modality of the add-in. (As you
probably know, forms within a COM add-in MUST be modal).
Using these methods seems to leave the add-in in an indeterminate
state, with both a modal thread for the add-in and a non-modal MSP
thread for the informationdialog - I believe this problem is the root
cause of the abends which may then happen anytime after the
application enters this state.
I can't find any way to 'enforce' modality on using these methods, and
my conclusion is that these methods should not be used from a form in
a COM add-in because of this modality issue - the only way I can
imagine they might work is if the application ends immediately after
calling these methods, thereby returning control to MSP with e.g. the
information dialogue active, however this would not be an appropriate
action in my case.
I believe the only clear solution is that I will have to create my own
modal forms which have equivalent functionality to these methods, and
display these modally within my add-in instead of using these methods.
Alternatively I imagine it might be possible to try and enforce
modality within my app, e.g. using WinAPI I might be able to loop
until the informationdialog window has been closed after calling the
method, but could I then trust the application to behave properly,
because the basic rule of add-ins and modality has been 'got around'
via these methods?
I can't find anything on this issue on Google or MSDN, and on scanning
the COM object model for MSP I believe the same problem would occur
with using the custom form method (application.form), although this is
more obviously an incorrect thing to do in an add-in.
Any thoughts or suggestions?
Cheers,
Mike T.