QTemporaryFile Problems
-
@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.
-
@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 afteropen()/fileName()and beforeexists()is that relevant?) -
@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.
@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.
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@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.
-
@ModelTech Unfortunately, the idea of a delay does not seem to work...
@ModelTech
If my standalone, minimal example always works but your "larger" code does not, maybe there is something there. Let's start by changing thefileName()line to:QString TempName = ImageFile->fileName(); qDebug() << "Filename created" << TempName; if (!ImageFile->exists()) ...What do you get for the
qDebug()line when theexists()fails? (And can you please state categorically that your "failure" case means thatexists()returns false and it writesError: 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 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.
@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 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 :)
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
If my standalone, minimal example always works but your "larger" code does not, maybe there is something there. Let's start by changing thefileName()line to:QString TempName = ImageFile->fileName(); qDebug() << "Filename created" << TempName; if (!ImageFile->exists()) ...What do you get for the
qDebug()line when theexists()fails? (And can you please state categorically that your "failure" case means thatexists()returns false and it writesError: 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?)@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 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 ;)
@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
ImageFileis deleted. SinceQTemporaryFilederives fromQobjectstart by attachingdestroyedsignal: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)?
-
I am trying to use QTemporaryFile as a means to temporarily store an image available from a QIODevice Device during the execution of my app. I have the following code that creates the QTemporaryFile as part of a constructor:
QDataStream InStream(Device); ImageFile = new QTemporaryFile(TempDir->path() + QDir::separator() + "image.XXXXXX"); ImageFile->open(); QString TempName = ImageFile->fileName(); if (!ImageFile->exists()) qDebug() << "Error: Could not create Temporary Image File"; QDataStream OutStream(ImageFile); const int BlockSize = 1024; char Block[BlockSize]; int Length = 0; while ((Length = InStream.readRawData(Block, BlockSize)) > 0) OutStream.writeRawData(Block, Length); ImageFile->flush(); ImageFile->close();The destructor contains the following code:
ImageFile->remove(); delete ImageFile;Between calling the constructor and destructor, a QPixmap is created from the QTemporaryFile.
This all works perfectly when I run it on Linux (actually WSL - Ubuntu 20.04) from within QtCreator. However, when I run it outside of QtCreator, the QTemporaryFile is not (always) created. What can be wrong here?
@ModelTech said in QTemporaryFile Problems:
QDataStream InStream(Device)
What is Device here? A socket?
-
@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
ImageFileis deleted. SinceQTemporaryFilederives fromQobjectstart by attachingdestroyedsignal: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)?
@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 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...
@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.
-
M ModelTech has marked this topic as solved on
