fdo#56818 Work around deadlock caused by differing lock orders

Change-Id: Iaabe36bf0c1f051f9cebc2b65e614063698959fa

embeddedobj/Library_embobj.mk

@@ -45,6 +45,7 @@ $(eval $(call gb_Library_use_libraries,embobj,\
 	cppu \
 	cppuhelper \
 	sal \
+	vcl \
 	$(gb_UWINAPI) \
 ))
 

embeddedobj/prj/build.lst

-eo	embeddedobj	:	offapi sal cppu cppuhelper comphelper tools unotools LIBXSLT:libxslt NULL
+eo	embeddedobj	:	offapi sal cppu cppuhelper comphelper tools unotools vcl LIBXSLT:libxslt NULL
 eo	embeddedobj\prj		nmake	-	all	eo_prj NULL

embeddedobj/source/commonembedding/embedobj.cxx

@@ -40,6 +40,7 @@
 #include <comphelper/processfactory.hxx>
 
 #include <rtl/logfile.hxx>
+#include <vcl/svapp.hxx>
 
 #include <targetstatecontrol.hxx>
 
@@ -529,6 +530,16 @@ void SAL_CALL OCommonEmbeddedObject::doVerb( sal_Int32 nVerbID )
 {
     RTL_LOGFILE_CONTEXT( aLog, "embeddedobj (mv76033) OCommonEmbeddedObject::doVerb" );
 
+    SolarMutexGuard aSolarGuard;
+        //TODO: a gross hack to avoid deadlocks when this is called from the
+        // outside and OCommonEmbeddedObject::changeState, with m_aMutex locked,
+        // calls into framework code that tries to lock the solar mutex, while
+        // another thread (through Window::ImplCallPaint, say) calls
+        // OCommonEmbeddedObject::getComponent with the solar mutex locked and
+        // then tries to lock m_aMutex (see fdo#56818); the alternative would be
+        // to get locking done right in this class, but that looks like a
+        // daunting task
+
     ::osl::ResettableMutexGuard aGuard( m_aMutex );
     if ( m_bDisposed )
         throw lang::DisposedException(); // TODO