I store my settings using QSettings class and sometimes, it gives me a strange behavior.
I use this to add a value :
QSettings _settings("MyCompany", "AppName")
_settings.setValue("lastfile", "SomeString");
And this to remove all values :
QStringList indexes = _settings.allKeys();
foreach(QString index, indexes)
_settings->remove(index);
And it seems to work randomly. Sometimes it add or remove the value to the .plist file (I checked it using _settings.fileName()) and sometimes nothing change.
My question, which is kind of implicit, is what am I missing and how to make it work normally?
Set the format with: -
QSettings::setDefaultFormat(QSettings::NativeFormat);
Related
The "delete" key on my Macbook is broken. I am attempting to use the hidutil command to remap F1 as my new delete key. The command isn't performing as expected.
The command requires the hex ID's for the keys whose values I'd like to interchange. I've located a resource that provides these hex ID's as well as an overview of how to perform the remapping (https://developer.apple.com/library/archive/technotes/tn2450/_index.html).
I've posted my specific code below. It adheres to the suggested format, but my OS doesn't seem to register any change. Can someone help me identify the issue? I suspect my Hex ID's are wrong, but it may very well be another issue.
Input :
hidutil property --set '{"UserKeyMapping":[{"HIDKeyboardModifierMappingSrc":0x2a,"HIDKeyboardModifierMappingDst":0x3a}, {"HIDKeyboardModifierMappingSrc":0x3a,"HIDKeyboardModifierMappingDst":0x2a}]}'
Output :
UserKeyMapping:(
{
HIDKeyboardModifierMappingDst = 58;
HIDKeyboardModifierMappingSrc = 42;
},
{
HIDKeyboardModifierMappingDst = 42;
HIDKeyboardModifierMappingSrc = 58;
})
There are no error objects. And judging by the output after the command is run some key remapping has occurred. However, my F1 key still retains functionality as F1 and doesn't delete I'd expected.
Your referenced link on apple.com says "The keys take a hexadecimal value that consists of 0x700000000 or’d with the desired keyboard usage value." So I think you should try e. g. HIDKeyboardModifierMappingSrc":0x70000002a ...
Thanks for the above information, I was able to remap the right Ctrl key to be the Command key on the mac with the following command.
% hidutil property --set '{"UserKeyMapping":[{"HIDKeyboardModifierMappingSrc":0x7000000e4,"HIDKeyboardModifierMappingDst":0x7000000e3}]}'
This is because I am using a very old IBM original keyboard that does not have a windows key, just an empty space between the Ctrl and Alt keys on the left and right of the Space bar.
I am trying to modify existing input cdf file to use SHA256 instead of SHA1 by adding following two lines under [CatalogHeader] section:
CatalogVersion=2
HashAlgorithms=SHA256
Executing makecat.exe now gives me following failure message even though nothing under [CatalogFiles] has changed:
Failed: CryptCATCDFEnumMembersByCDFTagEx. Last Error: 0x00000057
Failed: No members found. Last Error: 0x00000057
Failed 0x00000057 (87)
Makecat does find and hash all files if I take out two lines I added.
Can anybody give me an idea what might be going wrong here?
Here is an example cdf file for MCVE:
[CatalogHeader]
Name=MCVE.cat
CatalogVersion=2
HashAlgorithms=SHA256
[CatalogFiles]
MCVE.xml=MCVE.xml
MCVE.xml is any old xml file you can find.
I encountered the same problem but was able to get it to work by putting '< HASH >' (without spaces) in front of each file entry. Example:
[CatalogFiles]
<HASH>manifest.json=.\manifest.json
<HASH>bsi.json=.\bsi.json
However, this causes the catalog file's entries to be tagged by their hash, instead of their filename, when viewing the .cat file in Windows Explorer. You can somewhat work around this by adding a custom attribute to display the filename in the catalog entry's details, as follows:
[CatalogFiles]
<HASH>manifest.json=.\manifest.json
<HASH>manifest.jsonATTR1=0x11010001:File:manifest.json
<HASH>bsi.json=.\bsi.json
<HASH>bsi.jsonATTR1=0x11010001:File:bsi.json
The attribute type is composed of (https://learn.microsoft.com/en-us/windows/desktop/seccrypto/makecat):
0x10000000: attribute is included in the catalog's hash
0x01000000: don't create a duplicated attribute with SHA1 hash (when using SHA256 and catalog version 2)
0x00010000: attribute is in plaintext, not base64
0x00000001: attribute is a keyvalue pair (e.g. File=bsi.json)
I discovered this workaround after running into the same problem as you when I found this example here: https://www-user.tu-chemnitz.de/~heha/viewzip.cgi/basteln/PC/USB2LPT/usb2lpt.zip/src/Makefile?auto=MAK
Hope this helps.
Can't add comments yet ---
Just wanted to say Jonathan's example with the 0x11010001 attribute works great, but PowerShell's Test-FileCatalog will still say it fails to parse the file. Using FilePath instead of File fixed this. Not sure if this is in the spec or just a powershell quirk or what, but it's what PowerShell does with New-FileCatalog.
Bonus points for not including the SHA1 hash, thanks!
My problem is the same as the one mentioned in this answer. I've been trying to understand the code and this is what I learned:
It is failing in the file parse_xml.cgi, tries to get messages (return $message{$name}) from a file named messages (located in the html_en directory).
The $messages value comes from the method GetMessageHash in file adminprotocol-lib.pl:
sub GetMessageHash
{
return $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"}
}
The $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} is set in the file streamingadminserver.pl:
$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} = $messages{"en"}
I dont know anything about Perl so I have no idea of what the problem can be, for what I saw $messages{"en"} has the correct value (if I do print($messages{"en"}{'SunStr'} I get the value "Sun")).
However, if I try to do print($ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"}{'SunStr'} I get nothing. Seems like $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} is not set
I tried this simple example and it worked fine:
$ENV{"HELLO"} = "hello";
print($ENV{"HELLO"});
and it works fine, prints "hello".
Any idea of what the problem can be?
Looks like $messages{"en"} is a HashRef: A pointer to some memory address holding a key-value-store. You could even print the associated memory address:
perl -le 'my $hashref = {}; print $hashref;'
HASH(0x1548e78)
0x1548e78 is the address, but it's only valid within the same running process. Re-run the sample command and you'll get different addresses each time.
HASH(0x1548e78) is also just a human-readable representation of the real stored value. Setting $hashref2="HASH(0x1548e78)"; won't create a real reference, just a copy of the human-readable string.
You could easily proof this theory using print $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} in both script.
Data::Dumper is typically used to show the contents of the referenced hash (memory location):
use Data::Dumper;
print Dumper($messages{"en"});
# or
print Dumper($ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"});
This will also show if the pointer/reference could be dereferenced in both scripts.
The solution for your problem is probably passing the value instead of the HashRef:
$ENV{"QTSSADMINSERVER_EN_SUN"} = $messages{"en"}->{SunStr};
Best Practice is using a -> between both keys. The " or ' quotes for the key also optional if the key is a plain word.
But passing everything through environment variables feels wrong. They might not be able to hold references on OSX (I don't know). You might want to extract the string storage to a include file and load it via require.
See http://www.perlmaven.com/ or http://learn.perl.org for more about Perl.
fix code:
$$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} = $messages{"en"};
sub GetMessageHash
{
return $$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"};
}
ref:
https://github.com/guangbin79/dss6.0.3-linux-patch
I have some UNICODE text in my win32 code.
I have declared it something like this..
std::wstring a = Träna; //swedish for practice
I copy that value into a variable using something like...
std::wstring b = a;
While debugging I don't see what im supposed to get in b.
I should be getting Träna in b, but what i get is Träna
This is observed only on windows, the program works fine on OS X.
I'm sure its some rookie mistake, what am i missing here?
As #SigTerm and #jukka said above, the issue was with UTF-8 encoding.
After saving the cpp file in <Unicode UTF-8 with signature> the issue was solved.
The file was earlier saved in <Unicode UTF-8 without signature>.
It wasnt't the issue with prefixing L, i already have defined my variables like that.
I'm trying to change some registry settings using an AutoIt script. The regWrite() method returns 1, which means that it was successful and when I call RegRead() on the same key it gives me the value that I passed into RegWrite(), but the value in does not change in regedit, even if I reboot the computer. I tried it on more than 10 keys and none of them really changed.
Sample code:
This is just one of the values I tried to change:
#RequireAdmin
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\ESET\Setup\CurrentSession","RebootSignal","REG_DWORD","0x00000000")
You should use
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\ESET\Setup\CurrentSession","RebootSignal","REG_DWORD",0x00000000)
or
RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\ESET\Setup\CurrentSession","RebootSignal","REG_DWORD",0)