I embed some container controls in a window, a slider in the container control executes a method which may need to close this container control and recreate it.
To avoid calling a containercontrol.close from a method called from the containercontrol itself (which causes a crash) I do it with a timer set to 1 second after slider changes but sometimes it still crashes which means it is not safe to close the container control.
Is there a way to know if it is safe to close and remove it?
Are you getting an exception? If yes, which one?
If you get a hard crash then post the relevant section of the crash log.
Can you show us your code how you close the container? Which version of Xojo do you use? macOS, Windows or Linux? Which versions?
A crash, unable to catch the exception.
Xojo 2018.3 Mac OS X 11.1 Big Sur
Date/Time: 2021-02-08 11:57:07.147 +0100
OS Version: macOS 11.1 (20C69)
Report Version: 12
Anonymous UUID: 7770525A-A26C-C928-28E8-586A3F12B494
Time Awake Since Boot: 14000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: NSPersistentUI Work
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
TeamPhotoComposite.debug(2542,0x105186e00) malloc: Heap corruption detected, free list is damaged at 0x600001f2d0e0
*** Incorrect guard value: 281479271677951
Thread 0 Crashed:: Dispatch queue: NSPersistentUI Work
0 libsystem_kernel.dylib 0x00007fff202fb462 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff20329610 pthread_kill + 263
2 libsystem_c.dylib 0x00007fff2027c720 abort + 120
3 libsystem_malloc.dylib 0x00007fff2015d430 malloc_vreport + 548
4 libsystem_malloc.dylib 0x00007fff20171702 malloc_zone_error + 183
5 libsystem_malloc.dylib 0x00007fff20171b08 nanov2_allocate_from_block.cold.1 + 32
6 libsystem_malloc.dylib 0x00007fff201500bc nanov2_allocate_from_block + 566
7 libsystem_malloc.dylib 0x00007fff2014f657 nanov2_allocate + 130
8 libsystem_malloc.dylib 0x00007fff2014f584 nanov2_malloc + 55
9 libsystem_malloc.dylib 0x00007fff20169dfe _malloc_zone_malloc + 118
10 com.apple.CoreFoundation 0x00007fff203a42b1 _CFRuntimeCreateInstance + 597
11 com.apple.CoreFoundation 0x00007fff2043313d _CFKeyedArchiverUIDCreate + 29
12 com.apple.Foundation 0x00007fff21198f4e __NSKeyedArchiverUIDCreateCached + 238
13 com.apple.Foundation 0x00007fff2119832d _encodeObject + 713
14 com.apple.Foundation 0x00007fff2119924b -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] + 371
15 com.apple.Foundation 0x00007fff21198508 _encodeObject + 1188
16 com.apple.AppKit 0x00007fff22e088d9 -[NSPersistentUIArchiver encodeObject:forKey:] + 68
17 com.apple.AppKit 0x00007fff22e08375 -[NSPersistentUIBucket encodeInvalidPersistentStateWithBackgroundQueue:completionHandler:] + 226
18 com.apple.AppKit 0x00007fff22e08147 __40-[NSPersistentUIManager flushAllChanges]_block_invoke + 803
19 com.apple.AppKit 0x00007fff23687953 ___NSPersistentUIDispatchQueueSync_block_invoke + 28
20 libdispatch.dylib 0x00007fff2017e7c7 _dispatch_client_callout + 8
21 libdispatch.dylib 0x00007fff2018b605 _dispatch_lane_barrier_sync_invoke_and_complete + 60
22 com.apple.AppKit 0x00007fff22e0778d -[NSPersistentUIManager flushAllChanges] + 526
23 com.apple.AppKit 0x00007fff22e23dfd __45-[NSPersistentUIFlushScheduler scheduleTimer]_block_invoke + 38
24 com.apple.AppKit 0x00007fff2354bc11 ___NSMainRunLoopPerformBlockInModes_block_invoke + 25
25 com.apple.CoreFoundation 0x00007fff204215a2 CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 12
26 com.apple.CoreFoundation 0x00007fff2042144c __CFRunLoopDoBlocks + 437
27 com.apple.CoreFoundation 0x00007fff204207bd __CFRunLoopRun + 2582
28 com.apple.CoreFoundation 0x00007fff2041f6ce CFRunLoopRunSpecific + 563
29 com.apple.HIToolbox 0x00007fff286a46d0 RunCurrentEventLoopInMode + 292
30 com.apple.HIToolbox 0x00007fff286a44cc ReceiveNextEventCommon + 709
31 com.apple.HIToolbox 0x00007fff286a41ef _BlockUntilNextEventMatchingListInModeWithFilter + 64
32 com.apple.AppKit 0x00007fff22c3cde9 _DPSNextEvent + 883
33 com.apple.AppKit 0x00007fff22c3b5af -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1366
34 XojoFramework 0x0000000104586859 0x1044b2000 + 870489
35 XojoFramework 0x000000010458689d 0x1044b2000 + 870557
36 TeamPhotoComposite.debug 0x00000001036e9095 Application._CallFunctionWithExceptionHandling%%op + 181
37 XojoFramework 0x00000001047075a7 CallFunctionWithExceptionHandling(void (*)()) + 262
38 XojoFramework 0x0000000104586806 0x1044b2000 + 870406
39 com.apple.AppKit 0x00007fff22c2db0a -[NSApplication run] + 586
40 XojoFramework 0x000000010470591d RuntimeRun + 42
41 TeamPhotoComposite.debug 0x000000010378aea3 REALbasic._RuntimeRun + 19
42 TeamPhotoComposite.debug 0x00000001040cd19e _Main + 846 (/#main:217)
43 TeamPhotoComposite.debug 0x00000001040cc083 main + 19
44 libdyld.dylib 0x00007fff20344621 start + 1
This is deep into the bowels of macOS. Your Xojo version is really old. I will assume that you have reasons for using such an old version. But first thing I’d try is with 2020r2.1.
Doing this by a timer is good. But it sounds that the code that the timer action event executes lives in the container. Move it to the window an store a reference somewhere to access the container. This should not crash.
Thanks, it is actually in the main window and I have set it to different times like 1 1.5 and 2 seconds. For some reason it still crashes sometimes but not always.
The code to close the containercontrols is called by the Timer in the main window.:
for n as integer = 0 to aMyCC.Ubound
aMyCC(n).Close
next n
Redim aMyCC(-1)
Run the aray backwards with DownTo that could fix your issue
Make sure that no control of a closing container has the focus. I would overwrite the container Close method to ensure that all timers, threads and other depencies are closed/removed before calling super.Close.
Thanks, I thought about this but I expected to be nil once closed, actually I can close a single ContainerControl from the array and the array doesn’t changes (Containercontrol handle is 0 but top value and others are still there) until I remove it.
Yes, it’s the same behaviour as with windows; you have to check the handle.
And do it the way DerkJ wrote: Iterate the array from the last item to the first. So you can safe remove the array item directly after closing the container.
Thanks for all your help. Will follow your suggestions.