View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0038235 | Lazarus | LCL | public | 2020-12-19 18:06 | 2020-12-30 10:40 |
| Reporter | jamie philbrook | Assigned To | Juha Manninen | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.1 (SVN) | ||||
| Summary | 0038235: Regression, can't delete components placed on a PairSplitter from OI and after many attempts back to locking the IDE again. | ||||
| Description | If you drop a component on a PairSplitter pane and then just go to the OI and attempt to delete it via right click:Delete or just highlight the object on the form. If you attempt to delete there it will at some point lock up the IDE. This was working and I just did a update to 64236 so I assume it has to be near by.. | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | r64254, r64274, r64301 | ||||
| LazTarget | - | ||||
| Widgetset | |||||
| Attached Files |
| ||||
| related to | 0038227 | resolved | Juha Manninen | TPairSplitter has not named properties for left and right side in the OI, crashes the IDE. makes it unusable. |
| related to | 0037434 | resolved | Juha Manninen | Object Inspector TreeView should not show nodes user has hidden - unless a hidden control is selected. |
| related to | 0038239 | closed | Juha Manninen | Items added to collections via context menu are not displayed in object tree |
|
|
Let me clarify here.. I just noticed that all controls are effected , can't delete anything dropped on the form, any attempt will render the IDE useless So I was too quick on picking on that control, its any of them from what I can see. Can't delete them without a mess. |
|
|
I cannot reproduce. I can delete components from the designer and from OI by Delete-key and by Right-Mouse -> Delete (Selection). Try a clean build of Lazarus. It often makes such problems go away. PairSplitter is a weird component. You can select and delete its side panes but the component recreates them. It always behaved like that. From procedure TCustomPairSplitter.RemoveSide : ... // if the user deletes a side at designtime, autocreate a new one if (ComponentState * [csDesigning,csDestroying] = [csDesigning]) and not DesignerDeleting then CreateSides; |
|
|
No, like I said I was quick to picking on that control , its doing it with all of them that I have tried so far I dropped a Tbutton on the form, delete it but if you look in the OI's treeview section up top the button is still there and if you attempt to delete it from there or add another control things start to go wrong If you drop another control on the form after deleting the last control from the form it overwrites the existing Tbutton and replaces it with that now.. if you place your mouse over that heading in the OI and click on it the IDE locks up with an Access Violation I can peal back the revisions but this just happen recently within the last few hours of updates. Since this seems to be all of the controls we need to change the description here because its not the Tpairsplitter. |
|
|
Confirmed here. Delete a control, and it's still in OI component tree. Select anything in the OI component tree and you get an an exception and it aborts. |
|
|
REV 64228 is the start of the problem for the lockup! But for the name of the component still in the OI Tree List after you delete it from the form must of been there for a long time and I never noticed it.. I went back a long ways it was still there but not causing any issues.. starting at 64228 however is the start of the lockups / crashes … because 64227 seems to work without crashes Right click on the component name to use the DELETE from there instead of the DELETE key while focused on the designer form seems to make it blowup sooner. |
|
|
Ok, I can reproduce by placing a component on the PairSplitter. Forget my earlier test. |
|
|
I start with a clean project, drop one button on it, then go over to the OI tree view and right click there, delete it. The Item in the OI will not go away and it may or may not lock at that time but click on that item that is not suppose to be there any longer and you most likely will get the lock Like I said, no locks at 64227, I see in the logs you did some cleanup etc... This problem may have been here for some time now and no one noticed lingering deleted items still in the OI tree view and it may have something to do with it, just hasn't crashed until now. EDIT: going back to 64227 just makes it take longer to lockup, it still does however,, It has something to do with the lingering component in the Tree View of the OI after deletion while it's still there and if you right click on it you don't always get the context menu with the DELETE option with 64227 but keep doing that enough then the context popup menu will show the option to delete and if you delete it the crash takes place. This behaves looks a lot like there is a Application.ProcessMessages taking place in a loop or some sort of sync operation where it should not be. |
|
|
A simple test proves the issue.. Drop a single button on the form and then delete it. the OI tree view still has the entry in the list and interacting with it produces undefined behavior, mostly IDE lookups and nice graphics to go with it at times. Drop many buttons on the form and you can delete any of them and they will go away from the list except the last one. |
|
|
The "last man standing" issue (last control left in object tree after all controls are deleted) was introduced in r64144: "IdeIntf: Remove ComponentCandidate data from ComponentTreeView code. Not used for anything." |
|
|
Please test with r64254. The code for deleting a component was wrong indeed.. TPairSplitter requires special treatment. There already was a boolean in WinControl just for TPairSplitter. I made it an enum flag and added another. Note, as part of recent optimization components are now deleted one by one from the tree. Earlier the whole tree was always rebuilt. If 10 selected components were deleted at one go, the tree was rebuilt 10 times during the process. |
|
|
Better but still broke Drop a TFlowControl on the form :Good; Drop a TButton on the flow control :good; Delete the TButton that was just dropped on the Flow panel: Good; Now go over to the Component List view and click on the caption below the TFolowPanel1 where It shows the Control list, click on the heading there, :BAD Puts it in a loop and locks up, basically it thinks there is still a control there and trying to process it.. if you don't put any child controls on the flow panel and just click on that control list heading, its ok. its only after you have dropped a child control on the flow panel and then delete, the View list must think it's still there ? |
|
|
I also wanted to mention that if you drop a TPSscript on the form from the Pascal Script tab, you can't add any items from the Tree list, the Add item does nothing but you can add them in the main property list and they do show.. However, when deleting them from the View list not all of them get deleted although they show as deleted in the view list but there will still be some in the property items list.. so you have more to work with … Sorry ;) EDIT: This problem seems to be random, it does not always fail so something is floating around unmanaged I guess. EDIT2: it seems if I add and item from the View List it does not show in the list of items for the child plugins. but as soon as I add an item from the Properties list "items" then they all show in the View list, that is all the children plugins.. So they are not synchronizing with each other property. |
|
|
Ok, I will look at it later. In the worst case scenario we must rebuild the tree again after every deletion. It would be unfortunate because the speed optimization was only a side effect of a bigger improvement. See issue 0037434. Deleting only the relevant node keeps the tree's expanded / collapsed state intact. Rebuilding the tree expands all nodes which can be considered an irritating bug in a densely populated form. Another approach would be to keep state information of user collapsed nodes and restore them after the tree was rebuilt. |
|
|
Please test with r64273. TFlowPanel has a Collection ControlList as a sibling of a deleted control. Now it is updated in a generic way. |
|
|
As for the deleting issue I don't see that any more, that has seem to been fixed however, During the test for me to ensure all controls work with the Treeview list I now see if you drop a TUpDown from the Common Controls tab it creates an error indicating a TUpdown1 already exists and does not place it in the form's class but does show on the form and properties list. I don't remember that being there before infact I am sure it wasn't Drop a TUpdown on the form, an empty form that is and you'll get that error. It shows on the form however and the property part of the OI but not inserted in the class or in the ComponentTree . P.S. If you drop another component on the form after the first TupDownButton, then it appears in the component tree and Class and seems to work but each time you add a TupDownButton to the form it will generate that message and not be visible until you add another control or maybe do something that refreshes the OI |
|
|
You are good in testing my changes! The bug you spotted in TUpDown was created already earlier in r64225. It should be fixed now. Please test with r64274. |
|
|
You have fixed the updown… Now the TPSscript on the Pascal Script tab drop one on the form. Add a Plugin.. There are two issues I see here 1. It does not give you a choice of selecting a plug in that you may already have sitting on the form, it creates a NIL plug in.. 2. You can assign a plug in you have on the form. Drop a plugin in on the form, Second ICON on the tab. Assign it to the script.. Now delete the plugin from the form and click on the node tree in the OI, the item is still there and it will lock up the IDE You are doing great! keep up the good work and Merry Xmas.. ;) |
|
|
I hope this has not been forgotten ! ;) At work we have a place called the "Healing Shelf" , It sometimes works but I don't think its going to work for this ;) |
|
|
Hey guess what? I think you fixed it, I can't seem to break anything ! ;) Good job! that last update was a big one! |
|
|
Great. I resolve this. The big update was mostly refactoring and formatting when moving a unit to a different package. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-12-19 18:06 | jamie philbrook | New Issue | |
| 2020-12-19 18:29 | Juha Manninen | Relationship added | related to 0038227 |
| 2020-12-19 18:45 | jamie philbrook | Note Added: 0127699 | |
| 2020-12-19 19:07 | Juha Manninen | Assigned To | => Juha Manninen |
| 2020-12-19 19:07 | Juha Manninen | Status | new => assigned |
| 2020-12-19 19:13 | Juha Manninen | Note Added: 0127700 | |
| 2020-12-19 19:42 | jamie philbrook | Note Added: 0127701 | |
| 2020-12-19 20:04 | Don Siders | Note Added: 0127702 | |
| 2020-12-19 20:04 | Don Siders | Note Edited: 0127702 | View Revisions |
| 2020-12-19 20:36 | jamie philbrook | Note Added: 0127703 | |
| 2020-12-19 20:36 | Juha Manninen | Note Added: 0127704 | |
| 2020-12-19 20:38 | Juha Manninen | Summary | TpairSplitter: Regression, Can't fully delete it from OI and after many attempts back to locking the IDE again. => Regression, can't delete components from OI and after many attempts back to locking the IDE again. |
| 2020-12-19 20:38 | Juha Manninen | Description Updated | View Revisions |
| 2020-12-19 20:38 | Juha Manninen | LazTarget | => - |
| 2020-12-19 20:40 | Juha Manninen | Note Edited: 0127704 | View Revisions |
| 2020-12-19 20:44 | Juha Manninen | Note Edited: 0127704 | View Revisions |
| 2020-12-19 20:44 | jamie philbrook | Note Added: 0127705 | |
| 2020-12-19 20:51 | Juha Manninen | Summary | Regression, can't delete components from OI and after many attempts back to locking the IDE again. => Regression, can't delete components placed on a PairSplitter from OI and after many attempts back to locking the IDE again. |
| 2020-12-19 20:51 | Juha Manninen | Description Updated | View Revisions |
| 2020-12-19 20:55 | jamie philbrook | Note Edited: 0127705 | View Revisions |
| 2020-12-19 20:56 | jamie philbrook | Note Edited: 0127705 | View Revisions |
| 2020-12-19 21:43 | jamie philbrook | Note Added: 0127706 | |
| 2020-12-19 22:32 | wp | Note Added: 0127707 | |
| 2020-12-20 15:54 | Juha Manninen | Status | assigned => feedback |
| 2020-12-20 15:54 | Juha Manninen | Note Added: 0127719 | |
| 2020-12-20 18:40 | jamie philbrook | Note Added: 0127726 | |
| 2020-12-20 18:40 | jamie philbrook | Status | feedback => assigned |
| 2020-12-20 18:59 | jamie philbrook | Note Added: 0127728 | |
| 2020-12-20 19:01 | jamie philbrook | Note Edited: 0127728 | View Revisions |
| 2020-12-20 19:05 | jamie philbrook | Note Edited: 0127728 | View Revisions |
| 2020-12-20 19:13 | Juha Manninen | Relationship added | related to 0037434 |
| 2020-12-20 19:25 | Juha Manninen | Note Added: 0127732 | |
| 2020-12-20 22:20 | wp | Relationship added | related to 0038239 |
| 2020-12-25 15:38 | Juha Manninen | Note Added: 0127796 | |
| 2020-12-25 15:38 | Juha Manninen | Status | assigned => feedback |
| 2020-12-25 16:24 | jamie philbrook | Note Added: 0127797 | |
| 2020-12-25 16:24 | jamie philbrook | Status | feedback => assigned |
| 2020-12-25 16:30 | jamie philbrook | Note Edited: 0127797 | View Revisions |
| 2020-12-25 18:31 | Juha Manninen | Note Added: 0127798 | |
| 2020-12-25 19:22 | jamie philbrook | Note Added: 0127799 | |
| 2020-12-29 00:04 | jamie philbrook | Note Added: 0127877 | |
| 2020-12-30 05:04 | jamie philbrook | Note Added: 0127927 | |
| 2020-12-30 10:40 | Juha Manninen | Status | assigned => resolved |
| 2020-12-30 10:40 | Juha Manninen | Resolution | open => fixed |
| 2020-12-30 10:40 | Juha Manninen | Fixed in Revision | => r64254, r64274, r64301 |
| 2020-12-30 10:40 | Juha Manninen | Note Added: 0127928 |
