search

abhisheknair / keynote-nf

Automatically exported from code.google.com/p/keynote-nf
0 stars 0 forks source link

Search regression with Beta 4 #456

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I've been using 1.7.9.3 Beta 3 with no problem... But when replacing a couple 
of installations with the Beta 4 rar contents, I've found that the Find feature 
from the resource panel (haven't tried other find options), no longer displays 
all search results - quite consistently.

I noticed on an XP system, that there are a series of quick "bings" as Find 
works (suggesting possible errors... tho not sure where to find any possible 
log or output).

Reverting keynote.exe to the Beta 3 version resolves the problem.

I wasn't able to reproduce this with a simple, ah-hoc test knt file, but given 
a couple of existing knt files I have (one compressed, the other encrypted in 
case it matters). 

What steps will reproduce the problem?
1. Upgrade to the 1.7.9.3 Beta 4 release
2. Open an existing knt file that has about 6-10 Notes (tabs) with anywhere 
from 5-20 nested tree nodes in each note.
3. Use Find tab in resource panel
   Options (selected):
    - Search all notes
    - Search hidden nodes
    - Search type: Exact phrase
4. Specify some text with known number of matches.  Examples used: "high sev", 
"updateinstaller", "eclipse"...

What is the expected output? What do you see instead?
Expect to see all note matches, but instead only seeing a small subset 
displayed.  One example: expected 317 matches, but only displayed like 32.  
Another case: expected 3 matches, but returns 1.

What version are you using? On what operating system?
1.7.9.3 Beta4 - on Win7 (64bit) and Win XP.

Please provide any additional information below.

Noticed that when a note is displayed, text in it will be matched, when 
otherwise it might not be.

Fwiw, don't why, but the About info shows 1.7.9.4 Beta 4 (07/01/2013) for some 
reason.

Original issue reported on code.google.com by rikker...@gmail.com on 10 Jan 2013 at 11:41

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hello Daniel,

unfortunately I had to find the above comment seems to be true in more than 
just one single case.

I tested a phrase "lpr_gwy" in an encrypted and quite nested file with 2 hits 
verified.

It was missed in some older versions of KN, but was fixed by you within the 
1.7.x.x family and was working in 1.7.9.3 Beta 3.

In 1.7.9.3 Beta 4 it is missed again completely (0 hits) regardless which 
search method was used (Ctrl+F from within the node that contained the phrase 
or the F9 search panel) and a bing sound is played with some delay.
The phrase is also not marked in my case if the node is displayed.

System used is Windows 8 32 Bit
I will test it on XP next week.

Original comment by stati...@gmx.net on 12 Jan 2013 at 12:34

GoogleCodeExporter commented 9 years ago 
Ok, I will try to reproduce it. Also, I encounter really strange what both of 
you tell about a sound played while find is executing ¿?
Thanks

Rikkertbf, the version is 1.7.9.4 or 1.7.9 Beta 4. When named the .rar file I 
made a mistake and now I can't change it withour removing and uploading it 
again.

Original comment by dpra...@gmail.com on 18 Jan 2013 at 8:20

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hello Daniel,

I managed to prepare a test file for you. (attached _TestSearchRegression - 
cleanedup2.knt)
The encryption has nothing to do with the issue, so I removed it.

The structure reads like:

XXXXX                   scratch
    qms_xxxxx.txt
       Software APPS
          WAN
             OLISNet
                config
       XXXXX.old

The culprit lies within "config"
If this node is positioned before the node that contains the search result it 
prevents a successfull search.
If you move it down to the end of the tree (or if you start the search from 
config marked) everything is fine. 

In short:
When you search "lpr_gwy" from the top of qms_xxxxx.txt you will get a 0 result.
When you search from config (or move config down the tree) you will get 2 
results.

To me it looks like there is a problem with the rtf coding, may be it gets 
somewhat unclean over time.
Generally i observed during the cleanup operation that there are still code 
chunks from deleted nodes in the rtf source that are not shown in KN.

What makes me wonder is: 1.7.9. Beta 3 has no problems with the same rtf code 
whilst 1.7.9.4 obviously has.

Original comment by stati...@gmx.net on 19 Jan 2013 at 11:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Fixed at revision r179

Staticip, your test file have been a great help. 
The problem was caused by a fragment (a letter) of text included in 'config' 
node marked as protected (you can see that RTF appears as: "usual password 
xxxxxx\protect x\protect0 x.")
That isn't correct, but the auxiliar edit control used in the find process was 
not configured to respond on ProtectChange events and, by default, changes 
affecting protected text are discarded. The editors associated to the different 
notes are configured to always allow that changes and so you can easily modify 
that text without problem. But the auxiliar edit control wasn't, never. 
When I began maintaining KeyNote I detected this problem in some rare 
ocassions, but I really didn't find why the auxiliar edit control refused to 
load another stream of data. The solution I found (brute force but worked...) 
was to free and recreate the auxiliar control if, after doing .Clear and before 
loading the stream, the control continued having text. In Beta 4 I have done a 
complete rewritten of the find/search problem and I forgot to include it.
With your example I have found easily the cause of the problem and so, the 
solution have been the correct one.

(The 'bip' sound you mentioned was raised by the edit control when refusing 
changes in protected text, one for each attempt (4 times, four nodes after 
'config'))

Regards

Original comment by dpra...@gmail.com on 26 Jan 2013 at 11:00

GoogleCodeExporter commented 9 years ago 
Thanks, you make me very happy (I hope I can get my dirty fingers on the next 
compiled clean version soon ;-) since I like the reworked optic on the search 
panels result list very much)

As I do not know of any option within KeyNote to set a protection tag I 
researched a little in the meantime and probably found the origin for this 
problem.
the \protect ... \protect0 tag  must have come into KN via a pasted e-mail from 
Outlook that contained this tag already.
I scanned my knt files meanwhile and the test part I sent to you was the only 
one containing this tags.

So in theory one could also manually parse the document from time to time to 
find and remove the offending tags.
But I like your brute force solution more as it is automatic.

KN seems not the only software that has to fight with this problem, there are 
numerous posts around that show that the \protect tag can cause problems in all 
sorts of places.
just one example http://www.devexpress.com/Support/Center/p/B147444.aspx
...
About the protected tag: I am NOT USING IT, I am just allowing my users to 
paste any rtf text they like, they can either type, or copy and paste from 
another source. In the particular case of my unhappy customer he copies and 
pastes an e-mail text from MS Outlook, and that rtf text contains "\protect".
...
same scenario

thanks for the fix (I'm sure this is also the source of search problem that KN 
1.6x was suffering from).

Original comment by stati...@gmx.net on 26 Jan 2013 at 4:06

GoogleCodeExporter commented 9 years ago 
Hello,
The final solution has not been the old 'brute force' but something simpler, 
just to listen to ProtectedChange event and respond allowing it  ;)

Best regards
Daniel

Original comment by dpra...@gmail.com on 26 Jan 2013 at 4:16