NX: Server GUI

[Ulrich Heeger]

Hi everyone,
Some questions arised while I'm programming my server GUI.
1. I have a connect- and a stop-button. The connect button starts the server by calling the register()-method of the server. The stop-button shuts the server down.
a.) Because the GUI shouldn�t freeze when I click the connect button, I start the server�s register() from another thread than the event-dispatching thread:

connectButton.addActionListener(
     new ActionListener(){
public void actionPerformed(ActionEvent e){
      if (!threadAlive){ 
  connThread = new Thread(new Connection());
  connThread.start();
   threadAlive = true;
      }
      else
     handleException("The "+
                                     "server is allready started");
      }
});
 

connThread is a static variable, so I ensure the Server�s starting thread is running only once.
The new Runnable target is a ordinary one:

private class Connection implements Runnable{
      public void run(){
        ...
      }
}

Have I missed something I have to take in consideration when I�m starting a new Thread within the event-dispatching thread? (something like synchronization etc.)
Or do you think it's fine?
2. Before the server shuts down, do you have an alerting procedure for the clients connected to the server?
Thanks in advance & Greetings
Ulrich
[ November 18, 2003: Message edited by: Ulrich Heeger ]

[Ulrich Heeger]

Hi,
I forgot to ask one more question:
At the server-side I check the port-number. I check the string I get from suncertify.properties against the expression "\\d{4}".(I have to admit I have copied this expression from somewhere in this forum )
Are only the port-numbers starting at 1000 potentially valid ports? I mean I can exclude the port-numbers from 1 - 999?
(The port-number will be checked once more later, simply when the registry starts and a Remote-Exception is thrown indicating the user that the portnumber is invalid, so even if the portnumber is between 1000 and 9999 but not valid, the User will get a message that the RemoteException might be caused by an invalid port number).
Greetings
Ulrich
[ November 18, 2003: Message edited by: Ulrich Heeger ]

[Jim Yingst]

Have I missed something I have to take in consideration when I�m starting a new Thread within the event-dispatching thread?
Looks OK. Though this can open up a can of worms. By starting a separate thread you're allowing the event handling thread to do other things before the server has completely started - which sounds good. But it also may complicate things. What if the user decides to hit "stop" now while the server is still starting? Depending on how you set things up, this may be OK, or it may result in an ubly stack trace on your screen. There are certainly ways to deal with this, but you may find that things can get more complicated than you realized at fist. May not be worth the effort to go down this road.
If you do stick with the start-a-separate-thread paradigm, you may want to consider enabling and disabling controls as approriate. Initially Connect can be enabled and Stop disabled; once Connect is pressed once, disable it immediately. Once the connection is completed, enable Stop. In between, you can call

mainWindow.setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));

to make things look nice.
One other thing to consider: is threadAlive accessed by any other threads? If it's only accessed from the event handling thread, you're fine. But if not, you need synchronization to access it safely.
2. Before the server shuts down, do you have an alerting procedure for the clients connected to the server?
No. I think that's one of those things that would be great in the real world, but is outside the bounds of this assignment, and too much work to implement. The provided API defines all the things you need for a client to be able to get from the server.
Port numbers: I found that , on Windows XP and 2000 Pro at least, I could connect using port numbers as low as 1 or as high as 65535. Dunno if that works on all other systems, but I figure the server admin can decide what port to run on, based on what makes sense for that system. So I allowed anything in this range.
[ November 18, 2003: Message edited by: Jim Yingst ]

[Ulrich Heeger]

Hi Jim,
thanks a lot for your help.

 mainWindow.setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR)); 

That sounds really
I will try this.
Thanks
Ulrich

[Philippe Maquet]

Hi Jim,

    mainWindow.setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR)); 

I got in trouble with mouse cursors in Java. When I set it on a component, it was OK only on this component's surface. When I set it on this component's parent, it was OK only while I didn't move the cursor on child components.
So I finally wrote these few static helper utility methods in a suncertify.util.gui.GuiUtilities class :

    public static void setWaitCursor() {
        setCursor(Cursor.WAIT_CURSOR);
    }
    public static void setDefaultCursor() {
        setCursor(Cursor.DEFAULT_CURSOR);
    }
    public static void setCursor(int type) {
        JRootPane rootPane = null;
        Window wnd = KeyboardFocusManager.getCurrentKeyboardFocusManager()
                                         .getActiveWindow();
        if (wnd instanceof JFrame) {
            rootPane = ((JFrame) wnd).getRootPane();
        } else if (wnd instanceof JDialog) {
            rootPane = ((JDialog) wnd).getRootPane();
        }
        if (rootPane != null) {
            Component glassPane = rootPane.getGlassPane();
            glassPane.setCursor(Cursor.getPredefinedCursor(type));
            glassPane.setVisible(true);
        }
    }

Using those methods, I can write something like :

try {
    GuiUtilities.setWaitCursor(); 
    // a lengthy process comes here
}
finally {
    GuiUtilities.setDefaultCursor(); 
}

It works fine, even when the cursor is moved by the user, but does it make sense, or did I miss something ?
Is there any standard way to set the mouse cursor "globally" ?
Best,
Phil.