Wingdings font problem

[Sergey Tkachenko]

As I explained before, the both versions of strings returned by GetItemTextW (new and old) are correct, but the new is more universal. The both of them must be displayed identically with Wingdings font.

I am absolutely sure that the problem is not in GetItemTextW, but somewhere else.

When using *R functions, you must be sure about internal representation of this text - it must be processed differently depending on Unicode property of its text style (RVData.GetRVStyle.TextStyles[Style].Unicode).

Also, when creating item directly, it is very important to include rvioUnicode in Item.ItemOptions, if RVData.GetRVStyle.TextStyles[Style].Unicode=True.

[BernhardRoos]

But what is to do that GetItemTextW returns (in my special report example) the characters 'nnnnn' and not '......'.
At design time in the reportbuilder all is shown correct. But at runtime after this routine has executed instead of 'nnnnn' there is suddently '......' (which shows then in wingdings another character). And this happens after GetItemTextW is called because it returns not the correct character (as it does in the old version) ('nnnnn'). So all what happens after this is, because in sText isn't the correct string, so AllgemeinSetzeMemFelder can't work correctly. GetItemTextW works correct with the most other fonts, only with Wingdings we had this problem (with the newest RV).

So far I see no problems with GetItemTextR and SetItemTextR because I don't change the internal representation but only the text. The internal represenation should be unchanged.

Best wishes
Bernhard

[BernhardRoos]

I have tested a lot of reports from our customer (and there are some very complicated reports with different fonts, tables in tables, input fields and so on). All works fine so far. So I think I can live with GetItemTextR and SetItemTextR. For our needs this functions does exactly what I expected.

Best wishes
Bernhard

[Sergey Tkachenko]

I found a problem in my code: RVInsertStringW was not updated to process characters of symbol fonts in Unicode private use area. It will be fixed in the next update.

As for you code with *R functions, it's ok, if you can guarantee that it is not called for text stored in TRichView as Unicode.

[BernhardRoos]

Thanks for the info.

Is this a complicated change in RVInsertStringW? If not, can you please tell me what is to change? So I can change it in the source code of RV and test it with my reports (with the *W functions).

Best wishes
Bernhard

[BernhardRoos]

One further information.
If I'm using GetItemTextA and SetItemTextA it works also fine.
Only GetItemTextW and SetItemTextW has in my reports this problem.
Best wishes
Bernhard

[Sergey Tkachenko]

*A functions are better than *R, but still using Unicode is preferable.
I sent changed files (after TRichView 14.5.2) to you by email.

[BernhardRoos]

Thanks for the files.
I've installed now RV14.5 and copied the four changed files in the RV folder. Then I've recompiled all packages and my application.
But the problem still exists.
So we can say with the *A functions it works well. With the *W functions there seems be a problem. Probably I can live with the *A functions. The reports which I've tested worked well. But of course I want rather to use the *W functions.

Best wishes
Bernhard

[Sergey Tkachenko]

Please send me a sample document as RVF file. I'll try to see what's wrong.