It actually does not override any method in svt::StatusbarController, so there
is no point in keeping it
(cherry picked from commit 83bf5a7b85a0e3430cc807415e081a10a1775f9f)
Conflicts:
dbaccess/source/ui/control/makefile.mk
dbaccess/source/ui/control/statusbarontroller.cxx
dbaccess/source/ui/inc/statusbarontroller.hxx
Change-Id: Id6adc11c3a54f642ebdec9c6016996134908da71
LimitBox set its value to -1 if the current
text is "All" but just when it loses its focus
so dispatching its value to the controller
must be after this setting.
(see limitboxcontroller.cxx)
Plus some clean up in LimitBox.cxx
Change-Id: Ic1d314a5a67c2b261b2e9c50973f51de2bfb8db8
To be honest, I do not userstand the code much. Julien pointed out that
the setParentTitle and onTypeSelected were newer called. The condition
looked like an optimisation and it helped to remove it.
It would be great to put it back. It might be enough to hand the
intial values.
Change-Id: Id06cc9c63a9e578cb3c698c8526851fec71ef9da
Let foo.odb be a database file that has a macro that connects to the
Database on "Open Document" event (and needs to prompt user for
user/password).
There was a race condition between two actions:
1) the asynchronous treatment of "OnFirstControllerConnected" in dbaui::OApplicationController,
which tries to get dbaui::OApplicationController's mutex
2) the StarBasic macro calling dbaui::OApplicationController::connect
which needs to display a dialog (to get username and password),
and thus puts that dialog in the main thread's event queue
and waits for it ... with dbaui::OApplicationController's mutex held
Now, if "1)" is before "2)" in the event queue of the the main thread,
*but* "1)" is executed *after* "2)" has taken the lock, there is a deadlock.
Fix:
1) Make OnFirstControllerConnected synchronous.
Make sure (by taking mutex in dbaui::OApplicationController::attachFrame, its ancestor in the call graph)
that nothing else will happen with the OApplicationController as long as it is not finished.
---> it does not need to take mutex itself anymore
This avoids the "order in the asynchronous events" dependency.
2) Change dbaui::OApplicationController::ensureConnection to do the user prompting
WITHOUT HOLDING the mutex, and use the mutex "only" to protect actually assigning
the connection to m_xDataSourceConnection.
Theoretically, in some race condition, we could connect twice and then discard one connection <shrug>.
ensureConnection will never return the discarded connection, though.
(I think I got that right with respect to http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
This keeps it from locking on another condition while holding the mutex.
Change-Id: Iab1bbec5d5df12bb89d027d43e498c78c92ffc32
Reviewed-on: https://gerrit.libreoffice.org/3310
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Moved portions from module i18npool, all of former i18nisolang1 library
that now is i18nlangtag. Included are languagetag, isolang and mslangid.
This i18nlangtag code is now even used by module comphelper, so
disentangling i18npool and making this an own module was needed to not
create circular module dependencies.
Change-Id: Ib887c3d6dde667403fd22d382310ba5f1a9b0015
