In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: If7cb4403f1861c465f44a1cae4065b0bf8dfad48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205323
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A data source can legitimately have a non-empty name but not be
registered in the object cache, e.g. when loading fails before
attachResource is called, or during context disposal.
This removes warnings like:
warn:legacy.osl:1611319:1611319:dbaccess/source/core/dataaccess/databasecontext.cxx:489: ODatabaseContext::storeTransientProperties: a non-empty data source which I do not know?!
Change-Id: I75e878107396d984f2fcf3d7d6a6e7678bc9b0c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200060
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@collabora.com>
All callers handle empty storage references, and this is expected
when database components are initialized without a backing file.
Fixes warnings like:
warn:legacy.osl:1530244:1530244:dbaccess/source/core/dataaccess/ModelImpl.cxx:768: ODatabaseModelImpl::getOrCreateRootStorage: no source to create the storage from!
Change-Id: Ie53b3be6908a2a9b910dd374703237a4aea09794
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200058
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@collabora.com>
Added new strings STR_WRITER_HEADERTEXT, STR_WRITER_HELPTEXT
in /dbaccess/inc/strings.hrc. The case
PAGE_DBSETUPWIZARD_DOCUMENT_OR_SPREADSHEET is now split into
PAGE_DBSETUP_DOCUMENT and PAGE_DBSETUP_SPREADSHEET. A duplicate function
ODocumentConnectionPageSetup() similar to OSpreadSheetConnectionPageSetup() in
dbaccess/source/ui/dlg/DBSetupConnectionPages.cxx is created. After the changes
there are now no inconsistencies in the database connection wizard for Word
documents or LibreOffice Writer Documents, also now the SpreadSheet connection
wizard no longer mentions Writer Documents in the sidebar title.
Change-Id: I126c679dab2eecf1e235a1e4c87406e04bb7486c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197523
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
If you use ResultSets with the XRowLocate interface, Base moves to the insertion row in the WrappedResultSet.cxx file, line 73.
And it never returns. Normally, this shouldn't happen, after the insert is done you must go away from the insertion row to continue.
At least that's what it seems to me?
The same scenario happens in the file BookmarkSet.cxx line 78 and so this has also been corrected.
Change-Id: I169fd0a32441922025b3cc5531b32166b4c54be0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190349
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
What has been done in:
https://gerrit.libreoffice.org/c/core/+/187567
only solves part of the problem.
Since cancelRowUpdate() is now indeed called when the ResultSet is no longer on the insert row, but it is still called even though the cursor is not positioned, in fact, at this point the cursor must be beforeFirstRow() and therefore cancelRowUpdate() should not be called until the cursor is positioned on a valid row.
These three instructions (ie: moveToInsertRow(), moveToCurrentRow() and cancelRowUpdate()) are apparently only there to ensure that the resultSet is modifiable, so I consider that if we only perform moveToInsertRow() and moveToCurrentRow() this is sufficient to ensure that the ResultSet is modifiable.
Moreover, this first correction introduces a nice regression because now, as cancelRowUpdate() is no longer called while the ResultSet is on its insert row, it becomes difficult to manage such a case.
Change-Id: I5924376d1b483451a439db97580b81fa8e4546c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190322
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Whatever that was intended to mean: if that meant that the constants
were encoded that way, these are UTF-16 already; is that meant that
they only contained characters in that range, that is unimportant.
Change-Id: I5463f1fca0d552a93d3c9d487ed9912c9e1a989e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191240
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
At least some IDEs are confused by our multitude of `tools` namespaces,
and show errors like `namespace "tools" is ambiguous`.
This removes one such namespace. The idea is to drop all but the one
in /tools (that has tools::Long and tools::Rectangle).
Change-Id: Ic718fa1be0ca34fc38fda10859f11d5a949b2603
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189951
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...during CppunitTest_dbaccess_dialog_save at
> /dbaccess/source/core/dataaccess/databasecontext.cxx:461:66: runtime error: load of value 190, which is not a valid value for type 'bool'
> #0 0x7f7563a4f478 in dbaccess::ODatabaseContext::storeTransientProperties(dbaccess::ODatabaseModelImpl&) /dbaccess/source/core/dataaccess/databasecontext.cxx:461:66
> #1 0x7f7563eb4b06 in dbaccess::ODatabaseModelImpl::release() /dbaccess/source/core/dataaccess/ModelImpl.cxx:1014:22
> #2 0x7f7563a60ef9 in rtl::Reference<dbaccess::ODatabaseModelImpl>::~Reference() /include/rtl/ref.hxx:126:22
> #3 0x7f7563a44db9 in dbaccess::ODatabaseContext::disposing() /dbaccess/source/core/dataaccess/databasecontext.cxx:254:5
> #4 0x7f75b1c465ab in cppu::WeakComponentImplHelperBase::dispose() /cppuhelper/source/implbase.cxx:104:13
> #5 0x7f7563a6ffc9 in cppu::PartialWeakComponentImplHelper<com::sun::star::lang::XServiceInfo, com::sun::star::sdb::XDatabaseContext>::dispose() /include/cppuhelper/compbase.hxx:90:36
> #6 0x7f75b1e0a3c2 in cppuhelper::ServiceManager::disposing(std::unique_lock<std::mutex>&) /cppuhelper/source/servicemanager.cxx:919:21
> #7 0x7f75b1b2e214 in cppuhelper::WeakComponentImplHelperBase2::dispose() /cppuhelper/source/compbase.cxx:27:5
> #8 0x7f75b1bddd29 in cppuhelper::WeakComponentImplHelper2<com::sun::star::lang::XServiceInfo, com::sun::star::lang::XMultiServiceFactory, com::sun::star::lang::XMultiComponentFactory, com::sun::star::container::XSet, com::sun::star::container::XContentEnumerationAccess, com::sun::star::beans::XPropertySet, com::sun::star::beans::XPropertySetInfo, com::sun::star::lang::XEventListener, com::sun::star::lang::XInitialization>::dispose() /cppuhelper/inc/compbase2.hxx:87:39
> #9 0x7f75b1b80810 in cppu::try_dispose(std::unique_lock<std::mutex>&, com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&) /cppuhelper/source/component_context.cxx:66:16
> #10 0x7f75b1b69605 in cppu::(anonymous namespace)::ComponentContext::disposing(std::unique_lock<std::mutex>&) /cppuhelper/source/component_context.cxx:430:5
> #11 0x7f75b1b2e214 in cppuhelper::WeakComponentImplHelperBase2::dispose() /cppuhelper/source/compbase.cxx:27:5
> #12 0x7f75b1b9c669 in cppuhelper::WeakComponentImplHelper2<com::sun::star::uno::XComponentContext, com::sun::star::container::XNameContainer>::dispose() /cppuhelper/inc/compbase2.hxx:87:39
> #13 0x7f75a719ea7c in (anonymous namespace)::Hook::deinitHook((anonymous namespace)::Hook*, LinkParamNone*) /test/source/setupvcl.cxx:67:46
> #14 0x7f75a719df94 in (anonymous namespace)::Hook::LinkStubdeinitHook(void*, LinkParamNone*) /test/source/setupvcl.cxx:37:1
> #15 0x7f7597d6104d in Link<LinkParamNone*, void>::Call(LinkParamNone*) const /include/tools/link.hxx:105:45
> #16 0x7f759b87c56e in DeInitVCL() /vcl/source/app/svmain.cxx:532:35
> #17 0x7f75bb739454 in (anonymous namespace)::Protector::~Protector() /test/source/vclbootstrapprotector.cxx:29:9
> #18 0x7f75bb739538 in (anonymous namespace)::Protector::~Protector() /test/source/vclbootstrapprotector.cxx:28:35
> #19 0x7f75bb2484f3 in CppUnit::ProtectorChain::pop() (/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.15.so.1+0x2de4f3)
> #20 0x7f75bb2f16ad in CppUnit::TestResult::popProtector() (/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.15.so.1+0x3876ad)
> #21 0x50ac01 in (anonymous namespace)::ProtectedFixtureFunctor::run() const /sal/cppunittester/cppunittester.cxx:337:20
> #22 0x506d13 in main2() /sal/cppunittester/cppunittester.cxx:482:16
> #23 0x50512f in sal_main() /sal/cppunittester/cppunittester.cxx:627:14
> #24 0x504f6e in main /sal/cppunittester/cppunittester.cxx:622:1
(<https://ci.libreoffice.org/job/lo_ubsan/3655/>), reading a member recently
introduced in 04d2a7d2f6 "tdf#167960 The password
of an unknown user is no longer stored", the initial value of which should
presumably be false
Change-Id: Ib46f6f37776688a9853d136adab99263714f0aba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189894
Tested-by: Jenkins
Reviewed-by: Pierre Vacher <prrvchr@gmail.com>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
To resolve this issue, several things were necessary.
- Add a Boolean attribute m_bAskPassword to the data source's Model implementation (i.e., the ModelImpl.hxx file)
- Modify the connectWithCompletion() procedure of the data source (i.e., the datasource.cxx file) that Base calls each time an ODB file is first opened. When opening the connection, it will verify that the connection is indeed made by the user provided by the data source. If this is not the case, the m_bAskPassword attribute of the model will be set to true.
- If this first connection is successful, the DataBaseContext (i.e., the databasecontext.cxx file) will attempt to cache the data source's properties, and if the m_bAskPassword attribute of the model is true, the Password property of the data source will not be cached.
Now if you connect with a user other than the one proposed by default, your password will be constantly requested after disconnecting and reconnecting or until the odb file is saved.
Change-Id: I40960c04fb84604c018374743a735676f556e2b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189732
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The problem was, that the password that got stored as a transient
session-persistent property, could be for one user; but after the
reload, it could be reused for another user, stored in the file.
That resulted in a failed authentication attempt; but since the
password was present, it didn't ask for a new attempt, but failed
the connection.
This change stores the current user name along with the password;
and when loading the document next time, it checks the username
set in the document (i.e., that will be used for logon), and if
it's different from the name used with the stored password, the
password is not reused.
Change-Id: I8f971e641492e3ab93dabfce38d376a06339be3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189828
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
and
cid#1660117 Variable copied when it could be moved
cid#1659985 Variable copied when it could be moved
cid#1659983 Variable copied when it could be moved
cid#1659982 Variable copied when it could be moved
cid#1659973 Variable copied when it could be moved
cid#1659956 Variable copied when it could be moved
cid#1659955 Variable copied when it could be moved
Change-Id: Icc0f2f4a37fa8eb4c874dfd842650067c186466b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189255
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1662041 Variable copied when it could be moved
cid#1662040 Variable copied when it could be moved
cid#1662038 Variable copied when it could be moved
cid#1660211 Variable copied when it could be moved
cid#1660147 Variable copied when it could be moved
cid#1660117 Variable copied when it could be moved
cid#1660071 Variable copied when it could be moved
cid#1660046 Variable copied when it could be moved
cid#1660046 Variable copied when it could be moved
cid#1659985 Variable copied when it could be moved
Change-Id: I34627585e593f9de6bfa195ee0617848d9ed6135
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189157
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
and
cid#1660421 Variable copied when it could be moved
cid#1660419 Variable copied when it could be moved
cid#1660416 Variable copied when it could be moved
cid#1660406 Variable copied when it could be moved
cid#1660405 Variable copied when it could be moved
cid#1660403 Variable copied when it could be moved
cid#1660388 Variable copied when it could be moved
cid#1660380 Variable copied when it could be moved
Change-Id: Ic017abb85bb9b3f9fdb962c0862476f40c0953f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188847
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Macros were disabled in Base when calls to macros were detected in
the Base document - since the document is not signed.
However, Base does not support document signatures at this stage.
So relax that requirement to require a signed document when detecting
calls to signed macros from an unsigned document - at least for Base.
Change-Id: I129f3ffb2607a1c5eebf4795fcd1638c206aea22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188458
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
I checked that this is where I saw Base open DatabaseMetData.getColumnVersion() as many times as there are columns in the ResultSet and never close them.
Change-Id: I4aa371dc08826d864718285588a685a799eca607
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187901
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
It is not possible to use the css.sdbcx.XRowLocate interface in
ResultSets because Base, in order to ensure that this ResultSet
is editable, performs cancelRowUpdates() when the cursor is on
the insertion row.
Change-Id: I4624623754c40dbef1f83b4d6498db17f996c65e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187567
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Switch all callers to use the other variant that
takes const OUString&, which the now dropped variant
was also calling internally.
Change-Id: If7d2861dc570744444f25b8124cc04781d7772d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185536
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
we can use unotools::WeakReference instead of untyped
WeakReferenceHelper.
Also rename the field to something more obvious
Change-Id: Iff674893ec0c3144830c46d1745c920f910d6067
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182458
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
found by a little plugin I created.
Plugin parked into store/ folder because it needs hand-holding
when run.
Change-Id: I2b4da7378f0becbc5f020ac9e78cd765aa0119b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181768
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
...that is not inline, so that RTTI and vtable are not emitted for each dynamic
library individually. (Where they would be internal on macOS, which could break
optimized uses of dynamic_cast for that final class just checking vtable pointer
identity, as could happen for the dynamic_cast at
dbaccess/source/core/dataaccess/documenteventnotifier.cxx:232:51,
> 232 | const DocumentEventHolder& rEventHolder = dynamic_cast< const DocumentEventHolder& >( _rEvent );
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And with the extern explicit template instantiation, EventHolder needs to be
SAL_DLLPUBLIC_TEMPLATE instead of just SAL_DLLPUBLIC_RTTI now, so that
Library_comphelper will export the DocumentEventHolder ctors and
DocumentEventHolder::getEventObject.)
(This would ideally have been caught by an upcoming improvement of
loplugin:dyncastvisibility, but might be complicated to check there for template
instantiations.)
Change-Id: I1e6280b185535968a870fbfadaff6238d38858e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176547
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Andrea Gelmini