QTemporaryFile Problems
-
@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
