Added more Vocab and Kanji filtering methods

[ghost]

For both kanji and vocab, added filtering by JLPT and WaniKani level. For vocab only, added filtering by category (e.g. na-adjective or sports term).

Also, I (slightly) optimized vocab/kanji/radical searching by using String.Format(...) or StringBuilder instead of repeated string concatenation.

@Doublevil You mentioned in the Readme that you got the WK level data from WaniKani, but how exactly did you get it? I'm asking because (as noted in the commit message) some things that (according to the current database) are not taught on WK are actually taught there. So I'm guessing Houhou is using obsolete data here.

[Doublevil]

Okay so after some trouble with a corrupted database, I got it to work. The problem is, I get exceptions when trying to retrieve SRS items in vocab retrieval requests. It seems to attempt to filter SRS items (in the SRS database) by a column that belongs to some table in the dictionary database. Just starting Houhou triggers the exception for me (it is ignored though, so maybe your exception settings weren't right and you didn't see it?). Can you reproduce it?

[ghost]

It seems there was a part that I forgot to comment out along with the rest of the code for SRS entry filtering. FYI: I actually did notice the exception in the output window when I was working on it the other day, but VS didn't break on the exception, so I kinda lumped it into the same category as FileNotFoundExceptions that happen when using an XmlSerializer (i.e. non-lethal exceptions that are caught).

[ghost]

I just noticed something else off about WK data: some radicals from the WK data set have a different name than they do on WK. For example, in Houhou it's called Emperor, but on WK it's called Mantis. And I know I've seen at least one other, but I can't remember off the top of my head which one that is.

[Doublevil]

Yeah there are differences between WK radicals and the WK radical set in Houhou. Some of the radicals just don't match and there's nothing I can do about it, but there are definitely radicals that could be fixed to match WK better. Now because the system allows you to customize your radical set, I don't consider this a priority at all.

Anyway I'll keep going through your request and probably update WK lists next weekend (it's taking longer than expected).

[ghost]

Earlier today, I decided to give this new version a test run for myself, and I actually noticed quite a severe bug. Filtering vocab by specific combinations of conditions doesn't work; it keeps loading forever. I have found the following combinations to not work:

• Meaning+category
• Meaning+JLPT Level
• Meaning+WK level
• Cat+JLPT
• Cat+WK
• And any combination of those (e.g. meaning+category+reading)

Strangely enough, combining JLPT+WK does work, as does reading+any of them. I'll see if I can fix this before or during the weekend.

Oh, and one other small thing: I updated the changelog to v1.3.0, but the version indicator at the top-right of the main tab still says 1.2.0. Can you change that? (I don't know if 1.3.0 is the version number you want.)

[Doublevil]

I see. Thank you for the heads-up.

1.3.0 is fine, you can update the assembly version of the project and it should automatically reflect on the interface.

Thanks!

[ghost]

By the way, do you think that the new filter section on the Kanji tab is fine where it is (i.e. at the bottom)? Because I was thinking it would probably fit better above the radicals filter section.

[Doublevil]

To be honest I think they need some visual arrangements. And yeah on the kanji screen they probably belong above the radicals.

[ghost]

I agree that the new UI elements aren't ideal; especially with the amount of filters that we have now.

Maybe there should be a single "Filter" button; pressing that applies all filters (as opposed to filtering whenever a single filter condition changes). This command can then still be triggered from the meaning/reading text fields by pressing Enter, but is not automatically triggered when that field loses focus. What do you think?

[Doublevil]

I think it makes sense and it wouldn't harm. Sounds good.

[ghost]

I'm going to be busy for the next three weeks or so, so I don't know if I'll be able to do much about it during that time. I do have a question, though. Is there a specific reason why you decided to display the date as a fixed format "yyyy-MM-dd H:mm:ss"? Because if the user has a different calendar than the Gregorian one (for example, the Japanese calendar), it breaks and Houhou crashes on startup (for example in the Japanese calendar, the 'yyyy' format doesn't exist -- ''gg' is used for the year within the current era).

[Doublevil]

I don’t know, I guess I wanted to control how long it is.

I’m aware of a bug related to date formats but I don’t know where it lies.

Thank you for the specifics on why it crashes, I never got that one. I thought it was using invariant culture when formatting dates in a specified format, but looks like it doesn’t.

[ghost]

I've been able to get around the crash by using a standard format ("FullDateTime") instead of the custom one on line 216 of SrsEntrySelectionActionControl.xaml and line 179 of EditSrsEntryWindow.xaml. Should I push those changes?

If you're talking about how long the date/time is when formatted, I think the text field in the EditSrsEntryWindow is too short to display a date and a time regardless of what format you use.

Actually, this crash is exactly what issue #2 is about. Judging from the name of the person who reported that, they are probably using the Arabic calender, so that would probably mean that anyone not using the Gregorian calendar would face the same problem.

[Doublevil]

Oh yeah that’s fine, thanks a lot.

And yeah it definitely seems to be the problem in issue #2 as well as in a few reports I’ve received.

I suspect it may cause some display issues but in any case, it’s better than crashing.

So yeah, please go ahead and push that too. :)

I’m currently going through your changes btw.

[Doublevil]

Okay. I had some trouble with git (I'm so bad at git) but I finally managed to check it out. The filters may need some rework later (what you are doing with hidden lists and stuff like that is a bit weird, and the controls may benefit from some styling) but I'm fine with the result, so I'm accepting the merge.

Thanks a lot! :+1:

[ghost]

I would have chosen something other than hidden lists (I know it's not the best way to do it and probably more than just a bit weird), but I did it because at the time I needed the sorting to work the same way as in the visible list. Though as you yourself have said before, there are other things that need some rework, too.

Oh, and I thought of another feature that could maybe be added in the future: Vacation Mode (like the one on WK). I guess for now you could get around it batch rescheduling all your SRS items, but that would also affect those that are set to never review or that are suspended, right?

In any case, glad to have been of help. It's helped me, too. I'm a lot more confident now that I can pass the JLPT in December than I was a few weeks ago.