fdo#60724 correct spelling

Change-Id: I3d978cb657647b4a4e9709258c6a6a4ac1d339a9

5 files changed, 7 insertions, 7 deletions

diff --git a/framework/inc/classes/filtercachedata.hxx b/framework/inc/classes/filtercachedata.hxx
index e8591bba2c08..324480b9cc1b 100644
--- a/framework/inc/classes/filtercachedata.hxx
+++ b/framework/inc/classes/filtercachedata.hxx
@@ -593,8 +593,8 @@ class DataContainer : private ThreadHelpBase
     @descr          We use the ConfigItem mechanism to read/write values from/to configuration.
                     This implementation could be used to handle standard AND additional filter configurations in the same way.
                     We set a data container pointer for filling or reading ... this class use it temp.
-                    After successfuly calling of read(), we can use filled container directly or merge it with an existing one.
-                    After successfuly calling of write() all values of given data container are flushed to our configuration.
+                    After successfully calling of read(), we can use filled container directly or merge it with an existing one.
+                    After successfully calling of write() all values of given data container are flushed to our configuration.
 
     @implements     -
     @base           ConfigItem
diff --git a/framework/inc/classes/protocolhandlercache.hxx b/framework/inc/classes/protocolhandlercache.hxx
index e090039aba9e..1f7963725fea 100644
--- a/framework/inc/classes/protocolhandlercache.hxx
+++ b/framework/inc/classes/protocolhandlercache.hxx
@@ -135,8 +135,8 @@ class FWI_DLLPUBLIC HandlerCache
     @short          implements configuration access for handler configuration
     @descr          We use the ConfigItem mechanism to read/write values from/to configuration.
                     We set a data container pointer for filling or reading ... this class use it temp.
-                    After successfuly calling of read(), we can use filled container directly or merge it with an existing one.
-                    After successfuly calling of write() all values of given data container are flushed to our configuration -
+                    After successfully calling of read(), we can use filled container directly or merge it with an existing one.
+                    After successfully calling of write() all values of given data container are flushed to our configuration -
                     but current implementation doesn't support writeing realy.
 
     @base           ::utl::ConfigItem
diff --git a/framework/inc/threadhelp/readguard.hxx b/framework/inc/threadhelp/readguard.hxx
index 22f337a61c08..ea59f8006a9f 100644
--- a/framework/inc/threadhelp/readguard.hxx
+++ b/framework/inc/threadhelp/readguard.hxx
@@ -31,7 +31,7 @@ namespace framework{
 /*-************************************************************************************************************//**
     @short          implement a guard to set read locks
     @descr          This guard should be used to set a lock for reading object internal member.
-                    Nobody can control it but don't use member after successfuly locking for writing!
+                    Nobody can control it but don't use member after successfully locking for writing!
                     We never need a own mutex to safe our internal member access - because
                     a guard is used as function-local member only. There exist no multithreaded access to it realy ...
 
diff --git a/framework/source/dispatch/dispatchprovider.cxx b/framework/source/dispatch/dispatchprovider.cxx
index 10b382b64610..962eadb07118 100644
--- a/framework/source/dispatch/dispatchprovider.cxx
+++ b/framework/source/dispatch/dispatchprovider.cxx
@@ -65,7 +65,7 @@ DEFINE_XTYPEPROVIDER_2( DispatchProvider             ,
 
 /**
     @short      standard ctor/dtor
-    @descr      These initialize a new instance of tihs class with needed information for work.
+    @descr      These initialize a new instance of this class with needed information for work.
                 We hold a weakreference to our owner frame which start dispatches at us.
                 We can't use a normal reference because he hold a reference of us too ...
                 nobody can die so ...!
diff --git a/framework/source/services/frame.cxx b/framework/source/services/frame.cxx
index 359a7bb4f55d..1641efd19523 100644
--- a/framework/source/services/frame.cxx
+++ b/framework/source/services/frame.cxx
@@ -1928,7 +1928,7 @@ void SAL_CALL Frame::dispose() throw( css::uno::RuntimeException )
         remove himself at this instance ...
         Release m_xFramesHelper after that ... it's the same problem between parent and child!
         "m_xParent->getFrames()->remove( xThis );" needs this helper ...
-        Otherwise we get a null reference and could finish removing successfuly.
+        Otherwise we get a null reference and could finish removing successfully.
         => You see: Order of calling operations is important!!!
      */
     implts_forgetSubFrames();