QTemporaryFile Problems

[JonB]

@ModelTech
Under Ubuntu 22.04, Qt 5.15 supplied from distro, the following code

#include <QCoreApplication>
#include <QDebug>
#include <QDir>
#include <QTemporaryFile>

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    QTemporaryFile *ImageFile = new QTemporaryFile(QDir::tempPath() + QDir::separator() + "image.XXXXXX");
    ImageFile->open();
    QString TempName = ImageFile->fileName();
    if (!ImageFile->exists())
        qDebug() << "Error: Could not create Temporary Image File";

    return a.exec();
}

seems to always work and create a named file in /tmp each time. Tested compiled for Release & Debug both inside & outside of Creator. Maybe you should try just this? Can you find a pattern as to when the exists() returns false?

If you are not wanting the file to be accessed from another application you do not need the temporary file to have a name, as per @Christian-Ehrlicher's comment, which you should answer as to why you do need it.

If you do need it, and for whatever reason (e.g. maybe WSL for all I know) you cannot get it to work reliably/consistently to your requirements, you can of course just "roll your own" temporary file without having to use QTemporaryFile.

[ModelTech]

@JonB I also expected that there should be no difference whatsoever between running it from within the context of QtCreator or not, but that is however exactly what is happening and it does not matter if it is Release or Debug... It's very weird and I never had this before...

The problem exposes itself from the fact that I need to create a (scaled) QPixmap based on the QTemporaryFile. This gives the error: QPixmap::scaled: Pixmap is a null pixmap

@Christian-Ehrlicher I also need the QTemporaryFile to be concrete with a filename etc to be able to parse & process it with libtiff elsewhere in my app.

[JonB]

@ModelTech
I asked you to try my minimal code sample, did you do that?
If you say the problem happens "sometimes", can you find a pattern? (Per chance, if you put in a delay after open()/fileName() and before exists() is that relevant?)

[ModelTech]

@JonB The minimal code works perfectly fine (It took me some time to be able to isolate this part)... I will now try your idea of a delay.

[Christian Ehrlicher]

@ModelTech said in QTemporaryFile Problems:

process it with libtiff elsewhere in my app

What do you do with libtiff which can Qt not do directly? And TiffOpenExt() allows to pass a custom read function if you really need special tiff functions.

[ModelTech]

@ModelTech Unfortunately, the idea of a delay does not seem to work...

[JonB]

@ModelTech
If my standalone, minimal example always works but your "larger" code does not, maybe there is something there. Let's start by changing the fileName() line to:

QString TempName = ImageFile->fileName();
qDebug() << "Filename created" << TempName;
if (!ImageFile->exists()) ...

What do you get for the qDebug() line when the exists() fails? (And can you please state categorically that your "failure" case means that exists() returns false and it writes Error: Could not create Temporary Image File, as opposed to any other way of "detecting the file does not exist", you still have not made that clear?)

[ModelTech]

@Christian-Ehrlicher I actually started like that, but I need to process the TIFF images in a way that Qt unfortunately does not support. Qt translates everything to RGB-based color spaces and that is the primary thing that must definately not happen in this case... libtiff is the primary library that supports everything I do need, except for displaying the images. That is what Qt is very good at :)

[Christian Ehrlicher]

Then pass a custom read function to open or simply use a regular file (or fix the bug in your code whereever it is)

[ModelTech]

@JonB Good remark! When I mentioned 'exists', I meant that I was looking at the /tmp directory. I have not seen the code produce any qDebug messages in any case...

Let me do some more testing with the full code by introducing a lot more qDebug() messages to see where the problem arises (and eventually gets exposed by the QPixmap error). It is a bit of a poormans approach to debug, but this is the only way given that it all works fine when debugging with QtCreator ;)

[JonB]

@ModelTech said in QTemporaryFile Problems:

I meant that I was looking at the /tmp directory. I have not seen the code produce any qDebug messages in any case...

That is a totally different case! I assumed since you showed the debug message if exists() fails that was what you were seeing. You should have said!

Then the first thing to check is: the file will be deleted any time ImageFile is deleted. Since QTemporaryFile derives from Qobject start by attaching destroyed signal:

connect(ImageFile, &QObject::destroyed, this /* some object which persists beyond your ImageFile's lifetime */, []() { qDebug() << "ImageFile destroyed!"; } );

Do you get this debug output any time prior to when you expect it to be destroyed (in your destructor)?

[Christian Ehrlicher]

@ModelTech said in QTemporaryFile Problems:

QDataStream InStream(Device)

What is Device here? A socket?

[ModelTech]

@JonB Sorry for beying unclear earlier. No, I do not get any 'destroyed' messages at all, even not when the destructor is called! It is however really no longer existing after the destructor is called ;)

Nevertheless, based on your ideas I did get a lot further now :) I have been able to check that the QTemporaryFile does still exist at the moment that I create the Pixmap. So, the problem exposed by the QPixmap message does not seem to originate from the existance of the QTemporaryFile at all. Although this hasn't solved my problem, I was looking completely in the wrong area...

[JonB]

@ModelTech said in QTemporaryFile Problems:

No, I do not get any 'destroyed' messages at all, even not when the destructor is called!

Well, you ought to! Changing my example to have

QObject::connect(ImageFile, &QObject::destroyed, qApp, []() { qDebug() << "ImageFile destroyed!"; } );
...
delete ImageFile;

does give me the message!

But if you are moving to look at a different area you may not care.

[ModelTech]

I found the problem! I needed to add the relavant Qt image format plugins to my deployable package...

Thanks for all the help in directing me to an approach that enabled me to identify the actual problem :) :) :)