How does Cintanotes sqlite db identify "worked" files from "halfworked" files?

[Pacerier]

I created a brand new Cintanotes DB, and added some test content.

The content can be found in the sqlite table NotesData_content. But how does Cintanotes identify which are the normal notes and which are the "halfworked" (popup) notes?

(I'm in desperate need to recover some important data and I was hoping to salvage them in the raw sqlite database, anyone with any info on the database structure please share some advice.)

[CintaNotes Developer]

There are no "halfworked" notes. CintaNotes only stores the ids of notes that should be reopened, in cintanotes.settings file.
Your notes were saved when you exited CN or shutdown the PC. But if CN crashed then it is possible that the information was lost. Sorry.

[Pacerier]

I have a dump file which I believed Cintanotes had generated at the point of crash: cintanotes_20170421-1208.dmp

Is there any possible salvageable information within the file cintanotes_20170421-1208.dmp ?

[CintaNotes Developer]

I'm afraid that the dump won't help here. It's not a full memory dump. Sorry.

[Pacerier]

Hi admin, I've got many of such dump files.

What kind of data is stored within the file? I might be able to salvage some clues from it using a reader.

[CintaNotes Developer]

This is a minidump file. It usually contains the general information about execution state. The edited but unsaved information is not there.
Still please send them to me to support@cintanotes.com, I'll analyze them to see if there's anything useful there.

[Pacerier]

It should be possible to observe the dump files to determine if a note is opened or unopened at the point of crash.

What are the variables in which those state are stored?

[CintaNotes Developer]

Well I doubt it will help, but nevertheless - who knows maybe your debugging skills are better than mine and you'll be able to extract
this info from the dump despite the lack of PDB files and it being serously obscured by the Enigma Protector!

Inside of CN, there's a class NoteEditManager that has a collection of NoteEditDialogs.
Each NoteEditDialog has several variables of type Note:

note: represents the most recent state of note (updated from UI controls)
originalNote: represents the note as it was loaded from the database

Each Note has fields:
id - id in the Notes table
uid- global note id, used for sync