QFile open file on a shared drive - qt

I have the following:
Q_ASSERT(QFile::exists("\\.host\Shared Folders\username On My Mac\Desktop\New Deck.txt"));
The file is picked from QFileDialog but when check if it exists with QFile::exists it returns FALSE;
Is there any reason why QT cannot open a file on a shared drive.
Btw, this path is a valid one on Windows and is generated by putting the "New Deck.txt" file on my Mac OSX desktop and tried to be read from a QT application run from VM Ware Windows XP SP2.

You must escape \ in the string literal via \: "\\.host\Shared Folders\..."
Also, unless this is for your debugging only, asserting on the existing of files is a bad idea. The file could always disappear between selecting it in the file dialog and opening it.

Related

Location of the program in the JDK that opens .jar files(double-click)

I would like to know the LOCATION of the .exe in the JDK that opens .jar files. What I mean is this: Which .exe in C:\Program Files\Java\jdk*version number*\jre\ opens the .jar files, so that they can be opened using a double click? I used to be able to do that, when I newly installed the JDK+JRE. Unfortunately, Nokia PC Suite has made itself the default program for opening .jar files, so that it can install them on my Symbian. Which program do I 'Open With' to get back the old functionality? I already know how to do it from the command line, but this is easier.
There is no specific program to run jar files.
It is java.exe only with the -jar option
For eg.--> java -jar "foo.jar"
Right Click on a jar file and go to its properties. Change the default opening program to java.exe.
I hope that should work.
use javaw.exe if you don't want the command window.
This convention is widely followed by others like perl/python/ruby as well.
I know how frustrating this issue is. I looked all over the internet forums before I finally found the problem...Here is the answer below :
"The root cause for the problem above is, that a program has stolen the .jar association. If you have installed the Java Runtime Environment the first time, the file type called "jar" is assigned to javaw.exe correctly. "jar" is an abbreviation for "java archive" and javaw.exe is the correct program to execute a .jar. However, on Windows any program can steal a file type at any time even if it is already associated with a program. Many zip/unzip programs prefer to do this, because a jar is stored in the .zip format. If you doubleclick on a .jar, your pack program opens the file, rather than javaw runs the program, because your pack program ignores the meta information which are also stored in a .jar."

QSettings IniFormat File gets empty after restart

I use QSettings to save and load parameters to/from an ini file using Linux:
write:
QSettings settings("setup.ini", QSettings::IniFormat);
settings.beginGroup("Setup_Parameter");
settings.setValue("Parameter1",parameter1_value);
settings.sync();
settings.endGroup();
read:
QSettings settings("setup.ini", QSettings::IniFormat);
settings.beginGroup("Setup_Parameter");
parameter1_value = settings.value("Parameter1","0").toInt();
settings.endGroup();
The setup.ini works fine, while the system is on.
If i reboot my system by switching power off and on again, the setup.ini file gets completely empty sometimes. I would say in 3 out of 5 trys.
I already tryed saving the file in application and root/Settings path.
As well as copying the file after writing it, but then also the copy is empty after power off and on.
Why does the setup.ini File looses its content? It needs to keep the parameters while restart.
A sync() was required after the write function:
QSettings settings("setup.ini", QSettings::IniFormat);
settings.beginGroup("Setup_Parameter");
settings.setValue("Parameter1",parameter1_value);
settings.endGroup();
settings.sync();
sync();
I am experiencing the same problem. My QSettings file gets wiped out sometimes after a power reset. The file remains, but it is zero bytes in size. The QT application is running on Debian Squeeze on an ARM processor. The filesystem, OS, and application are all located on a 4G SD Card.
I've modified the application to call the sync function after any change to the Settings file. But we had a power reset last night and one of the units (we have about 60 running) lost its settings. We're running QTEmbedded-4.8.2, and I am at a loss how to fix this.
We have fixed the same problem calling 'sync' linux command after the 'sync' function of QSettings.

Qt: Cannot execute '': The requested operation requires elevation

I am not able to run the application the Qt creator. It complains the following error:
Cannot execute '': The requested operation requires elevation
My .exe file has a Windows administrator shield symbol on it. Do I need to make a project settings changes? I am extensively using Qt File library for doing some file operations.
What's your executable's file name? Without an embedded manifest, windows tries to be smart and wants to run executables with "install", "update", "setup", "patch", etc. in the file name as administrator. It even checks for those names within words such as "autoupdate".
The problem is that qmake/mingw doesn't embed those manifests, while MSVC does. If someone has a clean solution to that problem, I'd be interested to learn about it.
If application you develop require administrator privileges, you cannot simply run it from Qt creator, started under non privileged account.
You can run your Qt creator as Administrtor.
Or you can start your application from QtCreator using runas utility.
But in this case you would not be able to see debug output in QtCreator console window and debug application.
If the name of the exe file has some words (update, patch, ...), the Windows UAC ask for admin privilegies. The only solution is that the project generates an exe without these words.
See this: Qt Creator create exes with admin privilegies

Disambiguation warning when running application

I am developing a Qt application, and I've been asking some friends of mine to test it. One of them told me that he can't run the application. Here is the error he gets:
When he presses yes, then he gets a "mingwm10.dll was not found" message. Of course there is mingwm10.dll in the working directory and then it says "application stopped working" error. When he presses no, it opens PeaZip.
I've tested the application successfully on Windows XP, Windows 7 and Windows Vista, so I really have no idea what's going on. (However, my friend is using Windows Vista, if that's helpful)
So, do you have any idea what it means?
From PeaZip's user manual (PDF):
If a single archive file is dragged to the browser PeaZip will show a
disambiguation popup to ask if adding the object to the archive or
rather opening it.
So if I have to guess he is either not putting the executable and other files into a clean directory, but into an archive, or directly trying to run the application from the archive. Have you by any chance wrapped everything into a single zip file which you gave him?
Make sure everything gets put into a clean directory and try running the exe from there.

QFileInfo::exists() for a shared-drive file path

Question from a newcomer to QT: when I supply the exists() method of a QFileInfo object with a shared-drive file path, it always returns false, even with me escaping every backslash with another backslash (i.e. \\10.1.2.34.56\dir1). And yes, the directory does exist :) Could there be some other issue at work here, such as a lack of permission for the directory in question? Thanks in advance for any light you might shed on this issue...
It seems it works correctly on XP (with Qt 4.7.3) either with doubled backslashes or single slashes ('//ip/share/filepath').
Try getting the file url through QFileDialog::getOpenFileName. As it uses a native dialog, it should ask for your login/password if needed.
If QFileInfo can then find that the file exists, you could try using the native API (Windows Networking) to connect or allow access programmatically to the network share.
As it turns out, my issue had everything to do with permissions and nothing to do with escaping backslashes.
The application I inherited actually has two components: i) the window that provides the GUI interface for the app and (ii) the Window service that does the actual work. The window was able to "see" the shared drive because the Windows userid for which it was running had permission for that drive, whereas the Windows service running as the local system could not. Once I used the Services window to change the service to run under a userid with permission for that drive, then it ran just fine. Thanks for your response...

Resources