Hi!
What are the glitches that you found in the Demo project? Lets fix them.
Well, without any real testing, I have found a few tiny problems:
***
--- IndexFiles.cs (revision 534902)
+++ IndexFiles.cs (working copy)
@@ -78,7 +78,7 @@
writer.Close();
System.DateTime end = System.DateTime.Now;
-
System.Console.Out.WriteLine(end.Millisecond - start.Millisecond + "
total milliseconds");
+ System.Console.Out.WriteLine((end -
start).TotalMilliseconds + " total milliseconds");
}
catch (System.IO.IOException e)
{
--- FileDocument.cs (revision 536850)
+++ FileDocument.cs (working copy)
@@ -53,7 +53,7 @@
// Add the last modified date of the file a field named
"modified". Use
// a field that is indexed (i.e. searchable), but don't
tokenize the field
// into words.
- doc.Add(new Field("modified",
DateTools.TimeToString(f.LastWriteTime.Millisecond,
DateTools.Resolution.MINUTE), Field.Store.YES,
Field.Index.UN_TOKENIZED));
+ doc.Add(new Field("modified",
DateTools.TimeToString(f.LastWriteTime.Ticks,
DateTools.Resolution.MINUTE), Field.Store.YES,
Field.Index.UN_TOKENIZED));
// Add the contents of the file to a field named
"contents". Specify a Reader,
// so that the text of the file is tokenized and indexed,
but not stored.
***
But, in general, I was quite surprised by the behavior of the
searching application with regards to the charset. It forces a
hard-coded character encoding, and it does it in a strange way that
makes it impossible for me to search for accented characters in the
interactive mode. (The batch mode using -queries works fine if the
given file is in ANSI encoding.) So my question is whether the
behavior is taken from the Java version (which I did not test), or if
it is a bug made during conversion to .NET.
Also, the demo IndexHtml isn't working. Do you want to take a look?
Well, I might try to test that.
-- Petr
