
Changes in 1.9.2 .01  (01 apr. 2024)
===================================
 
* Fixed: Nodes not showing cursor position when opening
  The cursor position was being saved correctly but the node was showing position 0 instead of the position where the cursor was
  (Only exception: the first selected node)
  Related to changes in "New: Returning to a node now retrieves the exact position in the editor, including status bar scrolling"
  Ref: #669

* Fixed: Cursor could be not visible on loading if zoom <> 100% and/or alternat. margin was set (also after changing zoom or margins)
   Also improved the initial display of the content when an alternative margin is established, seeking to display directly
   this one already adapted to the margins (and zoom).

* Modified the implementation of "Fix scrollbars" (e.g. to use with Linux-Wine)

  Based on the behavior described in "Linux Wine Compatibility Notes Jan 1st 2024 + Request to see if text area scrollbar glitch 
  can be fixed" (#633), especially in the comment in https://github.com/dpradov/keynote-nf/issues/633#issuecomment-2016696660, it
  seems that a possible solution to this problem could be to ensure that the RichEdit control has focus before starting its update
  (loading the content of the selected node)
  I have reused the existing option (Fix scrollbars), available in Configuration Options...|Advanced (or in the .ini file:
  [KeyOptions] FixScrollBars) for which the existing implementation does not seem to be helping.

  On this occasion what is ensured is that at the time of loading the editor (TKntFolder.DataStreamToEditor) the editor has the focus,
  establishing it if it is not (whenever possible), and returning the focus to the control that had it at the end . All this ensuring
  that the above does not trigger the Editor.OnEnter event.
  It is also ensured that the editor is focused when setting the scrollbar or caret position.

  Among other things, and unlike the previous implementation, this one should not involve any flickering.

  Note: At the moment I have not verified that it actually solves the problem. If the problem continues to persist, I will look for another solution.

- - - - - - 
* Fixed: External storage mode: Images not saved were lost if 'Reload Images' was executed (Ctr+click on Show Images when images are displayed)

  Now 'Reload Images' can be run safely. Images not yet saved will be ignored.
  Also fixed: images can now be reloaded if storage mode is External + EmbeddedKNT (not only in External storage mode)

* Fixed: Images. Max.auto width on insert = -1 was not considering current zoom.
  When inserting images, with Max.auto width on insert = -1 (limit to visible size of editor), the visible
  width of the image could be different than expected, partially truncating its display, as the current zoom
  was not taken into account.
  The same thing happened when executing "Restore Image[s] proportions" in relation to the established zoom

* Fixed: After running "Restore Image Proportions", the editor was displayed at 100% zoom
  Returning to the node showed it again with its current zoom

* New: It is possible to recalculate the ID of the next image to be saved

 	A new button have been included in File|Properties form ("Settings" tab): "Recalc Next ID..."
 	It is enabled only when storage mode is not EmbeddedRTF and file has no modifications
	Can be useful when we have inserted many images in some nodes of a file and later decide to move that nodes
 	(with all the images) to another file, so removing the nodes and images from the source file.
 	(To move the nodes with the images to a another file can be done exporting to a knt file format, for example)
 	This way the counter of next ID will be adjusted to the last available image ID in the file.
 	It looks for the max ID in the image list (so ignoring deleted images).

 	If configured Next ID > 1 + Max ID then it will show the following message:
	 "Max ID in image list is %d and Next ID is %d
 	  Do you want the NEXT image to be saved with ID = %d
	  * YOU MUST MAKE SURE there are no images with larger IDs on the external storage,
	  perhaps referenced by other knt files (New images could override existing files)
	  CONTINUE? "

	If Next ID = 1 + Max ID it will show the following message:
	  "Current Next ID (%d) cannot be reduced
	  (Max ID in image list is %d)"

- - - - - - 
* 2 Fixes to "Normal vs maximum tree width" functionality
  * Could cause keyboard to be ignored temporarily
    Since version 1.9.1, when maximum tree width was set and tree panel had the focus, switching to editor by clicking on
    it (restoring at the same time the tree width) could cause on certain ocassions that keyboard input were ignored until
    we changed focus or click with the mouse in other location of the editor.

  * While editing a node, hovering over the RTF panel will not restore the tree width, and so will not cancel the edition.

* Improvements in "Normal vs maximum tree width" functionality

    - You can prevent hovering over the tree panel from expanding to maximum width by pressing down the Ctrl button
	  one time (while the mouse is over the tree panel). It is not necessary to maintain the Ctrl button pressed
	  all the time.	
    - To disable the maximum tree width:        Ctr+Click in the tree panel
    - To toggle the tree width fixed state (*): Alt+Click in the tree panel

    - Change the width of the tree panel ...
      - without pressing Ctrl or Alt:  normal width will be modified
      - with Ctrl pressed:             maximum width will be set or modified
      - with Alt pressed:              maximum width will be set or modified *and* the fixed state will be activated

    - If the fixed state is active and the tree width is changed without pressing Alt, the normal or maximum width will be
  	  changed *and* the fixed state will be disabled
    - The color of the splitter will highlight the active situation:
      - button face (very light gray) - No maximum width set
      - Light gray                    - Maximum width is set
      - Light blue                    - Maximum width is set, with fixed state (*)
    (*) Note that it is possible to fix the maximum or normal tree width

- - - - - - 
* Changes in Ctrl+Up/Down and Ctrl+Shift+Up/Down shortcuts

	- Ctrl+Shift+Up/Down returns to its default behavior in Word and WordPad:
	 Selects the paragraph above (up) or below (down) the current cursor position. These shortcuts allow for quick selection
	 of entire paragraphs.

	- Added new general editor option, "Ctrl+Up/Down" (in Tools|Configuration options -> General settings|Rich Text editor)
	 It includes three options:
		1- Moves cursor to prev or next paragraph [default]
		2- Shift view one line up or down
		3- Smoothly moves scroll bar vertically

	 First option is the default one in WordPad and Word: Moves the cursor to the beginning of the previous or the next paragraph.

	 Second option is the one currently assigned to Ctrl+Up/Down
	 Third option is the one assigned to Ctrl+Shift+Up/Down in version 1.9.1

	 These two last options doesn't change the cursor(caret) location, as first one does.

	Ref: Paragraph selection and line viewing. #666
- - - 
* Changed the default extensions filtered in Insert | Link to File menu option
  Now defaults to All files (*.*)
  Modified also other extensions offered in other groups
  Ref: Default file type for "Link to File" #670

- - - - - - 
* Fixed: The detection of URLs could be incorrect when other URL prefixes where present
  Example: "https://web.archive.org/web/20171103002946/http://www.s3graphics.com/en/"
  Ref: "URLs with two http:\\ prefixes are partially working" #664

* Fixed: Setting the font size with the Font dialog when using scaling settings > 100% results in a larger font than expected
  There is an issue with TFontDialog in Delphi when using scaling settings other than 100%. This issue can cause the selected font to appear larger than expected.
  The problem lies in how TFontDialog (and, in fact, the underlying Win32 ChooseFont API) handles DPI awareness.
  Ref: #613
- - -
* Fixed: Glossary did not correctly handle the backslash character
  As indicated in "Some issues with the Glossary #671", something like shrug=¯\_(ツ)_/¯ was replaced with ¯_(ツ)_/¯
  It was caused by the expansion performed searching metacharacters as indicated in the help:
  <<Glossary expansion function supports \n and \t metacharacters. "\n" is replaced with a line break, and "\t" is replaced with a tab.
   For example, a string "one\ntwo" will be displayed as
   one
   two
  >>
  The first '\' was being considered only as a special character to be used with \n and \t, that needed to be escaped to be also used
  (¯\\_(ツ)_/¯)
  '\' can now be used normally and \t and \n are still available as metacharacters.
  If we want to use \n (or \t) directly, not replaced with linebrek (or tab), we need to write \\n (or \\t)
- - -
* Fixed: Glossary doesn't display correctly items that include '=' character inside the shortcut
  The '=" is used to separate the Name from the Value (Name = Value). To allow seamless use of that character in the name KeyNote
  now saves that escaped character with the '\' character.

  For example:
  => expands to ⇒

  will be saved as:
  \=>=⇒

  Once loaded the file, KeyNote will replace internally the '=' separator with another non problematic character

  Ref: Some issues with the Glossary #671
- - -
* Fixed: Favorites in Resource Panel need to be refreshed in certain ocassions
 Refs:#631, #655

= = = = =
* Refactoring. Simple notes disappear. Switch to using only Tree-Notes
  - When opening files with simple notes, they are converted to Tree-Notes with a single node initially, and the tree panel hidden
  - From this version when creating a new note (now "Folder", see below) it will be a "Mmultilevel-tree"
    As before, you can keep hidden the tree panel and so the appearence will be identical to old 'Standard Rich text editor'

- - - -
* Change of terminology: Simple notes / Tree Notes + nodes ==> "Folders" with "notes"

  Until now, when talking about documents (always modifiable in the same kind of RichEdit Editor) we will always had to differentiate between
  documents as tree-nodes and documents as simple-notes.
  I myself found it very uncomfortable to talk about nodes and notes, and it also complicated development. Now I stop talking about tree-type
  notes ('multilevel-tree') and simple notes ('standard rich text editor'). And also stop talking about nodes to refer to what we write down,
  since we also do it in notes that do not have nodes... All this forced me to take into account the distinction in many parts of the code.

  Now KeyNote NF starts using simply "notes", in general, which will have a title and other metadata, and "folders" in which notes are grouped.
  Continuing with the current terminology, in essence the current simple notes are nothing more than tree-type notes where there is only one
  node (and without a title) and the tree panel is hidden.
  For compatibility, when opening files with simple notes, they will be converted to 'Tree-Notes' with a single node initially, and the tree
  panel hidden (but can shown, as any other 'tree-note..')

  In this way the behavior will be homogeneous: all notes will be equivalent, whether they are displayed together with other notes in a tree,
  or in any other way. And on any of them it can be implemented tag management or whatever is necessary.
  These folders can perfectly be dynamic, and nothing prevents a note from appearing in several folders.

  So:
   All the data we have in KeyNote NF will reside now in individual "notes". All this notes are grouped in note "folders" (KntFolders)
   Each note in any folder will have relations with other notes, and so any note can have a 'parent' (except "Top" notes), many siblings 
   and many childs. The normal form of representation of this notes will be a hierachical tree, where each "note" corresponds with one "node"
   of the tree. But any other views can be used to show the list of notes of one folder.
