I've been using Copernic Desktop Search for several months now and I think it's really a great program, especially as it is free. I've recently tried X1, to see if I'm missing anything, but I decided that for the steep price there's not enough X1 can offer me. This is even more true for the new (beta) version 1.5 of CDS, where a lot of features have been added.
Although things have been extended a lot, there are still a lot of features that are restricted for no apparent reason. Here's my list of things I'd like to see implemented/changed in CDS. In case anybody at Copernic reads this... personally, I'd be willing to pay a price for CDS, it doesn't have to be free. I also have licenses for Agent Professional, Tracker and Summarizer. Just don't make it as expensive as X1 :-)
- Search overall. Why do I always have to specify first which kind of file I'm searching for?
- For Thunderbird, index at least all locally stored folders, including offline folders. I'm using Thunderbird with IMAP, and apart from several weirdly named folders (like "02c67ac5"), I can only select my RSS folders for indexing, nothing else. Some of my IMAP and news group folders are offline folders and could be indexed as such.
- For Outlook, index appointments and notes. I don't use Outlook for mail or contacts, so that support is useless for me.
- Index favourites and history for more than one browser. Who uses just one browser these days? Why does there have to be a restriction to only one browser?
- Indexing of OneNote data. At least this could be added by a custom extractor (I have an upcoming post on that) in the future.
- Indexing of IMAP mail servers.
- Configuration for the allowance of system load. Currently I can't influence when CDS thinks my system's resources are highly used, and therefore stops indexing. There are often very many processes running on my system and CDS stops indexing much too often. Nevertheless, generally the Copernic implementation of unintrusive background indexing works great, compared with X1 again.
I've been using Developer Express components with VS.NET 2005 (beta 1) for a while, but nearly always in forms that I had previously created with VS.NET 2003. Now, suddenly some problems showed up when these old forms were edited, specifically with XtraGrids and XtraEditors on them.
These problems were quite severe, as the VS designer would simply refrain from persisting all properties that are stored in "inner objects" of the main component. This concept is used all over the DX libraries, for example for the Properties property in the XtraEditors library and the Styles and Views properties of the GridControl. A single modification in the designer would trigger recreation of the InitializeComponent method, thereby effectively destroying the form.
The funny (and good) thing about this is that I found the necessary modifications in the source code files already. As far as I know, DX distribute compiled versions for VS.NET 2005 to the customers that need them, and I guess these versions are actually compiled with the modifications enabled. Using the standard distribution, on the other hand, these modifications are not active by default!
What you need to do is this: Add a constant
DXWhidbey to the constant list of the configuration you are compiling for, for all the projects in the DX source code. If you do this within VS, it should look like this (for the Debug configuration):
You can also edit the .csproj file yourself (or use search/replace), in that case the changed line should look like this:
Recompile all the libraries and voilÃ¡: Working persistence in VS.NET 2005.
I was recently trying to find a solution for a problem with code pages in Zope, in conjunction with Structured Text. The basic problem, which is discussed all over the web, is this: the correct code page has to be configured in the running Zope instance to make STX work correctly with "non-US" ASCII characters. If this is not done, there'll be problems with special formatting, because STX can't find the borders of words correctly.
*zaczÄ™Å‚o* should really appear as zaczÄ™Å‚o and **FrÃ¼hstÃ¼ck** as FrÃ¼hstÃ¼ck, they appear as *zaczÄ™Å‚o* and **FrÃ¼hstÃ¼ck**, respectively. Or one of them would work, but not the other, because these two words need different code pages: zaczÄ™Å‚o needs ISO 8859-2 and FrÃ¼hstÃ¼ck needs ISO 8859-1.
The problem is that STX is dependent on the code page configured for the running Zope instance. As there can obviously be only one code page configured at a time, this is a problem when there are pages that need one code page and others that need another one. Two solutions seemed useful, but didn't prove to really work in the end:
- Not using STX. There are other variants of the Structured Text concept, which might not have the same problems. I didn't really check no this because it wasn't an option in my situation; too much text had already been written in STX format over the course of several years and it had been hard enough to have users understand that concept the first time.
- Using Unicode, just like I'm doing in this page, to be able to mix characters from different code pages. I actually tried going this way, but it didn't work. While the Unicode encoding would allow for the characters to be shown correctly by the end users' browsers, the STX implementation still had the same problems as before, parsing the strings when formatting was in use.
In the end, my workaround was simple: I changed the regular expressions in the STX implementation to work with whatever characters there might be between the start and end markers. The original expressions went out of their way to make sure there would only be specific characters, and that was the core of the problem because that character set was the one that would be defined depending on the code page.
For example, the line where the strong marker was searched for looked like this:
expr = re.compile(r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, strongem_punc)).search
I used this expression instead:
expr = re.compile(r'\*\*([^*]+?)\*\*').search
I made similar changes in the places where the em and ul markers are checked. Of course, my changes allow a wider range of characters between the markers than would originally be allowed, which may have its own problems. But the workaround seems to work fine for me, as long as no real fix is available (and there probably won't be because I don't think anyone's really still working on the old STX implementations).
Click here to download a patch file with all changes I made to DocumentClass.py.