Go Down

Topic: BUG: Serial Monitor keyboard shortcut inserts CR (Read 1 time) previous topic - next topic


I noticed that sometimes the Arduino IDE would randomly destroy my code in the editor.  It could be as harmless as changing number of spaces between functions, or as bad as renaming my variables or missing code chunks.

It turned out that everytime I press the Serial Monitor keyboard shortcut: CTRL+SHIFT+M

Not only the Serial Monitor would open, but Arduino IDE also types a Carriage Return character WHEREVER my selection happens to be!  If I have code selected, it would be removed and replaced with a return.

Not cool... :-(

I'm running Arduino 0018 on 32-bit Windows Vista Ultimate.


Same here on 64bit Kubuntu Linux.

Its only happened with the shortcut, if I use the Menu it works correct.
(Arduino 0018)


Apr 05, 2010, 09:45 pm Last Edit: Apr 05, 2010, 11:30 pm by qistoph Reason: 1
On Windows XP, I have noticed the same and was looking for some information before posting this as a bug.

There isn't  much information here yet. So lets try to improve this.

What I think is happening, is that pressing Ctrl-Shift-M triggers an event that opens the Serial Monitor, though this event isn't consumed. So then the event continues it's travel through the application and ends up in the textfield where it represents a CR.
A CR can often be entered using Ctrl-M (it's even sometimes represented by ^M, which is a notation for Ctrl-M). You can confirm this by pressing Ctrl-M or Ctrl-Shift-M in Notepad (Windows).

Looking into a solution for a minute, I have come across a consume() method in the ActionEvent. It is however protected, and cannot be called from the Arduino source. I am not familiar with a solution for this.

Any other Java developers who can help solving this really annoying bug?

I might look into it some more later this week. I'll post any updates.

Edit: some findings up till now

I have created a independent test app to try to reproduce the bug in a less-code app.
Code: [Select]
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;

public class ConsumeTest extends JFrame {
     public ConsumeTest() {

           JMenuBar menuBar = new JMenuBar();
           JMenu menu = new JMenu("Menu");

           JMenuItem ctrlMTestItem = new JMenuItem("Ctrl M Test");
           int modifiers = Toolkit.getDefaultToolkit().getMenuShortcutKeyMask();
           modifiers |= ActionEvent.SHIFT_MASK;
           ctrlMTestItem.setAccelerator(KeyStroke.getKeyStroke('M', modifiers));
           ctrlMTestItem.addActionListener(new ActionListener() {
                 public void actionPerformed(ActionEvent e) {
                       System.out.println("Action taken");


           JTextArea textArea = new JTextArea();

           setPreferredSize(new Dimension(400, 300));
           setMinimumSize(new Dimension(400, 300));

     public static void main(String[] arg) {
           new ConsumeTest().setVisible(true);

When trying to create the bug, I noticed that my app doesn't even insert a newline when pressing Ctrl(-Shift)-M. So my guess is that Arduino interprets the keystroke somehow, and that's where the possible error is. I haven't been able to track down where the Ctrl-M keystroke is handled and the CR is inserted. Any suggestions where this happens? (I have tried to find it in processing.app.syntax.DefaultInputHandler)


Apr 06, 2010, 03:00 pm Last Edit: Apr 06, 2010, 03:02 pm by qistoph Reason: 1
I have found what goes wrong.

In processing.app.syntax.JEditTextarea, in the method processKeyEvent, the KeyEvent is passed through all the handlers.
First by 'super', then editorListener and finally inputHandler.

The consume status possibly set by super.processKeyEvent is, however, ignored.

Unfortunately, when I tried changing the code so it looks at the consumed status after the call to 'super', some other functionality (like cursor keys) no longer works.

Here's what I've tried:
Code: [Select]
 public void processKeyEvent(KeyEvent evt) {
       System.out.println("evt.isConsumed (1): " + evt.isConsumed());
   // this had to be added in Processing 007X, because the menu key
   // events weren't making it up to the frame.

       System.out.println("evt.isConsumed (2): " + evt.isConsumed());

[glow]    // Don't handle events that have been handled already
           if(evt.isConsumed()) return;[/glow]

   //System.out.println("jedittextarea: " + evt);
   if (inputHandler == null) return;

   switch(evt.getID()) {
   case KeyEvent.KEY_TYPED:
     if ((editorListener == null) || !editorListener.keyTyped(evt)) {
   case KeyEvent.KEY_PRESSED:
     if ((editorListener == null) || !editorListener.keyPressed(evt)) {
   case KeyEvent.KEY_RELEASED:

This bug will probably end up being ignored, since the error actually is in the Processing code. Though there's no real reason to fix it in Processing I guess, since they don't have this conflict.


Can you return only if the event was consumed AND is Ctrl-Shift-M?
The art of getting good answers lies in asking good questions.


PaulS, I think that would be possible.
But I was looking for a more solid solution.
One that'll work for possible future shortcuts too.

This code, not thoroughly tested, should do that.
Code: [Select]

   if(evt.isConsumed() && evt.getKeyCode() == KeyEvent.VK_M && evt.getModifiers() == (InputEvent.CTRL_MASK | InputEvent.SHIFT_MASK))

Go Up