I'm using the new type=query in a formatted search that return the expected result but a
CALC{"$ROW()"}
at the bottom of this formatted search as usual gives now a bad result though the same works fine with a formatted search of type=regex for example ? This a bit anoying !
--
TWiki:Main/EricCharikane
- 11 Oct 2007
Trying to reproduce the issue here on bugs web.
It would be so much easier for us developers if people would put the failing example in the bug report instead of us spending an hour making a test case.
First a simple regex search
And then a query search. Not looking for the same but with similar formatted table.
Row |
Id |
Summary |
2 |
Item7859 |
Concurrent EditTable Issue broken |
3 |
Item7426 |
EDITTABLE's checkbox type adds blank before comma separator |
4 |
Item7412 |
Customized Comment templatetopics fail in subwebs |
5 |
Item6930 |
tambar value does not change on edit |
6 |
Item6574 |
label format and row spanning breaks table editing |
7 |
Item6344 |
Included Editable Tables do not work as expected if Sections are used |
8 |
Item6343 |
Edit button should refresh page before calculating table contents |
9 |
Item6394 |
Opaque error when EDITTABLE encounters a confusing condition |
10 |
Item6340 |
JSCalendarContribInline conflicts with Edittable date picker |
11 |
Item6299 |
RevCommentPlugin doesn't play nicely with users |
12 |
Item6241 |
EditTable removes extra spacing |
13 |
Item6237 |
header="on" changes header cell contents of working table |
14 |
Item6234 |
EditTable does not properly support headerrows and footerrows |
15 |
Item6225 |
Comment Plugin do not process well verbatim tags. |
16 |
Item6162 |
Comment plugin doesn't know about Compare Revisions |
17 |
Item6008 |
EditTablePlugin returns to viewauth page after save |
18 |
Item6013 |
EDITTABLE breaks TOOLTIP |
19 |
Item6057 |
Comment forrm that updates TWikiForm data fails with version control system error |
20 |
Item6024 |
Can't handle comment templates in subwebs |
21 |
Item6016 |
EditTable almost works with Glue (but fails to save content) |
22 |
Item5913 |
EditTablePlugin does not update label fields upon save |
23 |
Item5146 |
EDITTABLE plays Too nicely with SEARCH |
24 |
Item1133 |
EditTablePlugin does not work in form fields |
25 |
Item5239 |
Solution to editing long tables: Scrollable editable table with fixed header row |
26 |
Item5015 |
EditTablePlugin does not support included tables |
27 |
Item4978 |
Move UserComments to Main |
28 |
Item4423 |
SpreadSheetPlugin calculations do not execute within CommentPlugin templates |
29 |
Item2401 |
CommentPlugin UserCommentsTemplate in webs over-rides TWiki.UserCommentsTemplate |
30 |
Item3499 |
Additional granularty to "ALLOWTOPICCHANGE" |
31 |
31 |
31 |
and now a manual table
Row |
Id |
Summary |
2 |
Item1234 |
Some text |
3 |
Item1234 |
Some text |
4 |
Item1234 |
Some text |
5 |
Item1234 |
Some text |
6 |
Item1234 |
Some text |
7 |
Item1234 |
Some text |
8 |
Item1234 |
Some text |
9 |
9 |
9 |
After some trials and some problems getting things to work I finally managed to get the searches with CALC in the format working. The problem is that the CALC must not be run until the table is created. So we need the search to finish. The usual way to do that is to change the % to $percnt inside the format string. But then the "} is no longer inside a twiki variable and the format string terminates too early. The fix of that is to escape the quotation marks with \" or use $quot.
But no matter what - I see no difference between the query and the regex searches.
So what is the problem?
My guess is you have a plain error in your search string.
Lowering to normal to not list it in release blockers and waiting for feedback. If no feedback is given within a few days we set it to No Action. If the reporter finds the syntax error please give feedback and set to No Action Required.
--
TWiki:Main.KennethLavrsen
- 11 Oct 2007
Dear Kenneth, thank you for the reply and the examples and sorry for this report too lite (and which may not be a bug). But for a new comer like me, it's far from obvious to understand that adding a
%CALC%
somewhere will break a
%CALC%
somewhere else and that you need to rewrite your
Search query
to escape some things.
Here a working example of what drove me here.
This query looks like good
%SEARCH{ " info.date >= '%CALC{"$TIME(2007/06/12)"}%' " web="LitterTray" type="query" nototal="on" topic="Item*" header=" |* Raw *|* Topic *|* Date *| " format=" | | $web.$topic | $date | " }%
see the result (except for the last item which should not be here or may be its special !).
Search:
info.date >= '1181631600'
Now adding a
CALC
inside and at the bottom like yours
%SEARCH{ " info.date >= '%CALC{"$TIME(2007/06/12)"}%' " web="LitterTray" type="query" nototal="on" topic="Item*" header=" |* Raw *|* Topic *|* Date *| " format=" | $percntCALC{\"$ROW()\"}$percnt | $web.$topic | $date | " }%
| %CALC{"$ROW()"}% | | |
and it doesn't work anymore. And I can't figure out what to do to have it works as expected even by trying many way to escape the different things ? I would very appreciate any advise about this behavior.
Search:
info.date >= '1181631600'
Thank you, Best regards,
--
EricCharikane - 12 Oct 2007
Seems related to weather CALC has been running before. If I remove the first calc the 2nd one works. Below I replaced the first CALC with a fixed number.
Search:
info.date >= '1181599200'
This seems like a bug to me. And it has nothing to do with query vs regex.
Changing the header to reflect the real problem.
TWiki variables such as CALC are not expanded inside formatted search if CALC is also used elsewhere on same line
It may have something to do with either the fact that Spreadsheet Plugin is running last - or that it is an old plugin that expands via a regex instead of registring the tag.
Changed the searches to look in LitterTray web to speed up topic loading.
--
TWiki:Main.KennethLavrsen
- 13 Oct 2007
Testing using CALCULATE instead of CALC:
Search:
info.date >= '1181631600'
--
TWiki:Main.PeterThoeny
- 2013-10-18
So this works now. Not sure why the CALC blocks subsequent CLACs. Setting this to "no action required" since it works as expected using CALCULATE.
--
TWiki:Main.PeterThoeny
- 2013-10-18