Maybe you are missing some basic info about GUI programming:

GUIs like Tk are working with "callbacks". That is, if the user clicks on some button (or menu item or...), a subroutine is called that you provided when you created the button. So when you program a GUI you have to think backwards. Not you as script writer control the sequence of events, it is the user.

If you want user-generated windows, you have to create (for example) a button before you call MainLoop. And provide a callback subroutine with the code to create a new window. This subroutine is not called by your code, it is called by Tks MainLoop.

I do have idea how it works. So I am confused. because I want to generate a main window which would be having few buttons to give users choice of actions to be performed. once user will choose the action, I want to put a dialog box for user asking further choices. so it should be like, once i get one answer, i should close that window and further a new window would be generated asking user for further choices, and so on.

So it should be simple. The subroutine that gets called with the answers to the previous question closes the old window and creates a new one with new questions. And it provides a new subroutine to the 'Done'- or 'next'-Button of this window.

But think about it. The user would get a sequence of windows that flash "violently" open and close again, probably ignoring where he put previous windows and always going into the foreground even though he might wish otherwise. It doesn't sound like good GUI design to me. Observe other programs on your operating system. How do they do it?

Most will probably have a window that changes its contents to provide the new questions to the user, not generate a new window. Think of install dialogs on windows with those 'next' buttons. Or they will have at most one popup window that leaves the original window intact. Or the window will be successively filled from top to bottom with more and more detail...

By the way, have you noticed how similar the interaction you want is with how web pages work? You press a 'finished' button and the browser tab or window contents is replaced by new information and questions. Also it is easy for a CGI script to create new tabs/windows (but not easy to delete the old ones at the same time, you have to stay in the same tab/window for that). That is another advantage of a web GUI beside the already working client-server communication and the easier graphical design of the GUI

The first thing I would advise is simplicity of the GUI. There can be a tendency to over complicate things. But, I have found that sometimes it is harder to design a simple GUI than a complex one because a lot of thought has to go into "what are the users going to do?" and "what info do they expect?".

One thing to consider is your "target user". From the info I've gleaned so far, you are describing an interface to a test tool which would be used by a test department or some field tech. If that is true, then some options are available to you which are better for them (more info) and you (less coding). More coding and thought is required for "just any random user".

It appears that you have some small number of main options, like #1,#2,#3. I would be thinking about making those "buttons" and the options for each button to the right hand side of each button within a "control panel". The user fills in the options like maybe "House or Apartment?", etc. Then hits the "go button", e.g. option #1. Then you reply with a typical "Ok,Cancel" screen that details what actions will be done if the user hits "ok". Hitting "Cancel" will dismiss this sort of window and the user can adjust settings.

So, I would be thinking along the lines of a single main window, "a control panel" with the buttons on the left and the options to the right of each button.

I would not be thinking about multiple toplevel windows, at least not from what you have described so far. MessageBox just pops up a window for the user to "click" upon and it is easy to use..No fancy TopLevel stuff involved.

The messageBox method to the mainWindow could work something like this (untested):

my $actions = "1)blah\n...2)blah\n...3)blah\n...4)\blah\n";
my $response = $mw->messageBox( -title => $STD_TITLE,
       -message => "HEY!! This will do:\n $actions\n\n".
                   "DO YOU WANT TO PROCEED?\n\n", 
       -type => 'YesNoCancel');
print "yes clicked" if ($response =~/^Yes$/i); #of course you do it, n
+ot print
[download]

Another thing to consider with a GUI is: how you are going to present "progress" to the user? Of course assuming that whatever is being requested is going to take "some noticeable time".

I have often seen programs that:
-start zoomy animated .gif process that looks like progress is being made
-start "real work"
-stop zoomy animated .gif
The problem with this is that if "real work" hangs or lasts a very long time, the user doesn't know whether to cancel the program or wait some more.

There are ways to make zoomy progress bars and also to present in the GUI: File #x processed as a periodically updated field. However, the easy way for this is to minimize the main window once the "actions" start being executed and just print something to STDOUT that represents "progress" (recommend more often than 5 seconds). If the main GUI window is minimized, the "command line" window will still be there. If that window is showing a different line every 5 seconds, the user will not CTL-C the application.

If you use printing to STDOUT for describing progress, if tester has problems, you can just have the tester start fancyGui.pl with a pipe to "tee", e.g. perl fancyGui.pl | tee SomeFile (or you provide some shell script like fancyGUI.bat) for error analysis and you will see where program "bombed".

...
$main->Button(-text => 'Test',
-command => \&Test)->pack(-side => 'left');
$main->Button(-text => 'Logging',
-command => \&LogOutput)->pack(-side => 'left');
...
MainLoop; #Here Main window ends
#And we declare our subs with own window for each
sub test{
my $TestWindow;
$TestWindow=$main->DialogBox(-title   => 'Test sub window',
                             -buttons => ["OK"]);
#We've created dialog box for test sub output
#Then folowing you testing code
...
Testing code =)
...
if($success){
$TestWindow->add("Label", -text => "Test passed!")->pack;
}
else {
$TestWindow->add("Label", -text => "Test Failed!")->pack;
  }
#Putting conditional output on our window
$TestWindow->Show(); # Poping it in front main window
#It is not separate window object, but dialog box produced  #by main o
+bject 
$InfoWindow->destroy; #Destroying it when OK pressed, and back to main
+ window
}
[download]

thanks man. Let me try this solution. I will get back to you if any further queries.