> Program complies and the interface shows up but there is no output
> after pressing run button. How come this is happening?
>
> Thanks.
<code snipped>
I don't see where you add the action listener to the RunButton. By
convention, instance variables should start with lower case to help
distinguish them from class names. Also, you're swallowing exceptions.
Matt Humphrey http://www.iviz.com/
Lew - 25 Mar 2008 15:00 GMT
"Soul Tech" <carla.pinate@gmail.com> wrote in message
> news:c81d32df-0486-47f4-ac03-0e76277b4c52@n77g2000hse.googlegroups.com...
>> Program complies and the interface shows up but there is no output
>> after pressing run button. How come this is happening?
> I don't see where you add the action listener to the RunButton. By
> convention, instance variables should start with lower case to help
> distinguish them from class names. Also, you're swallowing exceptions.
Cross-posted so both groups to which the OP multi-posted can see this answer.

Signature
Lew
> Program complies and the interface shows up but there is no output
> after pressing run button. How come this is happening?
I think Matt has spotted the cause.
Here's some comments on style in case you're interested (if not, please
ignore).
> package newpackage4;
>
[quoted text clipped - 5 lines]
>
> public class NewClass5 extends JFrame{
Nowadays I encapsulate JFrame rather than extend it. I'm not sure why :-)
In cases where my imagination fails, I'd name the class Class5, instead
on NewClass5 to avoid things like "new NewClass5()". If you refactor
this, would you call the old version OldNewClass5 and the new one
NewNewClass5?
> public NewClass5() {
> initiateComponents();
> }
Unless initiateComponents() gets called from somewhere else I don't see
the value of moving the construction code out of the constructor.
> private JLabel TitleLabel;
>
> private JPanel innerPanel;
I note that innerPanel is accessible to all methods in NewClass5.
> private JLabel StringInputLabel;
>
[quoted text clipped - 11 lines]
> private void initiateComponents() {
> getContentPane().setLayout(null);
Eeek!
> setTitle("Simplified Simulation: RSA Security Algorithm");
> setSize(new Dimension(1025, 703));
[quoted text clipped - 6 lines]
> getContentPane().add(getTitleLabel());
> populateInnerPanel();
I hate chains of method calls. I'd call populateInnerPanel right after I
call initiateComponents(). That way the large scale structure of the
program isn't hidden.
The "getContentPane()." prefixes can be omitted.
If they were needed, I'd do
Container c = getContentPane();
c.setLayout(...);
...
c.add(...);
c.add(...);
I find less dense code easier to read.
> }
>
> private JLabel getTitleLabel() {
> TitleLabel = new JLabel();
Variable names should start with a lowercase letter.
I use short names for short scope. I might have
JLabel l = new JLabel();
...
return l;
> TitleLabel.setFont(new Font("Arial",1,44));
> TitleLabel.setText(" RSA Algorithm");
> TitleLabel.setBackground(new Color(255,255,255));
> TitleLabel.setBorder(new EtchedBorder());
> TitleLabel.setBounds(300,40,500,60);
> return TitleLabel;
Since the scope of TitleLabel is NewClass5, you don't need to return it
from a private method. You could have a void method. I'd instead create
a local label and return a reference to that. This is because I like to
develop the habit of making chunks of code relatively independent of
context. I think of this as being related to ensuring good encapsulation.
> }
>
[quoted text clipped - 22 lines]
> innerPanel.add(InputStringTextField);
> InputStringTextField.setBounds(180,20,220,20);
I hope you have a visual GUI editor producing these coordinates. I'd
much rather use a layout manager.
> RunButton = new JButton();
> RunButton.setFont(new Font("Bookman Old Style",1,13));
[quoted text clipped - 4 lines]
> SaveButton = new JButton();
> SaveButton.setFont(new Font("Bookman Old Style",1,13));
I'd have long ago re-factored 'new Font("Bookman Old Style",1,13) into a
local variable and I'd probably make the font-name string a constant
declared at the top of the source file.
> SaveButton.setText("Save");
> innerPanel.add(SaveButton);
[quoted text clipped - 11 lines]
> innerPanel.add(ExitButton);
> ExitButton.setBounds(794,420,70,20);
I'd replace the prior 24 lines with
p.add(makeJButton(RUN));
p.add(makeJButton(SAVE));
p.add(makeJButton(RESET));
p.add(makeJButton(EXIT));
I might even replace them with something using an enum, like
for (ButtonName b: ButtonName.values())
p.add(makeJButton(b));
> OutputWindow = new JTextArea();
> Font equalSpacedFont = new Font("Monospaced",Font.PLAIN,14);
> OutputWindow.setFont(equalSpacedFont);
You define a variable for a font you use once, you don't for one you use
four times. I'd probably do the opposite.
> OutputWindow.setEditable(false);
> JScrollPane scrollPane = new JScrollPane(OutputWindow);
[quoted text clipped - 7 lines]
>
> if(arg.equals("Run"))
To avoid typos causing problems, I use Enums for values like "Run". One
day I must get into the habit of using Action.
> {
> try
> {
> int plainTextLength = plainText.length;
I can't see where this variable is used - doesn't your IDE warn you
about this?
> String inputString = InputStringTextField.getText();
> int inputStringLength = inputString.length();
> char[] result = new char[inputStringLength];
You saved three characters ".()" at the expense of an extra line. I'd
not make that trade-off.
char[] result = new char[inputString.length()];
> //char currentSource = inputString.charAt(i);
> }
> catch (Exception e) {
>
> }
Eek, an ignored exception!
I'd at least do System.err.println(e.getMessage());
I'd preferably log it and work out how the program should handle this. I
usually pop up a JDialog and maybe either exit the program or let the
user choose.
> int [] cipherText = new int[plainText.length];
>
[quoted text clipped - 11 lines]
> }
> }
All the above is blocking the EDT. It may not matter for small amounts
of text but it's not a good habit.
I'd separate the 'encryption' into separate methods (and/or classes)
from the GUI code.
I'd also do something if arg doesn't equal "Run". Like emit an error
message about an unexpected command. It's an old "defensive programming"
habit.
> }
>
[quoted text clipped - 10 lines]
> }
> }
There seems to be a total absence of Javadocs and comments. OK for code
put up for discussion but probably not OK for anything to be used in
production.

Signature
RGB