Daniel Pantea

Hi David, I think too the code is correct, but wanted to circumvent the complaint without dropping "-Wall". Copilot and Claude's patch uses memcpy, which sounds heavy... Probably simplest for me is to just suppress this with target_compile_options(${PROJECT_NAME} PRIVATE -Wno-strict-aliasing). Thanks, Daniel

GCC (15.2.0) with "-Wextra" complains on: Win32xx/include/wxx_docking.h:2700:34: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers] 2700 | CDocker* pDockTopLevel = (CDocker* const)this; | ^~~~~~~~~~~~~~~~~~~~ const_cast<CDocker*>(this) would please it... Thanks, Daniel

Just a note: the wxx_treeview.h:363 line reinterpret_cast<HTREEITEM*>(&rc) = item; triggers error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] with MinGW64 (tested with version 15.2.0...) Thanks, Daniel

Thanks a lot David! Another observation related to Dock.exe and DockContainer.exe: 1. close almost all dockers, leaving only one open 2. restart the app 3. observe that the previous layout is preserved (one docker only) 4. close also the last docker (from DockContainer.exe -> menu -> Docking -> Close All) 5. restart the app 6. observe that the layout is reset to default I think this is because CDocker::LoadDockRegistrySettings sets isLoaded = TRUE only when dockList.size() > 0: is this expected?...

Hi David, in the DockContainer sample I noticed that undocking a view will make it jump to the current cursor position... This looks a bit odd when the app is maximized because then the newly undocked view can get easily out of the screen. I couldn't add pictures here, so I added some details on Win32xx/issues/14. Kindly please check if it makes sense to do such a change (to avoid that jump). And a second issue observed with the DockContainer.exe: - undocking one of the "Output" views doesn't un-maximize...

Thanks David, they work fine now!

Hi David, I noticed that in TextFileReader demo, pressing F1 multiple times trigger more than one About dialog: after that only the last one can be closed, the other ones not, and then the TextFileReader.exe has to be killed from Task Manager. An almost similar behaviour is for Tray demo, but there all the opened ones can be closed (with OK in any order, or with Esc in reverse opening order). If you find the route case for both, can you please provide a fix? Thank you, Daniel