Saving a file using a relative path

[Lesiok]

Is it possible that the class constructor is called before QDir::setCurrent(QCoreApplication::applicationDirP ath()); ?

---

Added after 5 minutes:

I think I understand what you are saying, but am not sure how that would affect this since I am not running it from command line.

I did as you suggested before and used

QDir::setCurrent(QCoreApplication::applicationDirPath());

QDir::setCurrent(QCoreApplication::applicationDirPath());

To copy to clipboard, switch view to plain text mode 

in main(). Is that not supposed to make QDir::current() constant? The only difference is where in the class I put

QString path = QDir::current().currentPath();
path.append("/data/completer.txt");

QString path = QDir::current().currentPath();
path.append("/data/completer.txt");

To copy to clipboard, switch view to plain text mode 

If I put it in the constructor, the result is: path_to_Build_folder/data/completer.txt.
If I put it in my function, the result is: path_to_Build_folder/debug/data/completer.txt.
The only difference I can see is when it is called. What I do not understand is how the directory is affected by that.

I am starting to think that having it in the constructor is not a good idea anyway, since the list will not be updated if it is changed somewhere else. I do not really want to do a read every time the user edits a cell either, though.

The IDE is running application that way (simulation) :

cd path_to_Build_folder<ENTER>
debug/app_name<ENTER>

cd path_to_Build_folder<ENTER>
debug/app_name<ENTER>

To copy to clipboard, switch view to plain text mode 

It is like example number 2 from my post.

[admkrk]

I did notice that the constructor was called sooner than I thought it would be, but I still thought it would have been after setCurrent(). Thinking about it now, I see how that was not necessarily right.

The IDE is running application that way (simulation) :

cd path_to_Build_folder<ENTER>
debug/app_name<ENTER>

cd path_to_Build_folder<ENTER>
debug/app_name<ENTER>

To copy to clipboard, switch view to plain text mode 

It never crossed my mind to think about how the IDE runs the application. I made a very simple IDE, as a school project, a couple of years ago. I do not remember how I handled it, but I can see how that could be the case.

Thank you for your patience with me.

[d_stranz]

It never crossed my mind to think about how the IDE runs the application.

A common "gotcha!". The last word in IDE is "environment", and it is configured in such a way as to establish the current working directory, paths to executables and runtime binaries needed for development and debugging, and so forth.

The IDE's environment may be different from the environment obtained when running from a command prompt, which may be different from the environment obtained when the program is run from a file system browser (like Windows Explorer), which may be different from the environment obtained when running a program from a Desktop icon or the Start menu.

And if you use a file browser from within your program (to allow the user to select files to open), this also can change the current working directory.

[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".