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.gelm...@gelma.net> AuthorDate: Tue Jul 17 23:18:10 2018 +0200 Commit: Julien Nabet <serval2...@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+libreoff...@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+libreoff...@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; } _______________________________________________ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits