https://wiki.openoffice.org/w/api.php?action=feedcontributions&user=Plumbumm&feedformat=atomApache OpenOffice Wiki - User contributions [en]2024-03-29T06:13:11ZUser contributionsMediaWiki 1.23.13https://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-11-24T08:48:59Z<p>Plumbumm: </p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog.<br> This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
<br>Please use these names to insert a module to the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.frame.StartModule (StartModule)<br><br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.text.WebDocument (HTML Document)<br><br />
com.sun.star.xforms.XMLFormDocument (XML Form Document)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Impress)<br><br />
com.sun.star.formula.FormulaProperties (Math)<br><br />
com.sun.star.sdb.OfficeDatabaseDocument (Base)<br><br />
com.sun.star.sdb.TableDesign (Base)<br><br />
com.sun.star.sdb.QueryDesign (Base)<br><br />
com.sun.star.sdb.FormDesign (Base)<br><br />
<br />
<br>And use these names to insert an OOo node (Writer, Calc, Impress...) to the "Nodes" section of optionsdialog.xcu:<br />
<br />
ProductName <br><br />
LanguageSettings <br><br />
Internet <br><br />
LoadSave <br><br />
Writer <br><br />
WriterWeb <br><br />
Math <br><br />
Calc <br><br />
Impress <br><br />
Draw <br><br />
Charts <br><br />
Base <br><br><br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T09:57:58Z<p>Plumbumm: </p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog.<br> This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
<br>Please use these names to insert a module to the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.frame.StartModule (StartModule)<br><br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.text.WebDocument (HTML Document)<br><br />
com.sun.star.xforms.XMLFormDocument (XML Form Document)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Impress)<br><br />
com.sun.star.formula.FormulaProperties (Math)<br><br />
com.sun.star.sdb.OfficeDatabaseDocument (Base)<br><br />
com.sun.star.sdb.TableDesign (Base)<br><br />
com.sun.star.sdb.QueryDesign (Base)<br><br />
com.sun.star.sdb.FormDesign (Base)<br><br />
<br />
<br>And use these names to insert an OOo node (Writer, Calc, Impress...) to the "Nodes" section of optionsdialog.xcu:<br />
<br />
Writer <br><br />
Calc <br><br />
Impress <br><br />
Draw <br><br />
Math <br><br />
Base <br><br><br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T09:57:25Z<p>Plumbumm: </p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog.<br> This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
Please use these names to insert a module to the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.frame.StartModule (StartModule)<br><br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.text.WebDocument (HTML Document)<br><br />
com.sun.star.xforms.XMLFormDocument (XML Form Document)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Impress)<br><br />
com.sun.star.formula.FormulaProperties (Math)<br><br />
com.sun.star.sdb.OfficeDatabaseDocument (Base)<br><br />
com.sun.star.sdb.TableDesign (Base)<br><br />
com.sun.star.sdb.QueryDesign (Base)<br><br />
com.sun.star.sdb.FormDesign (Base)<br><br />
<br />
<br>And use these names to insert an OOo node (Writer, Calc, Impress...) to the "Nodes" section of optionsdialog.xcu:<br />
<br />
Writer <br><br />
Calc <br><br />
Impress <br><br />
Draw <br><br />
Math <br><br />
Base <br><br><br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T09:54:41Z<p>Plumbumm: nodes added</p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog.<br> This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
Please use these names to insert a module in the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.frame.StartModule (StartModule)<br><br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.text.WebDocument (HTML Document)<br><br />
com.sun.star.xforms.XMLFormDocument (XML Form Document)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Impress)<br><br />
com.sun.star.formula.FormulaProperties (Math)<br><br />
com.sun.star.sdb.OfficeDatabaseDocument (Base)<br><br />
com.sun.star.sdb.TableDesign (Base)<br><br />
com.sun.star.sdb.QueryDesign (Base)<br><br />
com.sun.star.sdb.FormDesign (Base)<br><br />
<br />
And use these names to insert an OOo node (Writer, Calc, Impress...) to the "Nodes" section of optionsdialog.xcu:<br />
<br />
Writer <br><br />
Calc <br><br />
Impress <br><br />
Draw <br><br />
Math <br><br />
Base <br><br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T08:27:58Z<p>Plumbumm: more modules</p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog.<br> This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
Please use these names to insert a module in the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.frame.StartModule (StartModule)<br><br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.text.WebDocument (HTML Document)<br><br />
com.sun.star.xforms.XMLFormDocument (XML Form Document)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Impress)<br><br />
com.sun.star.formula.FormulaProperties (Math)<br><br />
com.sun.star.sdb.OfficeDatabaseDocument (Base)<br><br />
com.sun.star.sdb.TableDesign (Base)<br><br />
com.sun.star.sdb.QueryDesign (Base)<br><br />
com.sun.star.sdb.FormDesign (Base)<br><br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T08:11:25Z<p>Plumbumm: </p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog.<br> This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
Please use these names to insert a module in the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Impress)<br><br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T08:10:28Z<p>Plumbumm: </p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog.<br> This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
Please use these names to insert a module in the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Base)<br><br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T08:09:40Z<p>Plumbumm: </p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog. This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
Please use these names to insert a module in the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.text.TextDocument (Writer)<br><br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br><br />
com.sun.star.drawing.DrawingDocument (Draw)<br><br />
com.sun.star.presentation.PresentationDocument (Base)<br><br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Framework/Article/Options_Dialog_ConfigurationFramework/Article/Options Dialog Configuration2007-05-30T08:06:59Z<p>Plumbumm: modules added</p>
<hr />
<div>Under Construction<br />
<br />
Please have a look at the Developer's Guide, chapter 5 Extension, to find out more about adding options pages to the options dialog. This page lists the build-in application names and node names which are used when someone adds new entries into the options dialog.<br />
<br />
Please use these names to insert a module in the "Modules" section of optionsdialog.xcu:<br />
<br />
com.sun.star.text.TextDocument (Writer)<br />
com.sun.star.sheet.SpreadsheetDocument (Calc)<br />
com.sun.star.drawing.DrawingDocument (Draw)<br />
com.sun.star.presentation.PresentationDocument (Base)<br />
<br />
<br />
[[Category:Development]]<br />
[[Category:Framework:Article]]<br />
[[Category:Framework]]<br />
[[Category:Article]]<br />
[[Category:API]]</div>Plumbummhttps://wiki.openoffice.org/wiki/FrameworkFramework2006-11-27T13:29:16Z<p>Plumbumm: /* Work in progress */</p>
<hr />
<div>Framework Lead: [[MBA|Mathias Bauer]] Framework Co-Lead: [[CD|Carsten Driesner]]<br />
<br />
This is the Framework Project Wiki. It is planned to move most content from the [http://framework.openoffice.org http://framework.openoffice.org] pages into the Wiki. Probably most interesting for many people is, what we are currently doing in the Framework project. You can find that in the [[Framework/WorkInProgress| work in progress]] area. One of the bigger things is to better support extension developers.<br />
<br />
The Framework Wiki follows [[Framework/Meta/Organization|this]] organization.<br />
<br />
==Functional Overview==<br />
<br />
==Work in progress==<br />
<br />
* Extending the UNO AWT toolkit to better support extension developers. <br />
** Language support for UNO AWT dialogs<br />
** Easy to use message boxes<br />
<br />
* An UNO API for the application document titles<br />
* DockingWindows in LayoutManager (preparation for usage in extensions)<br />
* Vista Readiness<br />
<br />
* Asynchronous dialogs for UNO threading framework ([[Effort/Make Dialogs Asynchronous]])<br />
* Move Items from svx to another library<br />
<br />
<DPL><br />
category=Framework:WorkInProgress <br />
suppresserrors=true<br />
</DPL><br />
<br />
==Articles & Tutorials==<br />
<DPL><br />
category=Framework:Article <br />
suppresserrors=true<br />
</DPL><br />
<DPL><br />
category=Framework:Tutorial<br />
suppresserrors=true<br />
</DPL><br />
<br />
==Framework Terms==<br />
<DPL><br />
category=Framework:Term<br />
suppresserrors=true<br />
</DPL><br />
<br />
[[Category:Project]]<br />
[[Category:Development]]</div>Plumbummhttps://wiki.openoffice.org/wiki/FrameworkFramework2006-11-27T09:39:04Z<p>Plumbumm: /* Articles&Tutorials */</p>
<hr />
<div>Framework Lead: [[MBA|Mathias Bauer]] Framework Co-Lead: [[CD|Carsten Driesner]]<br />
<br />
This is the Framework Project Wiki. It is planned to move most content from the [http://framework.openoffice.org http://framework.openoffice.org] pages into the Wiki. Probably most interesting for many people is, what we are currently doing in the Framework project. You can find that in the [[Framework/WorkInProgress| work in progress]] area. One of the bigger things is to better support extension developers.<br />
<br />
The Framework Wiki follows [[Framework/Meta/Organization|this]] organization.<br />
<br />
==Functional Overview==<br />
<br />
==Work in progress==<br />
<br />
* Extending the UNO AWT toolkit to better support extension developers. <br />
** Language support for UNO AWT dialogs<br />
** Easy to use message boxes<br />
<br />
* An UNO API for the application document titles<br />
* DockingWindows in LayoutManager (preparation for usage in extensions)<br />
* Vista Readiness<br />
<br />
* Asynchronous dialogs for UNO threading framework<br />
* Move Items from svx to another library<br />
<br />
<DPL><br />
category=Framework:WorkInProgress <br />
suppresserrors=true<br />
</DPL><br />
<br />
==Articles & Tutorials==<br />
<DPL><br />
category=Framework:Article <br />
suppresserrors=true<br />
</DPL><br />
<DPL><br />
category=Framework:Tutorial<br />
suppresserrors=true<br />
</DPL><br />
<br />
==Framework Terms==<br />
<DPL><br />
category=Framework:Term<br />
suppresserrors=true<br />
</DPL><br />
<br />
[[Category:Project]]<br />
[[Category:Development]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Effort/Make_Dialogs_AsynchronousEffort/Make Dialogs Asynchronous2006-08-11T08:22:32Z<p>Plumbumm: /* Status */</p>
<hr />
<div>As we proceed with the [[Uno/Effort/Creating the Uno Threading Framework|UNO Threading Framework]], it becomes necessary to fix asynchronous dialogs so as to avoid deadlocks. This page documents the background, necessary tasks and the status of '''Modal OpenOffice.org Dialogs in Multi-threaded Environments'''.<br />
* Author: Kai Sommerfeld <br />
* Version: 1.0<br />
* Feb. 13, 2006<br />
<br />
== The Problem == <br />
<br />
Currently VCL dialogs are executed using synchronous Dialog::Execute(). <br />
Dialog::Execute() calls Application::Yield() periodically, until dialog <br />
is about to be ended. Today, Application::Yield() releases the VCL mutex <br />
(the Solar Mutex), which is wrong, because due to this a second thread can<br />
enter VCL while another thread is already within VCL (Dialog::Execute()). <br />
The logical consequence for a fix is that Application::Yield() must no<br />
longer release the VCL mutex. But then another problem arises.<br />
<br />
The thread calling Dialog::Execute() will acquire the VCL mutex once it and<br />
not release it until Dialog::Execute() has finished. This means, that during<br />
the time a thread executes a dialog, no other thread can enter VCL. If a<br />
dialog implementation creates (or uses) a thread in order to obtain data it <br />
needs itself for being able to end sometimes and this thread needs to call <br />
back to VCL in order to fullfil its work (example: deliver search results to a <br />
VCL control contained in a search dialog), this will no longer work. The <br />
worker thread will never be able to enter VCL and therefore never end. The <br />
dialog thread, staying in VCL all the time, will never get results from<br />
the worker thread and therefore never end. <br />
<br />
Unfortunately, in the current OOo code base there are some dialogs that<br />
suffer from the problem just described.<br />
<br />
The demand to fix those dialogs soon comes from the upcoming [[Uno/Effort/Creating the Uno Threading Framework|UNO Threading Framework]]. There, the Solar Mutex will be retired and replaced by another <br />
global mutex that will be used to synchronize access to all [[Uno/Term/Thread Unsafe|non-threadsafe]]<br />
components (incl. non-threadsafe UNO components). Additionally, <br />
Application::Yield() will be fixed not to release this new mutex for the<br />
reasons discussed earlier.<br />
<br />
<br />
== The Solution == <br />
<br />
We want to change the dialog execution model to an asynchronous one. The <br />
code that wants to display a dialog simply triggers execution and enters <br />
VCL just for a short time, leaves VCL immediately after having triggered <br />
the dialog. Results will be delivered asynchronously using a callback.<br />
<br />
Unfortunately, we also have chosen the broken dialog API design for the <br />
UNO API that models dialogs. We need to introduce a new API for UNO dialogs <br />
as well and to extend (not replace: compatibility!!!) the existing <br />
components that implement the old interface.<br />
<br />
== Old Dialog Interfaces ==<br />
<br />
=== VCL ===<br />
'''(vcl/inc/dialog.hxx)'''<br />
<br />
<pre> <br />
<br />
class VCL_DLLPUBLIC Dialog : public SystemWindow<br />
{<br />
...<br />
public:<br />
virtual short Execute();<br />
...<br />
};<br />
<br />
</pre><br />
<br />
=== UNO ===<br />
<br />
'''(offapi/com/sun/star/ui/dialogs/XExecutableDialog.idl)'''<br />
<br />
<pre><br />
published interface XExecutableDialog: com::sun::star::uno::XInterface<br />
{<br />
void setTitle( [in] string aTitle );<br />
short execute();<br />
};<br />
</pre><br />
<br />
== New dialog interfaces ==<br />
<br />
== VCL ===<br />
<pre><br />
class VCL_DLLPUBLIC Dialog : public SystemWindow<br />
{<br />
...<br />
public:<br />
// Link impl: DECL_LINK( MyEndDialogHdl, Dialog* ); <br />
// - param is a pointer to the dialog just ended<br />
virtual void StartExecuteModal( const Link& rEndDialogHdl );<br />
long GetResult() const;<br />
<br />
...<br />
};<br />
</pre><br />
<br />
=== UNO ===<br />
<br />
* (offapi/com/sun/star/ui/dialogs/XAsynchronousExecutableDialog.idl)<br />
* (offapi/com/sun/star/ui/dialogs/XDialogClosedListener.idl)<br />
* (offapi/com/sun/star/ui/dialogs/DialogClosedEvent.idl)<br />
<br />
<pre><br />
interface XAsynchronousExecutableDialog: com::sun::star::uno::XInterface<br />
{<br />
void setDialogTitle( [in] string aTitle );<br />
void startExecuteModal( [in] XDialogClosedListener xListener );<br />
};<br />
<br />
interface XDialogClosedListener: com::sun::star::lang::XEventListener<br />
{<br />
void dialogClosed( [in] DialogClosedEvent aEvent );<br />
};<br />
<br />
struct DialogClosedEvent: com::sun::star::lang::EventObject<br />
{<br />
/*<br />
@see <type>ExecutableDialogResults</type><br />
*/<br />
short DialogResult;<br />
};<br />
</pre><br />
<br />
== Status ==<br />
<br />
We already created a Child Workspace (CWS) for changing all dialogs<br />
that must be changed in order to make them compatible with the upcoming [[Uno/Effort/Creating the Uno Threading Framework|Threading Framework]]. The name of the CWS is 'asyncdialogs'.<br />
<br />
The new dialog API (VCL and UNO) is available in this CWS. <br />
<br />
Many affected dialogs are already adapted. Although the number of <br />
affected dialogs is not that big, lots of work is to be done because not <br />
only the dialog itself but all its callers that rely on data that are <br />
synchronously returned by the dialog must be adapted, too. This is like<br />
the well-known snowball effect.<br />
<br />
The latest changes were the replacement of SfxApplication::InsertDocumentDialog().<br />
Now we want to close this CWS because the amount of changes are already big and our Quality Assurance needs much time to approve them. The CWS is resynced to m171. All platforms are built.<br />
After this CWS is integrated we will open a new CWS (asyncdialogs2). <br />
It is planned to integrate asyncdialog early in OOo 2.1.<br />
<br />
== Work Required == <br />
It is necessary to find and adapt all dialogs that <br />
are executed synchronously and that use SvtURLBox <br />
(svtools/source/control/inettbc.cxx). SvtURLBox creates a thread for <br />
filename autocompletion which will no longer work once the [[Uno/Effort/Creating the Uno Threading Framework|Threading Framework]] is in place. We need to adapt all callers of the dialogs just <br />
mentioned, if those callers rely directly or indirectly on data <br />
synchronously delivered by the dialogs.<br />
<br />
Important affected dialogs are the OOo Filepicker and the OOo Folderpicker <br />
dialogs (fpicker/source/office/*). Those are heavily used throughout the <br />
whole OOo code. They must be changed, because they use SvtURLBox. Changing <br />
all affected code, especially the dozens of direct and indirect clients of<br />
the picker dialogs, is really much work.<br />
<br />
Currently, we are in the middle of adapting sfx2::FileDialogHelper <br />
(sfx2/include/filedlghelper.hxx) that is a wrapper for the file dialog and <br />
that is heavily used in the OOo code.<br />
<br />
Other affected SvtURLBox clients are subject of further investigations <br />
(LXR is your friend...)<br />
<br />
To help find the classes that use SvtURLBox or use a dialog that has a SvtURLBox embedded in it, this (hopefully correct) UML diagram was created:<br />
[http://wiki.services.openoffice.org/mwiki/images/6/60/SvtURLBox_UML.jpg SvtURLBox_UML.jpg] (The Visual Paradigm file would be here: [http://wiki.services.openoffice.org/mwiki/images/6/60/SvtURLBox.vpp SvtURLBox.vpp] ...but I couldn't upload .vpp files)<br />
<br />
== Conclusion ==<br />
<br />
Much work is already done in order to solve the problem that certain OOo <br />
dialogs will have in conjunction with the new OOo [[Uno/Effort/Creating the Uno Threading Framework|Threading Framework]]. All<br />
conceptional work is done. What's open is to finish adapting affected OOo<br />
code.<br />
<br />
== Typical Changes - Example == <br />
IMO a simple example for the code changes typical for asyncdialog can be found in /svx/source/dialog/cuigaldlg.cxx and the respective header file in the same directory.<br />
<br />
There is a class SearchProgress which creates an instance of class SearchThread. The SearchThread worker thread calls back into VCL (e.g. SearchThread::ImplSearch(): mpBrowser->aLbxFound.InsertEntry()).<br />
<br />
In asyncdialogs the latter will lead to a deadlock, because: <br />
* The thread that calls SearchProgress::Execute() thereby enters the Office [[Uno/Spec/Thread Unsafety Bridge|Thread Unsafe Environment]]. <br />
* That thread stays there at least until Execute() returns.<br />
* But Execute() will never return, because it waits for the SearchThread to end.<br />
<br />
In fact it waits indefinetly that CleanUpHdl will be called (handler calls EndDialog() and this will let Execute() return), which is only done from inside SearchThread::onTerminated(). But the worker thread only terminates if it is ably to deliver search results to VCL, but it will never be able to do so because every VCL call will automatically guarded by the Office [[Uno/Spec/Thread Unsafety Bridge|Thread Unsafe Environment]] ...<br />
<br />
The solution was to switch to the new asyncdialog VCL Dialog execution API.<br />
<br />
Another solution would be to deliver the results of the SearchThread asynchronously - wouldn't it?<br />
That is, instead of calling InsertEntry directly, the search thread could post an asynchronous event<br />
to the thread currently doing the message loop, and in this event, the entry would be inserted.<br />
This way, only the dialog itself would need to be fixed, not all of its clients.<br />
(Frank Schönheit)<br />
:: You mean, would have been, don't you?! ;-). Your suggested solution probably would have worked to fix this one dialog again, but would have left the following points open:<br />
::* While a synchronous (AKA ::execute) dialog is open, no function call can enter the office over the UNO API.<br />
::* Synchronous dialogs keep staying on the stack, therefor enforcing that the opened dialogs need to be closed in the reverse order (just try to open some dialogs in otherwise unrelated documents, dependent on the a/synchrnous nature of the involved dialogs, you need to close these in the reverse order).<br />
::* Depending on the actual call stack, mutexes etc. may be kept locked, while the dialog is open, potentially introducing long lasting locks respectively deadlocks. <br />
::* Last but not least: "::execute" is a blocking and potentially long lasting call, conflicting with a potential [[Spec/Architecture/Advanced Threading|event based architecture]] I think we should head for.<br />
:: So, basically converting all dialogs to asynchronous is the "right thing" anyway :-). [[User:Kr|Kr]] 13:27, 19 July 2006 (CEST)<br />
<br />
::: The first item is not really convinicing, as it affects only the UNO API which is "protected" using the SolarMutex. Other API would continue to work fine. The other items sounds more convincing :) (fs)<br />
<br />
== To DO == <br />
List of things to do in CWS asyncdialogs <br />
<br />
=== General ===<br />
* Find and change all dialogs that are executed via Dialog::Execute() and that indirectly or directly spawn threads that need to call back to [[Uno/Term/Thread Unsafe|non-threadsafe]] code (for example VCL API, [[Uno/Term/Thread Unsafe|non-threadsafe]] UNO objects) in order to get the dialog finished.<br />
** VCL: deprecate Dialog::Execute() => changes mail!<br />
** UNO: deprecate css::ui::dialogs::XExecutableDialog => changes mail!<br />
<br />
=== Affected dialogs ===<br />
* '''unopkg binary -- gui mode'''<br />
** desktop/source/deployment/gui/dp_gui_service.cxx => ServiceImpl::execute()<br />
** dialog creates threads.<br />
** dialog is a non-threadsafe UNO service => does not use Dialog::Execute, but Application::Execute()<br />
*** BUG: Application::Execute() enters apartment at the beginning and remains in apartment all the time<br />
*** dialog worker threads will never be able to enter apartment => deadlock<br />
*** UTF2: Application::Execute() must be fixed - DONE (by KR)<br />
*** asyncdialogs: com.sun.star.comp.deployment.ui.PackageManagerDialog service: - does no longer implement XExecutableDialog, but XAsynchronousExecutableDialog DONE: changed<br />
<br />
* '''fpicker/source/unx/gnome/asynceventnotifier.hxx: #include <osl/thread.hxx>'''<br />
** triggered by dialog - ./fpicker/source/unx/gnome/SalGtkFilePicker.cxx => SalGtkFilePicker::execute()<br />
** 'execute' problem must be solved<br />
** DONE: no change (asynceventnotifier no longer used in m124)<br />
<br />
* '''svtools/source/control/inettbc.cxx:#include <vos/thread.hxx>'''<br />
** triggered by misc dialogs using SvtURLBox => 'execute' problem must be solved<br />
** class XMLFilterTabPageXSLT (/framework/filter/source/xsltdialog/xmlfiltertabpagexslt.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvxIMapDlg (/graphics/svx/inc/imapdlg.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvxHyperURLBox : public SvtURLBox (/graphics/svx/source/dialog/hltpbase.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class OFileURLControl : public SvtURLBox (/graphics/svx/source/dialog/urlcontrol.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class AddInstanceDialog (/graphics/svx/source/inc/datanavi.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvtExpFileDlg_Impl (/gsl/fpicker/source/office/iodlgimp.hxx)<br />
*** part of implementation of class SvtFileDialog (/gsl/fpicker/source/office/iodlg.hxx)<br />
*** lots of direct and indirect callers!<br />
*** @@@ IN PROGRESS (Peter Burow)<br />
** class ScLinkedAreaDlg (/sc/sc/source/ui/inc/linkarea.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class FileURLBox : public SvtURLBox (/util/svtools/inc/fileurlbox.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class OFileURLControl : public SvtURLBox (/util/svtools/inc/urlcontrol.hxx)<br />
*** @@@ todo: callers? => investigate<br />
*** IN PROGRESS<br />
<br />
* '''sw/source/ui/inc/maildispatcher.hxx:#include <osl/thread.hxx>'''<br />
** class MailDispatcher (sw/source/ui/inc/maildispatcher.hxx) is an osl::Thread<br />
*** Instances are created in:<br />
***# sw/source/ui/dbui/dbmgr.cxx<br />
***# sw/source/ui/dbui/mailmergechildwindow.cxx<br />
*** MailDispatcher has interface for regsistration of UNO listeners<br />
***# no Dialog::Execute in any possible callstack (currently only reachable via UNO API) ==> DONE: no change needed<br />
***# SwMailSendDialog is a modeless dialog, does not need to be changed therfore, but is called by MailMergeWizard which has overridden Dialog::Execute()<br />
***** MailMergeWizard and calling code must be changed ==> DONE: changed<br />
** DONE<br />
<br />
* '''svx/source/dialog/cuigaldlg.hxx:#include <vos/thread.hxx>'''<br />
** @@@ triggered by dialog => 'execute' problem must be solved<br />
** DONE: changed<br />
<br />
<br />
[[Category:Effort]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Effort/Make_Dialogs_AsynchronousEffort/Make Dialogs Asynchronous2006-08-11T08:21:42Z<p>Plumbumm: </p>
<hr />
<div>As we proceed with the [[Uno/Effort/Creating the Uno Threading Framework|UNO Threading Framework]], it becomes necessary to fix asynchronous dialogs so as to avoid deadlocks. This page documents the background, necessary tasks and the status of '''Modal OpenOffice.org Dialogs in Multi-threaded Environments'''.<br />
* Author: Kai Sommerfeld <br />
* Version: 1.0<br />
* Feb. 13, 2006<br />
<br />
== The Problem == <br />
<br />
Currently VCL dialogs are executed using synchronous Dialog::Execute(). <br />
Dialog::Execute() calls Application::Yield() periodically, until dialog <br />
is about to be ended. Today, Application::Yield() releases the VCL mutex <br />
(the Solar Mutex), which is wrong, because due to this a second thread can<br />
enter VCL while another thread is already within VCL (Dialog::Execute()). <br />
The logical consequence for a fix is that Application::Yield() must no<br />
longer release the VCL mutex. But then another problem arises.<br />
<br />
The thread calling Dialog::Execute() will acquire the VCL mutex once it and<br />
not release it until Dialog::Execute() has finished. This means, that during<br />
the time a thread executes a dialog, no other thread can enter VCL. If a<br />
dialog implementation creates (or uses) a thread in order to obtain data it <br />
needs itself for being able to end sometimes and this thread needs to call <br />
back to VCL in order to fullfil its work (example: deliver search results to a <br />
VCL control contained in a search dialog), this will no longer work. The <br />
worker thread will never be able to enter VCL and therefore never end. The <br />
dialog thread, staying in VCL all the time, will never get results from<br />
the worker thread and therefore never end. <br />
<br />
Unfortunately, in the current OOo code base there are some dialogs that<br />
suffer from the problem just described.<br />
<br />
The demand to fix those dialogs soon comes from the upcoming [[Uno/Effort/Creating the Uno Threading Framework|UNO Threading Framework]]. There, the Solar Mutex will be retired and replaced by another <br />
global mutex that will be used to synchronize access to all [[Uno/Term/Thread Unsafe|non-threadsafe]]<br />
components (incl. non-threadsafe UNO components). Additionally, <br />
Application::Yield() will be fixed not to release this new mutex for the<br />
reasons discussed earlier.<br />
<br />
<br />
== The Solution == <br />
<br />
We want to change the dialog execution model to an asynchronous one. The <br />
code that wants to display a dialog simply triggers execution and enters <br />
VCL just for a short time, leaves VCL immediately after having triggered <br />
the dialog. Results will be delivered asynchronously using a callback.<br />
<br />
Unfortunately, we also have chosen the broken dialog API design for the <br />
UNO API that models dialogs. We need to introduce a new API for UNO dialogs <br />
as well and to extend (not replace: compatibility!!!) the existing <br />
components that implement the old interface.<br />
<br />
== Old Dialog Interfaces ==<br />
<br />
=== VCL ===<br />
'''(vcl/inc/dialog.hxx)'''<br />
<br />
<pre> <br />
<br />
class VCL_DLLPUBLIC Dialog : public SystemWindow<br />
{<br />
...<br />
public:<br />
virtual short Execute();<br />
...<br />
};<br />
<br />
</pre><br />
<br />
=== UNO ===<br />
<br />
'''(offapi/com/sun/star/ui/dialogs/XExecutableDialog.idl)'''<br />
<br />
<pre><br />
published interface XExecutableDialog: com::sun::star::uno::XInterface<br />
{<br />
void setTitle( [in] string aTitle );<br />
short execute();<br />
};<br />
</pre><br />
<br />
== New dialog interfaces ==<br />
<br />
== VCL ===<br />
<pre><br />
class VCL_DLLPUBLIC Dialog : public SystemWindow<br />
{<br />
...<br />
public:<br />
// Link impl: DECL_LINK( MyEndDialogHdl, Dialog* ); <br />
// - param is a pointer to the dialog just ended<br />
virtual void StartExecuteModal( const Link& rEndDialogHdl );<br />
long GetResult() const;<br />
<br />
...<br />
};<br />
</pre><br />
<br />
=== UNO ===<br />
<br />
* (offapi/com/sun/star/ui/dialogs/XAsynchronousExecutableDialog.idl)<br />
* (offapi/com/sun/star/ui/dialogs/XDialogClosedListener.idl)<br />
* (offapi/com/sun/star/ui/dialogs/DialogClosedEvent.idl)<br />
<br />
<pre><br />
interface XAsynchronousExecutableDialog: com::sun::star::uno::XInterface<br />
{<br />
void setDialogTitle( [in] string aTitle );<br />
void startExecuteModal( [in] XDialogClosedListener xListener );<br />
};<br />
<br />
interface XDialogClosedListener: com::sun::star::lang::XEventListener<br />
{<br />
void dialogClosed( [in] DialogClosedEvent aEvent );<br />
};<br />
<br />
struct DialogClosedEvent: com::sun::star::lang::EventObject<br />
{<br />
/*<br />
@see <type>ExecutableDialogResults</type><br />
*/<br />
short DialogResult;<br />
};<br />
</pre><br />
<br />
== Status ==<br />
<br />
We already created a Child Workspace (CWS) for changing all dialogs<br />
that must be changed in order to make them compatible with the upcoming [[Uno/Effort/Creating the Uno Threading Framework|Threading Framework]]. The name of the CWS is 'asyncdialogs'.<br />
<br />
The new dialog API (VCL and UNO) is available in this CWS. <br />
<br />
Many affected dialogs are already adapted. Although the number of <br />
affected dialogs is not that big, lots of work is to be done because not <br />
only the dialog itself but all its callers that rely on data that are <br />
synchronously returned by the dialog must be adapted, too. This is like<br />
the well-known snowball effect.<br />
<br />
The latest changes were the replacement of SfxApplication::InsertDocumentDialog().<br />
Now we want to close this CWS because the amount of changes are already big and our Quality Assurance needs much time to approve them. The CWS is resynced to m171. All platforms are built.<br />
After this CWS is integrated we will open a new CWS (asyncdialogs2).<br />
It is planned to integrate asyncdialog early in OOo 2.1.<br />
<br />
== Work Required == <br />
It is necessary to find and adapt all dialogs that <br />
are executed synchronously and that use SvtURLBox <br />
(svtools/source/control/inettbc.cxx). SvtURLBox creates a thread for <br />
filename autocompletion which will no longer work once the [[Uno/Effort/Creating the Uno Threading Framework|Threading Framework]] is in place. We need to adapt all callers of the dialogs just <br />
mentioned, if those callers rely directly or indirectly on data <br />
synchronously delivered by the dialogs.<br />
<br />
Important affected dialogs are the OOo Filepicker and the OOo Folderpicker <br />
dialogs (fpicker/source/office/*). Those are heavily used throughout the <br />
whole OOo code. They must be changed, because they use SvtURLBox. Changing <br />
all affected code, especially the dozens of direct and indirect clients of<br />
the picker dialogs, is really much work.<br />
<br />
Currently, we are in the middle of adapting sfx2::FileDialogHelper <br />
(sfx2/include/filedlghelper.hxx) that is a wrapper for the file dialog and <br />
that is heavily used in the OOo code.<br />
<br />
Other affected SvtURLBox clients are subject of further investigations <br />
(LXR is your friend...)<br />
<br />
To help find the classes that use SvtURLBox or use a dialog that has a SvtURLBox embedded in it, this (hopefully correct) UML diagram was created:<br />
[http://wiki.services.openoffice.org/mwiki/images/6/60/SvtURLBox_UML.jpg SvtURLBox_UML.jpg] (The Visual Paradigm file would be here: [http://wiki.services.openoffice.org/mwiki/images/6/60/SvtURLBox.vpp SvtURLBox.vpp] ...but I couldn't upload .vpp files)<br />
<br />
== Conclusion ==<br />
<br />
Much work is already done in order to solve the problem that certain OOo <br />
dialogs will have in conjunction with the new OOo [[Uno/Effort/Creating the Uno Threading Framework|Threading Framework]]. All<br />
conceptional work is done. What's open is to finish adapting affected OOo<br />
code.<br />
<br />
== Typical Changes - Example == <br />
IMO a simple example for the code changes typical for asyncdialog can be found in /svx/source/dialog/cuigaldlg.cxx and the respective header file in the same directory.<br />
<br />
There is a class SearchProgress which creates an instance of class SearchThread. The SearchThread worker thread calls back into VCL (e.g. SearchThread::ImplSearch(): mpBrowser->aLbxFound.InsertEntry()).<br />
<br />
In asyncdialogs the latter will lead to a deadlock, because: <br />
* The thread that calls SearchProgress::Execute() thereby enters the Office [[Uno/Spec/Thread Unsafety Bridge|Thread Unsafe Environment]]. <br />
* That thread stays there at least until Execute() returns.<br />
* But Execute() will never return, because it waits for the SearchThread to end.<br />
<br />
In fact it waits indefinetly that CleanUpHdl will be called (handler calls EndDialog() and this will let Execute() return), which is only done from inside SearchThread::onTerminated(). But the worker thread only terminates if it is ably to deliver search results to VCL, but it will never be able to do so because every VCL call will automatically guarded by the Office [[Uno/Spec/Thread Unsafety Bridge|Thread Unsafe Environment]] ...<br />
<br />
The solution was to switch to the new asyncdialog VCL Dialog execution API.<br />
<br />
Another solution would be to deliver the results of the SearchThread asynchronously - wouldn't it?<br />
That is, instead of calling InsertEntry directly, the search thread could post an asynchronous event<br />
to the thread currently doing the message loop, and in this event, the entry would be inserted.<br />
This way, only the dialog itself would need to be fixed, not all of its clients.<br />
(Frank Schönheit)<br />
:: You mean, would have been, don't you?! ;-). Your suggested solution probably would have worked to fix this one dialog again, but would have left the following points open:<br />
::* While a synchronous (AKA ::execute) dialog is open, no function call can enter the office over the UNO API.<br />
::* Synchronous dialogs keep staying on the stack, therefor enforcing that the opened dialogs need to be closed in the reverse order (just try to open some dialogs in otherwise unrelated documents, dependent on the a/synchrnous nature of the involved dialogs, you need to close these in the reverse order).<br />
::* Depending on the actual call stack, mutexes etc. may be kept locked, while the dialog is open, potentially introducing long lasting locks respectively deadlocks. <br />
::* Last but not least: "::execute" is a blocking and potentially long lasting call, conflicting with a potential [[Spec/Architecture/Advanced Threading|event based architecture]] I think we should head for.<br />
:: So, basically converting all dialogs to asynchronous is the "right thing" anyway :-). [[User:Kr|Kr]] 13:27, 19 July 2006 (CEST)<br />
<br />
::: The first item is not really convinicing, as it affects only the UNO API which is "protected" using the SolarMutex. Other API would continue to work fine. The other items sounds more convincing :) (fs)<br />
<br />
== To DO == <br />
List of things to do in CWS asyncdialogs <br />
<br />
=== General ===<br />
* Find and change all dialogs that are executed via Dialog::Execute() and that indirectly or directly spawn threads that need to call back to [[Uno/Term/Thread Unsafe|non-threadsafe]] code (for example VCL API, [[Uno/Term/Thread Unsafe|non-threadsafe]] UNO objects) in order to get the dialog finished.<br />
** VCL: deprecate Dialog::Execute() => changes mail!<br />
** UNO: deprecate css::ui::dialogs::XExecutableDialog => changes mail!<br />
<br />
=== Affected dialogs ===<br />
* '''unopkg binary -- gui mode'''<br />
** desktop/source/deployment/gui/dp_gui_service.cxx => ServiceImpl::execute()<br />
** dialog creates threads.<br />
** dialog is a non-threadsafe UNO service => does not use Dialog::Execute, but Application::Execute()<br />
*** BUG: Application::Execute() enters apartment at the beginning and remains in apartment all the time<br />
*** dialog worker threads will never be able to enter apartment => deadlock<br />
*** UTF2: Application::Execute() must be fixed - DONE (by KR)<br />
*** asyncdialogs: com.sun.star.comp.deployment.ui.PackageManagerDialog service: - does no longer implement XExecutableDialog, but XAsynchronousExecutableDialog DONE: changed<br />
<br />
* '''fpicker/source/unx/gnome/asynceventnotifier.hxx: #include <osl/thread.hxx>'''<br />
** triggered by dialog - ./fpicker/source/unx/gnome/SalGtkFilePicker.cxx => SalGtkFilePicker::execute()<br />
** 'execute' problem must be solved<br />
** DONE: no change (asynceventnotifier no longer used in m124)<br />
<br />
* '''svtools/source/control/inettbc.cxx:#include <vos/thread.hxx>'''<br />
** triggered by misc dialogs using SvtURLBox => 'execute' problem must be solved<br />
** class XMLFilterTabPageXSLT (/framework/filter/source/xsltdialog/xmlfiltertabpagexslt.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvxIMapDlg (/graphics/svx/inc/imapdlg.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvxHyperURLBox : public SvtURLBox (/graphics/svx/source/dialog/hltpbase.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class OFileURLControl : public SvtURLBox (/graphics/svx/source/dialog/urlcontrol.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class AddInstanceDialog (/graphics/svx/source/inc/datanavi.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvtExpFileDlg_Impl (/gsl/fpicker/source/office/iodlgimp.hxx)<br />
*** part of implementation of class SvtFileDialog (/gsl/fpicker/source/office/iodlg.hxx)<br />
*** lots of direct and indirect callers!<br />
*** @@@ IN PROGRESS (Peter Burow)<br />
** class ScLinkedAreaDlg (/sc/sc/source/ui/inc/linkarea.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class FileURLBox : public SvtURLBox (/util/svtools/inc/fileurlbox.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class OFileURLControl : public SvtURLBox (/util/svtools/inc/urlcontrol.hxx)<br />
*** @@@ todo: callers? => investigate<br />
*** IN PROGRESS<br />
<br />
* '''sw/source/ui/inc/maildispatcher.hxx:#include <osl/thread.hxx>'''<br />
** class MailDispatcher (sw/source/ui/inc/maildispatcher.hxx) is an osl::Thread<br />
*** Instances are created in:<br />
***# sw/source/ui/dbui/dbmgr.cxx<br />
***# sw/source/ui/dbui/mailmergechildwindow.cxx<br />
*** MailDispatcher has interface for regsistration of UNO listeners<br />
***# no Dialog::Execute in any possible callstack (currently only reachable via UNO API) ==> DONE: no change needed<br />
***# SwMailSendDialog is a modeless dialog, does not need to be changed therfore, but is called by MailMergeWizard which has overridden Dialog::Execute()<br />
***** MailMergeWizard and calling code must be changed ==> DONE: changed<br />
** DONE<br />
<br />
* '''svx/source/dialog/cuigaldlg.hxx:#include <vos/thread.hxx>'''<br />
** @@@ triggered by dialog => 'execute' problem must be solved<br />
** DONE: changed<br />
<br />
<br />
[[Category:Effort]]</div>Plumbummhttps://wiki.openoffice.org/wiki/Effort/Make_Dialogs_AsynchronousEffort/Make Dialogs Asynchronous2006-06-29T16:25:51Z<p>Plumbumm: /* Status */</p>
<hr />
<div>As we proceed with the UNO Threading Framework, it becomes necessary to fix asynchronous dialogs so as to avoid deadlocks. This page documents the background, necessary tasks and the status of '''Modal OpenOffice.org Dialogs in Multi-threaded Environments'''.<br />
* Author: Kai Sommerfeld <br />
* Version: 1.0<br />
* Feb. 13, 2006<br />
<br />
== The Problem == <br />
<br />
Currently VCL dialogs are executed using synchronous Dialog::Execute(). <br />
Dialog::Execute() calls Application::Yield() periodically, until dialog <br />
is about to be ended. Today, Application::Yield() releases the VCL mutex <br />
(the Solar Mutex), which is wrong, because due to this a second thread can<br />
enter VCL while another thread is already within VCL (Dialog::Execute()). <br />
The logical consequence for a fix is that Application::Yield() must no<br />
longer release the VCL mutex. But then another problem arises.<br />
<br />
The thread calling Dialog::Execute() will acquire the VCL mutex once it and<br />
not release it until Dialog::Execute() has finished. This means, that during<br />
the time a thread executes a dialog, no other thread can enter VCL. If a<br />
dialog implementation creates (or uses) a thread in order to obtain data it <br />
needs itself for being able to end sometimes and this thread needs to call <br />
back to VCL in order to fullfil its work (example: deliver search results to a <br />
VCL control contained in a search dialog), this will no longer work. The <br />
worker thread will never be able to enter VCL and therefore never end. The <br />
dialog thread, staying in VCL all the time, will never get results from<br />
the worker thread and therefore never end. <br />
<br />
Unfortunately, in the current OOo code base there are some dialogs that<br />
suffer from the problem just described.<br />
<br />
The demand to fix those dialogs soon comes from the upcoming UNO Threading <br />
Framework. There, the Solar Mutex will be retired and replaced by another <br />
global mutex that will be used to synchronize access to all non-threadsafe <br />
components (incl. non-threadsafe UNO components). Additionally, <br />
Application::Yield() will be fixed not to release this new mutex for the<br />
reasons discussed earlier.<br />
<br />
<br />
== The Solution == <br />
<br />
We want to change the dialog execution model to an asynchronous one. The <br />
code that wants to display a dialog simply triggers execution and enters <br />
VCL just for a short time, leaves VCL immediately after having triggered <br />
the dialog. Results will be delivered asynchronously using a callback.<br />
<br />
Unfortunately, we also have chosen the broken dialog API design for the <br />
UNO API that models dialogs. We need to introduce a new API for UNO dialogs <br />
as well and to extend (not replace: compatibility!!!) the existing <br />
components that implement the old interface.<br />
<br />
== Old Dialog Interfaces ==<br />
<br />
=== VCL ===<br />
'''(vcl/inc/dialog.hxx)'''<br />
<br />
<pre> <br />
<br />
class VCL_DLLPUBLIC Dialog : public SystemWindow<br />
{<br />
...<br />
public:<br />
virtual short Execute();<br />
...<br />
};<br />
<br />
</pre><br />
<br />
=== UNO ===<br />
<br />
'''(offapi/com/sun/star/ui/dialogs/XExecutableDialog.idl)'''<br />
<br />
<pre><br />
published interface XExecutableDialog: com::sun::star::uno::XInterface<br />
{<br />
void setTitle( [in] string aTitle );<br />
short execute();<br />
};<br />
</pre><br />
<br />
== New dialog interfaces ==<br />
<br />
== VCL ===<br />
<pre><br />
class VCL_DLLPUBLIC Dialog : public SystemWindow<br />
{<br />
...<br />
public:<br />
// Link impl: DECL_LINK( MyEndDialogHdl, Dialog* ); <br />
// - param is a pointer to the dialog just ended<br />
virtual void StartExecuteModal( const Link& rEndDialogHdl );<br />
long GetResult() const;<br />
<br />
...<br />
};<br />
</pre><br />
<br />
=== UNO ===<br />
<br />
* (offapi/com/sun/star/ui/dialogs/XAsynchronousExecutableDialog.idl)<br />
* (offapi/com/sun/star/ui/dialogs/XDialogClosedListener.idl)<br />
* (offapi/com/sun/star/ui/dialogs/DialogClosedEvent.idl)<br />
<br />
<pre><br />
interface XAsynchronousExecutableDialog: com::sun::star::uno::XInterface<br />
{<br />
void setDialogTitle( [in] string aTitle );<br />
void startExecuteModal( [in] XDialogClosedListener xListener );<br />
};<br />
<br />
interface XDialogClosedListener: com::sun::star::lang::XEventListener<br />
{<br />
void dialogClosed( [in] DialogClosedEvent aEvent );<br />
};<br />
<br />
struct DialogClosedEvent: com::sun::star::lang::EventObject<br />
{<br />
/*<br />
@see <type>ExecutableDialogResults</type><br />
*/<br />
short DialogResult;<br />
};<br />
</pre><br />
<br />
== Status ==<br />
<br />
We already created a Child Workspace (CWS) for changing all dialogs<br />
that must be changed in order to make them compatible with the upcoming<br />
Threading Framework. The name of the CWS is 'asyncdialogs'.<br />
<br />
The new dialog API (VCL and UNO) is available in this CWS. <br />
<br />
Many affected dialogs are already adapted. Although the number of <br />
affected dialogs is not that big, lots of work is to be done because not <br />
only the dialog itself but all its callers that rely on data that are <br />
synchronously returned by the dialog must be adapted, too. This is like<br />
the well-known snowball effect.<br />
<br />
The latest changes were the replacement of SfxApplication::InsertDocumentDialog().<br />
Now we want to close this CWS because the amount of changes are already big and our Quality Assurance needs much time to approve them. The CWS is resynced to m171. All platforms are built.<br />
After this CWS is integrated we will open a new CWS (asyncdialogs2).<br />
<br />
== Work Required == <br />
It is necessary to find and adapt all dialogs that <br />
are executed synchronously and that use SvtURLBox <br />
(svtools/source/control/inettbc.cxx). SvtURLBox creates a thread for <br />
filename autocompletion which will no longer work once the Threading <br />
Framework is in place. We need to adapt all callers of the dialogs just <br />
mentioned, if those callers rely directly or indirectly on data <br />
synchronously delivered by the dialogs.<br />
<br />
Important affected dialogs are the OOo Filepicker and the OOo Folderpicker <br />
dialogs (fpicker/source/office/*). Those are heavily used throughout the <br />
whole OOo code. They must be changed, because they use SvtURLBox. Changing <br />
all affected code, especially the dozens of direct and indirect clients of<br />
the picker dialogs, is really much work.<br />
<br />
Currently, we are in the middle of adapting sfx2::FileDialogHelper <br />
(sfx2/include/filedlghelper.hxx) that is a wrapper for the file dialog and <br />
that is heavily used in the OOo code.<br />
<br />
Other affected SvtURLBox clients are subject of further investigations <br />
(LXR is your friend...)<br />
<br />
To help find the classes that use SvtURLBox or use a dialog that has a SvtURLBox embedded in it, this (hopefully correct) UML diagram was created:<br />
[http://wiki.services.openoffice.org/mwiki/images/6/60/SvtURLBox_UML.jpg SvtURLBox_UML.jpg] (The Visual Paradigm file would be here: [http://wiki.services.openoffice.org/mwiki/images/6/60/SvtURLBox.vpp SvtURLBox.vpp] ...but I couldn't upload .vpp files)<br />
<br />
== Conclusion ==<br />
<br />
Much work is already done in order to solve the problem that certain OOo <br />
dialogs will have in conjunction with the new OOo Threading Framework. All<br />
conceptional work is done. What's open is to finish adapting affected OOo<br />
code.<br />
<br />
== Typical Changes - Example == <br />
IMO a simple example for the code changes typical for asyncdialog can be found in /svx/source/dialog/cuigaldlg.cxx and the respective header file in the same directory.<br />
<br />
There is a class SearchProgress which creates an instance of class SearchThread. The SearchThread worker thread calls back into VCL (e.g. SearchThread::ImplSearch(): mpBrowser->aLbxFound.InsertEntry()).<br />
<br />
In asyncdialogs the latter will lead to a deadlock, because: <br />
* The thread that calls SearchProgress::Execute() thereby enters the Office Mutex threading environment <br />
* That thread stays there at least until Execute() returns.<br />
* But Execute() will never return, because it waits for the SearchThread to end.<br />
<br />
In fact it waits indefinetly that CleanUpHdl will be called (handler calls EndDialog() and this will let Execute() return), which is only done from inside SearchThread::onTerminated(). But the worker thread only terminates if it is ably to deliver search results to VCL, but it will never be able to do so because every VCL call will automatically guarded by the Office Mutex threading environment...<br />
<br />
The solution was to switch to the new asyncdialog VCL Dialog execution API.<br />
<br />
== To DO == <br />
List of things to do in CWS asyncdialogs <br />
<br />
=== General ===<br />
* Find and change all dialogs that are executed via Dialog::Execute() and that indirectly or directly spawn threads that need to call back to non-threadsafe code (for example VCL API, non-threadsafe UNO objects) in order to get the dialog finished.<br />
** VCL: deprecate Dialog::Execute() => changes mail!<br />
** UNO: deprecate css::ui::dialogs::XExecutableDialog => changes mail!<br />
<br />
=== Affected dialogs ===<br />
* '''unopkg binary -- gui mode'''<br />
** desktop/source/deployment/gui/dp_gui_service.cxx => ServiceImpl::execute()<br />
** dialog creates threads.<br />
** dialog is a non-threadsafe UNO service => does not use Dialog::Execute, but Application::Execute()<br />
*** BUG: Application::Execute() enters apartment at the beginning and remains in apartment all the time<br />
*** dialog worker threads will never be able to enter apartment => deadlock<br />
*** UTF2: Application::Execute() must be fixed - DONE (by KR)<br />
*** asyncdialogs: com.sun.star.comp.deployment.ui.PackageManagerDialog service: - does no longer implement XExecutableDialog, but XAsynchronousExecutableDialog DONE: changed<br />
<br />
* '''fpicker/source/unx/gnome/asynceventnotifier.hxx: #include <osl/thread.hxx>'''<br />
** triggered by dialog - ./fpicker/source/unx/gnome/SalGtkFilePicker.cxx => SalGtkFilePicker::execute()<br />
** 'execute' problem must be solved<br />
** DONE: no change (asynceventnotifier no longer used in m124)<br />
<br />
* '''svtools/source/control/inettbc.cxx:#include <vos/thread.hxx>'''<br />
** triggered by misc dialogs using SvtURLBox => 'execute' problem must be solved<br />
** class XMLFilterTabPageXSLT (/framework/filter/source/xsltdialog/xmlfiltertabpagexslt.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvxIMapDlg (/graphics/svx/inc/imapdlg.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvxHyperURLBox : public SvtURLBox (/graphics/svx/source/dialog/hltpbase.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class OFileURLControl : public SvtURLBox (/graphics/svx/source/dialog/urlcontrol.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class AddInstanceDialog (/graphics/svx/source/inc/datanavi.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class SvtExpFileDlg_Impl (/gsl/fpicker/source/office/iodlgimp.hxx)<br />
*** part of implementation of class SvtFileDialog (/gsl/fpicker/source/office/iodlg.hxx)<br />
*** lots of direct and indirect callers!<br />
*** @@@ IN PROGRESS (Peter Burow)<br />
** class ScLinkedAreaDlg (/sc/sc/source/ui/inc/linkarea.hxx)<br />
*** @@@ todo => investigate if change needed<br />
** class FileURLBox : public SvtURLBox (/util/svtools/inc/fileurlbox.hxx)<br />
*** @@@ todo: callers? => investigate<br />
** class OFileURLControl : public SvtURLBox (/util/svtools/inc/urlcontrol.hxx)<br />
*** @@@ todo: callers? => investigate<br />
*** IN PROGRESS<br />
<br />
* '''sw/source/ui/inc/maildispatcher.hxx:#include <osl/thread.hxx>'''<br />
** class MailDispatcher (sw/source/ui/inc/maildispatcher.hxx) is an osl::Thread<br />
*** Instances are created in:<br />
***# sw/source/ui/dbui/dbmgr.cxx<br />
***# sw/source/ui/dbui/mailmergechildwindow.cxx<br />
*** MailDispatcher has interface for regsistration of UNO listeners<br />
***# no Dialog::Execute in any possible callstack (currently only reachable via UNO API) ==> DONE: no change needed<br />
***# SwMailSendDialog is a modeless dialog, does not need to be changed therfore, but is called by MailMergeWizard which has overridden Dialog::Execute()<br />
***** MailMergeWizard and calling code must be changed ==> DONE: changed<br />
** DONE<br />
<br />
* '''svx/source/dialog/cuigaldlg.hxx:#include <vos/thread.hxx>'''<br />
** @@@ triggered by dialog => 'execute' problem must be solved<br />
** DONE: changed<br />
<br />
<br />
[[Category:Effort]]</div>Plumbumm