2.2.12 Bug Report / Feedback Thread

[mikelove]

I think this has got something to do with Guifan. My pleco isn't exactly crashing but when I'm searching through some of the rarer characters in the words section it freezes up *A LOT* either when toggling to Guifan or if Guifan has become the default (since it was the last opened) dictionary (of the words section).

So it's slow but it eventually delivers results? Very odd.

Would it be too much of a problem to have it save more frequently? :\ Then I can return from where I was more easily. This is really because some parts of history is also lost when Pleco is closed normally.

Well that definitely shouldn't be happening - which parts of history are lost that way? In general the goal is to save reasonably often but to make sure we always save before any situation in which our app might be unloaded from memory - that way you get the battery life savings of infrequent writes but are never aware of your history disappearing except on a (hopefully rare) crash.

not sure if it's this version's bug or other, but right now i m looking is there a way to back up everything...including settings, cause i dont even know which setting i've chnaged during the last 3 years and if resetting my settings wont help, it'd b a shame to try to make it as i wanted before when i can just upload the old settings...
anyways...in Settings->Flashcards->Card categories. i have 3 layer/nested category and the name itself (which is long of course being 3 nests)is written under/behind the "Default category" meaning thery r both written in the same space (isnt it breaking some kind of physical law? (-: ). i can read "Default category" which is black, but behind it also the category name in chinese in blue.
if u dont understand, i'll try to let someone else take a pic of that, but right now i m unable to do that.

There's never been a "backup settings" command, though it'd be a good idea - the main worry is compatibility, we have to have a way to validate settings so that they don't conflict with each other or put our app in an instant-crash-on-startup state.

Category names can indeed get truncated in Settings - we're working on it but it's a little fiddly and may take a few releases to get around to fixing.

If you're referring to the mechanical switch on the left side above the +/- buttons, then the position of that switch doesn't matter for either application. I.E., in vibrate mode, I still get voice from both my GPS app and from Pleco. (My GPS app has a software mute switch on their map page.) I don't think they have excessive dead space at the beginning of audio because when I hit their speaker button to repeat or say an instruction it speaks instantly if the BlueTooth is not in its idle mode. Again no need to fix this just for me.

OK, thanks!

I'm on 2.2.12 on my iPhone4S on 6.0. I have a similar crash on looking up components of a character. It's repeatable. 1) Search for 傀儡 de 儡. 2) Select it. 3) Push the zi button. 4) Select the component with the 3 tians. 5) Push the "word" button. The app freezes and finally crashes. It doesn't remember that I was in flashcard mode and starts a new flashcard session.

Yep, looks like the same issue - thanks!

 

[mikelove]

We've now managed to fix the rare character search crashing issue - turns out to relate to our fix for the bug that prevented the sentence breakdown feature from skipping over punctuation correctly. Anyway we'll have it patched soon - thanks to all!

 

[yuvalcho]

There's never been a "backup settings" command, though it'd be a good idea - the main worry is compatibility, we have to have a way to validate settings so that they don't conflict with each other or put our app in an instant-crash-on-startup state.

i m not sure if there has to b a validation, i mean maybe a warning is enough...i m not importing setting to a different version, i just want to change settings and put them back if i dont like the change. think about it that someone wants to make a complete over-whole of the appearance/functionality of Pleco or just trying new things, so now he has to write all the chnages he made if he wants to go back to the original he was using, which is kind of "mafan"

oh, and btw, just did it, and it seems it fixed the problem of not find search with tones...though i have to change so many settings that i even forgot that i made )-:
u know maybe a summary of the settings that were changed from original settings would also help, i mean i really have no clue what i did in the last 3 years.

Category names can indeed get truncated in Settings - we're working on it but it's a little fiddly and may take a few releases to get around to fixing.

frankly it doesnt bother me at all, i just thought you should know, i mean it's such a minor bug, from what i understand it has existed for a while, but it's the first time i've noticed it after a few years...

 

[scykei]

Would it be too much of a problem to have it save more frequently? :\ Then I can return from where I was more easily. This is really because some parts of history is also lost when Pleco is closed normally.

Well that definitely shouldn't be happening - which parts of history are lost that way? In general the goal is to save reasonably often but to make sure we always save before any situation in which our app might be unloaded from memory - that way you get the battery life savings of infrequent writes but are never aware of your history disappearing except on a (hopefully rare) crash.

Every so often it does that when it gets unloaded from memory. Most of the time I won't really notice but it does happen. I also get infrequent random crashes and this makes it a little troublesome to recover to where I was.

Would instant saving really use up a lot of the battery? I mean, just look at how web browsers handle it. Google Chrome on the PC can even restore tabs after crash, occasionally even the cache and the back buttons work too. It would be excellent if Pleco and many layers of pages too.

If it really will be too much of a problem then it's okay. It's just a minor issue I've been having so if you feel that it will definitely cause performance issues then don't bother about it.

 

[mikelove]

i m not sure if there has to b a validation, i mean maybe a warning is enough...i m not importing setting to a different version, i just want to change settings and put them back if i dont like the change. think about it that someone wants to make a complete over-whole of the appearance/functionality of Pleco or just trying new things, so now he has to write all the chnages he made if he wants to go back to the original he was using, which is kind of "mafan"

It's not just a question of different versions, it's also that right now there's code to prevent you from choosing certain combinations of settings - we'd have to rewrite that code to work with imported settings files too if we wanted to allow for export / import. Which we can do, but it's not really a popular enough feature request to make it a priority, particularly when we're about to redo a lot of our settings anyway (and get rid of quite a few of them).

oh, and btw, just did it, and it seems it fixed the problem of not find search with tones...though i have to change so many settings that i even forgot that i made )-:
u know maybe a summary of the settings that were changed from original settings would also help, i mean i really have no clue what i did in the last 3 years.

Great! We already submitted 2.2.13 since we got spooked by the "Containing" search crashes (plus there was a bug related to device IDs that was causing weird and difficult-to-work-around error messages for quite a few OS6 users).

frankly it doesnt bother me at all, i just thought you should know, i mean it's such a minor bug, from what i understand it has existed for a while, but it's the first time i've noticed it after a few years...

No problem! Appreciate the reminder

Every so often it does that when it gets unloaded from memory. Most of the time I won't really notice but it does happen. I also get infrequent random crashes and this makes it a little troublesome to recover to where I was.

Hmm, well then that's something we need to investigate / fix. It might actually relate to exiting Pleco if it's stuck in an infinite loop somewhere - either because of the about-to-be-fixed "Words" bug or some other issue (we've seen a bunch of crash logs lately relating to a problem with unloading the pronunciation database for Apple's Pinyin keyboard, so there may be an OS6 problem here).

Would instant saving really use up a lot of the battery? I mean, just look at how web browsers handle it. Google Chrome on the PC can even restore tabs after crash, occasionally even the cache and the back buttons work too. It would be excellent if Pleco and many layers of pages too.

If it really will be too much of a problem then it's okay. It's just a minor issue I've been having so if you feel that it will definitely cause performance issues then don't bother about it.

It's not that, it's just that I think our efforts would be better spent fixing these edge cases where it's not being saved - the current behavior is a tiny bit better for most users and I think it would be better for all if we could just get it to save reliably on exit.

 

[scykei]

Does 2.2.13 fix the issue with unpacking files with non-unicode characters names?

 

[johnh113]

Dear MIke,

I think someone may have mentioned this already, but it not, I'm having a problem with searches with a tone number at the end. Embedded tone numbers seem to work fine. For instance, if I search for chi3, it comes up with all of the chi1, then all of the chi2 and then chi3 and chi4 rather than going straight to the chi3.

John

 

[mikelove]

Does 2.2.13 fix the issue with unpacking files with non-unicode characters names?

No, didn't quite get that working in time, though we've got it now so we'll include it if we have to pull and resubmit that update (as we'll probably do if we manage to reproduce this tone number bug).

I think someone may have mentioned this already, but it not, I'm having a problem with searches with a tone number at the end. Embedded tone numbers seem to work fine. For instance, if I search for chi3, it comes up with all of the chi1, then all of the chi2 and then chi3 and chi4 rather than going straight to the chi3.

We still haven't managed to reproduce this one - could you let me know the values of all of your settings under Settings / Dictionary / Search Types and Search Results? Also, what model of iPhone are you using?

 

[johnh113]

I think someone may have mentioned this already, but it not, I'm having a problem with searches with a tone number at the end. Embedded tone numbers seem to work fine. For instance, if I search for chi3, it comes up with all of the chi1, then all of the chi2 and then chi3 and chi4 rather than going straight to the chi3.

We still haven't managed to reproduce this one - could you let me know the values of all of your settings under Settings / Dictionary / Search Types and Search Results? Also, what model of iPhone are you using?

Dear Mike,

iPhone 4S, OS 6.0.

Search Types:
Flexible syllable splits: on
Don't allow longer: off
Integrate in E-C searches: on
Integrate in C-E searches: on
Sort by relevance: on
Full-text prefix: #
Keep on clear: off
Single-char wildcard: @
Multi-char wildcard: $
Button inserts multi-char: on

Search Results:
Auto-detect language: enabled
Match length: never
Split incomplete searches: on
Delay before search: none
Sort results by: word length
1-char for 1-char: off
Chinese always results mode: off
Dict search order: From first
Stop on partial match: off
Skip demo dicts: on

John

 

[yuvalcho]

for me resetting pleco fixed it. so for an immediate solution it might work.

 

[mikelove]

for me resetting pleco fixed it. so for an immediate solution it might work.

Yes, that should indeed fix it, though we're still trying to figure out which setting is responsible for the problem - just tried your combination here and that didn't reproduce it, and nothing on any other screen should affect the handling of Pinyin in searches at all.

Also, we went through all of the code changed since 2.2.11 line-by-line and there was nothing that had any chance at all of affecting this - the only change to the search algorithm was the fix for the unable-to-break-down-sentences-with-punctuation bug, which is what caused those crashing issues with "Containing" searches (and for which we've already submitted a fix to Apple, a fix that's actually delaying our "early access" dictionary release a bit since that update also corrects an issue that's preventing some users from purchasing add-ons). So it seems like this has to be something to do with iOS 6, which is very strange indeed.

 

[Maximilian]

Hello Mike,

I use a ipad3 for flashcard testing. After I have updated to IOS 6 some characters are not displayed correctly during flashcard session, in the way that strokes are not displayed correct or even false. For example in the chars/words 这, 八, 漂(亮), 对不(起)。The character in parenthesis shows the error.

Regards

Maximilian

 

[mikelove]

I use a ipad3 for flashcard testing. After I have updated to IOS 6 some characters are not displayed correctly during flashcard session, in the way that strokes are not displayed correct or even false. For example in the chars/words 这, 八, 漂(亮), 对不(起)。The character in parenthesis shows the error.

That's because you're using the wrong character set (simplified versus traditional) - a few releases ago, we updated our software so that it would display characters in the correct style in Taiwan/HK versus the mainland, based on a lot of complaints we'd gotten from users about characters like the ones you mention (though the most complaints actually came from 骨, where the "inner box" is on the bottom left or bottom right corner depending on your region). Anyway, if you tap on the button to toggle between simplified and traditional you should then find that characters display in the way that you're accustomed to.

 

[dcarpent]

Is the character 侧 one of those crashing Pleco? In Flashcards if I highlight that character and then hit the character tab at the top right Pleco freezes. Is this the bug that is already known and now fixed in 2.2.13? I've had more crashes of Pleco since updating to iOS 6 than probably in the previous several years of using the program, which is to say that in the past Pleco had been very stable.

 

[mikelove]

Is the character 侧 one of those crashing Pleco? In Flashcards if I highlight that character and then hit the character tab at the top right Pleco freezes. Is this the bug that is already known and now fixed in 2.2.13? I've had more crashes of Pleco since updating to iOS 6 than probably in the previous several years of using the program, which is to say that in the past Pleco had been very stable.

It happens with lots of them, actually - illustrates the danger of doing unnecessary fixes (in this case one for the failure of the search box sentence breakdown system to work correctly with punctuation, our fix for which is responsible for this Words tab crashing bug) in minor updates as opposed to saving them for major ones that get more thoroughly tested. After the next major update, we're going to try to keep everything on the same code base for a few years, rather than operating with two significantly-different versions of our app at the same time as we're doing now (and have been doing since we started working on Android).

 

[tranxenne]

Hi,
I use Pleco on an iPod 4 and since the last update the lock orientation option seems to be broken. The screen keeps changing orientation whether the option is on or off.
Awesome software nonetheless. I use it all the time.

 

[mikelove]

Hi,
I use Pleco on an iPod 4 and since the last update the lock orientation option seems to be broken. The screen keeps changing orientation whether the option is on or off.
Awesome software nonetheless. I use it all the time.

Actually broken by iOS 6 - fix should be out tomorrow.

 

[tranxenne]

Hi,
I use Pleco on an iPod 4 and since the last update the lock orientation option seems to be broken. The screen keeps changing orientation whether the option is on or off.
Awesome software nonetheless. I use it all the time.

Actually broken by iOS 6 - fix should be out tomorrow.

Glad to hear that. Thanks for the fast reply!

Not a bug per se but a bit of feedback: when looking at the dynamic stroke order (in the "Strokes" tab) I really like to follow the strokes with my finger on the screen. Problem is that quite often a left to right finger stroke will cause the character to shrink, revealing a red 'delete' button. It doesn't happen all the time so I don't know what triggers this option. Is there a way to completely disable it?

 

[mikelove]

Not a bug per se but a bit of feedback: when looking at the dynamic stroke order (in the "Strokes" tab) I really like to follow the strokes with my finger on the screen. Problem is that quite often a left to right finger stroke will cause the character to shrink, revealing a red 'delete' button. It doesn't happen all the time so I don't know what triggers this option. Is there a way to completely disable it?

It should be disabled already - we'll investigate why it's not, thanks. (you're definitely using the latest version, right?)

 

[tranxenne]

Not a bug per se but a bit of feedback: when looking at the dynamic stroke order (in the "Strokes" tab) I really like to follow the strokes with my finger on the screen. Problem is that quite often a left to right finger stroke will cause the character to shrink, revealing a red 'delete' button. It doesn't happen all the time so I don't know what triggers this option. Is there a way to completely disable it?

It should be disabled already - we'll investigate why it's not, thanks. (you're definitely using the latest version, right?)

Version 2.2.13, yes.
Strange thing is that, as I said, it doesn't happen all the time but I really can't figure out what triggers the occurrence. When it does happen I hit 'back' then 'strokes' again and more often than not it doesn't happen anymore.