IMPORTANT!!: Alarms and Images can be removed from .knt file if it is saved after some actions (see details)

[dpradov]

I have detected and fixed an important bug, which I described below.

Today I will upload a patch. In the meantime, please use extreme caution:

• Maintain backup copies
• Be sure to save any pending changes before executing the File|New action, or any other action that may involve opening a new file by closing the current file.
• If you cancel the File|Close operation, do not end up saving the file (or do it with Save As on another file to be able to recover any text that you have added but not saved yet)

• And also verify if you were affected.
  In my case it happened to me by chance while editing the help file that I am creating, when I accidentally pressed the keyboard shortcut Ctrl+Shift+N (Create a new KeyNote file), having Auto Save=true
  (I have been able to incorporate the changes I made since the last correct copy of the .knt file without any problem)

If you were affected and you have doubts about how to return to a correct situation, you can tell me and I will try to help you.

I have been using the latest versions a lot, at home and at work and it happened to me yesterday for the first time. I trust that in the same way very few people have been affected, and if so, they have backup copies

• Keep in mind that the alarm deletion problem can occur with any older version, not just the newer ones.

Problem detected:

When executing the File|New action, if the current file has modifications and it is saved at this point manually or automatically (by Auto Save), the following will occur:

• The storage mode is set to the default option, but without any conversion that may be necessary.
• As a consequence, when saving the file the generated .knt file will not include the images
• All existing alarms will have been deleted in the saved .knt file.
  Even if the New action is canceled (possible if Auto Save=False), if the file ends up being saved during the session, the same problems described will occur.

=> If this problem has occurred, it would be necessary to resort to a backup copy.
In case of using images external storage, the images contained therein are not affected, so backup copies of the file will use them.
But it is advisable to look at the _LOG.txt file to identify images added after the backup. These images should be removed from storage and subsequently added to the .knt file, which will include them again, since for the rescued KNT version the ID of the next image to be added will be that of the oldest of those last added images.

When executing the File|Open action (using the menu, with the button, or as a result of opening a link to another file),
if the current file has modifications and it is saved at this point manually or automatically (by Auto Save),
the following will occur:

• All existing alarms will have been deleted in the saved .knt file.
  The alarms are deleted from memory even if the Open action is canceled (and the current file is not closed), so if the file ends up being saved during the session, the same problems described will occur: all existing alarms will have been deleted in the saved .knt

=> If this problem has occurred, it would be necessary to resort to a backup copy to consult/recover the lost alarms.

When executing the File|Close action, if the current file has modifications and you cancel the close action,
the same problems described for File|New action will occur if the file ends up being saved during the session.
=> If this problem has occurred, it would be necessary to resort to a backup copy, as indicated for the incidence with New action.

File|Exit or closing the application is no problem

[dpradov]

To verify if you were affected for this bug:
It is important to check from File | Properties that the image storage mode is correct, both in the last file that we have, and in the backup copy that we are going to recover (if we have been forced to resort to it).
Because it may happen that images are seen on the node from which we were when the problem occurred, but these are embedded in RTF mode (which may cause the file to take up a lot of size). But the rest of the nodes, if they were not selected, will have the content corresponding to the file storage mode, which does not include the content of the images but references to them; If the file has not been saved it will not incorrectly include the list of images (theri metadata), so KeyNote cannot get and display the images for those nodes.
The first thing is to try to recover a recent backup that does not have this problem. If it is very old and we have a lot of updated data in the last file, we must take into account that if we are using external storage mode, the images are still there.

If we see that the file occupies a large size, it may be because the format was changed (due to the indicated error) to Embedded RTF. If that is the case, I would advise changing the format to what it was and trying to save the file with another name (Save As). Any embedded images in the file will be saved in a new folder and the file will return to its normal size.

In the worst case the last file has the final text. It would be enough to add the images that we will have in the external folder. Although we do not see the images in our file, we must see the links to the images (like when we decide to hide them). These links show the name of the file, which we can search in the external folder.

And of course, do not delete any files or backup copies until we are sure that we have finally solved the problem.

Sorry for the inconveniences

[dpradov]

I just uploaded a new version: 1.8.4 .01, which fixes this bug.

[mpradovelasco]

Thank you for the new version!

[Stefanoko]

Great work on relative links and offering both ways, relative to .exe AND relative to the current .knt. The handling makes total sense now and the ">>"-syntax is easy enough.

Also a good idea to include the NoHyp and EncodeName options. I don't use them atm, all my knt-files are tree-type and rtf, and the dialog window and the easy access to it are just too good :-), but it's nice to have those ini-options.

When it comes to favorites in the resource panel, maybe there is chance to have custom font size and BG-color one day? Not just for favorites, but for templates and macros, too.

Thanks for the continuing development and improvements!