@JonB Solved!! Thank you so much for the help here troubleshooting which made the issue obvious after trying your suggested tests.

As you expected, the QSqlQuery is not the issue as the proper data is being returned;

Test #2

QSqlQuery q; qDebug() << "Prep: " << q.prepare("SELECT ClassCode, SUM(EstimatedChargeablePayroll) AS Total FROM Payroll GROUP BY ClassCode"); qDebug() << "Exec: " << q.exec(); while(q.next()){ QVariant code = q.value(0); QVariant total = q.value(1); qDebug() << code << total; }

Results in the correct records being returned.

Prep: true Exec: true QVariant(QString, "5555") QVariant(double, 350000) QVariant(QString, "6666") QVariant(double, 50000)

This completely ruled out the QSqlQueryModel issue and forced me to review the rest of the code. The class I've been working on is derived from QSqlQueryModel and has an overridden data() method that was not properly presenting the data to the view. The model was always working in the background it just didn't look like it.

@Christian-Ehrlicher, I was spooling up the example when this dawned on me, but appreciate the assist here.

It might be the charts module that triggers this dependencies.

What does DeepSkyStackerKernel use ?

@ChrisW67 It works, but I was hoping there was a more intuitive way :D

@aha_1980

Thanks, Bud! Mine has worked. It was previously named "00-syntax." I converted it to syntax, and my project worked, which was stuck for about three hours.

thanks again!!

If found a recent addition to Qt that does pretty much what I want (though it adds more Qt libraries than are necessary - I think it just copies them all :( ). It is qt_generate_deploy_app_script

Here's the complete code from my CMakeLists.txt file showing the both the non-Linux and the Linux path:

if(NOT LINUX) set (deploy_tool_options_arg "") if(APPLE) set(deploy_tool_options_arg "${deploy_tool_options_arg} --hardened-runtime") elseif(WIN32) set(deploy_tool_options_arg "${deploy_tool_options_arg} --pdb") endif() # Generate a deployment script to be executed at install time # App bundles on macOS have an .app suffix if(APPLE) set(executable_path "$<TARGET_FILE_NAME:DeepSkyStacker>.app") else() message ("Target filename:" $<TARGET_FILE_NAME:DeepSkyStacker>) set(executable_path "${CMAKE_INSTALL_BINDIR}/$<TARGET_FILE_NAME:DeepSkyStacker>") endif() message ("executable_path: " ${executable_path}) message ("deploy tools options arg: " ${deploy_tool_options_arg}) qt_generate_deploy_script( TARGET DeepSkyStacker OUTPUT_SCRIPT deploy_script CONTENT " qt_deploy_runtime_dependencies( EXECUTABLE \"${executable_path}\" DEPLOY_TOOL_OPTIONS ${deploy_tool_options_arg} )" ) else() qt_generate_deploy_app_script( TARGET ${PROJECT_NAME} OUTPUT_SCRIPT deploy_script DEPLOY_TOOL_OPTIONS ${deploy_tool_options_arg} ) endif() install (SCRIPT ${deploy_script}) install(TARGETS ${PROJECT_NAME})

Be warned if you are using the Visual Studio Linux workload: It invokes CMake on Linux with

-DCMAKE_SYSTEM_NAME:STRING=“Linux”

which is a big "no-no". It results in CMAKE_CROSSCOMPILING being set to TRUE which results in qt_generate_deploy_app_script refusing to play.

See: https://developercommunity.visualstudio.com/t/Using-CMake-with-Linux-Workload-the-bui/10813104

David

"refresh the installer." = click "Filter"

@Christian-Ehrlicher Thank you! For the time being I switched the overall QApplication style to "Fusion" and cleared this up. For some reason the "windowsvista" was still having issues with formatting. I'll keep an eye out for 6.8.2 ;)

main.cpp

QApplication::setStyle(QStyleFactory::create("Fusion"));

I have a function that scan a long list of input and output (100 + 100 more or less) than change "state" of some widget on my gui .... that function work based on a timer start from gui with time of 100ms .... can be these that generate my problem? I think not because with mouse all work perfectly ...... my function work on qt5 perfectly with mouse or with touch .... only qt6 version have problem with touch ..... about these it may be that this further explanation could help someone come up with an idea that would help me solve the rather boring problem... I've been wasting my time on it for 2 months now.

regards

@jack_study_qt Hi Jack,

I'm facing kinda the same issue about libc:

19:31:14: Package deploy: Running command "C:\Users\MadGuy\AppData\Local\Android\Sdk\platform-tools\adb.exe -s emulator-5554 pull /system/bin/app_process64 D:\Projects\Qt\DiceRoller\build\Android_Qt_6_8_1_Clang_x86_64-Release\android-app-process\app_process". 19:31:14: Package deploy: Running command "C:\Users\MadGuy\AppData\Local\Android\Sdk\platform-tools\adb.exe -s emulator-5554 pull /system/bin/linker64 D:\Projects\Qt\DiceRoller\build\Android_Qt_6_8_1_Clang_x86_64-Release\android-app-process\linker64". 19:31:15: The command "C:\Users\MadGuy\AppData\Local\Android\Sdk\platform-tools\adb.exe -s emulator-5554 pull /system/bin/linker64 D:\Projects\Qt\DiceRoller\build\Android_Qt_6_8_1_Clang_x86_64-Release\android-app-process\linker64" terminated with exit code 1. 19:31:15: Package deploy: Running command "C:\Users\MadGuy\AppData\Local\Android\Sdk\platform-tools\adb.exe -s emulator-5554 pull /system/lib64/libc.so D:\Projects\Qt\DiceRoller\build\Android_Qt_6_8_1_Clang_x86_64-Release\android-app-process\libc.so". 19:31:15: The command "C:\Users\MadGuy\AppData\Local\Android\Sdk\platform-tools\adb.exe -s emulator-5554 pull /system/lib64/libc.so D:\Projects\Qt\DiceRoller\build\Android_Qt_6_8_1_Clang_x86_64-Release\android-app-process\libc.so" terminated with exit code 1. 19:31:15: Package deploy: Failed to pull "/system/lib64/libc.so" to "D:\Projects\Qt\DiceRoller\build\Android_Qt_6_8_1_Clang_x86_64-Release\android-app-process\libc.so".

Here are the gradle.properties:

org.gradle.jvmargs=-Xmx2500m -XX:MaxMetaspaceSize=768m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 # Enable building projects in parallel org.gradle.parallel=true # Gradle caching allows reusing the build artifacts from a previous # build with the same inputs. However, over time, the cache size will # grow. Uncomment the following line to enable it. #org.gradle.caching=true #org.gradle.configuration-cache=true # Allow AndroidX usage android.useAndroidX=true androidBuildToolsVersion=34.0.0 androidCompileSdkVersion=android-34 androidNdkVersion=26.1.10909125 androidPackageName=com.diceroller.app buildDir=build qt5AndroidDir=C:/Qt/6.8.1/android_x86_64/./src/android/java qtAndroidDir=C:/Qt/6.8.1/android_x86_64/./src/android/java qtGradlePluginType=com.android.application qtMinSdkVersion=28 qtTargetAbiList=x86_64 qtTargetSdkVersion=34

The tools downloaded are shown in the screenshot. GPT said some latest Google Play images doesn't allow pulling system files. But I found this post. I'm suspicous about the SDK Version 16.0 in the screenshot.

Screenshot 2024-12-14 195906.png

I can see it at https://bugreports.qt.io/browse/QTCREATORBUG-32176 Thank you.

Thank you. Please comment there with the details of the computer running. Memory, CPU, etc. Was the project using a remote device and so o.

@Pl45m4
So, are you suggesting to create separate event filters for each window?

If someone wants to proof-read the doc: https://codereview.qt-project.org/c/qt/qtbase/+/611693

Better you provide one sample. Difficult to imagine what you would like to achieve. It is possible to do. One simple example is here.

main.qml Window { width: 640 height: 480 visible: true title: qsTr("Hello World") MyQmlPropertyMap{ id : owner} Text { text : owner.name } MyButton{ b1 : y1 } YourButton{ id : y1 visible: false } } MyButton.qml Rectangle { width: 200;height: 200 color: "blue" property var b1 MouseArea{ anchors.fill: parent onClicked: { b1.visible = true } } } YourButton.qml Rectangle { width: 100;height: 100 color: "red" }

Hi and welcome to devnet,

Did you already try to use a different mirror ?

If heob shows a leak after program exit, then it means the memory was not (yet) freed at the time when ExitProcess was called.
It is possible that some memory is freed after ExitProcess, when a DLL is unloaded, but I don't think that's usually true for Qt objects.
The -d4 parameter of heob can be used to check for leaks after all DLLs were unloaded, maybe it makes a difference in this case (but I doubt it).
If Control leak recording is enabled, you can control in the heob console when to start/stop recording memory allocations, and also output all current non-freed memory at any time.

You don't need QtCreator at all to use heob, it's first and foremost a standalone command-line tool.