sw/source/uibase/utlui/content.cxx | 4 +++ vcl/README.lifecycle | 44 +++++++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+)
New commits: commit bf82918e53422ebfbe1f1d71cc0ed4b556966b11 Author: Michael Meeks <[email protected]> Date: Thu Apr 16 10:50:26 2015 +0100 Improve the VclPtr documentation. Change-Id: Ie69fa0fcc8cae0a3f5be8fb4a5b884caa2d56a94 diff --git a/vcl/README.lifecycle b/vcl/README.lifecycle index 0b09f57..7e34026 100644 --- a/vcl/README.lifecycle +++ b/vcl/README.lifecycle @@ -127,6 +127,15 @@ or: - VirtualDevice aDev; + ScopedVclPtrInstance<VirtualDevice> pDev; + Other things that are changed are these: + +- pButton = new PushButton(NULL); ++ pButton = VclPtr<PushButton>::Create(nullptr); +... +- vcl::Window *pWindow = new PushButton(NULL); ++ VclPtr<vcl::Window> pWindow; ++ pWindow.reset(VclPtr<PushButton>::Create(nullptr)); + ** Why are these 'disposeOnce' calls in destructors ? This is an interim measure while we are migrating, such that @@ -175,6 +184,11 @@ or: + shrink them - some work should incrementally migrate back to destructors. + * VclBuilder + + ideally should keep a reference to pointers assigned + in 'get()' calls - to avoid needing explicit 'clear' + code in destructors. + ---------- FAQ / debugging hints ---------- ** Compile with dbgutil @@ -209,3 +223,33 @@ or: => also worth git grepping for 'new sfx::sidebar::TabBar' to see where those children were added. +** Check what it used to do + + While a ton of effort has been put into ensuring that the new + lifecycle code is the functional equivalent of the old code, + the code was created by humans. If you identify an area where + something asserts or crashes here are a few helpful heuristics: + + * Read the git log -u -- path/to/file.cxx + + => Is the order of destruction different ? + + in the past many things were destructed (in reverse order of + declaration in the class) without explicit code. Some of these + may be important to do explicitly at the end of the destructor. + + eg. having a 'Idle' or 'Timer' as a member, may now need an + explicit .Stop() and/or protection from running on a + disposed Window in its callback. + + => Is it 'clear' not 'disposeAndClear' ? + + sometimes we get this wrong. If the code previously used to + use 'delete pFoo;' it should now read pFoo->disposeAndClear(); + Conversely if it didn't delete it, it should be 'clear()' it + is by far the best to leave disposing to the VclBuilder where + possible. + + In simple cases, if we allocate the widget with VclPtrInstance + or VclPtr<Foo>::Create - then we need to disposeAndClear it too. + commit 35178d188a91cd30012c25ade39fcbb437d7cbab Author: Michael Meeks <[email protected]> Date: Thu Apr 16 10:40:04 2015 +0100 Another malingering timer. Change-Id: Id101fe2023a1f9d6b66e7621516a1710a494ff34 diff --git a/sw/source/uibase/utlui/content.cxx b/sw/source/uibase/utlui/content.cxx index 40b1154..4e37206 100644 --- a/sw/source/uibase/utlui/content.cxx +++ b/sw/source/uibase/utlui/content.cxx @@ -850,6 +850,7 @@ void SwContentTree::dispose() { Clear(); // If applicable erase content types previously. bIsInDrag = false; + aUpdTimer.Stop(); SvTreeListBox::dispose(); } @@ -2453,6 +2454,9 @@ void SwContentTree::HideTree() IMPL_LINK_NOARG(SwContentTree, TimerUpdate) { + if (IsDisposed()) + return 0; + // No update while drag and drop. // Query view because the Navigator is cleared too late. SwView* pView = GetParentWindow()->GetCreateView(); _______________________________________________ Libreoffice-commits mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
