[SOLVED] Creation and writing to .dat file using QFile on Windows some problem...

[alexisdm]

The reason of the error should be indicated by QFile::errorString.

And QIODevice::WriteOnly and QFile::WriteOnly have the same value because the enum is inherited.

[p91paul]

use this
@if (!file.open(QIODevice::WriteOnly))@

since WriteOnly is the same in QFile and QIODevice since is simply inherited, so it's useless to or those values. using QFile::WriteOnly or QIODevice::WriteOnly is exactly the same.
probably best (but I don't know if you use text files) is to use QIODevice::WriteOnly|QIODevice::Text, that removes the problem of handling windows line terminators \r\n, that can be treaten as they are \n, also in writing(when flushing to the actual file, \n will be converted in the os default line terminator)

you can use "error()":http://doc.qt.nokia.com/latest/qfile.html#error to retrieve last error; it will be one of "FileError":http://doc.qt.nokia.com/latest/qfile.html#FileError-enum

you can also use "fileName()":http://doc.qt.nokia.com/latest/qfile.html#fileName to retrieve the name set (it can have double slash if outputDir already has a terminal /)

[swhweng]

alexisdm, p91paul you've added useful advices:
I've outputed :
after
@....
QFile file(QDir::toNativeSeparators(outputDir + "/" + fileName));
file.open(QFile::ReadWrite);
...
@
I've got: file.fileName() = "(path to file + file name BUT with separators "/" and not "" as on Windows)"
file.errorString() = "The parameter is incorrect"
file.error() = 5 ( Error in opening file ).

Why file.fileName() returns path name with "/" ( Linux like separators ) and not that of Windows "\" or "" ??
Still can't open file in rw directory?
What is the problem?
Thank you for your help.

[p91paul]

do not use toNativeSeparators, it is probably not a good idea since QFile expects /

I think the problem is the directory. try to copy outputDir contents to the windows shell and see what you get. probably something about windows drive letters? are you using absolute paths? or relative paths starting with /?

[swhweng]

without using QDir::toNativeSeparators(...) file.fileName() returns file name with path with "/" slashes that is not for Windows.
Next also does not work:
@
...
QFile file(outputDir_+"/"+fileName);
if (!file.open(QFile::WriteOnly))
{
QMessageBox::warning(0,"Could not create Project File",
QObject::tr( "\n Could not create Project File on disk"));

              return false;
     }

else
...
@
file.fileName() returns on Windows path and file name with "/" separators.
How to set file name with windows separators "" ?

[p91paul]

it's correct that fileName() contains /, because conversion is done only when actually opening the file. trust Qt and remove toNativeSeparators, is not your problem.

you haven't replyed to my questions. are you using relative or absolute path? if relative, remember that the first char must not be /
if absolute, on windows you have to put drive letter name; if you use / as the first char in a windows absolute path, the current drive is used.

Another thing: if you use relative path, pay attention to the current path; It may change depending on where the executable is built and other things. try to output "QDir::currentPath()":http://doc.qt.nokia.com/latest/qdir.html#currentPath to obtain your current path, and see if it is what you expect.

[mlong]

Just use "/" separators for all QFile-related paths. The QFile class is smart enough to make the substitution for you. "/" is the Qt file separator, which allows you to write paths without having to worry about the native path separators in your code.

[swhweng]

outputDir inside QFile file(outputDir_ + "/" + fileName) contains path name ( file directory ) returned from QFileDialog with "/" separators.

[swhweng]

outputDir is absolute path that contains drive letter and "/" separators and all that passed to QFile constructor but file is not created and file.fileName() returns fileName + outputDir with the "/" separators like Qt did not take care of conversion but should.
I try to find the possible miss here ( solution ) , if you have time help me.
Thank you.

[mlong]

What are the contents of outputDir_ and fileName that you're passing to the constructor, and what is the value you're getting back from file.fileName()?

What are you expecting that you should see?

[swhweng]

mlong please read my previous post I've wrote there what is in outputDir ( directory name with "/" separators ) and there is some windows friendly file name with .dat extension in fileName. That passed to the QFile constructor and I expect separators are automatically converted to "" for Windows but as you can see they didn't. So I'm looking what is the problem...

[mlong]

[quote author="Pavel Mazniker" date="1312828520"]mlong please read my previous post I've wrote there ...[/quote]

I realize that. I was just looking for a more concrete example "E:/foo/bar/baz/file.dat" or whatever... just to make sure that there's not something else subtle that is happening in your use case.

I believe that file.fileName() will not return the "" separators. It will continue to use the Qt-friendly "/" separators. The "/" and "" conversion happens at a lower level.

[swhweng]

why the file is not opened(created) on Windows in the case?

[mlong]

Without more information, it's hard to tell. Qt's pretty robust in opening files, so I would be led to believe that there's more than likely something subtle in the way the file and/or path is being set up. Could you create and post a small example snippet of code (very similar to your first posts's code sample) which has a real path and filename which is not working?

[goetz]

Pavel, it's time to post some concrete examples. Your "anonymized" snippets are hard to analyze. Some actual paths, as mlong suggested, would be very helpful.

Qt does its job with files pretty good. So it is very likely that you messed up some paths.

Double check the actual paths with [[Doc:QFileInfo]]:

@
QFileInfo fi(file);
qDebug() << fi.absoluteFilePath();
@

[swhweng]

Separators are "treated" automatically by Qt. I've changed file name for Windows and now it works.
Thanks for your help. Solved.

[mlong]

Good deal! Please be sure and add [SOLVED] to the beginning of the thread title! Thanks!