summaryrefslogtreecommitdiff
path: root/vcl/win
AgeCommit message (Collapse)Author
2021-02-24use unique_ptr in WinSalBitmap::AcquireBufferNoel Grandin
Change-Id: I1fca86f6d1f9bd64238b8e75cd98f53df99f91bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111447 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-24use unique_ptr in WinSalBitmapNoel Grandin
Change-Id: I3c536b766d35b3137d79739c232d0d5cff3652b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111446 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-24use unique_ptr in WinSalBitmapNoel Grandin
Change-Id: I8ca55870094443f7eb670df06de34ad0ed87ad8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111445 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-24Fix typosAndrea Gelmini
Change-Id: If005139571e46fbf8aedb37e2626c54a43853fd5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111483 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-02-24add additional 0-1 alpha argument to DrawTransformedBitmap()Luboš Luňák
This allows the VCL backends the apply the extra alpha transformation as it sees fit, rather than it being done manually elsewhere (and even if the backend doesn't implement it, at least do it in one place in the function). With the document from tdf#136223, going from slide 2 to slide 3, this easily saves 10-30% of CPU cycles. As an additional bonus, using AlphaMask::BlendWith() rather than AlphaMask::Replace() makes edges of shapes noticeably more smooth. Change-Id: I036dc9b887d6def0c7cdad3982becabdc7cd5206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111247 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24simply use drawTransformedBitmap()Luboš Luňák
At least with Skia this is faster than GraphicObject trying to handle it manually, even in raster mode. Change-Id: If77d108751f5621878d4ea87a996c2ea0253d111 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111246 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24use unique_ptr in ImplHandleIMECompositionInputNoel Grandin
Change-Id: I9587d97fbdd73844590fd6380e594ec7b4f4df14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111441 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-11make win32 variant AnyInput() not deliver events (tdf#140293)Luboš Luňák
Win32 API PeekMessage() actually may deliver events, despite what the name may suggest, even with PM_NOREMOVE argument. That means this is problematic for use in AnyInput(), as that function should just check the event queue but not do anything with it. Using GetQueueStatus() should solve the problem. See https://lists.freedesktop.org/archives/libreoffice/2021-February/086788.html for further details. Change-Id: I10d3423f89f6f050534625110113dee60959f7a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110718 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2021-02-09loplugin:fakebool (clang-cl)Stephan Bergmann
But GetMessageW encodes more than true vs. false in its BOOL return value, so silence the unhelpful loplugin with auto. Change-Id: I77d053b760e93f918367532c63a6dfe963faa12d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110645 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-04fix sporadic crash in sd_misc_tests on windowsNoel Grandin
we end up trying to process a timer message, but from inside the vcl de-init function, which means the timer stuff has already been de-initialised. Change-Id: I94703219754f1ccabd3065fc5ea437f39264197b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110397 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-29Fix typoAndrea Gelmini
Change-Id: Ie9dab2d4813b986bf7eb4e2f7dee37171e9be9fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110162 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-28WIN handle GetMessageW return valuesJan-Marek Glogowski
GetMessageW returns a BOOL with three defined return values; a bit unexpected (-1 = error, 0 = WM_QUIT, * = dispatch message). So this tries to handle the non-dispatch results in some way. It's not clear for me, if there is some sensible way to "recover" from an error, but from all I've read it doesn't look like it. "Recover" means in this case, that the last call failed but next call may still succeed without changing the parameters. Change-Id: Ib1f366c7ce8b48158d1935938b49d8da991b30e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110043 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-01-28WIN refactor ImplSalYieldJan-Marek Glogowski
While looking for some reason for multiple ABORTED Jenkins runs, presumely due to unprocessed Idles, I found the ImplSalYield code way too hard to follow, so this restructures the PeekMessage loop and adds some better comments to make that easier. We now bail out a bit earlier in m_nNoYieldLock mode and also account for eventual tick wraps in single message mode, which isn't needed, as we already just process one message, but it removes additional conditions and further simplifies the code. We also now explicitly report GetMessageW non-message return codes. Change-Id: Ibd745d5540dd9998570ece9aeb0d37886b627eb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110042 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-01-28WIN move dtrans log to vcl.win.dtransJan-Marek Glogowski
Missing from commit 9613165239ade3f0b4d3d06e238430aabc9fcff3 ("WIN move dtrans code into vcl/win/dtrans"). Change-Id: I257017ae617f72c3ce48828ee34e9246af08fd8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110073 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-01-13loplugin:stringviewparam (clang-cl)Stephan Bergmann
Change-Id: Ie66996f905fcb68ee413171c8727cb42dcb28dbc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109178 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-13loplugin:stringliteralvar (clang-cl)Stephan Bergmann
Change-Id: I79949789634242eb95cc722bab83e0348775f274 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109174 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-12Revert "WIN replace clipboard update thread with Idle" et alStephan Bergmann
This reverts commit 9617bc9544cd569066ff187c3672a87fe28fe17f "WIN replace clipboard update thread with Idle" plus follow-up commits f5ab8bcbfd20ecce4a358f62ee3f81b8b968a5de "WIN don't notify clipboard change with SolarMutex" and c921f9bd64187823af2356d7a8ceb77444c17219 "Release solar mutex before using an apartment-threaded COM object". The Gerrit Jenkins Windows builds had started to abort after timeout for almost all builds now. Going back to before the youngest of the above three commits, c921f9bd64187823af2356d7a8ceb77444c17219 "Release solar mutex before using an apartment-threaded COM object" did not improve things (see the <https://gerrit.libreoffice.org/c/core/+/109100> "Test build #1, DO NOT SUBMIT" chain, where three out of three of the Gerrit Jenkins Windows builds timed out). But going back to before the oldest of the above three commits, 9617bc9544cd569066ff187c3672a87fe28fe17f "WIN replace clipboard update thread with Idle", does look promising (see the <https://gerrit.libreoffice.org/c/core/+/109155> "Test build #7, DO NOT SUBMIT" chain, where three out of three of the Gerrit Jenkins Windows builds succeeded). So the hope is that reverting all three commits brings back a green master, allowing us to understand and fix the actual issue later. Change-Id: Ie83ba742f216396b49f561d19c2cda7758740502 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109158 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-06Release solar mutex before using an apartment-threaded COM objectMike Kaganski
See https://lists.freedesktop.org/archives/libreoffice/2020-December/086448.html for motivation This partially reverts f5ab8bcbfd20ecce4a358f62ee3f81b8b968a5de. Although this change is questionable, it's intended to avoid crashes (tdf#139074); a better fix should replace this eventually. Optionally releasing a lock isn't a good API and might hide other bugs, but the better solution to handle all requests in the main thread would need an even larger rewrite of the Windows clipboard code. It's simply too late for that in this LO release cycle. Change-Id: I60e847599fe873025c9903b9d6290ed4cdf4a961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107669 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-26tools: add Color::IsTransparent()Chris Sherlock
This removes the need for OutputDevice::ImplIsColorTransparent(). Change-Id: I8f98199c5ce1c171c453b6897f27eacbd53f1eea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108248 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-24vcl: move access functions into appropriate bitmap access filesChris Sherlock
Split class functions into BitmapInfoAccess.cxx, BitmapReadAccess.cxx and BitmapWriteAccess.cxx Split header files into BitmapInfoAccess.hxx and BitmapReadAccess.hxx Change-Id: I7dcbe1d26c5b64d297658a6b809c93d7ad7f053d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108039 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-12-16WIN don't notify clipboard change with SolarMutexJan-Marek Glogowski
Regression from commit 52a7eb58f5c137b6de76cc49be07dd43c42a6d6c ("WIN replace clipboard update thread with Idle"). Previously the notification was done without the SolarMutex. Now it's run via an Idle and SolarMutex is required by the Scheduler, so release it. Foreign contents is again protected by the clipboard lock. And also unlock the SolarMutex in getContents, to prevent a deadlock in the clipboard STA thread, if it's already processing other request, like CXNotifyingDataObject::GetData, blocking on the SolarMutex. Change-Id: I6855b045b3065289ec7833498f6785ee31eda61c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107675 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-12-15Silence warning C4100: unreferenced formal parameterStephan Bergmann
Change-Id: I27d28ebeca8425b7750996edae0cf704b5626c49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107739 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Silence warning C4189: local variable is initialized but not referencedStephan Bergmann
Change-Id: Ie36d7c4dfee5115b5909ed58a0b16b367e05866d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107734 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Reuse pInstStephan Bergmann
Change-Id: I91e5a469344ab951225e61237b462ed58ed796be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107733 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Fix and clean up SalAbort implementations on macOS and WindowsStephan Bergmann
Since "forever", SalAbort has been declared as non-exported in vcl/inc/salinst.hxx and (only) called from Application::Abort (vcl/source/app/svapp.cxx) in Library_vcl. Its various implementations for different platforms have always been scattered across Library_vcl. For Windows, SalAbort was originally implemented in vcl/win/app/salinst.cxx, until 1698debed2993fc5f262aa3ebbdb32fc112ac556 "Implement Windows VCL backend as plugin" introduced an incompatible implementation in vcl/win/app/salplug.cxx (which was added to Library_vcl) and moved the original implementation in vcl/win/app/salinst.cxx from Library_vcl to Library_vclplug_win, where it thus became dead code (and where it now gets removed). For macOS, SalAbort was originally implemented in vcl/osx/salinst.cxx, until 3af4e1a0825c5b11ae4ef58fc411378aab669387 "Implement MacOSX VCL backend as plugin" introduced a different implementation in vcl/osx/salplug.cxx (which was added to Library_vcl) and moved the original implementation in vcl/osx/salinst.cxx from Library_vcl to Library_vclplug_win, where it thus became dead code (and where it now gets removed). (In 0f3be2e19fa408d7069d586ccf04cb3f3eccd6b9 "Unify sal plugin loaders", the--- identical---new implementations in vcl/osx/salinst.cxx and vcl/win/app/salinst.cxx where then consolidated with other---also identical--- implementations in vcl/source/app/salplug.cxx.) For macOS, the original, now removed implementation in vcl/osx/salinst.cxx and the consolidated implementation in vcl/source/app/salplug.cxx only differed in an added CrashReporter::addKeyValue("AbortMessage", rErrorText, CrashReporter::Write); which is presumably harmless to add. But for Windows, the original, now removed implementation in vcl/win/app/salinst.cxx differed substantially from the consolidated implementation in vcl/source/app/salplug.cxx, which is updated here to reflect those differences. The one thing that cannot easily be updated, though, is the //TODO: ImplFreeSalGDI(); call, as ImplFreeSalGDI is defined in Library_vclplug_win. I'll thus leave fixing that TODO for another commit (if calling ImplFreeSalGDI from SalAbort is even necessary, given that it ends in FatalAppExitW anyway)---my gut feeling is that the whole 1698debed2993fc5f262aa3ebbdb32fc112ac556 "Implement Windows VCL backend as plugin" was somewhat misguided. Change-Id: I641a3d7b1bc27ae14c38eb1ec0838bc04e4290d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107666 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-14Silence MSVC warning C4189 "local variable is initialized but not referenced"Stephan Bergmann
Change-Id: I346cf6cf148cd3b4ac851f8c441d54c858f55935 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107674 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-13WIN replace clipboard update thread with IdleJan-Marek Glogowski
Little "fallout" patch when moving code from /dtrans/** to /vcl/win/dtrans and merging CWinClipbImpl into CWinClipboard while I tried to reproduce tdf#62196... And since we now process the notification in the main thread, we can get rid of m_pfncClipViewerCallbackMutex, which brings us down from 6 (!) to 4 mutexes (if Mike counted correct) in the Windows clipboard code... ok, technically the scheduler / Idle adds its mutex to this count, but that is not related to the clipboard handling on Windows ;-) This also moves the UnregisterClassW into the OLE thread, which already calls RegisterClassW, to be more consistent. This now also gets merged, because it seem to fix a deadlocks when running CppunitTest_sc_macros_test in a loop, which is unclear where it comes from and I can't reproduce. Tinderboxes and Gerrit also still seem fine. Change-Id: Iacbda0bdf6c98f27f6e59964d541524cb45ade24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107168 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-12-08remove more no longer needed OpenGL-related codeLuboš Luňák
Change-Id: If7f47cf6dad860e4f8eab68931b72a38a7eda136 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107362 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-07remove WinGlyphCache and related codeLuboš Luňák
The code for separately rendering glyphs was used only by OpenGL code (and temporarily by Skia code). Change-Id: I8eee764045273705c108f3734b330a2237de15f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107291 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-07remove OpenGL VCL backend codeLuboš Luňák
It is by now practically unmaintained, even bugreports in bugzilla have been already closed for it. AFAICT this used to be really used only on Windows, where it's no longer the default. There's still some OpenGL code left, because there are still two other places that use OpenGL. One is OpenGL slideshows, which reuse some of the base OpenGL code (and I've checked they still work even after this removal). Second one is OpenGL canvas, which it seems has never been finished or enabled (or so it most probably should be dumped too). Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-07Fix typoAndrea Gelmini
Change-Id: I4d2955576925ef6d44b32447d953dc75bf41cf37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107293 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-12-04tdf#134128 Use Gdiplus::DashCapRound for round dash or dot.Regina Henschel
If Skia and OpenGL are disabled, rendering in edit mode shows no round dashes and dots on Windows. This becomes especially visible, when importing OOXML documents. In that case it looks as if dots are lost. The patch uses now Gdiplus::DashCapRound instead of the previously used Gdiplus::DashCapFlat, and it adds a similar tweak as in OOXML import and increases the dash length by the cap size for rendering. Change-Id: I98a258809ef253a2cacb7c5c94f2b26b89ee2488 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107181 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-01OSL_FAIL.*exception -> TOOLS_WARN_EXCEPTIONNoel
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-27WinSalFrame::mnWidth/Height should presumably be of type LONGStephan Bergmann
...as they are only ever set to LO-/HIWORD values cast to a signed integer type Change-Id: I82f9a80bab7c3b7e3ee5545725efd0d88601b8c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106755 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27DWRITE_GLYPH_METRICS members are of INT32 and UINT32 typesStephan Bergmann
Change-Id: Ie09e0150bf73efd552e3a3b455ffc395d6b6370c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106754 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27RECT members are of type LONGStephan Bergmann
Change-Id: I8c0ad0878903c729be7149f81f5844a4baea7883 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106753 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27LOGFONTW::lfHeight is of type LONGStephan Bergmann
Change-Id: Iec7e8e84b8a6ee9e4ddbbbf5708bf9040418bbb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106752 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27DocumentPropertiesW returns LONGStephan Bergmann
Change-Id: I1ee167ef1bca530be9399dd081d7d25bd4155794 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106750 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27loplugin:toolslong (Library_vclplug_win)Stephan Bergmann
Change-Id: I1e8c02a4fdb42a7bbc25764ceaf96972f175130a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106751 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27GetLastError returns DWORDStephan Bergmann
Change-Id: I4e886d1d5f94f8a25591c41e9f03300cfba641dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106729 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-27Windows InterlockedIncrement/Decrement use LONGStephan Bergmann
Change-Id: Ib3e8e89332399eba443d9ff291f694cfceb95af1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106726 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-25-Wc++11-narrowing (clang-cl)Stephan Bergmann
MSVC seems not to mind, but a Windows 64-bit build with clang-cl fails with "error: non-constant-expression cannot be narrowed from type 'tools::Long' (aka 'long long') to 'LONG' (aka 'long') in initializer list". But adding explicit casts would have the downside of preventing tools like -fsanitize=implict-conversion (if we ever use that on Windows) from detecting truncation, so introduce o3tl::narrowing. Change-Id: Ia33a9ae4d8134b5ad0c8b7cf6812fbdd625ca89e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106577 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-22tdf#123936 Formatting files in module vcl with clang-formatPhilipp Hofer
Change-Id: Ia162ad5b7499c0ddfdbfca59ae76b81335ce2d45 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105728 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-11-16Instead of labs, use overloaded absStephan Bergmann
...more likely to pick an appropriate version for the involved integer types, esp. after the recent long -> tools::Long changes Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-14remove SalPointNoel Grandin
<caolan> that "SalPoint" doesn't really seem to to have a purpose except to highlight that "Point" is assumed to use LONG under windows and can be passed unchanged to those windows drawing apis <caolan> so I guess remove SalPoint entirely, use Point instead, and convert to "POINT" under windows ? Change-Id: Ic15a7f4516e2075a228fa65cac4e8494d5b3abaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105634 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-11Fix 64-bit --disable-pch build on WindowsMike Kaganski
Change-Id: Ieeef0309faa77558fb30fceaed83ad97fb6e26ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105590 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11convert more long -> tools::LongNoel
found by grepping and changed by hand. Change-Id: I3c720859dba430fde3abc76c6c5cb58269efaf4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105512 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11make tools::Long 64-bit on Windows platformNoel Grandin
This is only for the 64-bit windows platform. I don't see the point in messing with the 32-bit platforms, they are (a) become more and more rare (b) unlikely to even have enough available process memory to load extremely large calc spreadsheets The primary problem we are addressing here is bringing Windows-64bit up to same capability as Linux-64bit when it comes to handling very large spreadsheets, which is caused by things like tools::Rectangle using "long", which means that all the work done to make Libreoffice on 64-bit Linux capable of loading large spreadsheets is useless on Windows, where long is 32-bit. The operator<< for tools::Rectangle needs to be inside the tools namespace because of an interaction with the cppunit printing template stuff that I don't understand. SalPoint changed to use sal_Int32, since it needs to be the same definition as the Windows POINT structure. Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-28convert some more long -> tools::LongNoel
grepping for stuff in template params this time Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21new tools::Degree10 strong typedefNoel Grandin
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-02-06 12:45:49 +0000