[Ann] CintaNotes 2.5 Beta 2

[CintaNotes Developer]

There is a log file, but it is completely empty

I see, thanks. Well maybe you could do the following:
1) Enable logging
2) Backup your current db
3) Restore the db from backup (named "..before upgrade to 2.5")
4) Upgrade DB again and see if this error happens again

Huge thanks in advance!

I use sqlite for the first time - so maybe I am doing something wrong.
Step 1: start sqlite3.exe
Step 2: .open d:\path_to_cintanotes_db\cintanotes.db
Step 3: .tables

There's no .open command, I guess you're using .load?
Also you could try running it like: sqlite3.exe d:\path_to_cintanotes_db\cintanotes.db

[CintaNotes Developer]

Alex, this is really a pain. I wish we could have this in 2.5. How about one of the following two suggestions? Either (a) show the title of the selected note in italic/bold or (b) show the complete preview item using the title's colour.

Thanks for the suggestions, and I totally feel your pain, but I'm afraid a feature freeze is already in effect for 2.5 and with no more exceptions. Otherwise we'll just never release it.
I promise that I'll implement this asap in a 2.6 Beta.

[CintaNotes Developer]

I have checked for Alt+Home/End. It is not used yet. The help file also does not mention it. As Ctrl+Home/End will be used for Remarks, may i ask you to add Alt+Home/End as unique shortcuts for 2.5 final? The shortcuts should be valid to the entire edit dialog and should jump to the beginning/end of the notes text.

Ok, I'll do it, since it's easy and the risk is low. But this is really the last one for 2.5.

[CintaNotes Developer]

You're always welcome to provide a Release Candidate before going public eventually.

Good idea, I'll probably do this. Thanks!

[CintaNotes Developer]

I thought the default empty cintanotes.db was created with two sections, Main and Clips (designated as the target for clipping). I must have created the Clips section myself as an inbox.

I see.. no, there's no such section by default. However it's very easy to set it up.

Sorry, I don't. Just enough to navigate around Japanese or other CJK versions of Windows or some apps, mostly by reading the English accelerator letters after the translations. Yes, I see that 50% of the Jpn translations are not there yet.

Yes, that's the problem with translations, they go outdated very quick.

Yes, I have it now.

Good

These are RightAlt-letter or Ctrl+Alt-letter keys. There might be something trapping the Ctrl or Alt keypress.

Yes, the focus is transferred to the search box only if you hit a plain alphanumeric key, without any modifiers - this is by design.

[CintaNotes Developer]

Alex, thank you very much for including this. I have just realized i had already posted a request http://roadmap.cintanotes.com/topic/260225-tag-sidebar-move-to-topbottom. This is for your information, so the item can be marked as started/completed. Thanks again.

No problem. Thanks for the link!

[CintaNotes Developer]

Alex, I just sent you a PM with some info about two bugs with accented characters. I tried attaching a sample db, but the board rejected all extensions I tried. I finally emailed it to support@cintanotes.com, hoping that this email exists. If not, please let me know how best to send you a sample db.

Yes, I've got it via email, thank you very much. Will get back to you as soon as I have something on the matter.

[CintaNotes Developer]

If the search is restricted to title/text, it works ok and accented and unaccented letters are properly distinguished. The problem is when the search includes the Link field. In that case, the accented char (ē) also matches unaccented versions (e) in the link. If I drop the 'e' in the link, it works ok. The Remark field seems to be working ok.

Thanks for the additional info!

I finally pinned this down. If focus is not in the search box, typing a regular letter moves focus to the search box and enters the letter there. This doesn't happen for accented letters (RightAlt+letter). Focus never changes and the character is ignored. Moving the focus to the search box before typing by clicking in the search box, typing a regular letter or starting with Ctrl-F lets the accented character go in the search string correctly

Yes - this what I've been referring to above. The focus transfer only happens when a single character key is pressed.
I don't see this issue as a grave one, however I've added this to the roadmap: http://roadmap.cintanotes.com/topic/350 ... haracters/

[CintaNotes Developer]

I find that sometimes I miss that a filter is in effect and I'm seeing only a subset of notes.

One idea for an indicator - the line with the search box shows the count ('nn notes') of notes currently displayed on the right end. If you move it over to the left of the search box, it would be right next to the total count for All where you could easily compare it to see if a filtered set of notes was being displayed. The 'nn notes' could even be highlighted (same pale highlight color used for text) if it was a subset.

Gunars

Probably this suggestion could help?
http://roadmap.cintanotes.com/topic/420 ... ction-bar/

[gunars]

Yes, the focus is transferred to the search box only if you hit a plain alphanumeric key, without any modifiers - this is by design.

I'd say the combined Ctrl+Alt modifier should cause the keypress to be treated as an alphanumeric character. Otherwise the help description becomes "enter any character, except for one with accents, to jump to the search box..."

[CintaNotes Developer]

I'd say the combined Ctrl+Alt modifier should cause the keypress to be treated as an alphanumeric character. Otherwise the help description becomes "enter any character, except for one with accents, to jump to the search box..."

That's a bit too specific - I guess that in the world not only Ctrl+Alt is used to enter accented characters.
I strongly suspect that it can be fixed in an easier and more universal way (by handling the WM_UNICHAR message instead of WM_CHAR, if it tells you anything). I've registered it as a bug on the issue tracker.

[gunars]

I'd say the combined Ctrl+Alt modifier should cause the keypress to be treated as an alphanumeric character. Otherwise the help description becomes "enter any character, except for one with accents, to jump to the search box..."

That's a bit too specific - I guess that in the world not only Ctrl+Alt is used to enter accented characters.
I strongly suspect that it can be fixed in an easier and more universal way (by handling the WM_UNICHAR message instead of WM_CHAR, if it tells you anything). I've registered it as a bug on the issue tracker.

The two methods used by Windows, besides the IMEs used for Asian languages, are a) the AltGr+letter we've been talking about and b) the dead key combination (e.g. the '~' key followed sequentially by 'n' = ñ). If you install the English US International keyboard, you'll see it actually uses both methods in the same driver to get different accents. The key sequences for them are described here:

http://www.forlang.wsu.edu/help/keyboards1.asp

For example:

These are produced with dead keys: ` followed by letter = è à ò

These are produced with: RightAlt + letter (or Ctrl + LeftAlt + letter) é á ó

In either case, TranslateMessage will send you a WM_CHAR with the accented character already composed (for dead keys, the WM_CHAR has the combined letter plus accent already, so ignore the WM_DEADKEY). So, the only thing to handle is WM_CHAR as you now do. The dead key characters work just fine in CN to shift focus to the search box.

I suspect that when you're getting a WM_CHAR, you're also checking for Alt or Ctrl being pressed in case they're used by the GUI. If found, you don't shift focus and don't pass on the character to the search box. The only thing needed for this to work properly is to also check for both Ctrl and Alt pressed together - in that case, just pass the WM_CHAR as you would for any other character.

WM_UNICHAR I believe is just the UTF-32 version of WM_CHAR (UTF-16).

Please take this info with caution - it's been a while since I've worked with this stuff.

Gunars

[CintaNotes Developer]

I suspect that when you're getting a WM_CHAR, you're also checking for Alt or Ctrl being pressed in case they're used by the GUI. If found, you don't shift focus and don't pass on the character to the search box. The only thing needed for this to work properly is to also check for both Ctrl and Alt pressed together - in that case, just pass the WM_CHAR as you would for any other character.

Wow, never expected to get such an expert advice! Thanks a lot!
Indeed I was wrong and WM_UNICHAR is not really what we need. You were right about the WM_CHAR handling.
I'll fix this problem in 2.5 final.

[CintaNotes Developer]

Please check out the 2.5 Beta 3 (Release Candidate)