Hi, I have a subclass of CodeEditorComponent (called CodeBuffer) that defines its own keyPressed() method. im noticing some behavior in juce TIP that was NOT present in JUCE v1.50 so I think im not understanding how keypresses are handled now.
my CodeBuffer::KeyPressed() method implements some Emacs style commands (combinations of control and option keystrokes) and also wants to get all the keypresses that arrive at the window. So for example, in addition to catching Control/Option keypresses it also wants to catch non-mod presses like ‘\t’ an ‘)’ so it can do syntactic code indentation and “matching parens” highlighting, for example.
now, my keyPressed() method does get called for most keypresses, but not all of them. for example it gets called when Tab and Backspace are pressed but but not when ‘)’ or any other non-modified char is pressed (the non-modified chars are getting trapped by someone and appear in the buffer however)
also keypresses that involve just the option key dont arrive ie when Option+f is pressed my method never get called. instead the Option mod causes non-ascii font chars to get inserted in my buffer. But my keyPressed method DOES get called correctly with control+option+f and control+f.
what I want to do is have my keyPressed() method receive ALL keypresses and – if it doesnt want to handle the current keypress – just call juce’s CodeEditorComponent::keyPressed for standard processing of that press.
as i say, this all works n v150 but not in the tip – im not sure how to insure that my keyPressed() method gets keypresses like ‘)’ and Option modified presses.
in all other respects the code editor support in tip is working beautifully for me!!
I should warn you that the code editor keyboard handling is really just a first draft to get it working, and not the finished design. As I develop the new jucer I’ll almost certainly be re-writing it to allow dynamic key-mappings, so will probably break your subclass (but probably also make it easier to implement whatever you’re trying to do).
But in the meantime, you should take a look at the TextInputTarget class to understand how the key events work.
But in the meantime, you should take a look at the TextInputTarget class to understand how the key events work.
jules thanks, ive had a look at TextInputTarget.h but im still not sure what I need to to do get my keyPressed() method on my CodeBuffer (subclass of CodeEditorComponent) to get all the keypresses. Is this the correct file? all i see in TextInputTarget.h are virtual declarations (i dont see a TextInputTarget.cpp file with any code dealing with key events for example)
my CodeBuffer inherits directly from CodeEditorComponent, are you suggesting that CodeBuffer also needs to (re)inherit from TextInputTarget too and (re)implement those virtual methods? there is no keypress methods in TextInputTarget.
CodeEditorComponent already implements it, but you should look at how it works. Some keypresses don’t reach the component because the OS turns them into text and delivers it via TextInputTarget.
Some keypresses don’t reach the component because the OS turns them into text and delivers it via TextInputTarget.
ok i see now juce tip some v1.50 “key presses” now arrive via insertTextAtCursor instread if keyPressed(). rats. but why is ALT- not a keypressed() and an unmondified TAB IS a keyPressed() ? the v1.50 way was really simple.
The OS decides which keypresses to use, because it handles international character composition, and that might involve any keys. If you want to get the raw keys, you just need to not make your component inherit from a TextInputTarget, and it will let them all through. But since the code editor is designed for entering text, it has to be a TextInputTarget.
If you want to get the raw keys, you just need to not make your component inherit from a TextInputTarget,
ok i see what is going on, my editor is a subclass of CodeEditorComponent so it already inherits the insertTextAtCaret() from TextInputTarget and thats the method that getting called when I press ALT- on osx. so i am able to get Alt- working on osx by adding my own insertTextAtCaret() that looks for strings with that text. im not sure who is creating this string – can i count on ALT-F always being 402 on osx?) also Alt- is now handled differently on differnt oses, so its harder hard to write code. for example on Windows an Alt- IS being handedl by keyPressed() and so the code works (except that i thnk the OS is beeping because ALT- must be interacting with the ms menus, not sure yet)
-rick
No, of course you can’t rely on alt-F being a particular character! It’ll be different on every keyboard.
You either use a TextInputSource and let the OS use whatever keys it wants to, or you use a normal component and lose the ability to let the OS do your international text input. There’s no way to get both!