1
votes

CASE

  1. my Qt application create a file by QFile
  2. I intend to use dll to read this file

SYMPTOM

  • dll cant use it, because it's occupied by the QAppilcation

ATTEMPT

  1. I tried file.close() to release the file, does not work;
  2. I tried other application to read this file, same symptom as occupied, which means dll is fine.

So, What can I do to release a file that is already created and closed by QFile?

Release the Qt file

    void MainWindow::creatFile(){
       QFile file("1.dat");
       if (!file.open(QIODevice::WriteOnly | QIODevice::Text))
           return ;

       if(!file.exists())
           return;

       QTextStream out(&file);
       out << "test" <<endl;

       out.flush();
       file.close(); // .~QFile() is not needed at all.
       return;
   }

convert QString to Character(Fortran)

typedef void (* myfun)(char string[255]); //How Qt pass character to Fortran dll

//QString-> std::string -> char* 
std::string fileName_std = fileName.replace("/","\\").toStdString();
const char* fileName_cstr = fileName_std.c_str();

char fileName_For90[255];
int length = sizeof(fileName_For90); 

//fill the left nulls of char with blanks which are required in Fortran
strcpy(fileName_For90,fileName_cstr);
for(int i = strlen(fileName_For90); i < length; i++){
    fileName_For90[i] = ' '; 
}
2
Is the QFile object used for writing destroyed at the point where the DLL wants to read the file?Frank Osterfeld
~QFile calls close(), but not vice versa.Frank Osterfeld
You don't have to call ~QFile explicitly. Leaving creatFile() does that for you (as stack variables are destroyed at the end of the block). Your code looks correct without the ~QFile call.Frank Osterfeld
More than that, you must (almost) never call destructor explicitly. It's dangerous and awkward. The rest of code is quite correct. Probably the cause is somewhere else. May be this file is still opened in another part of your app.Pavel Strakhov
What is this SHARE=? It is not standard Fortran.Vladimir F

2 Answers

0
votes

(This question has answers in the comments and edited into the question. The question has repeated edits and is more like a blog than a question and it is no longer clear what the question was, whereas SO expects a clear question and a clear answer. See Question with no answers, but issue solved in the comments (or extended in chat). I'm putting this community Wiki Answer so that the question is recorded as answered, however I'm finding it hard to extract an answer from all that chat and edit.)

The OP wrote:

Here is what I get during solving:

  1. .close() actually does close the file. And .flush() might be needed as you can find details here QFile::flush() vs QFile::close()
  2. the real problem lies in converting QString to Character in Fortran.
0
votes

I would suggest using QSaveFile. I have run into many instances where trying to create a file in place, and then immediately referencing and using it can cause this problem. QSaveFile creates the file in a temp space and moves it to it's final destination. This seems much more deterministic when other functions or signaled processes need to work on the file. This is partciularly true of QFileSystemWatcher.

void MainWindow::createFile(){
   QSaveFile file("1.dat");
   if (!file.open(QIODevice::WriteOnly | QIODevice::Text))
       return ;

   if(!file.exists())
       return;

   QTextStream out(&file);
   out << "test" <<endl;


   file.commit(); // .~QFile() is not needed at all.
   return;

}