Bugs item #1728405, was opened at 2007-05-30 17:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1728405...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: keyname issues in Windows
Initial Comment: I only have tested this on Windows XP.
The [keyname] doesn't handle correctly at least the following keys: - space bar - enter - escape
It doesn't correctly return the key name on the right outlet.
With the space bar key, it returns "symbol ", which probably is "symbol" plus a space, but however, "symbol space" or something like that would be more appropriate, since in PD a space in a message is equivalent to just nothing and there is no way to handle it as far as I understand.
With enter key, it seems to output "symbol " followed by the actual newline character (appears as a square in the output window in Windows)
With the escape key, it has a peculiar and incoherent behaviour: on keydown, it outputs "symbol " plus some special character (and outputs a 1 on the left outlet), while on keyup it outputs "symbol Escape" (and a 0 on the left outlet) which is correct.
I think all keys should have a name. However, if we accept that some keys don't have a name, I think [keyname] shouldn't output anything when those keys are pressed or releases, just like [key] and [keyup] don't output anything when an unrecognized key is pressed.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1728405...
Hallo, SourceForge.net hat gesagt: // SourceForge.net wrote:
The [keyname] doesn't handle correctly at least the following keys:
- space bar
- enter
- escape
It doesn't correctly return the key name on the right outlet.
I believe everything is right on Pd's side, but cannot test ATM, so could you do the following test: You can make "symbol <space>" where <space> is an actual " " with [makefilename %c] and sending the ASCII-Number for space (32 IIRC). If you use this symbol in a [select DUMMY] object's right inlet to set the selected symbol, then you should be able to properly [select] on a <space>-symbol coming in from [keyname]. Same should be valid for other whitespace or some non-printing characters.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
SourceForge.net hat gesagt: // SourceForge.net wrote:
The [keyname] doesn't handle correctly at least the following keys:
- space bar
- enter
- escape
It doesn't correctly return the key name on the right outlet.
I believe everything is right on Pd's side, but cannot test ATM, so could you do the following test: You can make "symbol <space>" where <space> is an actual " " with [makefilename %c] and sending the ASCII-Number for space (32 IIRC). If you use this symbol in a [select DUMMY] object's right inlet to set the selected symbol, then you should be able to properly [select] on a <space>-symbol coming in from [keyname]. Same should be valid for other whitespace or some non-printing characters.
Okay, I could test this now: Backspace, Esc and Space work with that patch: [bang( [key] \ / [f ] | [keyname] [makefilename %c] | | [select dummy] | [bng]
First press key you want to test, then click the top bang and press key again: [select] will fire correctly on <Space>, <Esc> and <Backspace>. However <Enter> doesn't work.
Note that "symbol <mystery_char_for_space>" is something different from "symbol " and also different from "symbol 32" or "symbol SPACE". I believe, the way keyname handles this ATM is okay.
Ciao
-
Frank Barknecht -
SourceForge.net