Bug 53920

[Reproducible] with "LibreOffice 3.6.1.2  German UI/Locale [Build-ID:  e29a214] on German WIN7 Home Premium (64bit), I will do some further research tomorrow

The problem does not appear when accessing the cell range via a named range.

I currently only can reproduce the problem for criteria in diffenret sheet, works fine with criteria in the same sheet.

@Reporter:
can you please attach a sample document with some examples "works / works not"?

Created attachment 66064 [details]
A sheet trying combinations of named/unnamed references to same/other sheet.

Also confirming. Marking as NEW and prioritizing.

Normal - Could make it more difficult to create professional quality documents. Raised from minor to normal because it's not consistent (as Rainer has pointed out, if the validity check values are on the same sheet, there is no problem), if a user didn't know this they could end up going round and round trying to figure out how to apply the validity check to a large range of cells or worse, do the validity check one by one

Low - Not a ton of users use validity checks. Only happens under specific circumstances

@Rainer - if you think it deserves different priority, feel free to changes

@Bug Reporter - thanks for reporting this one

code pointers:

ScValidationData is the class that contains the validation information.

Still present in Linux in 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2) and 4.1.0.1 rc

adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details

I would like to attempt this, but I am new to LibreOffice and want to have a better understanding of the code base before assigning this to myself.  Can anyone offer some pointers on getting started?

(In reply to comment #9)
> I would like to attempt this, but I am new to LibreOffice and want to have a
> better understanding of the code base before assigning this to myself.  Can
> anyone offer some pointers on getting started?

so most of the calc specific code is inside sc/

sc is split into 3 parts:

sc/source/core contain mostly the model
sc/source/filter containing mostly the calc specific parts of the filters
sc/source/ui containing the ui related code + some other non model parts

ScValidationData is the main class for the validation feature.

Cell ranges are represented by

ScAddress a single cell address
ScRange a continuous cell range
ScRangeList a list of ScRange
ScMarkData also able to contain multi-selection

Please ask more detailed question if you need more details.

You can use opengrok.libreoffice.org for browsing the Libreoffice source code.

also don't forget that you can jump into the dev IRC channel or email the list to get help :)

Hi,

The bug seems to come from the fact that visible tab is not the initial tab. Some easy workarounds:
- don't use the picker:
   - either use a named reference (as mentioned previously)
   - or type the reference
- after using the picker, click on tab where the cells to be validated are
- apply twice Data > Validity: second time the dialog is pre-filled, you just need to click on OK

It is quite strange because after executing dialog, tab is forced to go back to initial one. See http://opengrok.libreoffice.org/xref/core/sc/source/ui/view/cellsh2.cxx#849
849  short nResult = pDlg->Execute();
850  //When picking Cell Range, other Tab may be switched. Need restore the correct tab
851  pTabViewShell->SetTabNo( nTab );

nTab value is correct. Why it is not enough? What else can be done?

I tried to debug what is happening at closure time after OK click.

in sc/source/ui/view/cellsh2.cxx:928
 pTabViewShell->SetValidation( aData ); 
should copy ValidationData to all selected cells. 
But in sc/source/ui/view/viewfunc.cxx:1092
function ScViewFunc::ApplySelectionPattern(
creates aFuncMark with
 ScMarkData aFuncMark( rViewData.GetMarkData() );
aFuncMark.bMarked should be true but is set to false if visible tab is not where selected cells are (in debugger, forcing it to true avoid the bug).

I tried to force to apply tab modification after sc/source/ui/view/cellsh2.cxx#851
 pTabViewShell->SetTabNo( nTab );
with pTabViewShell->PaintExtras(); but it has no effect.

So I propose to avoid the bug by just switching back tab earlier: at RefButton shrink box closure. In commit 11560, 
https://gerrit.libreoffice.org/#/c/11660/
I propose to:
- switching back tab in ScTPValidationValue::RefInputDonePostHdl 
- remove unnecessary switch back tab in cellsh2.cxx

Laurent Balland-Poirier committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=31432c4469e7e0d05516143533d6b5e0b411dda3

fdo#53920 Switch back tab at RefButton closure time



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.

Laurent Balland-Poirier committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=50eac342603ca08d808f53dc9a32bb9d1dfba372&h=libreoffice-4-3

fdo#53920 Switch back tab at RefButton closure time


It will be available in LibreOffice 4.3.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.

Laurent Balland-Poirier committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8cdb25a38530319e0b08d97d2706ff019797fe08&h=libreoffice-4-2

fdo#53920 Switch back tab at RefButton closure time


It will be available in LibreOffice 4.2.7.

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.

I'll mark this fixed.