TRichView.com

Hi, i am currently evaluating the RichView-Demo for my company. Therefor i am trying to reimplement all features that are currently working with our old rtf-editor to the ScaleRichView-Editor.

Now i am stuck at this problem:

In the rtf-SourceFiles we are using some Fields like Our old Editor we were able to implement a routine that replaced those #216 with another Text. (Name of the Field / Value of the Field depending on View-Mode).
Currently the TSRichviewEdit just ignories those Fields and does not even.

Is there a way to enable field-support in the Editor or any other suggestions?

If not, another idea would be to preprocess the rtf-data and parse/replace those fields manually.
For example: Scanning for all {\field{\*\fldinst{#xxx}}{\*\fldrslt{}}}, replacing with something like
I wouldn really like this solution, because i would also have to implement "the other" way, as it should be possible to insert Fields to the RTF-File during the editing and those would have to be saved with the #ID.

So i hope i am only missing some setting/function to recognize those fields automatically

Thanks,
Sillicoid

Currently the TSRichviewEdit just ignories those Fields and does not even show anything there.


(Am i to stupid to find the edit-button or isnt there any? )

Currently, only several types of fields are supported (HYPERLINK, SEQ, SYMBOL, NCLUDEPICTURE). For other fields, only a content of \fldrslt is shown.
For mail merging functionality, see http://www.trichview.com/forums/viewtopic.php?t=8
Unfortunately, only *-text* demos can work with RTF fields (not \field, but fields typed directly in text). Other demos use TRichView-specific features, so such documents can be stored only in native TRichView format (RVF).

Hi Sergey.

Thanks for ur answer. If i get you right, the workaround to make this testable for me would now be to preprocess the rtf-data and fill the fldrslt data with what i would like to have displayed. I will try this now. If i do so, is it possible to "lock" the fldrslt string in editor, so that it only can be deleted at once?
How would you suggest to make it possible to add those fields with the currently available features / is it possible to directly work on the rtf-Data in the RichViewEdit?

Assuming we would buy the modules later on, would it then be possible for us to manually add extended support to the fields in the source-code - so is the related source code included? In our case this would be scanning for #[id] and "X=[id]" in the fldinst values.

We already have the routines for that, as we use that method in our actual text-editor overwriting the method that processes the fields/text objects there.

Thanks.

Hi again.

I managed to display the right fieldnames with the mentioned preprocessing and postprocessing. Before i pass the rtf-Data to the RichViewEdit i replace the complete field-tag with the corresponding fieldname like
After i edited the file i do a postprocessing replacing the <[xxx]> with the rtf-code again. So i can use the fields in the TSRichViewEdit and in our old Editor what was the target.

There is only one problem left:
The <Field.Name> text is just normal text now, so in TSRichViewEdit i can edit each char. What i need is some way to combine the Strings like <...> to one block that can only be edited(deleted) at once and perhaps give them another background color.

Any suggestions for that?

After ordering, you receive a full source code, including RTF import and export. However, I do not recommend making changes, because you will have problems in updating.

Our components provide the following protection options for text: http://www.trichview.com/help/idh_tcust ... ction.html
Alternatively, fields can be implemented as a special item type - label: http://www.trichview.com/help/idh_class ... minfo.html (but it does not support line wrapping).

But loading text with protection options (or labels) from RTF is not supported. Without modifying the source code, applying protection options can be implemented only as a postprocessing after RTF loading (but before displaying to the user).

Fine, thanks for the links and the fast replys.

I will have to look into the (2nd) preprocessing then that shouldn be that difficult as i am already doing similar on the post-processing, but i wont be able to try it before Thursday.
But i see upcoming performance issues there as i will have to parse the whole data twice an load and once on save + the parsing that is already done by the component.

Perhaps it would be a good thing for an upcoming version to add some kind of event when importing rtf-data that can be assigned to a function that is called with the fldinst-parameter of each unknown field returning the string to display instead and not just ignore the field.

Well, may be. I think, the most flexible solution would be an event OnRTFField, where a programmer can provide a content that should be inserted in this place as a Stream in RVF format.

Sergey Tkachenko wrote:Well, may be. I think, the most flexible solution would be an event OnRTFField, where a programmer can provide a content that should be inserted in this place as a Stream in RVF format.

Is there anything planned in this issue? Or perhaps an ETA available?

No, I still do not know a good solution.

Event providing an RTF code to insert in place of a field? Not very good, because you will not be able to define a font name or color in this RTF (you do not have access to RTF tables).

A stream with RVF content? Not very good as well, because when generating RVF content, you do not have access to the current font that should be applied to the field result.