Fine, 'textchanged' solves your problem.
But the bug revealed by this thread still remains.
So just to 'round up' (also with regards to HTML5) this discussion
with a working method for getting keyCodes and characterCodes.
One could also use javascript for that, see here, also for a good
Hello Hermann,
Thank you, issues solved, see my replies to Mark from this morning
Tiemo
-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von
hh
Gesendet: Dienstag, 6. Dezember 2016 13:33
An: use-livecode@lists.runrev.com
Betreff: Re:
Tiemo wrote:
> Can I rely on this workaround to get the correct chars, which
> have been entered on "all" systems?
TMHO:
No. As a workaround to get the "char input" this isn't reliable on
_any_ system or hardware configuration. You only *guess* with that:
IF the user uses a 'usual' keyboard
Tiemo wrote:
> You say Apple changed the keyboard mapping.
NO, I said, Apple changed his keyboard mapping _method_.
That's why developers had to change the lookup method for the mapping.
Anyway, 'the keysdown' and 'rawkeydown/up' should return the _hardware_ code
[keydown/up may return,
FYI,
Mark Waddingham has just answered this issue in the QC:
" Whilst Panos has observed a difference between the pre-Cocoa and Cocoa Mac
engines, it was actually incorrect in the pre-Cocoa engines.
The raw keycodes are the keycodes of the actual keyboard keys and not the
characters they
Thanks Hermann and Paul for clarifying this to me. I didn't noticed the
difference to *the keysdown*
You say Apple changed the keyboard mapping. I have no idea, if and how this
could affect now LC 8 concerning backward compatibility with older systems.
Will the keysdown give me on "all" systems
Hi all. Yes that's the point:
*The keysDown* return the correct (hardware) keyCode.
Tiemo is right, there is a bug introduced around LC 8. From the dictionary:
"The keycodes returned by the keysDown function are the same as those
passed as parameters with the rawKeyDown and rawKeyUp messages."
On Mac OS Sierra 10.12.1 with LC 8.1.2(rc2) and German Keyboard layout I see:
Shift + dot (":") the keyname = 58
Shift + ö ("Ö") the keyname = 58
But if you add to these 'the keysDown' as Herman suggested I see:
Shift + dot (":") the keyname = 58 and the keysDown = 46,65505 (46 is the : key
Hello Richmond,
an essential feature of my main programs, which I just wanted to release in a
new Quicktime free version is to enter text.
As I have pointed out in my thread "LC 8: no keyUp at fast enter" you can't
enter fast text in LC anymore, because the keyup handler (the engine?) swallows
Um . . .
On 12/5/16 1:58 pm, Tiemo Hollmann TB wrote:
Since the keyup handler is broken,
I am not entirely sure what you mean by this . . . I am currently
running LiveCode 8.1.1 on
Mac OS 10.7.5 and have a boring little stack with 2 fields, "ff" & "gg",
and this in the cardScript:
Why are you stuck with LiveCode 8?
1. My Indy licence lets me go on downloading commercial versions until
it expires (sometime in 2018).
2. If this is not possible, you can, at least, download the Community
version of later builds and
fiddle around to see what happens there.
Richmond.
On
Hallo Hermann,
shift + ö and shift + dot both return 58, anyhow if I give the output tot he
message box or a field. I can't see a script error. For me it's an engine error.
Same with "-" and "ß", both return 45.
I don't see a chance on how I could differentiate between "-" and "ß", when
The '58-example' is obviously a script error:
the message box has always display bugs, you may better use a field
for the display.
If I understand right, then you want now
the keyCode (an event, depending on _hardware_)
and NOT
the characterCode (a number representation of the char).
Some Mac
Since the keyup handler is broken, I am still trying to build a table for
mapping the rawkeyup key to a char. When testing a prototype it seemed to be
easy, but now there are some pitfalls I don't get over. On Mac OS X 10.11,
German system, German keyboard I get with some different char the
14 matches
Mail list logo
