Assistance Request for Transition to Version 22 and Markdown Functionality

[a.mancini]

Hello,

We are currently in the process of transitioning from version 16 to version 22 of our system to leverage the markdown functionality offered in the latest releases. During this transition, I have encountered some challenges that I have been unable to address through the forum and Help resources.
I have a couple of questions regarding our document storage processes that I hope you can provide guidance on:

1. In our system, we store RTF documents generated by the library in a BLOB field in ORACLE. Are the old documents compatible with the new version, or do I need to perform any specific conversions?
2. we stored documents produced by a cxDBmemo (plain text) in a CLOB field. Now, we aim to use the TDBRichviewEdit to save text in markdown format.
However, I haven't been able to find a way to instruct the component to interpret and save data read from the CLOB field as markdown. Can you please assist me with this?

Your support in addressing these queries would be greatly appreciated
Thank you for your time and assistance.
Best regards
Alessandro Mancini

[Sergey Tkachenko]

1. No changes in RTF are required, they are compatible.
2. TDBRichViewEdit does not support Markdown, unless you use OnSaveCustomFormat and OnLoadCustomFormat events. But it's easy to add it.
I can do it today, and send changes to you.

[a.mancini]

thank you for replay

For the second request I implemented this code:


procedure TFormSintesi.EdtSintesiLoadCustomFormat(Sender: TCustomRichView;
Stream: TStream; var DoDefault: Boolean);
begin
EdtSintesi.LoadMarkdownFromStream(Stream,FApplicationInfo.Path.Cache);
DoDefault := False;
end;

procedure TFormSintesi.EdtSintesiSaveCustomFormat(Sender: TCustomRichView;
Stream: TStream; var DoDefault: Boolean);
begin
EdtSintesi.SaveMarkdownToStream(Stream,FApplicationInfo.Path.cache,False);
DoDefault := False;
end;

[Sergey Tkachenko]

Ok, if it works, you can use this solution.
I'd suggest to store images directly inside Markdown code. Include rvmdsoInlineImages in EdtSintesi.MarkdownProperties.SaveOptions.

Potential problems with this solution:
1. No format auto-detection. If you have a database that already contains documents in other formats, you cannot edit it using EdtSintesi.

In the next update, rvdbMarkdown option will be added to TDBRichViewEdit.FieldFormat, to allow saving as markdown.
On loading, the component will try to detect field format by content. If the field does not contain RVF, RTF, DocX, it will load Markdown instead of plain text, it (TDBRichViewEdit.FieldFormat = rvdbMarkdown) or TDBRichViewEdit.AllowMarkdown
(where AllowMarkdown will be a new property)

2. Potential problem with encoding. TRichView always saves Markdown in UTF-8.
In the next update, Markdown saving method will have an optional CodePage parameter (UTF-8 by default).
If you use binary type of field that can contain anything, code page does not matter.
But if you use Unicode text field (WideMemo field type), data must be saved in UTF-16.
In the next update, Markdown will be saved as UTF-16 in WideMemo fields, and using the specified CodePage (UTF-8 by default) otherwise.

If you want, I can send these changes to you before the release.

[a.mancini]

Our software relies on databases containing data spanning up to 20 years. Unfortunately, a complete migration of database fields to WideMemo for Oracle NVARCHAR2 is not feasible due to certain constraints. As a result, we continue to save data using the MEMO function in Delphi, ensuring compatibility through conversion with Oracle's charset (typically 1258).

Now, we are contemplating an approach for handling images within our system. Specifically, we are considering setting up a dedicated table for image storage. The rationale behind this decision is that the field read by EdtSintesi is also displayed in a DevExpress grid (same dataset and field for edtSintesi). However, this grid can potentially contain an extensive number of items, exceeding 1,000,000.

To avoid potential memory issues associated with storing images directly in the EdtSintesi field, we are exploring the option of creating a separate table and saving files to disk only when requested by EdtSintesi.
Suggestions, or alternative approaches you may have encountered in similar situations. Your expertise and insights would be highly valuable in guiding our decision-making process.

thank you if you can send me the updated version

Best regards

[Sergey Tkachenko]

I just sent modified units to you.

As for images, you can use OnSaveImage2 to store images in a table.
You can also use OnSaveCustomFormat event to detect the beginning of saving. In this event, save nothing, but remove all images related to the current document from the image table.

[a.mancini]

I have sent you an email with some observations. Thank you for the support."