View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002755 | JEDI VCL | 00 JVCL Components | public | 2005-03-14 12:47 | 2007-08-08 09:30 |
| Reporter | anonymous | Assigned To | obones | ||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.00 BETA 2 | ||||
| Target Version | Fixed in Version | ||||
| Summary | 0002755: rtf files with protect tags makes tjvrichedit unable to load files | ||||
| Description | JvRichEdit.pas,v1.62 - JVCL3 RC1 When rtf files with protect tags (\protect\, \protect0\) have been opened, TJvRichEditStrings.DoImport SendMessage(FRichEdit.Handle, EM_STREAMIN, TextType, Longint(@EditStream)) no longer calls the callback function (StreamLoad, via pfnCallBack). | ||||
| Additional Information | This bug also occurs in Borland's TRichEdit control. Sample project attached. Reproduction instructions: 1) Compile & run project. 2) Click load, select PlainRTFFile-1.rtf 3) Load, select PlainRTFFile-2.rtf -notice how the text changes in the richedit control. 4) Load RichEditProtectBug-1.rtf (or RichEditProtectBug-2.rtf). 5) Try to load PlainRTFFile-1.rtf. Notice the lack of change in the richedit control. | ||||
| Tags | No tags attached. | ||||
|
2005-03-14 12:47
|
RichEditBug.zip (2,288 bytes) |
|
|
This is by design (apparently). Add an OnProtectChange or an OnProtectChangeEx handler and set AllowChange to true to change this behaviour. |
|
|
If this is by design then TJvDBRichEdit (and TDBRichEdit, but that's Borland's problem) needs a fix (or two). If a DBRichEdit control hits a field with (an rtf file with) protect tags, the DBRichEdit locks up too. It is then possible to make changes to the DBRichEdit and have it post wrong data back to the field. |
|
|
We can't do anything about the VCL's controls, and our control allows you to work. This is then a non issue. |
|
|
This is still an issue, and you cannot say that crash with protect tags should be default behaviour and that this has to be fixed by providing event's that adjust it back. You provide a workaround, but this should still be fixed. Something like this: function TJvCustomRichEdit.ProtectChange(const Msg: TMessage; StartPos, EndPos: Integer): Boolean; var Bogus: boolean; begin Result := True; Bogus := false; if Assigned(OnProtectChangeEx) then OnProtectChangeEx(Self, Msg, StartPos, EndPos, Bogus) else if Assigned(OnProtectChange) then OnProtectChange(Self, StartPos, EndPos, Bogus); end; Or this, if you want an event to be able to crash this component... function TJvCustomRichEdit.ProtectChange(const Msg: TMessage; StartPos, EndPos: Integer): Boolean; var Bogus: boolean; begin Result := false; if Assigned(OnProtectChangeEx) then OnProtectChangeEx(Self, Msg, StartPos, EndPos, result) else if Assigned(OnProtectChange) then OnProtectChange(Self, StartPos, EndPos, result) else result := true; end; |
|
|
Please get a login and reread what we said. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-03-14 12:47 | anonymous | New Issue | |
| 2005-03-14 12:47 | anonymous | File Added: RichEditBug.zip | |
| 2005-03-14 13:49 | remkobonte | Note Added: 0006706 | |
| 2005-03-15 00:29 | anonymous | Note Added: 0006709 | |
| 2005-05-18 09:33 | obones | Status | new => resolved |
| 2005-05-18 09:33 | obones | Resolution | open => no change required |
| 2005-05-18 09:33 | obones | Assigned To | => obones |
| 2005-05-18 09:33 | obones | Note Added: 0007220 | |
| 2007-08-08 06:47 | anonymous | Status | resolved => feedback |
| 2007-08-08 06:47 | anonymous | Resolution | no change required => reopened |
| 2007-08-08 06:47 | anonymous | Note Added: 0013620 | |
| 2007-08-08 09:30 | obones | Status | feedback => closed |
| 2007-08-08 09:30 | obones | Note Added: 0013621 | |
| 2007-08-08 09:30 | obones | Resolution | reopened => fixed |
