NX: URLy Bird 1.3.1 Suncertify.properties

[Bharat Ruparel]

Hello All,
I want to start a new thread particularly for the URLy Bird assignment. Can I please request everyone to keep their comments confined to ONLY the URLy Bird assignment? I promise whatever I learn I will contribute to the Contractors or FBN assignments should anyone need it.
The topic of this thread is "suncertify.properties"! I can imagine Andrew rolling his eyes and thinking here we go again! Please, stay with me on this one. Not since the "thread locking" work which Max and Andrew walked me through have I been so confused in this effort. At least I had the smug satisfaction of wrestling with an "intellectually" stimulating topic. Alas, this one doesn't qualify. Hopefully, this is the last major (may be minor I don't know!) piece of work left. Rest is clean-up, packaging, testing, and documentation. Anyway, here we go:
My assignment is URLy Bird 1.3.1 and has the following text pertaining to the suncertify.properties file:
Quote # 1

Your choice of RMI or serialized objects will not affect your grade, but no other approach is acceptable. In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely

Quote # 2

All configuration information must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be stored in the current working directory.

Quote # 3

The mode flag must be either "server", indicating the server program must run, "alone" indicating standalone mode, or left out entirel, in which case the network client and GUI must run.

Based on the above, here is what I think needs to be done and things I am not sure about:
1. Quote number 1 says "In either case, the program must allow the user to specify the location of the database,...". I am interpreting it as: regardless of whether one chooses to follow "sockets" or use "RMI", the location of the database needs to be specified. Therefore, the implicit constraint here is "network". The statement DOES NOT apply to the standalone mode. In a network environment, how do you specify the location of the database (or any remote service, e.g., application server) for that matter? The only logical answer is: by specifying 1. DNS name (or IP Address), and 2. listening port number. That is what we have been using in our day to day work in an Application Server (WebLogic) environment. Therefore, here is my take-away point: We need to create GUI to allow user to enter DNS name/IP address and port number for the database service.
2. Quote number 1 goes on to finish the unfinished sentence above as..", and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely." . This is somewhat in conflict with the first part of the sentence discussed in point 1 above. I think that Quote # 3 clearly and sufficiently overrides this since it says: "The mode flag must be either "server", indicating the server program must run, "alone" indicating standalone mode, or left out entirel, in which case the network client and GUI must run." . The mode flag clearly defines what will run 1. "server" - run the server, 2. "alone" - run the standalone program, i.e., no networking, 3. nothing - means run the client in the network mode to "correctly" connect to the database server which presumably has already been started. Therefore my conclusion is that the second part of quote # 1 has been effectively made redundant by the Quote # 3 above.
3. Now, the question is: How do we "find" the database service in the standalone mode? Remember, this has nothing to do even with loop-back or localhost based approach which is really a specialized case of the network approach. The only reasonable way of doing this will be to: 1. Let the user enter the path for the database file in a text-box, or 2. let the user use a JFileChooser dialog box to determine this path, or a combination of both.
Realize that we are still talking some GUI work at the client side to satisfy both network mode client that needs to find the database service and the standalone mode that needs to find the database file. This can be specified in one screen which can be a menu choice off the main JTable screen. This information can then be saved in the suncertify.properties file as follows:
servername=localhost
serverport=1099
datafilepath=C:\SCJD\db-1x1.db
When the program runs in the network mode, only the first two name/value properties, i.e., servername=localhost, and serverport=1099 need to be used. The third entry, i.e., datafilepath=C:\SCJD\db-1x1.db will be ignored. Conversely, in the standalone mode, the third entry will be used and the first two will be ignored.
The screen will have a capability to save the user-entered information and this should be saved in the suncertify.properties file per Quote # 2 in the current working directory on the client side in the network mode and the current working directory period since there is no client/server differentiation in the standalone mode since they both run in the same JVM.
Therefore, my conclusion is: THERE IS NO NEED TO DEVELOP ANY GUI SCREENS FOR THE SERVER-SIDE ONLY FOR THE CLIENT SIDE AND SAVE ALL THE INFORMATION IN THE SUNCERTIFY.PROPERTIES FILE WHICH RESIDES IN THE CURRENT WORKING DIRECTORY.
I am not sure about Contractors and FBN, but I suggest that those who have doubts like I do apply the same approach that I have above and see what kind of conlusion can they come-up with.
I would love to have someone verify my conclusion and reasoning above.
Andrew/Max/Phil/Vlad/Tony/Ulrich anybody/everybody.
My sincere thanks in advance (I feel I was in the law school tonight!).
Regards.
Bharat

[Andrew Monkhouse]

Hi Bharat,

Can I please request everyone to keep their comments confined to ONLY the URLy Bird assignment?

I don't think there is any need for it to be kept to URLyBird, but OK.

I can imagine Andrew rolling his eyes

How can you even imagine I would do such a thing :roll:

Quote number 1 goes on to finish the unfinished sentence above as..", and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely." . This is somewhat in conflict with the first part of the sentence discussed in point 1 above. I think that Quote # 3 clearly and sufficiently overrides this since it says: "The mode flag must be either "server", indicating the server program must run, "alone" indicating standalone mode, or left out entirel, in which case the network client and GUI must run."

I think the "local" mode flag is the indicator that the indication that a local database should be used.
As such, I consider that "must also accept an indication" requirement to be the easiest requirement to implement.

When the program runs in the network mode, only the first two name/value properties, i.e., servername=localhost, and serverport=1099 need to be used. The third entry, i.e., datafilepath=C:\SCJD\db-1x1.db will be ignored. Conversely, in the standalone mode, the third entry will be used and the first two will be ignored.

I would go further. In my opinion only the option for the correct mode should be visible. The other options should not be visible as they do not apply.
You could just disable them I guess (so they will appear greyed out), but you would not want them enabled (IMHO) since the user may get confused at being able (or possibly feeling required) to enter data in fields that do not apply.

Therefore, my conclusion is: THERE IS NO NEED TO DEVELOP ANY GUI SCREENS FOR THE SERVER-SIDE ONLY FOR THE CLIENT SIDE AND SAVE ALL THE INFORMATION IN THE SUNCERTIFY.PROPERTIES FILE WHICH RESIDES IN THE CURRENT WORKING DIRECTORY.

Really? What if the current working directories are different?
What if (due to firewalls or similar) we need to specify a different port oon the server than on the client?
Also: as per my comment before, I don't believe the server name / port should be available unless you are connecting in networked mode. If this is accepted you have a rather roundabout way of running things:

On the server, start the client in networked mode, enter the relevant information, and click ok. At which point it will try to connect and give you a fatal error.

Now you can start the server

Then you can start the client on the client machines.

Regards, Andrew

[Tony Collins]

I think you're going to need a GUI on the Server.
The server requires the location of the database and the port number to start on. This needs to be aquired from somewhere either suncertify.properties or the user.
Does anyone have an opinion on locking the properties file, Vlad seems to think it's not necessary I hope that's the case.
Tony

[Philippe Maquet]

Hi Bharat,
Andrew:
I think the "local" mode flag is the indicator that the indication that a local database should be used.
Agreed.
Andrew:
I would go further. In my opinion only the option for the correct mode should be visible. The other options should not be visible as they do not apply.
Agreed.
Bharat:
Therefore, my conclusion is: THERE IS NO NEED TO DEVELOP ANY GUI SCREENS FOR THE SERVER-SIDE ONLY FOR THE CLIENT SIDE AND SAVE ALL THE INFORMATION IN THE SUNCERTIFY.PROPERTIES FILE WHICH RESIDES IN THE CURRENT WORKING DIRECTORY.
Disagreed.
Tony:
I think you're going to need a GUI on the Server.
The server requires the location of the database and the port number to start on. This needs to be aquired from somewhere either suncertify.properties or the user.
Agreed.
Tony:
Does anyone have an opinion on locking the properties file, Vlad seems to think it's not necessary I hope that's the case.
I disagree with Vlad as I know Andrew will too.
Here are my own opinion about it :
In network mode server-side, database location and listen port are server properties which, as such, must be set through a server GUI and saved in a suncertify.properties file in the current directory (user.dir).
In network mode client-side, server adress and connection port are client properties which, as such, must be set through a client GUI and saved in a suncertify.properties file in the current directory (user.dir).
In stand-alone mode, database location becomes the only one client property which, as such, must be set through a client GUI and saved in a suncertify.properties file in the current directory (user.dir).
There is a locking issue, because it's possible to start the server, a client and a stand-alone client from the same directory on the same machine (it's likely what the grader will do BTW). So you may have 3 different applications which are likely to access the same suncertify.properties at the same time. IMO, there is even more than a locking problem : similar properties owned by the different applications (port, dbLocation) should be named differently. One way of doing this would be to prefix all server properties with "server.", client ones with "client." and stand-alone ones by "alone.". So the server dbLocation ("server.location") won't interract with the stand-alone db location ("alone.dbLocation").
I think that sharing that properties file among 3 apps need special care when retrieving / saving properties from / to the file :
Retrieving :

<font size="2">
lock
load
get the properties used by the given app
unlock
</font>

Saving :

<font size="2">
lock
load
set the properties used by the given app
save
unlock
</font>

Now, as far as the locking technique is concerned, Andrew proposed a technique based on a temporary file (for example a file named "suncertify.properties_"). While that file cannot be created nor deleted, it would mean that the lock is owned by another app.
Unfortunately, I don't see another way to achieve it (because FileLock is part of NIO which is incompatible AFAIK with class Properties). I say "unfortunately" because I read this in the File.createNewFile() doc :
Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably. The FileLock facility should be used instead.
If anybody has a better idea, please let me know !
Best,
Phil.
[ September 17, 2003: Message edited by: Philippe Maquet ]

[Tony Collins]

I agree there is a case to lock the properties file but I'm not sure if it's overkill or not.
The reason being is that I do not have two mice, two keyboards and four hands. Therefore I think the chance of updating the properties on the client and server at the same time are very slim.
And anyway why would you ever practically want the client and server on the same machine if you have the alone mode.
Though I would like to hear others views.
Tony
[ September 17, 2003: Message edited by: Tony Collins ]

[Philippe Maquet]

Hi Tony,

I agree there is a case to lock the properties file but I'm not sure if it's overkill or not.
The reason being is that I do not have two mice, two keyboards and four hands. Therefore I think the chance of updating the properties on the client and server at the same time are very slim.

Good point. If it'd been easy to do and with a technique which cannot be criticized, it would probably worth while anyway. But as Andrew's proposed solution (as far as I remember and undestand it) is not 100% safe (see API note above) ...
As you, I'd like to hear others views.
Regards,
Phil.

[Andrew Monkhouse]

Hi Tony,
As always, it is hard to define exactly where something is required for a professional solution, and something that is completely out of specification.
I suspect that this is outside of specification, but I am not going to argue against those who believe it is necessary for a professional solution.

I think the chance of updating the properties on the client and server at the same time are very slim.

Very slim, but not non existant.

And anyway why would you ever practically want the client and server on the same machine if you have the alone mode.

I have worked at plenty of small places where the progression has been:

One user runs the application for a while on their machine in stand alone mode

That user then opens their machine up to act as a server for that application for a while

Finally it gets moved to the real server

In such a scenario, in case 2 the user would probably have both a client app as well as the server app on their machine.

BTW: If we assume that all three application modes are going to have their parameters in the one configuration file, then if you start in a mode that has not been started before, then you could look at the other modes to see what their defaults are. So:

Run stand alone mode for 1st time (no defaults for anything)

Run server mode for 1st time: see if physical location of DB file from stand alone mode is valid, and if so offer it as default

Run networked client mode for 1st time: see if server address / port have been defined, and if so offer them as defaults.

Regards, Andrew

[Bharat Ruparel]

Thank you gents.
The defense had wrongly concluded that it had the case all wrapped up. In light of the fresh new evidence presented by prosecution, the defence needs to regroup and argue the case after some more homework.
Regards.
Bharat

[Tony Collins]

I think this project is as complex and long winded as you want it. I enjoy all the scenarios though, but I think the defense is handing in his project and going to the pub.

Tony

[Bharat Ruparel]

Hello Andrew/Tony/Phil,
I think I understand most of what you gents are driving at. The server component does indeed need a GUI (dialog-box sufficient?) to provide the configuration management service.
Andrew, I have a follow-up question:

What if (due to firewalls or similar) we need to specify a different port oon the server than on the client?

I do not understand it. I thought that the client and the server must agree to be on the same port, e.g., the default port for RMI service is 1099. RMI registry is started on port 1099 and the server is bound to it, therefore, the client must also look-up the remote object on the server on port 1099. How can the client and server be on different ports?
I am sure there is something that I am not following. Look forward to hear from you.
Thanks.
Bharat

[Andrew Monkhouse]

Hi Bharat,
I probably should not have mentioned that possibility. It is way outside of scope for this assignment.
But basically one thing you can usually do with a good firewall or router is to change ports without the client being aware of it. Technically I should have said router in my original comment as well, but I am so used to good firewalls having routing capabilites that I tend to forget that it is really a routing issue.
For example, I run two web servers on my computer. One serves the pages I want the outside world to see, and one serves the pages I am experimenting with. I want my experimental web server to be available on port 80 for me (because I am too lazy to type it into the address bar), however outside clients also expect to find my external pages available via port 80. Simple solution: my firewall routes any requests for port 80 to port 8080 on my web server.
So if I were to tell you the IP address and port number to connect to me, you would not really know what IP address and port the web server is really on. All you know is the IP address and port number of my firewall/router.
Regards, Andrew

[Bharat Ruparel]

Hello Andrew,
Thanks for the explanation. You wrote:

So if I were to tell you the IP address and port number to connect to me, you would not really know what IP address and port the web server is really on. All you know is the IP address and port number of my firewall/router.

Sounds like a proxy-server to me.
Regards.
Bharat

[Vlad Rabkin]

Hi Bharat,
Sorry for joining the topic so late.
I agree with Andrew and Phil except one issue mentioned by Phil:

There is a locking issue, because it's possible to start the server, a client and a stand-alone client from the same directory on the same machine (it's likely what the grader will do BTW).

Sun says:

You may assume that at any moment, at most one program is accessing the database file

So, this situation to my opinion is impossible: If there is only program which can access database, there can be only one program accessing a property file!!!
I am really sure that we should NOT take care of locking a property file.
There is always something to "upgrate", but we cannot be prepared for everything.
One more issue:
I don't disable fields for ip and ports if working in stanalone mode. I just don't show it. There is opportunity in Max books sample to change the mode every time, but it is not required in the assignement. So, I whow this dials only on the start of client. As client know the desired mode from comand line a show different dialogs. I don't think it is breach of requirement, because the main window after that has no clue if it is remote/local mode.

Best,
Vlad
[ September 18, 2003: Message edited by: Vlad Rabkin ]

[Bharat Ruparel]

Hello Vlad,
You wrote:

I am really sure that we should NOT take care of locking a property file.
There is always something to "upgrate", but we cannot be prepared for everything.
One more issue:
I don't disable fields for ip and ports if working in stanalone mode. I just don't show it. There is opportunity in Max books sample to change the mode every time, but it is not required in the assignement. So, I whow this dials only on the start of client. As client know the desired mode from comand line a show different dialogs. I don't think it is breach of requirement, because the main window after that has no clue if it is remote/local mode.

I agree with everything that you wrote above. I haven't yet implemented the solution yet, but was planning on doing pretty much what you outline above. I wasn't planning on locking the suncertify.properties file.
Thanks for confirming though.
Regards.
Bharat

[Andrew Monkhouse]

Hi Bharat,

[Andrew] So if I were to tell you the IP address and port number to connect to me, you would not really know what IP address and port the web server is really on. All you know is the IP address and port number of my firewall/router.
[Bharat]Sounds like a proxy-server to me.

Almost.
But in this case, all my firewall/router is doing is routing the traffic. It does not attempt to cache web requests at all. And that is one of the things a proxy server usually gives you.
Regards, Andrew

[Bharat Ruparel]

Gents,
Now that you have convinced me that I need two different UI for client and server, I am trying to get to the first base.
My plan is to display a dialog-box or dialog-boxes depending on which mode the program is started with, display the default information if found in the suncertify.properties file, let the user change it if he wants to, save the changed information by clicking on an appropriate button, or abort the run by clicking on the Cancel button.
As usual, I am starting with a test program which is supposed to display a dialog-box which extends the JDialog from Swing. I am passing it default information which is displayed in the text boxes. If the user decides to change it, the changed information is captured and displayed. I have written (or adapted from Core Java Vol 1.) a program that is supposed to display a dialog box and WAIT FOR THE USER edit the displayed information. It displays the dialog box all-right, but keeps going! I have the following problems:
1. I am not sure how to block it so that it doesn't execute the next lines of code. i.e., System.out.println("New Name: " + cInfo.username);... It should wait for the user input and THEN execute the next lines of code.
2. How do I remove the default menu from left hand top corner?
3. How do I center it on the middle of the screen?
Here is the code:

package test.dialogboxtest;
/**
 * Created by IntelliJ IDEA.
 * User: BRuparel
 * Date: Sep 19, 2003
 * Time: 2:10:26 PM
 * To change this template use Options | File Templates.
 */
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class DataExchangeTest   {
    public DataExchangeTest()    {
      }
   public static void main(String[] args)    {
      ConnectInfo cInfo = new ConnectInfo("Bharat","Ruparel");
      ConnectDialog conn = new ConnectDialog();
      if (conn.showDialog(cInfo))   {
        System.out.println("New Name: " + cInfo.username);
        System.out.println("New Password: " + cInfo.password);
        // System.exit(0);
      }
   }
   private ConnectDialog dialog = null;
}
class ConnectInfo
{  public String username;
   public String password;
   public ConnectInfo(String u, String p)
      { username = u; password = p; }
}
class ConnectDialog extends JDialog
   implements ActionListener    {
    public ConnectDialog()  {
      Container contentPane = getContentPane();
      JPanel p1 = new JPanel();
      p1.setLayout(new GridLayout(2, 2));
      p1.add(new JLabel("User name:"));
      p1.add(username = new JTextField(""));
      p1.add(new JLabel("Password:"));
      p1.add(password = new JPasswordField(""));
      contentPane.add("Center", p1);
      Panel p2 = new Panel();
      okButton = addButton(p2, "Ok");
      cancelButton = addButton(p2, "Cancel");
      contentPane.add("South", p2);
      setSize(240, 120);
   }
   JButton addButton(Container c, String name)
   {  JButton button = new JButton(name);
      button.addActionListener(this);
      c.add(button);
      return button;
   }
   public void actionPerformed(ActionEvent evt)
   {  Object source = evt.getSource();
      if(source == okButton)
      {  ok = true;
         // System.out.println("Pressed OK button.");
         setVisible(false);
      }
      else if (source == cancelButton)  {
         setVisible(false);
         // System.out.println("Pressed Cancel button.");
      }
   }
   public boolean showDialog(ConnectInfo transfer)
   {  username.setText(transfer.username);
      password.setText(transfer.password);
      ok = false;
      show();
      if (ok)
      {  transfer.username = username.getText();
         transfer.password = new String(password.getPassword());
      }
      return ok;
   }
   private JTextField username;
   private JPasswordField password;
   private boolean ok;
   private JButton okButton;
   private JButton cancelButton;
}

I am no Swing expert. I will look forward to your help.
Thanks.
Bharat

[John Hembree]

Here's two out of the three...

   public void actionPerformed(ActionEvent evt)
   {  Object source = evt.getSource();
      if(source == okButton)
      {  ok = true;
         //System.out.println("Pressed OK button.");
         setVisible(false);
      }
      else if (source == cancelButton)  {
         setVisible(false);
         ok = false;
         //System.out.println("Pressed Cancel button.");
      }
   }
   public boolean showDialog(ConnectInfo transfer)
   {

      username.setText(transfer.username);
      password.setText(transfer.password);
      ok = true;
      // Center on screen
      Dimension d = Toolkit.getDefaultToolkit().getScreenSize();
      int x = (int) ((d.getWidth() - getWidth())/ 2);
      int y = (int) ((d.getHeight() - getHeight())/ 2);
      setLocation(x, y);
      //Stop it from continuing to process lines of code
      setModal( true ) ;
      show();
      if (ok)
      {
          transfer.username = username.getText();
         transfer.password = new String(password.getPassword());
      }
      return ok;
   }

[ September 19, 2003: Message edited by: John Hembree ]

[Philippe Maquet]

Hi Bharat,
From 1.4, "setLocationRelativeTo(null)" will center your dialog on the screen too.
By "the default menu from left hand top corner", do you mean the popumenu attached to the close box ? I am not sure it's possible to access it in Java, it should be platform-specific right ?
If nobody replies here, try the Swing/AWT forum. That's what I do when I have a technical question (well just only one till now ).
Best,
Phil.
[ September 20, 2003: Message edited by: Philippe Maquet ]

[Bharat Ruparel]

Hello Phil,
You wrote:

By "the default menu from left hand top corner", do you mean the popumenu attached to the close box ? I am not sure it's possible to access it in Java, it should be platform-specific right ?
If nobody replies here, try the Swing/AWT forum. That's what I do when I have a technical question ...

I meant the menu on the dialog- box that shows Move, Size, and X Close when you click on the "Java" coffee icon. I don't think that I will pursue it any more. The reason that I was thinking along those lines is that I was going to construct one dialog-box specifically for the Server. The only parameters that I would store for the server in Suncertify.properties file for the server would be server port number and the data file location. I thought that it might be a good idea to only show a dialog box without a containing frame and therefore I was trying to prevent the user from closing the dialog box by choosing the x Close option from this drop-down. It seems to me that this could be treated as just another case of the user choosing the "Quit" or "Cancel" button and abort or shut the server down? What are your thoughts on that? I did go to the Swing forum last night and did a search for the JDialog and found some useful threads there.
Hey John,
Thanks! You are right on with your suggestions. Follow up questions though. What exactly does "setModal(true)" do? Does it just prevent the user from clicking on "other" GUI widgets behind the currently displayed dialog box? What happens to the code that displayed the box in the first place? I may not be asking this question correctly, but I will take a stab at clarifying my question. I would love to pop-up a specific dialog box before I get going with 1. starting my server, and 2. displaying my client GUI either in "alone" or "network" mode; display the defaults to the user (if any) let him or her make any necessary changes by changing the values displayed in the dialog box. Doing all my validations there, update the Suncertify.properties file and then start the server and the client. Good idea? Bad idea? Any suggestions?
Regards to you both gentlemen.
Bharat
[ September 20, 2003: Message edited by: Bharat Ruparel ]

[Philippe Maquet]

Hi Bharat,

It seems to me that this could be treated as just another case of the user choosing the "Quit" or "Cancel" button and abort or shut the server down?

Good idea.
Regards,
Phil.

[Bharat Ruparel]

Hello Phil and John,
I am rolling again!
Thanks.
Bharat

[Bharat Ruparel]

Hello All,
Submission time details: OK so my runme.jar file runs the server on a remote machine. I can run it on my local machine and remotely connect to the server. In a nutshell, things work! What do I do with the suncertify.properties file? Should it be packaged with runme.jar file or outside of it in the master.jar file (what should I call this master.jar file? I am not able to find a specific name for it in the instructions.).
The reason I bring up this question is: When the server is run on a remote machine, the instructions are clear about packaging the db-1x1.db file with the master.jar file. What about the suncertify.properties file? My program currently assumes that such a file is available in current directory from where either the server is started or the client is started (same for the alone mode too).
My question is: Can I assume that the grader will care to put this file (suncertify.properties) in the current directory where he/she starts the server, the client, and the application in alone mode?
Will appreciate your response.
Regards.
Bharat

[Dave Knipp]

I would think if you put this in your installation instructions that the grader would follow your instructions and place the suncertify.properties file within the current working directory.
IMO i would put the file in the master jar where the database file goes and tell the grader that he must extract the properties file and place it in his current working directory.
Do you think this would be sufficient?
Does anyone else know if this is ok??
Dave

[Andrew Monkhouse]

Hi Bharat & Dave,
Personally I would use the suncertify.properties file if it exists in the current working directory, but just create a new one if it doesnt already exist (and provide decent default values in the GUI).
Then allow the sys admin to copy the suncertify.properties file if they want to / if they can do it easily. Don't force them to do extra work.
This would allow me to ship the submission without a suncertify.properties file - after all, why should the examiner care where my database file exists or what my server IP address is (which are going to be the defaults in your GUI if you ship your suncertify.properties file.
Regards, Andrew

[Bharat Ruparel]

Thanks Andrew,
I shall do that.
Regards.
Bharat