We should only use generic foo function name when it takes params
that are also dependent on UNICODE define, like
LoadCursor( nullptr, IDC_ARROW )
where IDC_ARROW is defined in MSVC headers synchronised with
LoadCursor definition.
We should always use Unicode API for any file paths operations,
because otherwise we will get "?" for any character in path that
is not in current non-unicode codepage, which will result in failed
file operations.
Change-Id: I3a7f453ca0f893002d8a9764318919709fd8b633
Reviewed-on: https://gerrit.libreoffice.org/42935
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... from the Drawing toolbar in Impress. The warning was
"DockingWindow has become non-layout because extra children
have been added directly to it.", but this DockingWindow is
actually a ToolBox which set as the parent of the color picker,
although it isn't really a parent in layout terms.
Change-Id: Id1384653ceda938ca0cc300c35467e562984bca1
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
There was support for an MOD2+drag operation in ToolBox, apparently intended to
allow customization by re-arranging items. However, in
ImplTBDragMgr::EndDragging that operation would always have ended in doing
nothing: Ever since at least 8ab086b6cc "initial
import", what happened was a call to virtual ToolBox::Customize, but which had
an empty body and wasn't overridden anywhere (and has since been cleaned away
over a series of commits).
Change-Id: I8c5962d7b29506dc7dc8d803f49847f30fb93ea1
...after b2262e8be3 "callcatcher: remove some
unused methods" (and other clean-up of unused functionality that came before)
identified ToolBox::ImplStartCusomizeMode as unused.
Change-Id: Ic2c6720ca5519842796c7e993064aed637503aa2
(vs. uses of sal_uInt16 representing such items' IDs). APPEND and ITEM_NOTFOUND
are members of ToolBox now (and have been bumped to the corresponding type's
max). The payload of VclEventIds
ToolboxButtonStateChanged
ToolboxClick
ToolboxHighlightOff
ToolboxItemAdded
ToolboxItemDisabled
ToolboxItemEnabled
ToolboxItemRemoved
ToolboxItemTextChanged
ToolboxItemUpdated
ToolboxItemWindowChanged
ToolboxSelect
has been changed too (note that reading/writing of those payloads isn't very
consistent, though: for some of these, values are written that are never read,
while for some others no values are ever written but the reading code would like
to receive some value if the payload wasn't a nullptr).
Change-Id: I4856ffb3637404b8d866621a3503d7922b1b8141
because as soon as we're wrapped somewhere with a temp.
uno/rtl::Reference, its destruction will lead to our own
destruction while we're still in ctor. Typical situation
is when the broadcaster rejects our listening request.
Change-Id: I7fd282e53095ab9939f803df9564c9767263b1f8
Seem UBSAN doesn't like my forced reinterpret_cast to set the Idles
Link in the Timer class. Now there are two possible solution:
1. convert all (DECL|IMPL).*_LINK call sites to use a Timer* or
2. split the inheritance of Idle from Timer again to maintain
different Link<>s and move all common code into a TimerBase.
While the 1st is more correct, the 2nd has a better indicator for
Idles. This implements the first solution.
And while at it, this also converts all call sites of SetTimeoutHdl
and SetIdleHdl to SetInvokeHandler and gets rid of some local Link
objects, which are just passed to the SetInvokeHandler call.
It also introduces ClearInvokeHandler() and replaces the respective
call sites of SetInvokeHandler( Link<Timer *, void>() ).
Change-Id: I40c4167b1493997b7f136add4dad2f4ff5504b69
Moves all the "task-specific" stuff into a Task class and just
keeps the "real" static Scheduler functions in the original
Scheduler class.
Change-Id: I9eb02d46e2bcf1abb06af5bab1fa0ee734d1984c
The custom shape popup toolbars used their own drawing code for
the drag handle. This was dropped in favour of the default toolbox
drag handle code.
This also drops the drag highlighting in favour of a move mouse
cursor as the drag indicator. The drag handle is currently always
drawn on the top, like a window title.
Change-Id: I08cbf715f1e240c2eb6d9a61fad2b705f9bd8014
Inspired by a recent bug report where we were assigning the result
of VclPtr<T>::Create to a raw pointer.
As a consequence, we also need to change various methods that were
returning newly created Window subclasses via raw pointer, to
instead return those via VclPtr
Change-Id: I8118e0195a5b2b4780e646cfb0e151692e54ae2b
Reviewed-on: https://gerrit.libreoffice.org/31318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
There is annoying overloading between Window::Notify and
SfxListener::Notify, and the Window one has apparently fewer
implementations, so rename that and remove lots of disambiguating
"using Notify" in multiply inheriting classes.
Change-Id: I8b597fd9e70cf2e7103b9dfa7cc666e79e7aff49
instead of using the MenuBar text color, cause for Ambiance theme the
menubar is dark and its font is light, while the toolbars can be light,
so light font on light bg appears greyed out
Change-Id: I0fa4ab8eabdd3cd69eb682e5ddba8314b8c9ff0f
