Created attachment 94531 [details] Database with a form, where all fields (except one) were set to "Input required" Open the attached database. Open the form "Table_Input_required_GUI_and_SQL". Delete, for example, the value in "Text" – no error appears, no saving is possible. LO seems to hang for the normal user. The dialog for an error ("Input required for filed "Name" ...) appears in all LO-Versions up to LO 4.1.*, doesn't appear since the first LO 4.2.*.
On pc Debian x86-64 with 4.2.4 LO Debian package, I tried to reproduce this but the text displays "0" instead of "Hallo". However with 4.2 sources updated some days ago, I don't have this problem and can't reproduce this. Robert: could you give a try to the prerelease 4.2.5?
The report isn't complete: The dialog appears for everybody, who will use the navigationbar. Most Base-users do not use the navigation-bar. They will change values in a form and switch with tabulator and arrow-key to the next row. With navigationbar and pressing the button for saving the row it works right. But it doesn't work right while using the tabulator or the arrow-keys. I will change the title a little bit.
Created attachment 100684 [details] New database, delete a value, try to save by tabbing through the form Open the form "Table_Input_required_GUI_and_SQL". Remove the word "Hello". Move through the form by using the tabulator or arrow-keys to the next row. No error appears. Works by using the navigationbar. Works with tabulator in all versions before LO 4.2.*
Created attachment 100685 [details] Dialog with Error-Message up to LO 4.1.* - lost since 4.2.* Let me add an information. The dialog for the error-message in 4.1.* and all versions before is translated to German (my first language). It informs normal users where an input is required. The dialog, which appears since 4.2.* when trying to save through the navigationbar is the same dialog, which appears, when you try to save a row directly in the table - not in the form. The message comes from the database. It shows the whole SQL-Code. The translated short dialog is missed since 4.2.*
Sorry for the delay Robert. I could reproduce the pb with master sources updated yesterday. I noticed this on console logs: warn:legacy.osl:5337:1:svx/source/form/formcontrolling.cxx:464: FormControllerHelper::errorOccurred: two errors during one operation? but indeed, no popup error.
According to description, regression. So regression + usability impact, I increase the importance.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=701bbaf93f0d31ae73e94e0cebccb1cfba0e5882 Resolves fdo#75339 : No Error-Dialog appears in specific cases in Base The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan? I'm having a difficulty with yet another subtelty of Reference in treating this bug. Consider this code (file svx/source/form/formcontroller.cxx): 308 bool lcl_isBoundTo( const Reference< XPropertySet >& _rxControlModel, const Reference< XInterface >& _rxNormDBField ) 309 { 310 Reference< XInterface > xNormBoundField( _rxControlModel->getPropertyValue( FM_PROP_BOUNDFIELD ), UNO_QUERY ); 311 return ( xNormBoundField.get() == _rxNormDBField.get() ); 312 } Consider this gdb trace: Breakpoint 5, svxform::(anonymous namespace)::lcl_isBoundTo ( _rxControlModel=uno::Reference to (frm::FormattedFieldColumn *) 0x5f0f128, _rxNormDBField=uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e44a88) at /home/master/src/libreoffice/workdirs/libreoffice-4-4/svx/source/form/formcontroller.cxx:311 (gdb) print xNormBoundField.get() $50 = (dbaccess::ORowSetDataColumn *) 0x2e448d0 (gdb) print _rxNormDBField.get() $51 = (dbaccess::ORowSetDataColumn *) 0x2e448d0 (gdb) print xNormBoundField $52 = uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e448d0 (gdb) print _rxNormDBField $53 = uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e44a88 (gdb) set print pretty off (gdb) set print object off (gdb) print _rxNormDBField.get() $54 = (com::sun::star::uno::XInterface *) 0x2e44a88 (gdb) print xNormBoundField.get() $55 = (com::sun::star::uno::XInterface *) 0x2e448d0 (gdb) finish Run till exit from #0 svxform::(anonymous namespace)::lcl_isBoundTo ( _rxControlModel=uno::Reference to (frm::FormattedFieldColumn *) 0x5f0f128, _rxNormDBField=uno::Reference to (dbaccess::ORowSetDataColumn *) 0x2e44a88) at /home/master/src/libreoffice/workdirs/libreoffice-4-4/svx/source/form/formcontroller.cxx:311 0x00007f88104df38d in svxform::ColumnInfoCache::initializeControls (this=0x2ef9ae0, _rControls=uno::Sequence of length 1 = {...}) at /home/master/src/libreoffice/workdirs/libreoffice-4-4/svx/source/form/formcontroller.cxx:378 Value returned is $56 = false The expectation of the code is that lcl_isBoundTo returns "true", but it returns false. Has something changed in 4.2 (compared to 4.1 and earlier) that breaks this assumption? How can we achieve the effect the code expects? I don't think we can commit to one particular implementation of "Column Model".
Created attachment 101649 [details] compare Reference< XColumn > instead of Reference< XInterface > This patch seems to work. My understanding is that instead of using an ambiguous base, we use a non-ambiguous base and then pointers into the same object are to the same entry in the vtable (because there is only one) instead of the risk of being into different entries for the ambiguous base in the vtable.
Created attachment 101652 [details] compare the references instead of comparing the .get() This patch also works... Aha, this seems to be thanks to special-case code in "inline bool BaseReference::operator == ( XInterface * pInterface ) const" (file include/com/sun/star/uno/Reference.hxx): if (_pInterface == pInterface) return true; try { // only the query to XInterface must return the same pointer if they belong to same objects Reference< XInterface > x1( _pInterface, UNO_QUERY ); Reference< XInterface > x2( pInterface, UNO_QUERY ); return (x1._pInterface == x2._pInterface); } Stephan? Your opinion? Is this patch 100% robust, or should we go with the other patch (comparing XColumn pointers)?
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f8115ce72dad45b82b044d9c8f5c253d0514574d fdo#75339: Substituting XInterface* eq. for object eq. requires queryInterface The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #10) > Stephan? Your opinion? Is this patch 100% robust, or should we go with the > other patch (comparing XColumn pointers)? Oh, sorry, didn't notice you were working on this in parallel with me. Yes, checking UNO object equality is achieved by checking equality of css.uno.XInterface pointers obtained via queryInterface, so your attachment 101652 [details] would work (while attachment 101649 [details] would need not, in general). But I meanwhile pushed a slightly different fix that simply reverts the regression that introduced this problem (the original code at least pretended to be more efficient, by computing the normalized xCol->xColumn XInterface ptr less often---of course at the expense of making the code more error prone to maintenance "improvements," oh my).
(In reply to comment #11) > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=f8115ce72dad45b82b044d9c8f5c253d0514574d > > fdo#75339: Substituting XInterface* eq. for object eq. requires > queryInterface requested backports to libreoffice-4-2 (<https://gerrit.libreoffice.org/#/c/9875/>) and libreoffice-4-3 (<https://gerrit.libreoffice.org/#/c/9874/>)
Lionel: just to be sure and for not making a mistake, are we ok that http://cgit.freedesktop.org/libreoffice/core/commit/?id=701bbaf93f0d31ae73e94e0cebccb1cfba0e5882 still needs to be reverted?
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a07f2fbc482c2644c4a80287b9139585150b30d1&h=libreoffice-4-2 fdo#75339: Substituting XInterface* eq. for object eq. requires queryInterface It will be available in LibreOffice 4.2.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=12167e566c6c27b7bcd43e322f35ed6c799175e8&h=libreoffice-4-3 fdo#75339: Substituting XInterface* eq. for object eq. requires queryInterface It will be available in LibreOffice 4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #14) > Lionel: just to be sure and for not making a mistake, are we ok that > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=701bbaf93f0d31ae73e94e0cebccb1cfba0e5882 still needs to be reverted? Well, unless it fixes scenarios that I did not test, yes, please revert it.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=402e0c0a679dd4da2b1767d959be9aa364c1878d fdo#75339 object comparison by reference, not pointer The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa7b9062f68b1cfdd76ad1987bde5eed170ed6cf Revert "Resolves fdo#75339 : No Error-Dialog appears in specific cases..." The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #17) > (In reply to comment #14) > > Lionel: just to be sure and for not making a mistake, are we ok that > > http://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=701bbaf93f0d31ae73e94e0cebccb1cfba0e5882 still needs to be reverted? > > Well, unless it fixes scenarios that I did not test, yes, please revert it. Done, see http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa7b9062f68b1cfdd76ad1987bde5eed170ed6cf (I reverted too Stephan's commit about include, since it's useless now) Thank you both of you! :)