[Libreoffice-commits] core.git: toolkit/source vcl/inc vcl/README.lifecycle

Libreoffice Gerrit user logerrit at kemper.freedesktop.org
Thu Jul 19 11:54:30 UTC 2018


 toolkit/source/helper/unowrapper.cxx |    2 +-
 vcl/README.lifecycle                 |   11 +++++------
 vcl/inc/win/winlayout.hxx            |    2 +-
 3 files changed, 7 insertions(+), 8 deletions(-)

New commits:
commit c9e31a8de05b5ba4b21849a22d7809ab0768aefb
Author:     Andrea Gelmini <andrea.gelmini at gelma.net>
AuthorDate: Tue Jul 17 23:18:10 2018 +0200
Commit:     Julien Nabet <serval2412 at yahoo.fr>
CommitDate: Thu Jul 19 13:54:05 2018 +0200

    Fix typos
    
    Change-Id: I2aa5448869bf60e9c8d9b1ebabd0d0932d28f3a1
    Reviewed-on: https://gerrit.libreoffice.org/57606
    Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice at googlemail.com>
    Tested-by: Christian Lohmaier <lohmaier+LibreOffice at googlemail.com>

diff --git a/toolkit/source/helper/unowrapper.cxx b/toolkit/source/helper/unowrapper.cxx
index c389d04ed8fa..b38ceeded3ab 100644
--- a/toolkit/source/helper/unowrapper.cxx
+++ b/toolkit/source/helper/unowrapper.cxx
@@ -275,7 +275,7 @@ void UnoWrapper::WindowDestroyed( vcl::Window* pWindow )
         xWindowPeerComp->dispose();
 
     // #102132# Iterate over frames after setting Window peer to NULL,
-    // because while destroying other frames, we get get into the method again and try
+    // because while destroying other frames, we get into the method again and try
     // to destroy this window again...
     // #i42462#/#116855# no, don't loop: Instead, just ensure that all our top-window-children
     // are disposed, too (which should also be a valid fix for #102132#, but doesn't have the extreme
diff --git a/vcl/README.lifecycle b/vcl/README.lifecycle
index 6ef91ccfce51..732b1908d077 100644
--- a/vcl/README.lifecycle
+++ b/vcl/README.lifecycle
@@ -296,12 +296,12 @@ ways and often both.
 	the inheritance chain from children to parent, during dispose.
 
 	The easiest way to fix these is to just ensure that these
-	cleanup methods, especially LoseFocus continue to work even
+	cleanup methods, especially LoseFocus, continue to work even
 	on disposed Window sub-class instances.
 
-** It crashes with some invalid memory ...
+** It crashes with some invalid memory...
 
-        Assuming that the invalid memory is a Window sub-class itself,
+    Assuming that the invalid memory is a Window sub-class itself,
 	then almost certainly there is some cockup in the
 	reference-counting; eg. if you hit an OutputDevice::release
 	assert on mnRefCount - then almost certainly you have a
@@ -309,13 +309,12 @@ ways and often both.
 	happen via this sort of pattern:
 
 	ModelessDialog *pDlg = VclPtr<ModelessDialog>(nullptr /* parent */);
-	// by here the pDlg quite probably points to free'd memory
-	...
+	// by here the pDlg quite probably points to free'd memory...
 
 	It is necessary in these cases to ensure that the *pDlg is
 	a VclPtr<ModelessDialog> instead.
 
-** It crashes with some invalid memory #2 ...
+** It crashes with some invalid memory #2...
 
 	Often a ::dispose method will free some pImpl member, but
 	not NULL it; and (cf. above) we can now get various virtual
diff --git a/vcl/inc/win/winlayout.hxx b/vcl/inc/win/winlayout.hxx
index 0ef5cc03b846..598d90c60588 100644
--- a/vcl/inc/win/winlayout.hxx
+++ b/vcl/inc/win/winlayout.hxx
@@ -157,7 +157,7 @@ public:
     void SetHFONT(const HFONT);
     HFONT GetHFONT() const { return m_hFont; }
 
-    // Prevend deletion of the HFONT in the WinFontInstance destructor
+    // Prevent deletion of the HFONT in the WinFontInstance destructor
     // Used for the ScopedFont handling
     void UnsetHFONT() { m_hFont = nullptr; }
 


More information about the Libreoffice-commits mailing list