2.0.3 Bug Report Thread

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

Yep, that shouldn't be - it's been mentioned a few times before but we never seem to remember to fix it when we do an update; I'll put it higher up on the list this time :)
 

TomB

Member
Re: 2.0.3 (final) Bug Report Thread

I've noticed a couple problems with HWR input during flashcard sessions. When auto-recognize is turned on, if you hit the 字 button before the auto-rec time is up, the recognition takes place but then when the auto-rec time expires the character choices disappear (they're really gone, not just invisible - tapping where a choice was doesn't do anything). The other problem is that if you leave the flashcard session (and tell it to save to resume later, if that matters), the HWR character palette in the dictionary mode is sometimes blank. When it's blank if you tap where the character choices should be you see that they are really still there, and then after tapping one the choices get filled in so you can see the previously invisible choices. (I'm using the PalmOS version on a Treo 650. I've got auto-rec set to 3/4s, and the skinny mode of HWR input always visible on the right side in dictionary mode with fullscreen handwriting input)
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

Yeah, looks like the timer isn't being reset properly when the Recognize button is pressed - thanks, should be easy to fix in the next update.
 

TomB

Member
Re: 2.0.3 (final) Bug Report Thread

When viewing simplified characters, entering 著 with HWR input or when copying it to the input field, the displayed entry jumps to 着 instead, presumably because it matches the traditional version. However, zhu4 is still 著 even in simplified characters, so it's confusing to be looking at that entry and then copy the headword to the input field and have it jump to the first match which is a different simplified character.

After playing with it a bit, I realized that when copying the headword from any character to the input field, it always jumps back to the first match, but this case is particularly obvious. It would seem more logical if the displayed entry would remain unchanged when copying the headword to the input field instead of jumping back to the first match.
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

Good note - I suppose it would be best in those cases if we temporarily revealed the traditional-character headword (even if it's normally set to be hidden).
 

TomB

Member
Re: 2.0.3 (final) Bug Report Thread

If my Chinese is good enough, I think there's a typo in the NWP dictionary under the entry for "crash". The example "飞机在山腰坠毁" has pinyin of "shui4hui3" for the final word, but it should be "zhui4hui3"... or is that a valid alternate pronunciation?
 

daniel123

榜眼
Re: 2.0.3 (final) Bug Report Thread

After working with 2.0.3 for some time I have two problems maybe not really bugs, where I think it would be great if possible to fix.

1) The CooTek Touchpal 4.0 keyboard is now the best SIP method for Chinese input I found (for myself). In my opinion it is also the best touchscreen keyboard on WM at all. Also lets me easyily and fast switch between Chinese (hanzi), English and pinyin (and even German) input methods for Pleco. In general it also works great with Pleco. But there is one very useful feature that does not work. I mean using some of its fingerfriendly navigation keys: for example Home and End (for setting the cursor position more quickly) or Select&Copy/Cut&Paste. This make many things that normally need a stylus much more compfortable just using my finger or thumb. For example let me doing cut&paste quite fast without the need of a stylus.
All those keys of Touchpal work great in all my other WM apps. But unfortunately those special keys do not work anywhere in Pleco. Neither could be used in "Edit Card" nor let me cut&paste words or sentences of dictionaries. (To make it clear: all other things of Touchpal work properly in Pleco even up-down-left-right keys.)

I think this could really be a way using Pleco on devices without a stylus like HTC HD2 or similar. This maybe could be a kind of "workaround" until you change the WM interface to be more fingerfriendly (what could take probably many more months).

2) Many of my individual flashcard words have a tailing space. If search for them in Manage Flashcards "pron" I can use "=" to find them even without the need to include the space in the search string. But in search mode "headword" this does not work. I have to add the space at the end or use "~" instead of "=" which finds many more cards I do not want to see. I wonder why the behaviour is different in "pron" and "headword" mode. So I would like to have behaviour of "pron" (ignoring spaces at the end) also for "headword".
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

Thanks for the bug reports. We'll do some testing with Touchpal and see how it's sending those special keys - doesn't seem like it'd be too difficult to detect / handle those messages, unless they use some sort of very non-standard / hackish system for moving the highlight around.

Pron and headword use almost the exact same SQL query structure, so I'm not sure why one of them's ignoring spaces but the other's not - are you sure that the pron sections of the cards actually have trailing spaces? It's possible that the database might be stripping those out of pron fields (in the course of the other sorts of reprocessing it does on the Pinyin) but not out of headword ones.
 

daniel123

榜眼
Re: 2.0.3 (final) Bug Report Thread

Glad to hear that you will check the Touchpal problem. :)

mikelove said:
Pron and headword use almost the exact same SQL query structure, so I'm not sure why one of them's ignoring spaces but the other's not - are you sure that the pron sections of the cards actually have trailing spaces? It's possible that the database might be stripping those out of pron fields (in the course of the other sorts of reprocessing it does on the Pinyin) but not out of headword ones.

You are write. It was my mistake. the pron section have the same problem is there is a trailing space. The search does not find it.

Is there the possibility for you to change the algorithm that it finds the entry even when used if there is a trailing space?
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

That should be possible, yes - we'll look at what we can do with that query for 2.1.
 

ben_gb

探花
Re: 2.0.3 (final) Bug Report Thread

I've noticed a problem with custom flashcards....

Basically if the flashcard has a '/' in the headword and pronuciation fields, then the tone colours of everything after the '/' are wrong.

(Basically I am sometimes using this in some situations there are two ways in chinese to say the one thing in English.)

Using other punctuation marks don't seem to have this problem. Unfortunately I've already used '/' quite alot!

Ben
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

The intended usage of / in our own dictionary entries at least is to accommodate multiple character possibilities in the same position in the same word, rather than multiple words - a lot of words can be written in a few different ways (I suppose reflecting the fact that when they started writing down vernacular Chinese it wasn't always 100% clear what the characters were for the now highly-diverged-from-classical-Chinese words). So if you use it in headwords but not in Pinyin, you should see the same Pinyin position / same color applied to the character before and after the /, and continuing on with the next Pinyin syllable after the latter character.

Since I imagine a lot of people have already built flashcards based on it working this way, though, I wouldn't want to change it now - I'm not wild about making it optional either, since that would mean exported / imported flashcard lists could be interpreted differently on different systems depending on how the / processing setting was configured.

If you're not intimidated by doing a little work with SQLite, though, it should actually be pretty easy to manually replace all of the /es in headword / pinyin fields with another character by opening up your flashcard database in a SQLite browser / editor / command prompt and doing a couple of commands; off the top of my head I think it'd be something like:

UPDATE pleco_flash_cards SET hw = REPLACE(hw, '/', ';')

to replace all of the /s in simplified character headwords with ;s, and likewise for althw (traditional character) and pron. (of course this should only be done on a backup copy of your database) If you wanted to apply it only to cards that weren't dictionary linked, you'd add a:

WHERE dictid == -1

to the end of the statement.
 

stisev

进士
Re: 2.0.3 (final) Bug Report Thread

Hi Mike,

Basically,I've confirmed that pleco 2.0.3 does not recognize buttons from the keyboard.

Going to "other button actions" and assigning the Xperia X1's TAB button to "clear" . I get "9" assigned to the box after hitting the TAB button, the screen slightly flashes (letters flash very slightly) but nothing happens.
I have, however, confirmed that the MAIN buttons on Xperia X1's front cover do all work. It's only the ones on the silver keyboard that don't work!

sony-ericsson-xperia-x1-4.jpg
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

OK, makes sense. It may be easiest for us to just try a different fix for this in each 2.0.4 (or 2.1) beta until we hit on the right one - I'm hoping it'll be as simple as using the Windows Mobile API for button control in games, but if that doesn't do it we may have to try some more unorthodox methods.
 

mfcb

状元
Re: 2.0.3 (final) Bug Report Thread

mike ,recently i got the "flashcard db not accessible, please reset phone" a few times, might be related to me starting pleco, immediately opening the reader and some document to read (and when i try to add the first flashcard, the error occurs the first time). when i open a flashcard session before starting the reader, everything is normal... when i start pleco and the reader opens (because of clipboard) i did not observe this (up to now).
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

Hmm... could be another instance of the too-many-data-files-open-at-once WM issue, I suppose... opening that document file right away might be screwing things up somehow. Perhaps we need to find a different way to open files on WM, though we've gone through the relevant code with a fine-toothed comb and haven't found anything the least bit suspicious so far.
 

caesartg

榜眼
Re: 2.0.3 (final) Bug Report Thread

Dear Mike

Not really a bug but thought I'd bring it up as it does seem strange if it is 'by design':

When I'm studying a character in more depth, I often use the 'Compounds' tab of the 'Char info' tool in concert with the Oxford C-E dictionary (to limit vocabulary as much as possible to useful productive language) and cherry-pick some compounds for further study using the 'Popup word' tool. During this pop-up, I would dearly love to be able to click on the Dictionary button (obviously it is 'OX') and browse other definitions of the pop-up word, as I tend to prefer ACE for compound word flashcards and ABC tends to be the best at nouns due to inclusion of measures. However, clicking on the 'OX' button has never done anything. As far as I know, this has always been the case so is this 'by design' as I can't see how it might be taxing on the hardware (after all it's just referencing the word in another dictionary and not performing an extensive search)? Then again, perhaps there's some kind of implementational issue with some device?

Cheers

Ben
 

caesartg

榜眼
Re: 2.0.3 (final) Bug Report Thread

Dear Mike

Again, not sure if you would consider this a 'bug' but it does seem strange.

I think I can recall you saying that you were impressed by ACE's character definitions and I tend to agree (although I think Oxford C-E is also exemplary for this). However, I've had to avoid the ACE for single character flashcard study simply because when testing myself by showing the definition, the character/headword invariably appears before my eyes within the definition, perhaps through an example or compound word. I've tried squinting and ignoring the Chinese text but it's no good and I've reverted to using Oxford C-E for all single-character flashcards. Would it be possible to have the flashcard engine parse the ACE definition and replace the headword with a ~ ? If this doesn't work well, how about limiting the parsing to single character headword entries? I think this would make ACE more useful for flashcard study. I've been using the ACE happily for compound character word flashcards and rarely have the same problem.

Best wishes

Ben
 

mikelove

皇帝
Staff member
Re: 2.0.3 (final) Bug Report Thread

The dictionary switch button doesn't work in Compounds popups yet because the popup definition code was never intended to do the stuff we've ended up doing with it - we really only planned to use it for highlighting / looking up words in dictionary entries and Instant Access, but now we've got it letting you edit input, popping up in flashcard sessions / compounds word lists, etc. It's gotten some minor improvements for the iPhone version that should be enough to get dictionary switches working in compounds word lists in (hopefully) 2.0.4, and then in 2.1 we're planning to merge it with the code for the full-size dictionary view and basically just be spawning another one of those when you go into a popup definition.

With your other issue, I hadn't realized this was this big a problem with single-character definitions but it seems like it should be fixable. As a temporary measure before we get these encoded/fixed in the database, perhaps we can add an option to search for / replace the headword with a ~ in flashcard definitions. It'd be a bit trickier with Pinyin, though, since we wouldn't want to end up hiding other instances of the same Pinyin (that could actually be kind of a giveaway - you'd see a Pinyin syllable masked out for another word that you knew well and be able to guess the Pinyin for the current word based on that).
 
Top