Saving a file using a relative path

[admkrk]

I might have to check all that out, when I get the time. I should not have a problem with any of that in this application though, except for this case where it seems I was trying to use a directory before it was established. At the very least, it something I am aware of it now.

Thanks!

[admkrk]

OK, now I am even more confused. Using QFile::copy() and a relative path, it only seems to work sometimes.

I have this in one function, and it works fine

QFileInfo temp(imagePath);
QString fileName = temp.fileName();
QFile::copy(imagePath, projectPath + "/" + fileName);

QFileInfo temp(imagePath);
QString fileName = temp.fileName();
QFile::copy(imagePath, projectPath + "/" + fileName);

To copy to clipboard, switch view to plain text mode 

In another function I had to change to this to get it to work

QFileInfo temp(bomPath);
QString fileName = temp.fileName();
//QFile::copy(bomPath, projectPath + "/" + fileName);
QString newPath = QDir::current().currentPath();
newPath.append(projectPath + "/" + fileName);
QFile::copy(bomPath, newPath);

QFileInfo temp(bomPath);
QString fileName = temp.fileName();
//QFile::copy(bomPath, projectPath + "/" + fileName);
QString newPath = QDir::current().currentPath();
newPath.append(projectPath + "/" + fileName);
QFile::copy(bomPath, newPath);

To copy to clipboard, switch view to plain text mode 

bomPath and imagePath both come from QFileDialogs. In both cases

qDebug() << "Current: " << QDir::current().currentPath();

qDebug() << "Current: " << QDir::current().currentPath();

To copy to clipboard, switch view to plain text mode 

prints the same thing. projectPath holds a relative path, to the same folder "/projects/Test". The only difference, I can see, is fileName, which includes different extensions; .jpg and .csv. What am I missing here? It makes me wonder if I switch the first one, to match the second for consistency, if it will still work?

[d_stranz]

When you use your QFileDialogs do you invoke them using the static methods, eg. QFileDialog::getSaveFileName(), or do you create a QFileDialog instance on the stack, connect slots to the signals, and then call exec()?

// mDBName is a member variable that keeps track of the last-opened database, stored in QSettings
// mDBDir is a member variable that holds the path containing the mDBName, stored in QSettings
 
void MyMainWindow::onOpenDB()
{
	QFileDialog	fd( this, "Select Database File", mDBDir, "Database Files (*.db *.sqlite)" );
	fd.setFileMode( QFileDialog::ExistingFile );
	fd.setAcceptMode( QFileDialog::AcceptOpen );
	if ( !mDBName.isEmpty( ) )
		fd.selectFile( mDBName );
 
	connect( &fd, &QFileDialog::fileSelected, this, &MyMainWindow::onDBFileSelected );  // updates mDBName and opens it
	connect( &fd, &QFileDialog::directoryEntered, this, &MyMainWindow::onDBDirectoryChanged );  // updates mDBDir
	connect( &fd, &QFileDialog::currentChanged, this, &MyMainWindow::onDBCurrentChanged );
	fd.exec();
}

// mDBName is a member variable that keeps track of the last-opened database, stored in QSettings
// mDBDir is a member variable that holds the path containing the mDBName, stored in QSettings

void MyMainWindow::onOpenDB()
{
	QFileDialog	fd( this, "Select Database File", mDBDir, "Database Files (*.db *.sqlite)" );
	fd.setFileMode( QFileDialog::ExistingFile );
	fd.setAcceptMode( QFileDialog::AcceptOpen );
	if ( !mDBName.isEmpty( ) )
		fd.selectFile( mDBName );

	connect( &fd, &QFileDialog::fileSelected, this, &MyMainWindow::onDBFileSelected );  // updates mDBName and opens it
	connect( &fd, &QFileDialog::directoryEntered, this, &MyMainWindow::onDBDirectoryChanged );  // updates mDBDir
	connect( &fd, &QFileDialog::currentChanged, this, &MyMainWindow::onDBCurrentChanged );
	fd.exec();
}

To copy to clipboard, switch view to plain text mode 

If you don't do something like this, then it might be helpful to reorganize your code so that it does. By looking at what is being sent to each of your slots and comparing it to what your logic thinks the current directory is might help you understand why your relative paths aren't what you think they should be.

[admkrk]

The whole section for copying the image looks like this

QString dir = QStandardPaths::writableLocation(
            QStandardPaths::PicturesLocation);
QString imagePath = QFileDialog::getOpenFileName(
            this, "Select Image", dir, "Images(*.jpg);;All files(*.*)");
if(imagePath == "")
    return;
 
QString projectPath = projectFiles.value("projectPath");
 
// Copy image to project directory.
QFileInfo temp(imagePath);
QString fileName = temp.fileName();
QFile::copy(imagePath, projectPath + "/" + fileName);

QString dir = QStandardPaths::writableLocation(
            QStandardPaths::PicturesLocation);
QString imagePath = QFileDialog::getOpenFileName(
            this, "Select Image", dir, "Images(*.jpg);;All files(*.*)");
if(imagePath == "")
    return;

QString projectPath = projectFiles.value("projectPath");

// Copy image to project directory.
QFileInfo temp(imagePath);
QString fileName = temp.fileName();
QFile::copy(imagePath, projectPath + "/" + fileName);

To copy to clipboard, switch view to plain text mode 

The other one is the same, except it looks for a different file type. projectFiles is a QHash that, in this case, gives the path where the file will be copied to. it may, or may not, be relative, but it is relative for this. Once the file gets copied, there are no problems with the rest of it, where it works on the copied file. I am not doing anything inside the dialog, other than getting the path to the file, so even if the current directory changes during that time, it should revert back once I exit it. Unless I am completely missing something.

[d_stranz]

it should revert back once I exit it. Unless I am completely missing something.

That's exactly the point. You don't really know if the QFileDialog is changing what Qt thinks is the current path or not, and making the assumption that somehow QFileDialog pushes the current path onto some kind of stack and then pops it back off when it goes out of scope might be a wrong assumption.

Modify your code to use the example I posted to set up the QFileDialog. Take your code that occurs from line 5 onward and move it into the slot that handles the QFileDialog::fileSelected() signal as I showed above, and check your paths there. Also do it following the fd.exec() call. You could put all of the code in my example method inside a sub-block (i.e. enclose it in braces ({}). Then, outside the braces, check the paths again. The QFileDialog would have gone out of scope at that point, so you can see whether or not the state is restored.

[admkrk]

That's exactly the point. You don't really know if the QFileDialog is changing what Qt thinks is the current path or not, and making the assumption that somehow QFileDialog pushes the current path onto some kind of stack and then pops it back off when it goes out of scope might be a wrong assumption.

Yeah I can be pig headed sometimes. The next couple days are going to be busy for me, but I will report back with the results when I get the chance.

I did check the current path in several places; before and after the QFileDialog call, for example, but did not think to scope it out.

[admkrk]

Change of plans so...

I setup the dialog as suggested, and scoped it out from the declaration to exec(). Checked the current directory before the block, at the end of the block, after the block, and in the slot. The current directory never changed from the application directory. The file still would not copy, until I added the whole path. Before using the whole path, I also changed it so I could get the error message, which was the same as originally; Error: "Cannot create /projects/Test/7segment2.csv for output".