TPopupMenu.Close() need rework
Original Reporter info from Mantis: zeljko@holobit.net @zeljan1
-
Reporter name: Zeljan Rikalo
Original Reporter info from Mantis: zeljko@holobit.net @zeljan1
- Reporter name: Zeljan Rikalo
Description:
Already posted on devel list, but no interest, so opened issue about problem.
I've run into problems (especially under qtlcl under macosx) with calling
TPopupMenu.Close directly from WS.
Problem is because FItems handles are destroyed in TPopupMenu.Close each time it is called so some ws like qt on mac cannot handle that without huge delay (I've managed that via single shot timer).
I've attached patch which:
1.Doesn't touch FItems handles in TPopupMenu.Close - think delphi does not touch handles here too.
2.Removes FItems handles before each popup (if exists) - delphi
works in this way too - it rebuild handles each time before popup.
3.Destroy FItems handles in TPopupMenu.Destroy - so no memleaks
I've tested it and it works ok here. So, patch is here for review.
With this patch it's safe to call TPopupMenu.Close from WS (or we should
rename it / or add IntfPopupMenuClose ....)
Things like postponing such things (gtk via gtk_idle_add()) are bad.I've already tried to postpone it under qtlcl , but under macosx it needs >= 200ms of delay because it'll crash with smaller delay.
I think that this patch is much cleaner implementation of TPopupMenu.Close(), and gtk postponing can be removed if this patch is applied.
Mantis conversion info:
- Mantis ID: 15614
- Version: 0.9.29 (SVN)
- Fixed in version: 0.9.29 (SVN)
- Fixed in revision: 23585 (#98ed7110)
- Target version: 0.9.30