I have two projects that both use the settings:
QSettings settings(
QSettings::SystemScope,
QCoreApplication::organizationName(),
QCoreApplication::applicationName());
I was under the impression that with SystemScome and the same application and organization names that these settings would be linked. But they aren't. What's the best approach for this?
Thanks!
EDIT:
It was on Linux, and I believe sudo needed to be used for SystemScope. UserScope did however work.
As it is thoroughly written in documentation - QSettings: Platform Specific Notes the path which QSettings use to store settings is uniquely determined by application and organization name parameters.
The First thing you could do is to check is settings are truly being written in location mentioned in link above for your system and what is different for those two applications. For example, there is a singular case that for windows their will be different for x86 and x64 applications.
Also if you try to use them simultaneously for both applications you should remember to use sync () function or create new QSettings instances when it's needed so the apps wouldn't conflict in operating on them.
Related
I've segregated my WinUI 3 application into different layers: Application, Infrastructure, Presentation etc.
And all the projects have targets: net6.0-windows and I want to move it to the Uno Platform.
So, I've added a new target: net6.0
And at this moment the problem arises:
Type [WinUI] component already defines a member, called InitializeComponent or some problems with binding.
Is it possible to make such type of library with targets to net6-windows and net6.0?
For the Windows app project itself, you need to use net6-windows, as that provides additional dependencies specific to Windows app projects. All other libraries (non-app projects) can then use net6.0.
Regarding the specific error message, you are getting, the reason might be the generated files have some kind of conflict - you can try deleting the obj and bin folders and rebuild.
The easiest way to make existing Windows app support Uno would probably be to create a blank Uno solution and then migrate the code there (as the solution has already the required setup for platform-specific projects prepared and you can then just add your code.
Uno also provides templates for cross-targeted libraries, so you might be able to use similar approach. The one linked is for "UWP" solution however, so to make it WinUI, you would need to switch from uap10.0.18362 to net6-windows.
I'm writing a Qt application for windows, and using windows 7 64 bit.
The application has to write to the registry, I tried to use QSettings class, but as I found in the documentation:
On Windows, for 32-bit programs running in WOW64 mode, settings are
stored in the following registry path:
HKEY_LOCAL_MACHINE\Software\WOW6432node\MySW
Is there a way to override it and write to: HKEY_LOCAL_MACHINE\Software\MySW directly?
Clarification:
The application is writing to the registry, the keys written are to be used by other application, which I cannot know if running on 64 or 32 bit mode.
I know it is possible in C#, so it must be possible in C++.
See this article on MSDN:
32-bit and 64-bit Application Data in the Registry
It appears that using some of the Win32 API you might be able to change how this behaves. Although I'm not sure why the default behavior won't work for you.
I suppose that if you want to do it in Qt then this would be the most appropriate way:
[ Source: http://doc.qt.digia.com/4.7/qsettings.html#accessing-the-windows-registry-directly ]
Accessing the Windows Registry Directly On Windows, QSettings lets you access settings that have been written with QSettings (or settings in a supported format, e.g., string data) in the system registry. This is done by constructing a QSettings object with a path in the registry and QSettings::NativeFormat.For example:
QSettings settings("HKEY_CURRENT_USER\\Software\\Microsoft\\Office", QSettings::NativeFormat);
All the registry entries that appear under the specified path can be read or written through the QSettings object as usual (using forward slashes instead of backslashes).For example:
settings.setValue("11.0/Outlook/Security/DontTrustInstalledFiles", 0);
I'm using Qt.
I could not find the function or class to start application at booting time.
In windows, for example, add register to HKMU/Software/Microsoft/Windows/CurrentVersion/Run.
I wanna know the function/class like above example.
You can use QSettings in order to set a value at Windows Registry.
QSettings settings("HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run",
QSettings::NativeFormat);
and then use the setValue function.
However this will work only in Windows so it is better to use an #ifdef before calling it.
The only thing I can think of is the QtService framework. It is available for all the major platforms (look here). It might not be exactly what you were looking for but it may help.
It is also important to mention that a Windows service has no direct access to the graphical interface. This means that if the application is graphical, you'll probably have to redesign it.
There is no such API in Qt, you have to search for 3rdparty library or write whole code on your own.
I have a sneaking suspicion that what I'm looking to do can be done more elegantly within Xcode 4 ... but then I've been wrong before. Here's the scoop:
I have an iOS app with the usual debug/release builds and regular, unit-test, and ui-test targets. Nothing unusual there. The app also calls out to a server. Nothing special there either. Except ...
Now I want to be able to build the app for four different server environments: Development, QA, UAT/Beta, and Production. In addition, each build must be able to co-exist on the same device, for developer builds or ad hoc distribution.
So let's see ... how might this pan out? Each app will need its own target identifier for starters. Perhaps detecting the kind of build could help target which server to use:
Debug builds target Development.
(Ad Hoc Distribution) Release builds target QA (... or UAT/Beta?).
(App Store Distribution) Release builds target Production.
As for those Target Identifiers (com.companyname.appname), I suppose I could use different Info.plist files for each build ... but that smells unwieldy (duplicate info). Perhaps it's the only way?
Bottom line: I'm uncertain of a) how to resolve the Ad Hoc vs. App Store Distribution cases, as well as b) the QA/UAT cases, as well as c) how to do this without messing up the (at least to me) more elegant setup Xcode 4 offers with those simple "Press Play" Debug/Release build ops.
Maybe I have to add new Schemes? Perhaps it's simply a matter of adding more Info.plist files ... or builds ... or configurations ... or targets ... or some mixture. Again, I'm trying to keep from duplicating a lot of info (only to change one or two settings) if I can help it. Debug/Release seems very clean as it is, and I want to make sure I change things along the proper axis. Measure twice, cut once, as they say.
Clues welcome/appreciated!
Here's what I ended up doing. Hopefully this is the most sensible way to go about it:
For now, I combined QA and UAT. (This may be split later on.)
I made three Info plists, one for Development (Debug), Beta/QA/UAT (Release), and Production (Release). Each of these has slightly different bundle display names, bundle identifiers, and bundle names, but is otherwise identical. (THIS is where the lion's share of duplicate info will be. Have to change things in all three - for instance, if I add a new font or URL type.)
I created a new configuration, Beta (based on the original Release/Production config), so now there's Dev, Beta, and Production configs as well.
In the Provisioning Portal, I set up App IDs using the previously declared bundle IDs, and generated new certs for Beta, Dev, and Production. (The existing app ID ends up being used for App Store releases.)
In the Build Settings, I used Conditional Settings to specify the appropriate Info plists and code signing identities.
I think this will do the trick! If there's a cleaner way, however, please weigh in. Thanks!
regsvr32 filename.ax
I just see it said something installed successfully,but what's the whole story?
COM that is widely used in Windows relies on registration. A component will provide type libraries, interfaces and classes. Each of these are defined by a GUID to uniquely name them. COM components can also defined ProgID's that are kind of shortcuts to the unwieldy GUID's.
All this information is stored in a special registry hive on the computer named HKEY_CLASSES_ROOT. Use RegEdit.exe to view it. In particular you can find type libraries in HKEY_CLASSES_ROOT\TypeLib, interfaces in HKEY_CLASSES_ROOT\Interface and classes in HKEY_CLASSES_ROOT\CLSID. Some of the information in the registry will contain the path of the actual DLL with the component allowing Windows to locate and load the component when it is requested.
When you install a COM component it is necessary to create the correct registry information. By convention the DLL can provide two exported functions:
DllRegisterServer
DllUnregisterServer
When you execute RegSvr32.exe MyComponent.dll the RegSvr32.exe executable will attempt to call DllRegisterServer in MyComponent.dll. The DLL is then supposed to create all the necessary registry entries to allow the component to be used.
In a similar way you can use RegSvr32.exe /u MyComponent.dll to unregister the component. That will remove all the information previously added to the registry.
Windows relies heavily on COM and it is very important that COM registrations are up to date. Unfortunately there is nothing that blocks you from deleting an already registered COM component. This will leave dangling pointers in the registry pointing to the no longer existing DLL. You can't even unregister it since it no longer exists.
Another problem is when two different applications requires different versions of the same component. The registry can only point to one of the two versions, and this may cause one of the applications to fail.
Microsoft has created fixes for these problems. It is much better to provide an installer for the COM component that is able to repair and uninstall the component if it has been deleted. You are also able to create side-by-side installation of the same component in different versions.
It basically calls into your dll (named filename.ax in this case) and call its "DllRegisterServer" method.
In the case of directshow filters, it might "register" those filters in the windows registry so that directshow knows about them.
ex: https://github.com/rdp/directshow-demo-audio-input-open-source/blob/master/acam/virt_audio_all.cpp#L698 calls
https://github.com/rdp/directshow-demo-audio-input-open-source/blob/master/acam/virt_audio_all.cpp#L631
Though there are more simple versions out there.
regsvr32 registers DLL's and EXEs into the Windows Registry (usually COM Type Libraries, Class IDs, Interface IDs etc). You can use regedit to navigate the registry.