[Ann] CintaNotes 2.0 Beta 2/3/4!

[abogawat]

Okay, B3 did the trick for me. Got it running and synchronized with SimpleNote.

[danielson]

Exporting all to html looks good.
Received this error message when trying to export all to xml (probably French accent):

XML parsing failed

XML parsing failed: syntax error (Line: 62, Character: 226)

Reparse document as HTML
Error:
invalid character
Specification:
http://www.w3.org/TR/REC-xml/#NT-Char
59: <sections>
60: <section id="0" num="0" name="Main" color="#005af0" />
61: </sections>
62: <note uid="f3b0dbb8-236c-47be-b8b8-63978b0499dc" title="Biscuits d'avoine" created="20121215T082122" modified="20121215T082151" source="outlook.exe" link="" tags="recipes" section="0" plainText="1"><![CDATA[2 tasses cassonade\0B3/4 tasse d'huile de soya \0B2 oeufs (gros)\0B1 tasse de jus de cerises ou de lait\0B1 c.à thé cannelle\0B1 c.à thé clou de girofle moulu\0B1 c.à thé muscade moulue\0B1 c.à thé épices mélangées (all spice) ou piments\0B2 tasses de farine de blé entier à pain \0B1 tasse de gruau ou farine de sarrasin\0B1 tasse de noix de coco\0B1 tasse de lait en poudre (si vous avez pas de lait en poudre n'ajoutez pas de liquide)\0B1 tasse de noix de coco râpé\0B1 tasse raisins secs lavées et asséchées et versés dans la farine\0B1 tasse de morceaux de dattes coupés en deux\0B\0BMêlez l'un après l'autre les ingrédient dans l'ordre indiqué en battant d'abord les oeufs dans le mélange d'huile et de cassonade.\0BTamisez la farine, le lait en poudre et la poudre à pâte, les épices etc. \0Bmêlez en battant bien.\0BÉtendre par cuillerées sur une tôle graissée légèrement.\0BMettre au four 15 min. à 325 ou 350.\0B\0BLa pâte est épaisse, c'est normal et c'est bien ainsi.]]></note>

[paulobrabo]

Okay, B3 did the trick for me. Got it running and synchronized with SimpleNote.

Same here!

I'm quite excited about this... I see myself purchasing a license real soon

[Thomas Lohrum]

Alex,

as already reported there is a bug with clipping. I am able to reproduce now. I used beta 3 for the test.

Steps to reproduce:

• open an editor, edit and select some text
• copy to clipboard and create a new note using Ctrl+F12
• edit the title
• modify the creation-date using Alt+Enter
• delete some lines from the beginning of the text
• assign Tags, e.g. "iphone apps"
• save note using Ctrl+S
• press ESC

Bang. There we go.
class db::DatabaseException
SQLite Error 19:
column uid is not unique

When you confirm the error dialog, more errors will be displayed. The process hangs and you have to kill it with the task manager.

I'll provide the debug.log by email.

Thomas

[danielson]

Hope to see some timing options on SN sync.
Automatic set to every 5 min. would be nice.

[Mark S.]

I don't know how to reproduce it (yet), but I've seen the old "disappearing tag trick" bug again.

Mark
CN2B3

[ChrisCN]

Want to add to the problem not being able to delete a section:
This is definitely position depending. I can move the section around and...
- I can delete the section if it is the last or the second to last one.
- On other positions I get an error

This is still reproducible for me (now on a different machine than yesterday).

[CintaNotes Developer]

add1) 7 sections (including the main one)
add2) third one from left (but doesn't matter) - I can't delete any section
-- CN just crashed after trying to delete the main section
-- I noticed that i CAN delete the last section
add3) maybe
-- but now I restarted CN and still can't delete the sections in the middle
add4) what do you mean?

I will mail the logfiles (don't want the content be shown public)
(I was in debugging mode when CN crashed so this may help even I can't reproduce the crash now)

Still can't reproduce And I haven't received the log files - would you mind sending them again to
jenter@cintanotes.com?
A couple of additional questions:
1) Are you able to reproduce this on a new database?
2) Are you deleting sections via context menu of via Ctrl+shift+del?
3) Could you please also send me your settings file?
Huge thanks!

[ChrisCN]

add1) 7 sections (including the main one)
add2) third one from left (but doesn't matter) - I can't delete any section
-- CN just crashed after trying to delete the main section
-- I noticed that i CAN delete the last section
add3) maybe
-- but now I restarted CN and still can't delete the sections in the middle
add4) what do you mean?

I will mail the logfiles (don't want the content be shown public)
(I was in debugging mode when CN crashed so this may help even I can't reproduce the crash now)

Still can't reproduce And I haven't received the log files - would you mind sending them again to
jenter@cintanotes.com?
A couple of additional questions:
1) Are you able to reproduce this on a new database?
2) Are you deleting sections via context menu of via Ctrl+shift+del?
3) Could you please also send me your settings file?
Huge thanks!

add1) No a new DB is not affected - seems to be a problem with the data-migration to the new db-schema.
add2) context menu
add3) yes - I will send you the logfiles again

Parts of the log...

Code: Select all

9:52:14.805938   10692              app::model::data::traceSql   SELECT COUNT(1) FROM Sections
9:52:14.805938   10692              app::controls::SectionBar::deleteSections   Begin
9:52:14.805938   10692                  app::model::data::traceSql   SELECT COUNT(1) FROM Sections
9:52:14.805938   10692                  app::model::Notebook::getSectionPropertiesByNum   Begin
9:52:14.805938   10692                      app::model::Notebook::getSectionPropertiesByNum   num=[3]
9:52:14.805938   10692                      app::model::data::traceSql   SELECT id FROM Sections WHERE num = 3
9:52:14.805938   10692                      app::model::data::traceSql   SELECT num, name, color FROM Sections WHERE id = 5
9:52:14.805938   10692                  app::model::Notebook::getSectionPropertiesByNum   End
9:52:14.805938   10692                  app::model::data::traceSql   SELECT id FROM Sections WHERE num = 3
9:52:14.805938   10692                  app::model::data::traceSql   SELECT COUNT(1) FROM Notes WHERE sectionid = 5
9:52:14.821538   10692                  app::controls::NotesList::onKillFocus   Begin
9:52:14.821538   10692                  app::controls::NotesList::onKillFocus   End
9:52:14.821538   10692                  app::controls::NotesList::onPaint   Begin
9:52:14.821538   10692                      app::model::Notebook::getSectionPropertiesByNum   Begin
9:52:14.821538   10692                          app::model::Notebook::getSectionPropertiesByNum   num=[3]
9:52:14.821538   10692                          app::model::data::traceSql   SELECT id FROM Sections WHERE num = 3
9:52:14.821538   10692                          app::model::data::traceSql   SELECT num, name, color FROM Sections WHERE id = 5
9:52:14.821538   10692                      app::model::Notebook::getSectionPropertiesByNum   End
9:52:14.821538   10692                      app::model::Notebook::getTotalCount   Begin
9:52:14.821538   10692                          app::model::data::NoteMapper::getTotalNoteCount   Begin
9:52:14.821538   10692                              app::model::data::traceSql   SELECT COUNT(*) FROM Notes;
9:52:14.821538   10692                          app::model::data::NoteMapper::getTotalNoteCount   End
9:52:14.821538   10692                      app::model::Notebook::getTotalCount   End
9:52:14.821538   10692                  app::controls::NotesList::onPaint   End

9:52:16.85547   10692                  app::model::Notebook::deleteSection   Begin
9:52:16.85547   10692                      app::model::Notebook::deleteSection   num=[3]
9:52:16.85547   10692                      app::model::data::traceSql   SELECT COUNT(1) FROM Sections
9:52:16.85547   10692                      app::model::data::traceSql   BEGIN
9:52:16.85547   10692                      app::model::data::SectionMapper::deleteSection   Begin
9:52:16.85547   10692                          app::model::data::traceSql   SELECT COUNT(1) FROM Sections
9:52:16.85547   10692                          app::model::data::traceSql   SELECT id FROM Sections WHERE num = 3
9:52:16.85547   10692                          app::model::data::traceSql   DELETE FROM NotesData WHERE rowid IN (SELECT id FROM Notes WHERE sectionid = 5)
9:52:16.85547   10692                          app::model::data::traceSql   -- SELECT docid,(x.'c0title'),(x.'c1text') FROM 'main'.'NotesData_content' AS x ORDER BY rowid ASC
9:52:16.105547   10692                          app::model::data::traceSql   DELETE FROM NoteCache WHERE noteid IN (SELECT id FROM Notes WHERE sectionid = 5)
9:52:16.105547   10692                          app::model::data::traceSql   DELETE FROM Notes WHERE sectionid = 5
9:52:16.105547   10692                          app::model::data::traceSql   DELETE FROM Sections WHERE id = 5
9:52:16.105547   10692                          app::model::data::traceSql   -- TRIGGER
9:52:16.105547   10692                          app::model::data::traceSql   UPDATE Sections SET num = num-1 WHERE num > 3
9:52:16.105547   10692                          db::DatabaseException::raise   errcode=[19], db.getErrorMessage()=[column num is not unique]
9:52:16.105547   10692                      app::model::data::SectionMapper::deleteSection   End
9:52:16.105547   10692                      app::model::data::traceSql   ROLLBACK

[ChrisCN]

Just found a smaller thing:
If you try to create a new section with a name that already exists -> you get an SQL-error

[CintaNotes Developer]

SN sync working ok so far.
I did sync with one section and then sync with a second section, to same SN account, and got lots of duplication. No problem as not my real data.
But if the guidance is one account per section then it shoud not be so easy to switch the section name that syncs.
Nod

Nod, thanks for the remark. I think we'll add a message when changing synced section, warning that all existing sync data will be deleted and the remote notes will be considered "new".

[ChrisCN]

Just encountered this error...

I created a link from a note and pasted it into Outlook.
When I try to follow this link I get this error.

The link does not contain the right database.

Any idea how this happened? Should I do additional tests (which one)?

[ChrisCN]

I just 'registered the link protocol' again and now it works.

I don't understand why the link protocol registration has something to do with
the database file it is using (or is the error message misleading?)

--------------

I think I can give some additional infos what happened:

1) I installed the preview version 1.9 on machine 1 and did the link protocol registration
2) I installed the Beta version 2 on machine 2 and did a link protocol registration
dropbox synced version 2 to machine 1
3) I started using version 2 on machine 1 without doing an additional link protocol registration
and run in that error.

So I still don't understand why the registration has something to do with the database file used.
And it seems that CN should do this protocol registration on every startup of the app!?

[CintaNotes Developer]

I just 'registered the link protocol' again and now it works.
I don't understand why the link protocol registration has something to do with
the database file it is using (or is the error message misleading?)

Chris, I see in your path 1_9_1! Seems that all your problems stem from the fact
that you've been using a DB from 1.9.1, which is incompatible with 2.0 (see warning in the top message).
Actually, the File MRU list shouldn't contain any databases from 1.9.1 for the links
to work correctly.

[ChrisCN]

I just 'registered the link protocol' again and now it works.
I don't understand why the link protocol registration has something to do with
the database file it is using (or is the error message misleading?)

Chris, I see in your path 1_9_1! Seems that all your problems stem from the fact
that you've been using a DB from 1.9.1, which is incompatible with 2.0 (see warning in the top message).
Actually, the File MRU list shouldn't contain any databases from 1.9.1 for the links
to work correctly.

I have just added additional information in my previous post!
I only have used version 1_9_1 in the past - not today - not while creating the link.
But CN got confused

[CintaNotes Developer]

1) I installed the preview version 1.9 on machine 1 and did the link protocol registration
2) I installed the Beta version 2 on machine 2 and did a link protocol registration
dropbox synced version 2 to machine 1
3) I started using version 2 on machine 1 without doing an additional link protocol registration
and run in that error.
So I still don't understand why the registration has something to do with the database file used.
And it seems that CN should do this protocol registration on every startup of the app!?

DropBox sync just copies the file over, so you've been using a 1.9.1 DB on CN 2.0, which lead to errors.
Please try to reproduce any of the errors while working solely with DBs from 1.8.5 and 2.0.

It would be best to export needed data from 1.9.1 to XML and delete all 1.9.1 DB files (and also 2.0 files
that were previously 1.9.1).

[ChrisCN]

1) I installed the preview version 1.9 on machine 1 and did the link protocol registration
2) I installed the Beta version 2 on machine 2 and did a link protocol registration
dropbox synced version 2 to machine 1
3) I started using version 2 on machine 1 without doing an additional link protocol registration
and run in that error.
So I still don't understand why the registration has something to do with the database file used.
And it seems that CN should do this protocol registration on every startup of the app!?

DropBox sync just copies the file over, so you've been using a 1.9.1 DB on CN 2.0, which lead to errors.
Please try to reproduce any of the errors while working solely with DBs from 1.8.5 and 2.0.

It would be best to export needed data from 1.9.1 to XML and delete all 1.9.1 DB files (and also 2.0 files
that were previously 1.9.1).

No I disagree (or don't understand your point).

I did not use the 1.9.1 DB on CN2.0 (at least not that I am aware of).
I only used the 1.9.1 DB with version 1.9.1 (where I did a 'register link protocol)
and I used the 2.0 DB with CN2.0 (where I did not do an explicit 'register link protocol)
-> and I think this got CN confused

And I still can't understand why this link protocol registration should effect the DB I am using in the link!?

----
I can try to reproduce this in a few hours.

[ChrisCN]

I CAN REPRODUCE THE PROBLEM:

If I open CN version 1.9.1 (with 1.9.1 DB) and start the 'register link protocol'
then close CN version 1.9.1
Then I open CN version 2.0b3 (with a 2.0 DB) and create a link
copy the link into outlook and try to follow this link

... the error occurs

[CintaNotes Developer]

I CAN REPRODUCE THE PROBLEM:

If I open CN version 1.9.1 (with 1.9.1 DB) and start the 'register link protocol'
then close CN version 1.9.1
Then I open CN version 2.0b3 (with a 2.0 DB) and create a link
copy the link into outlook and try to follow this link

... the error occurs

Of course it occurs! 1.9.1 registered itself as a cintanotes:// link handler.
CintaNotes 2.0 does NOT check on start if it is the link handler, and does not try to register itself (otherwise it would
bug the user to run as admin every time).
When you click on a link in Outlook, 1.9.1 gets started (because it has written path to itself in the registry),
handles this request and this leads to error.

Just simply forget about 1.9.1, delete it and all its .db files from everywhere (doing XML backup as necessary), re-register 2.0 with the system and everything will be OK.

I understand this is inconvenient, sorry for that but please mind that 1.9.1 was not a public release, only a small number of people ever had it, and those people have been forewarned about possible future DB incompatibilities.

[ChrisCN]

Of course it occurs! 1.9.1 registered itself as a cintanotes:// link handler.
CintaNotes 2.0 does NOT check on start if it is the link handler, and does not try to register itself (otherwise it would
bug the user to run as admin every time).
When you click on a link in Outlook, 1.9.1 gets started (because it has written path to itself in the registry),
handles this request and this leads to error.

Just simply forget about 1.9.1, delete it and all its .db files from everywhere (doing XML backup as necessary), re-register 2.0 with the system and everything will be OK.

OK understood

What will be the final behavior?
Because this problem will also occur if I move the application to a different folder - or rename the folder and so on.
(We already talked about renaming the db-file and you mentioned that CN will know the new file after opening it).

Shouldn't the final version be similar stable in regards to the CN folder getting a new destination/name (we are still talking about a portable app)?
So if you get rid of the 'run as admin' dialog wouldn't it be a good idea to register on every start?