Qt stores QSettings values in the windows registry: https://doc.qt.io/qt-5/qsettings.html
Users normally expect an application to remember its settings (window sizes and positions, options, etc.) across sessions. This information is often stored in the system registry on Windows, and in property list files on macOS and iOS. On Unix systems, in the absence of a standard, many applications (including the KDE applications) use INI text files.
I wish to delete those entries if I un-install my Qt App. Is there an easy way to do this, without explicitly deleting all values. I am asking about a Qt function to delete all values for my particular application.
If you initialise the QSettings object with the company and application name or using the default constructor, you can use the method clear()
Example:
QSettings settings;
settings.clear();
Alternatively, you can also try:
QSettings settings(QSettings::SystemScope, "Org", "App");
settings.clear();
Related
I'm developing a Qt application that will be distributed on Windows and OS X.
The application makes use of an SQLite database. Where can I keep the database file on both systems for it not to be overridden during application updates?
Note 1:
I already find a similar question about that for OS X. The answer was to keep it in the Application Support using the following command:
NSString * supportDir = [NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, YES) lastObject];
But I need to do that on Windows too. Should I use this command on Windows too?
Note 2:
I'm using an INI file to store my application settings as follows:
QString path = QStandardPaths::writableLocation(QStandardPaths::ConfigLocation);
QSettings *settings = new QSettings(path+"/Settings.ini", QSettings::IniFormat);
The path variable is C:/Users/user/AppData/Local/MyApplication/ (Windows).
Can I store the database file in the same path?
Thank you.
Does QStandardPaths::AppDataLocation cover your requirements for this?
From the qt documentation:
Returns a directory location where persistent application data can be
stored. This is an application-specific directory. To obtain a path to
store data to be shared with other applications, use
QStandardPaths::GenericDataLocation. The returned path is never empty.
On the Windows operating system, this returns the roaming path. This
enum value was added in Qt 5.4.
I'm using GetOpenFileName to open files in C++, is it possible to set the initial dir at "Computer" virtual location with lpstrInitialDir?
Thanks,
Lee.
This is not possible with GetOpenFileName because the location you wish to use is not part of the file system. Rather it is part of the wider shell namespace.
If you look at the documentation for GetOpenFileName you will see that it has been superseded (over 10 years ago in fact) by the Common Item Dialogs. Those dialogs do allow you to specify the initial folder as a shell item.
If you need to support legacy Windows older than Vista, where IFileDialog is not available, try specifying a Shell folder GUID. For example, the My Computer GUID is 20D04FE0-3AEA-1069-A2D8-08002B30309D. You can specify it like this:
ofn.lpstrInitialDir = "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}";
However, it is worth noting that this method is almost doomed to fail on Windows 7 and later, due to behavioral changes
So, you are better off using IFileDialog on Vista and later instead.
I'm looking to store some "preferences" for my C++ application.
Under windows I know I have to use the "AppData" folder, but I need the equivalent for Linux and OsX.
Is there some library or portable way to get such information in C++ ?
Here is the code I use currently:
#ifdef VD_OS_WINDOWS
LPWSTR wszPath = NULL;
HRESULT hr = SHGetKnownFolderPath(FOLDERID_RoamingAppData, KF_FLAG_CREATE, NULL, &wszPath);
_bstr_t bstrPath(wszPath);
std::string strPath((char*)bstrPath);
CoTaskMemFree(wszPath);
return strPath;
#else
char* path = getenv("XDG_CONFIG_HOME");
if (!path)
getenv("HOME") + ".local/share";
return string(path);
#endif
Thanks
If you happen to write a Qt application, there is the QSettings Class. The documentation says the following about this class:
The QSettings class provides persistent platform-independent application settings.
Users normally expect an application to remember its settings (window sizes and positions, options, etc.) across sessions. This information is often stored in the system registry on Windows, and in XML preferences files on Mac OS X. On Unix systems, in the absence of a standard, many applications (including the KDE applications) use INI text files.
This delivers IMHO the best "out-of-the-box" experience. And it's really platform independent.
An alternative would be boost::program_options or boost::property_tree. But the aim of these libraries is the data handling, not so much the storage. This means you would still need to detect the platform, and store the data in the correct location.
Historically on Linux the program stores its configuration data in a hidden file or folder (one beginning with a dot .) in the $HOME directory.
So something like:
$HOME/.my_prog_data.conf
or
$HOME/.my_prog_data/config.conf
In a more recent effort to clean up the $HOME directory nowadays programs tend to either use $HOME/.config or $HOME/.local/share rather than $HOME itself.
I use IShellLink to get the target path of a shortcut. Most of the time it is good, but I am missing some of the files once in a while. I read somewhere that the Integrity Priority could be an issue. See Integrity Priority here - http://msdn.microsoft.com/en-us/library/bb625960.aspx
My question is - if I change the integrity priority of all the dll on my development machine, then build an install build with these dll's, and then move the install-build to another machine and install the program there; will the medium integrity priority I set persist on the new machine. Or I have to write a script to change the integrity priority after I install the program.
I am hoping I dont need to do anything after the install.
I don't know the IShellLink functionality very well so I'll try to address this from the Windows Installer point of view. ( Assuming that by referencing the installshield tag that you are using MSI. )
MSI uses the Shortcut table and if on Win7/Server2008R2 the ShortcutProperty Table. This article Application User Model IDs (AppUserModelIDs) has a section that says:
In the System.AppUserModel.ID property of the application's shortcut
file. A shortcut (as an IShellLink, CLSID_ShellLink, or a .lnk file)
supports properties through IPropertyStore and other property-setting
mechanisms used throughout the Shell. This allows the taskbar to
identify the proper shortcut to pin and ensures that windows belonging
to the process are appropriately associated with that taskbar button.
Note The System.AppUserModel.ID property should be applied to a
shortcut when that shortcut is created. When using the Microsoft
Windows Installer (MSI) to install the application, the
MsiShortcutProperty table allows the AppUserModelID to be applied to
the shortcut when it is created during installation.
The MsiShortCutProperty table is pretty new and I haven't really had any developers come to me wanting to leverage it yet so I haven't dug into the details of what all the various properties that can be set are. However, I suspect this is the road you need to go down.
I am newbie in WinCE Programming, i want to Create Custom File Dialog for our application, which has totally diffrent look and feel than the default windows file dialog....
I looked into many Flag value bt they won't worth it ...
Any pointers will be helpful
Thnks...
Mukesh
It depends on what level you're looking at replacing it. Do you want to replace it device-wide, or just for your app? If it's just for your app, create a new Dialog with the features you want and call it.
To replace it system-wide you have to have the ability (i.ee tools and BSP) to create a new OS image. You would clone the following folder in your project tree:
%WINCEROOT%\PUBLIC\SHELL\OAK\HPC\CESHELL\UI
Then modify the resource (and potentially code) files you want changes and rebuild your OS.