0

I wanted to develop a console-like interface, similar to IDLE. That involved determining how to prevent a certain part of the text in a JTextField from being edited. For example:

>>> help

Where the ">>> " is uneditable. The caret must never move behind a certain position, and the text behind that position cannot be edited in any way.

Azar
  • 1,086
  • 12
  • 27
  • answer is about Prompt or NavigationFilter – mKorbel Aug 06 '14 at 20:19
  • @mKorbel Perhaps you could write an answer? I looked at NavigationFilter, but it doesn't seem to prevent keyboard driven manipulation of the caret. – Azar Aug 06 '14 at 21:36
  • [crossposted](http://www.coderanch.com/t/637725/GUI/java/Making-JButton-switches-text-JTextFields#2925467) – mKorbel Aug 07 '14 at 06:53

2 Answers2

3

I looked at NavigationFilter, but it doesn't seem to prevent keyboard driven manipulation of the caret.

This shows how to do it with a NavigationFilter:

import java.awt.event.*;
import javax.swing.*;
import javax.swing.text.*;

public class NavigationFilterPrefixWithBackspace extends NavigationFilter
{
    private int prefixLength;
    private Action deletePrevious;

    public NavigationFilterPrefixWithBackspace(int prefixLength, JTextComponent component)
    {
        this.prefixLength = prefixLength;
        deletePrevious = component.getActionMap().get("delete-previous");
        component.getActionMap().put("delete-previous", new BackspaceAction());
        component.setCaretPosition(prefixLength);
    }

    @Override
    public void setDot(NavigationFilter.FilterBypass fb, int dot, Position.Bias bias)
    {
        fb.setDot(Math.max(dot, prefixLength), bias);
    }

    @Override
    public void moveDot(NavigationFilter.FilterBypass fb, int dot, Position.Bias bias)
    {
        fb.moveDot(Math.max(dot, prefixLength), bias);
    }

    class BackspaceAction extends AbstractAction
    {
        @Override
        public void actionPerformed(ActionEvent e)
        {
            JTextComponent component = (JTextComponent)e.getSource();

            if (component.getCaretPosition() > prefixLength)
            {
                deletePrevious.actionPerformed( null );
            }
        }
    }

    private static void createAndShowUI()
    {
        JTextField textField = new JTextField("Prefix_", 20);
        textField.setNavigationFilter( new NavigationFilterPrefixWithBackspace(7, textField) );

        JFrame frame = new JFrame("Navigation Filter Example");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.getContentPane().add(textField);
        frame.pack();
        frame.setLocationRelativeTo( null );
        frame.setVisible(true);
    }

    public static void main(String[] args)
    {
        SwingUtilities.invokeLater(new Runnable()
        {
            public void run()
            {
                createAndShowUI();
            }
        });
    }
}
camickr
  • 321,443
  • 19
  • 166
  • 288
  • +1 That is excellent. While functionally the same as my answer, this seems like a much cleaner and more robust approach. – Azar Aug 06 '14 at 23:17
0

Spent a little while figuring this out, so I thought I would share my solution for anyone else with the same dilemma. I don't know if it's optimal, but it does seem to work.

It prevents the user from using backspace behind the postion n. It also moves the caret back to n for any other events, such as (illegally) changing the caret position with the arrow keys or mouse. Finally, it resets the text and caret position after a entry is processed.

EDIT: While I'm leaving this answer here for posterity, see the accepted answer for the best way to solve this problem.

    JTextField in = new JTextField();
    final String protectMe = ">>> "; //protect this text
    final int n = protectMe.length();
    in.setText(protectMe);
    in.setCaretPosition(n);

    in.addCaretListener(new CaretListener()
    {
        @Override
        public void caretUpdate(CaretEvent e)
        {
            if (e.getDot() < n)
            {
                if (!(in.getText().length() < n))
                    in.getCaret().setDot(n);
            }
        }
    });

    in.addKeyListener(new KeyListener()
    {

        @Override
        public void keyPressed(KeyEvent arg0)
        {
            if (in.getCaret().getDot() <= n)
            {
                in.setText(protectMe + in.getText().substring(n));
                arg0.consume();
            }
        }

        @Override
        public void keyReleased(KeyEvent arg0){}

        @Override
        public void keyTyped(KeyEvent arg0){}
    });
    in.addActionListener(new ActionListener()
    {
        public void actionPerformed(ActionEvent evt)
        {
            String input = in.getText().substring(n).trim(); 

            //do something

            in.setText(protectMe);
            in.setCaretPosition(n);
        }
    });

As usual, let me know if there's anything I missed!

Azar
  • 1,086
  • 12
  • 27
  • I think this wouldn't work if I highlighted the text and then pressed any other key besides backspace, right? – NESPowerGlove Aug 06 '14 at 19:17
  • @NESPowerGlove Ah you're right! I'll figure out a workaround. – Azar Aug 06 '14 at 19:19
  • There's a couple ways to do this that I can think of from top of my head, 1. Have the >>> portion be drawn to the component separately and figure out the Font used in the drawing and set the position the text is drawn to the correct position, 2. Create a custom component which is a JLabel and a JTextField where both have no borders or other effects but the parent custom component has the visual effects that a JTextField by itself has. – NESPowerGlove Aug 06 '14 at 19:22
  • @NESPowerGlove Well it's definitely a workaround, but I 'fixed' the problem. – Azar Aug 06 '14 at 19:46
  • It looks like to me the JTextField cannot be anything other than what protect me is as you always call in.setText(protectMe); near the end of the ActionListener. Is that the case? – NESPowerGlove Aug 06 '14 at 19:52
  • please to delete this answer contains KeyListener, nor for JTextComponents, – mKorbel Aug 06 '14 at 20:17
  • @NESPowerGlove No, that listener is only fired when the user hits enter. – Azar Aug 06 '14 at 21:14