View Single Post
Old 06-07-2025, 06:18 AM   #46
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 28,695
Karma: 205039118
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Quote:
Originally Posted by KevinH View Post
My understanding is that it is the getOpenGpFileNames routine that is somehow crashing before it returns. Is that correct?
I don't think I have enough info to answer that question yet. Without any extra added debug info enabled in the 2.5.2 Windows release, I can say that the crash happens quite a long time after the OK button on getOpenFileNames is clicked. The mouse pointer changes to and from "working" several distinct times. The QTreeView on the left of the SelectFiles.cpp dialog (the one whose "Other Files" buttons call the getOpenFileNames dialog) changes in appearance just before the crash. So I can't be certain if it's getOpenFileNames itself, or if it's QModelIndex data associated with the treeview being handed something (from getOpenFileNames) that it's barfing on. Hoping to do a debug build today or tomorrow to determine where exactly it's dying.

If it is the latter, then clearly the non-native dialog has some sort of extra guardrails that the native dialogs lacks to prevent bad data from being passed on.

Last edited by DiapDealer; 06-07-2025 at 06:24 AM.
DiapDealer is online now   Reply With Quote