View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0038388 | Lazarus | LCL | public | 2021-01-23 15:25 | 2021-01-26 12:08 |
Reporter | jamie philbrook | Assigned To | Juha Manninen | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Product Version | 2.1 (SVN) | ||||
Summary | 0038388: The TMemo MODIFIED property does not work correctly like TEDIT does, not Delphi compat! | ||||
Description | This is a rehash of another report that looks like has been forgotten, most likely due to the lengthy trail of confusing in the report.. With a TEDIT the Modified property is set if USER makes changes not code when the OnChange event is fired. This allows for code to determine who made the changes. That once was buggy but was fixed however, it never got carried over to the TMemo which is the same as A TEDIT but multiline. Attached is a Patch file that was created from the other post but has seem to gotten ignored, at least I have not seen any traction on it. The patch could be too old, if so I can make one against the current but its a simple two line insertion to use the exiting text feature of the TEDIT since it is part of it. | ||||
Additional Information | This effects all widgets. | ||||
Tags | No tags attached. | ||||
Fixed in Revision | r64420 | ||||
LazTarget | - | ||||
Widgetset | Win32/Win64 | ||||
Attached Files |
|
related to | 0032602 | confirmed | TEdit.OnChange event handler is calling twice for same text | |
related to | 0038009 | resolved | Juha Manninen | TMemo.Modifed/OnChange handling is inconsistent and wrong on Assignments via TMemo.Text := 'aString' |
|
custommemo.inc.patch (460 bytes)
Index: custommemo.inc =================================================================== --- custommemo.inc (revision 64192) +++ custommemo.inc (working copy) @@ -158,7 +158,9 @@ {$ifdef DEBUG_MEMO} debugln('TCustomMemo.RealSetText "',AValue,'"'); {$endif} + fTExtChangedByRealSetText:=True; //Jp Lines.Text := AValue; + fTExtChangedByRealSetText:=False; //Jp end; function TCustomMemo.GetCachedText(var CachedText: TCaption): boolean; |
|
I applied it in r64420. Please test everybody. Does it solve the related issues, too? |
|
Yes,it works.. One note that should be added to the DOCS is the MODIFIED property will retain its value when focusing the Memo until user types or does something but if code makes changes this value will still be present. This is also Delphi compliant because the MODIFIED property only changes when user does something, it is not initiated to False up on entry.. This has to be kept this way in case code wants to force the MODIFIED := True prior to using a Memo.text := ???? in code so they can have the option of handling the event as if the user changed it. Also when changing focus to another control this value is retain so that later checks can be done.. Thank you.. |
|
@jamie: Would the following fill the bill? ======== Please note: The value in the Modified property is not altered when changes are made in code to the text in the control. Modified is only updated when the keyboard or mouse is used to physically change the content in the control. This behavior is Delphi compatible. To recognize when a programmatic change is made, set the value in Modified before calling the code that modifies the value in the memo control. For example: AMemo.Modified := True; AMemo.Append(AString); // or AMemo.Lines.Delete(0); // or AMemo.Lines.Assign(AOtherMemo.Lines); // or AMemo.Lines := AOtherMemo.Lines; // or AMemo.Lines.Text := AString; In addition, the existing value in Modified is retained when the control gains or loses focus whether by keyboard navigation or by a mouse click. ========== |
|
More or less.. The idea is to signal the OnChange event that user has made the change which does that now but if you want code to use the same event process you can simply set the property before hand and the OnChange event will see the that property set when changing content via code.. In most cases this will never be needed because the whole idea is to be able to tell if the OnChange was user edited or code applied. In your example you don't need to even use it actually, just clear it and when ever the Onchange is called and that property is clear then you know it wasn't user edited. but as you have up there like that := True it will basically fake the OnChange call into thinking it was user edited and you can do something different in that case if you wish.. Basically the rest you have is correct... value will be retain unless you change it within the even and the OnChange event still gets called either way if the text is different .. |
|
Resolving this one. |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-01-23 15:25 | jamie philbrook | New Issue | |
2021-01-23 15:25 | jamie philbrook | File Added: custommemo.inc.patch | |
2021-01-23 15:57 | Jesus Reyes | Relationship added | related to 0032602 |
2021-01-23 19:11 | Jesus Reyes | Relationship added | related to 0038009 |
2021-01-25 10:31 | Juha Manninen | Assigned To | => Juha Manninen |
2021-01-25 10:31 | Juha Manninen | Status | new => assigned |
2021-01-25 10:33 | Juha Manninen | Status | assigned => feedback |
2021-01-25 10:33 | Juha Manninen | LazTarget | => - |
2021-01-25 10:33 | Juha Manninen | Note Added: 0128581 | |
2021-01-25 22:52 | jamie philbrook | Note Added: 0128591 | |
2021-01-25 22:52 | jamie philbrook | Status | feedback => assigned |
2021-01-26 02:36 | Don Siders | Note Added: 0128593 | |
2021-01-26 03:24 | jamie philbrook | Note Added: 0128594 | |
2021-01-26 03:29 | jamie philbrook | Note Edited: 0128594 | View Revisions |
2021-01-26 12:08 | Juha Manninen | Status | assigned => resolved |
2021-01-26 12:08 | Juha Manninen | Resolution | open => fixed |
2021-01-26 12:08 | Juha Manninen | Fixed in Revision | => r64420 |
2021-01-26 12:08 | Juha Manninen | Widgetset | Win32/Win64 => Win32/Win64 |
2021-01-26 12:08 | Juha Manninen | Note Added: 0128598 |