John,
In a dialog you have to press CRLF (enter) before the style change.
I have tried to dynamically modify the RTF but without success
FiveTech Support Forums
FiveWin / Harbour / xBase community
Board index FiveWin for Harbour/xHarbour error in Richedit [bug in FWH]
Page: 1 2 (29 posts)
Antonio,
Thanks for reply, but this way is unusable. It should work as Word.
Is it possible to fix it?.
Thanks so much,
FWH 11.11, Harbour 3.1 and Borland C++ 5.82
Antonio,
It worked fine with FW 11.03.
What happened before?.
Please, I need a fix urgent.
Thank you.
FWH 11.11, Harbour 3.1 and Borland C++ 5.82
John,
We have not modified Class TRichEdit neither its C functions lately:
We have not modified Class TRichEdit neither its C functions lately:
John,
If it was working fine in FWH 11.03 that means 30 x 9 = 270 days aprox.
Maybe my changes for:
- Adapting internal\richedit.c to 64 bits (232 days ago)
made the difference.
Are you using Borland ?
Antonio,
Yes, I use BORLAND 5.82.
Thanks.
FWH 11.11, Harbour 3.1 and Borland C++ 5.82
Also, in FW 11.03 I used Harbour 2.x provided by Fivetech (with the installer).
FWH 11.11, Harbour 3.1 and Borland C++ 5.82
John,
The changes that I did only affected Microsoft code, not Borland.
So if it was working fine in 11.03 and now it is not, then it may be the side effect of another change. That will make it harder to locate it to provide a quick fix.
Can't you use a window instead of a dialog ? That would solve it for now...
Antonio,
Thanks, but I can´t use a Window. The Richedit must be in the dialog (in fact, it´s a Folder with several Pages).
The point is why FW 11.11 select all text when issuing a oRtf:Refresh().
FWH 11.11, Harbour 3.1 and Borland C++ 5.82
Antonio, John,
TRichEdit inherits from TControl and TWindow, maybe there has been made some changes since 11.03 causing that behavior.
You could compare the sources to find out what happened.
Just an idea ...
kind regards
Stefan
Stefan
Stephan,
We are going to check from version 11.03 to see what may have caused the difference
Stephan, John,
We have been doing some more tests with the RichEdit control and found that there are different behaviors on it when using it on a window or on a dialog. The tests I have done use pure C language (no Harbour, no FWH).
I plan to publish the tests here for your review, thanks 
Antonio Linares wrote:
I plan to publish the tests here for your review, thanks
Ok
kind regards
Stefan
Stefan
Hi everyone;
If I follow the discussion correctly, then I confirm that I've observed this Trichedit unwanted behavior. The problem can be reproduced with \samples\testrich.prg. Simply change line #32 to this:
Highlight some text and then press the last button (#998). The selected text is set to bold, but immediately after that, all text gets selected (select all).
I did a diff on TRichEdi and could not find any differences dating way back. I think the culprit is TControl. There is a newer method PaintBack() that loos very conspicuous.
Reinaldo.
If I follow the discussion correctly, then I confirm that I've observed this Trichedit unwanted behavior. The problem can be reproduced with \samples\testrich.prg. Simply change line #32 to this:
REDEFINE BUTTON ID 998 ACTION ( oRich:SetBold( .t. ) /*oRich:GoToLine( 10 )*/, oRich:SetFocus() )Highlight some text and then press the last button (#998). The selected text is set to bold, but immediately after that, all text gets selected (select all).
I did a diff on TRichEdi and could not find any differences dating way back. I think the culprit is TControl. There is a newer method PaintBack() that loos very conspicuous.
Reinaldo.
Page: 1 2 (29 posts)