problem with application after it runs on start up

[budda]

SO I wrote an application with Qt 4.6 in Windows 7, that uses a few .txt files for storing information. It runs just fine when I run it from the release folder.
However, I implemented QSettings to add the application to the registry so that it runs on system startup. It does this just fine, BUT my problem is that it then does not open and read the text files. I'm guessing because its not in the actual directory when running from the startup. At first I realized that I was using a Relative path in the same directory as the application, so I grabbed the application Dir Path through the main when I call



#include <QtGui/QApplication>
#include "mainwindow.h"


int main(int argc, char *argv[])
{

QApplication a(argc, argv);
QString exePath = a.applicationDirPath();
MainWindow w;
w.exePath = exePath;
return a.exec();

}


exePath is a Public QString in mainwindow.h

so, when I open the file to read, I put the applicationDirPath in front of the file name and use the absolute path.
with:



QString thisDir = exePath;
thisDir += "time.txt";

QFile fileOpen(thisDir);


but this still doesn't solve the problem. And nothing is opened when it's run from startup in the registry... Does anyone know why this is happening? Are startup programs forbidden to open text files, or is it just running from some different directory still? Some tips would be great, because every time I test this, I have to restart the machine after a new change/compile/and run. And this is starting to get tedious....

[Jonny174]

See to output:


if (fileOpen.open( QIODevice::ReadWrite ))
{
}
else
qDebug( fileOpen.errorString() );

[ChrisW67]

If by "store information" you mean write to these files then you should know that you cannot write to protected directories on Windows 7: this includes "Program Files" and subdirectories. Use QDesktopServices or Windows API calls to find a better location to store these files.

[budda]

Thanks, that QDesktopServices tip totally worked and fixed my read file on startup problem and the future write to file problem I wasn't aware of as I haven't put the application into Program Files yet...

[wysota]

I think your reads failed because you were missing a directory separator between applicationDirPath() and the file name.

[d_stranz]

ChrisW67's observation is mostly correct: in Win 7, applications are forbidden from creating files in protected directories. In our experience, if we try to create a file after installation of the app, this fails. However, if we use the installer (NSIS, in this case) to create an empty file at installation time, we find that we can then write to it afterward.

Of course, Micro$oft wants you to use "Application Data" instead, but in our case, the file was required to be in the app startup folder. Took a while to figure out what was wrong and how to fix it.