What are QKeyEvent.nativeModifiers()? The documentation doesn't say much (https://doc.qt.io/qtforpython/PySide6/QtGui/QKeyEvent.html#PySide6.QtGui.PySide6.QtGui.QKeyEvent.nativeModifiers). From what I understand, the integer that is returned by calling this method on a QKeyEvent object represents the full state of the modifier keys (Ctrl, Shift, Alt, etc.).
Moreover, I would assume that the mapping between these integers and their respective modifier states is systematic, so is there a way to test whether a given modifier state contains a specific modifier (e.g. by using the "&" operator)?
Importantly, are the native modifiers cross-platform such that a Left Ctrl keypress on a PC returns the same integer as a Left Command on a Mac (since Qt.Key_Control corresponds to the MacOS command keys)?
As name suggests native modifiers has different values on mac and on pc. On windows value is a combination of WindowsNativeModifiers, on macOS it is a combination of NSEventModifierFlags, both translated to Qt::KeyboardModifiers (windows macOS) which is same on both platforms.
Related
UPDATE: If you want to help test this quickly in your locale. Launch PowerShell (hold down the Windows key, tap R, release the Windows key, type in "powershell" and press OK) and run this
command - (is the InstallDate2 column empty? Please let us know what you see.):
Get-WmiObject Win32_Product | Format-Table -Property InstallDate, InstallDate2, Name
I should start by saying that this issue is not critical for me (yet), but I am baffled. I am accessing the WMI object Win32_Product, and there are two properties related to dates: InstallDate and InstallDate2 respectively.
InstallDate seems to be a string representation of a DateTime value without the time part. Sort of a cut-off UTC format. Example: 20170819. The field is a string value, and not a DateTime format.
InstallDate2 is supposed to be in real DateTime format, but it is consistently null for all Win32_Product items on all my systems (Windows 7, Windows 10, various editions).
Using WMIExplorer.exe I see this description of InstallDate: "...the InstallDate property has been deprecated in favor of the InstallDate2 property which is of type DateTime rather than String. New implementations should use the InstallDate2 property."
As stated I get null back on all my machines, so I was assuming that InstallDate2 was simply not implemented properly, but then I found this article: Working with Software Installations. This article clearly shows InstallDate2 returning a WMI DateTime (with missing time part?): InstallDate2 = 20060506000000.000000-000.
I am simply wondering what can be causing this InstallDate2 null value on all my systems when I see it working on other systems? Some possibilities that has crossed my mind (one more far fetched than the next perhaps):
OS issue? I don't have access to older OSs, but I see null on several different editions (home, ulitmate, etc...) of Windows 7 and Windows 10 systems. Perhaps it worked on XP and older? I find this unlikely.
Locale issue? I am in a Norwegian locale. Could this affect things? I tried briefly to change the locale on a Windows 10 system, but it had some language pack issues and the result was the same.
Domain (network) issue? Is it conceivable that machines in workgroups work differently than machines that are part of a domain?
Patch level? Could a recent Windows Update have changed something in WMI?
What else could conceivably affect this?
And a second part of the question (in addition to what the cause of the null value for InstallDate2 is). The string I get back for InstallDate (the string format date): 20170819. I am assuming this is just a chopped of version of Universal Time Coordinate (UTC) format. And that it is a locale-independent format? It seems like it when I read about CIM_DATETIME.
I tried filling the rest of the chopped off date string with zeros and passing it to a SWbemDateTime scripting object, and it seemed to work, but that really smells as a "solution". Doesn't seem reliable at all:
Set dateTime = CreateObject("WbemScripting.SWbemDateTime")
dateTime.Value = "20170601000000.000000+000"
MsgBox dateTime.Year
MsgBox dateTime.UTC
It shows 2017 for year, and 0 for UTC. With such a "solution" I obviously really want to get the InstallDate2 DateTime field working correctly so I get a proper Datetime back.
So in all its verbosity, basically a two-part question:
What could be causing Win32_Product.InstallDate2 to consistently report null seemingly only on my systems?
The short string returned by InstallDate - is this in a locale-independent format?
Since I am in a Norwegian locale and see what looks like an English style format, it would seem that it is? Since the field is just a string, the content could basically be "anything" though.
It would be great if someone in another locale could verify that the format returns as: Win32_Product.InstallDate = yyyymmdd.
Reading about CIM_DATETIME seems to indicate the string is locale-independent (even if chopped off).
If you want to test, the quickest way is probably using wbemtest.exe (or better yet PowerShell if you have it available on your box - as mentioned by JosefZ in the comment below):
Launch wbemtest.exe (Hold down the Windows key, tap R, release the Windows key, type in "wbemtest.exe" and press OK).
Click "connect" and then OK (namespace defaults to root\cimv2), and click "connect" again.
Click "Query" and type in this WQL command: SELECT Name,InstallDate2 FROM Win32_Product and click "Use" (or equivalent).
Double click any entry returned, and check InstallDate2 in the middle list box (scroll down).
In my opinion you won't get a full date-time back. The only information available is effectively from MsiGetProductInfo (...INSTALLPROPERTY_INSTALLDATE....). This format is YYYYMMDD. You're only ever going to get the data because that seems to all there is. Note that the documentation for INSTALLPROPERTY_INSTALLDATE says that it is the installation date only if there has been no other servicing since the product was installed, so it appears that you can't even rely on it being the date the product was installed.
See Detecting the time when the program was installed
I suspect the best way to get the time the product was installed is to get the local package path with MsiGetProductInfo (Ex) ...INSTALLPROPERTY_LOCALPACKAGE... and get the cached MSI's CreationDate.
I am trying various different options of building Asterisk 11 and these will be deployed on various servers. They are all built from the same sources and have what I presume to be some sort of checksum embedded in the version ID (26dd464).
In order to distinguish the various versions of the executable I would like to add my own version number or string on similar. I note that /usr/src/asterisk/main/version.c specifies a const char [] variable asterisk_version, but if I manually edit this it gets overwritten as part of the make process. Is there a sensible way I could specify some sort of identifying label (e.g. as a parameter passed to make or some such)?
In /usr/src/asterisk/build_tools/make_version_c you can specify it. This script overwrites the file you've mentioned (/usr/src/asterisk/utils/version.c).
I'm trying to do a case-sensitive search in Nano. The help menu at the bottom of the screen says I can toggle case-sensitivity by typing M-C.
^G Get Help ^Y First Line ^T Go To Line ^W Beg of Par M-J FullJstify M-B Backwards
^C Cancel ^V Last Line ^R Replace ^O End of Par M-C Case Sens M-R Regexp
I'm not sure how to do this. Does M- refer to a modifier key that should be held while I type C? Or does M- mean I should press some key or key combination before hitting C?
M refers to the meta key, which is not present on most keyboards. (Its use in software is for primarily historical reasons.) Usually, the meta key is emulated by another key on your keyboard. On Windows and Linux, it is usually the Alt key. On Mac OS X, that key (aka Option) already has other uses, and so Escape is used instead.
Esc
For instance, if you wanted to go to the end of the file press
Esc then /
You don't need to hold down Esc as if it were Shift.
I do not know for nano, but for emacs, M- stands for the Meta key, which can mean pressing the Alt key simultaneously with the letter key or by pressing Esc key before the letter key. Alt generally only works when using an X version of the application, so when using a dumb terminal, only Esc will work.
I have a necessity to add support for a proprietary headers that FPGA in our design inserts in incoming Ethernet frames between MAC header and payload. Obviously have to dig in tcpdump sources and libpcap, but could anybody give some hints at where exactly to start, so that I could save time?
The first thing you need to do is to get a DLT_/LINKTYPE_ value for your proprietary headers. See the link-layer header types page on the tcpdump.org Web site for the existing DLT_/LINKTYPE_ link-layer header type values and information on how to either use one of the DLT_USERn values internally or get a new value assigned if you plan to have people outside your organization use this.
Once you have the value assigned, you'll have to do some work on libpcap:
If you've been assigned a DLT_ value, you'll have to modify the pcap/pcap.h file to add that link-layer type (and change the DLT_MATCHING_MAX value in that header file, and LINKTYPE_MATCHING_MAX in pcap-common.c, so that they are >= your DLT_ value), or wait for whoever at tcpdump.org (which will probably be me) assigns your DLT_ value and updates the libpcap Git repository (at which point you could use top-of-trunk libpcap).
If you plan to do live capturing, you may have to add a module to libpcap to support live capturing on your hardware, or, if your device looks like a regular networking device to your OS, so that you can use its native capture mechanism, modify the module for that OS to map whatever link-layer header type value the OS uses (e.g., a DLT_ value on *BSD/OS X or an ARPHRD_ value on Linux) to whatever DLT_ you're using for your link-layer header type.
You'd have to modify gencode.c to be able to compile capture filters for your DLT_ value.
Once that's done, libpcap should now work.
Now, for tcpdump:
Add an if_print routine that processes the proprietary headers (whether it just skips them or prints things for them), calls ether_print(), and then returns the sum of the length of your proprietary headers and the Ethernet header (ETHER_HDRLEN as defined in ether.h). See ether_if_print() in print-ether.c for an example.
Add a declaration of that routine to interface.h and netdissect.h, and add an entry for it, with the routine name and DLT_, to ndo_printers[] if you copied ether_if_print() (which you should) or to printers[] if you didn't (if you didn't, you'll have to pass &gndo as the first argument to ether_print()). Those arrays are in tcpdump.c.
If I add a listener to KeyboardEvent.KEY_DOWN, I can find out the keyCode and the charCode.
The keyCode maps to a different character depending on the keyboard.
The charCode is just as useless, according to the help:
The character code values are English keyboard values. For example, if you press Shift+3, charCode is # on a Japanese keyboard, just as it is on an English keyboard.
So, how can I find out which character the user pressed?
You left out a pretty important part of the quote or it was missing where you found it:
For example, if you press Shift+3, the
getASCIICode() method returns # on a
Japanese keyboard, just as it does on
an English keyboard.
http://livedocs.adobe.com/flex/201/langref/flash/events/KeyboardEvent.html
This is probably more helpful:
The charCode property is the numeric value of that key in the current character set (the default character set is UTF-8, which supports ASCII).
http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000480.html
Your application determines what characters set is used, meaning that the even if you have to use separate keys of different keyboard locals to produce the same character, it will have the same charCode.
NOTE: (This is about keyboard messages in general and does not apply to actionscript alone. I misread the question and provided a deeper answer then was helpful)
Really, the path from keyboard to windows char is a VERY complex one, it goes something like this:
Keyboard send scancode to Keyboard device driver (KDD).
KDD sends a message to the system message queue.
The system then sends the message to the foreground thread that created the window with the current keyboard focus.
The thread's message loop picks up the message and figures out the correct character translation.
The 'real' char that was typed is not calculated until it finishes that whole process, as each window and thread can be on a different locale and you can't really 'translate' the key without knowing the locale and key buffer history.
The "WM_KEYDOWN" and "WM_KEYUP" messages cannot just be converted with MapVirtualKey or something because you don't know how many key presses make up a single char. The simple method is just handle the 'WM_CHAR' event and use that. Consider the following:
en-US locale, you press the following keys a + ' + a, you get the following output "a'a"
pt-BZ locale, you press the following keys a + ' + a, you get the following output "aá"
So in both examples you would get 3 KEYDOWN, KEYUP messages, but in the first you get 3 WM_CHAR and in the second you only get 2.
The following article is really good for the basic concepts:
http://msdn.microsoft.com/en-us/library/ms646267(VS.85).aspx
You cannot effectively use charCode or keyCode to determine the character that was entered. You must compare strings only. The KeyboardEvent does not give you the entered text, which is also silly.
In my case I implemented a KeyboardEvent.KEY_DOWN event in addition to a TextEvent.TEXT_INPUT event. In the handler for the latter I implemented all functionality where the charCode was needed and didn't vary per keyboard locale (eg. space bar or enter). In the the former I checked for the text property of the event to compare what I needed locale independent.
Forgot to mention that this post hinted me to that solution: How to find out the character pressed key in languages?
Typing Japanese hiragana etc characters often require several keystrokes and sometimes even selecting the appropriate character from a drop down menu. You probably want to listen for a different event, something like a textfield's change event.