hleperlier - sorry about the unexpected expiration, we should probably put a note about that into the download file (or display it on first run) but honestly we thought 2.0 would be done by 8/1. B5 expires on 10/1 for everyone's info. The number of TX problems reported here is I think largely a function of how many people are using TXes - for a "power user" who wants a Palm but doesn't want a smartphone they're pretty much the only option, but having resolved that file corruption issue I don't really think the situation on them is that much worse than on other Palms.
The XML format has changed a bit between B4 and B5, but as long as you're not expecting 100% accuracy, an XML export from B4 should come into B5 reasonably smoothly - you might end up with a few weirdly-named categories but it should be mostly OK aside from that.
marsch - how did it mess up your flashcards? Reproducible or no, file corruption is definitely something we want to know about. Not sure why the once-per-day switch isn't working, we made that optional rather recently (used to be automatic but then we realized some people might not like it). We've seen that extra digits issue one or two other times, actually - probably a lazily-cleared text buffer or something along those lines. You can do an AND filter in Manage Flashcards by going to the Settings screen. (but yeah, the SQL design is pretty straightforward - we'll probably even release some basic documentation on it at some point, at least for the category/card/score areas which people are likely to want to hack away on) I assume from the fact that you were able to edit the SQLite database that you're on Windows Mobile, right?
Send me an e-mail with the new SD card ID and I'll switch your license over to that. (same goes for anybody else who wants to try that out) There's no way to transfer individual scores between files, but if you duplicate a scorefile that would give you a second copy of all of those scores that you could then use for other things - if you don't want scores for cards you're not interested in taking up space, make sure that scorefile's the active one, pull up all of the cards you're not interested in in a Manage result and then reset their statistics. (or just go into the SQLite file and delete any record in that scorefile's table with a card ID that you're not interested in - cards only get score records when they've been reviewed at least once, so it's pretty much always safe to delete score records)
daniel123 - yeah, we've seen quite a few of those neverending loops here too. Resets in general seem significantly less common after the changes we've made in the last few days, though, even on the defective TX... glad to hear the user dictionary's working correctly this time at least. Not sure why the sketch box isn't working correctly - do you see the same behavior with handwriting input or only with sketches? The numbers in pronunciation are getting stripped out because it doesn't want them to be confused with tone numbers - I guess the best solution on that might be to offer the option to export Pinyin with tone marks instead, or just to apply the don't-try-to-clean-up-user-created-entries rule to pronunciation as well as headwords.
The Palm version of Pleco 1.0 is in fact more stable, and to me at least also feels a good bit faster - the biggest reason why we've still been recommending Palm the last few years is because for 1.0 it really is the best platform to run Pleco on. There was also that few-month window in which we had that nasty Windows Mobile 6 crashing bug we couldn't figure out how to fix, steering even more people towards Palm. If we'd done a better job the first time around with Windows Mobile we might have been recommending that instead, but as is, for anyone who wanted to use Pleco before now Palm really was the better bet. Outside of flashcards I still like Palm better than WM in some respects - the resolution on Palm screens (especially Treos) is just right for displaying characters clearly without anti-aliasing, the brighter colors go great with our new headword-coloring feature, Instant Access though slower to start up is noticeably easier to access on Palm than on WM, and as others have pointed out Pleco's interface is still a bit more Palm-like than Windows-like. So I don't feel too bad that we've been recommending Palm all this time, since it legitimately has been the better platform to run Pleco on - we really just should have done a better job of making it clear that that wouldn't necessarily remain the case with Pleco 2.0. But I'm sorry you ended up buying a TX for the sake of 2.0.
The best way to preserve calendar/contact/etc data going between Palm and WM is to sync your Palm with Outlook (if you don't have Outlook, it's included with almost every Pocket PC and almost every Palm includes software to get Palm Desktop syncing with it) - Vista shouldn't be much of a problem. Haven't heard much about these sync issues on iPAQ, in general I like Palm's sync-when-I-tell-you-to model over WM's sync-when-you-feel-like-it but we haven't noticed any specific issues with sync from our iPAQs. (though the 110's scroll down button just recently stopped working, so maybe HP has some of the same quality control problems that Palm does...)
ldolse - oh I do understand that we need to get it to disambiguate better, but it's still largely a free-dictionary-specific issue. The importer actually doesn't assume that any partial match is correct, it just assumes that with a single-character search the first result it gets will always be a single-character entry, something we can guarantee with our own dictionaries but not with Adso. The reason it accepts inaccurate Pinyin matches is because in a lot of cases there's significant disagreement between one dictionary and another about Pinyin, and not even just tones; a lot of flashcard lists also tend to be less-then-perfectly proofread, so we frequently run into Pinyin errors in those. The current algorithm basically checks every entry it finds for both partial and exact matches; if it finds an exact match it uses that (or an ambig prompt if it finds more than one), if it only finds a partial match (i.e. headword is OK but pinyin or traditional characters don't line up) it uses that (or again an ambig prompt if it finds more than one), if it doesn't find any matches it moves on to the next dicitonary.
Rejecting outright any result that doesn't match the length correctly makes sense (though we do need to ignore punctuation marks like ?, because quite a few dictionaries include those in headwords and we don't want them factored into the length in that case), and we should probably also check other dictionaries for exact matches when we only find partial ones from a particular dictionary, but these are both mainly important for people using something other than the default import dictionary order. If you're not using Adso and ABC is your first dictionary then pretty much everything is going to match the ABC and you'll end up with a quite acceptably accurate set of flashcards. So this is why we didn't put too much stress into those two areas for the beta - in hindsight we probably should have waited for the finished version to release Adso at all, since at that point we'll have actually done some testing with it along with the other dictionaries.