I’m a relative Perl newbie, but I’ve been programming computers since 1967, hence the name PapaGeek!

My first Perl project is a personal investment management program to manage my 401K / IRA investments. The first step is to use Win32::GUI to create the menus for the front end. Please feel free to pick my plan apart.

I plan to publish the source when I am done, for your use, and also a step by step guide and example for using Win32::GUI.

Plan A is to create a Top Level Menu that merely has a few button that take you to the other parts of the process: managing what stock symbols to invest in, tracking what I’m invested in, tracking which accounts are invested in what stocks/funds. As one menu calls another the plan is to use code like:

Code

$thisMenu->Show(); # Display the new menu $parentMenu->Hide(); # And hide the previous

When I am finished with the new menu:

Code

$thisMenu->Hide(); # Hide the menu we are done with $parentMenu->Show(); # And go back to caller

For Pop Up error messages with only an OK button, I plan to use enable and disable so the parent menu will remain visible.

My first attempt was to place all the code for all the menus in a single file. Huge Mistake!

Plan B is to create separate Perl files for each menu. The directory structure would look something like a tree, but some of the branches would intersect. For example; many of the menus would have a dropdown to allow you to select which stock symbol you want to update or modify. Each dropdown would include an entry to allow you to enter a new symbol. Since this dropdown would exist on multiple menus, the Add Symbol menu could be called from multiple location in the menu tree.

The plan is to call the top level create menu process then show the top level menu and start the dialog. The top level menu Perl file would know what other menus it can link to and call the create menu process for those menus within its own create menu process. Each create menu process would return the handle toe the menu it just created and each Perl menu file would remember the handles to the menus it can call as it creates them.

Since the add symbol menu can be called from multiple other menus, it should remember the handle to the menu after the first call and merely return it the next time it is called. This would also avoid infinite recursive coding. If A calls B which calls C which can call B again. Perl file A’s create process would call the menu B create process which would call the menu C create process which in turn calls the Menu B create process, but this time the create process would know that B was already created so it would merely return to previously create menu handle and not follow the code that creates C again.

Each menu would call itself “$thisMenu” and the menu that called thisMenu would be call “$parentMenu” so the code for things like the cancel and OK buttons could merely be copied from one source file to the next.

Is it best to use classes to create each menu, or would a package be better.

Each menu will need a series of global variables for things like the handle to the menu itself, $thisMenu, and the menu that called it, $parentMenu, as well as the handles to various controls within the individual menu. Because the menu dialog process calls a number of event processing subroutines, these sub process have to know the handles to the various controls and menus needed by the individual menu. Can these variable me made global to the package / single perl file and also hidden from other programs even if they know the package name?

Also, I am assuming that if I use a class or package, that I can call the Cancel button on each menu “Cancel” and that when the dialog process call sub Cancel_Click that it knows to use MenuA::Cancel_Click or MenuB::Cancel_Click, etc. based on which cancel button was clicked.

If you haven't already done so, I'd recommend developing a detailed flowchart of your app. Doing so would help you to visualize what you're needing to do as well as help others to understand your goals and help catch design flaws.

I already have a fairly detailed flowchart of the entire app. The top level of the chart is the GUI, then other parts are designated as LOGIC, DATABASE, WEB ACCESS, INTRANET, etc based on the primary functionality.

You stated that: “If you need a menu option/object to "remember" the menu handlers, then you'll want to store that in an OO object.”

I broke it down into two separate packages, not OO, and it still requires that all event handlers reside in the Perl script that starts the dialog.

I tried starting a dialog in the package, but that caused everything to fail.

I’ll try the OO approach is you can give me a hint on how to set it up. My next step will be to create separate open and close functions in each menu and look for a way to pause the dialog in the parent menu so I can start a new dialog in the child menu.

Again, my biggest concern is that in a large GUI application with many menus, having every event handler for every menu in one location will make maintenance of the code a nightmare.

Here is the stripped down code for a single button with a single click event handler.

Code

TestGUI.pl

use Modern::Perl '2013'; use Win32::GUI(); use TopMenu;

main();

sub main { my $topMenu; # Mainline is a skeleton program $topMenu = TopMenu::Create(); # It only creates the top menu $topMenu->Show(); # Displays it Win32::GUI::Dialog(); # And starts the dialog }

# This is the code I want to avoid # I don't want to have every event from every menu in one place # This will make maintenance of the GUI very difficult as the process grows

I won't be able to have access to a system that has Win32::GUI until Tue, so I can't do any testing until then.

I'm not 100% sure what you're want to achieve. Are you wanting a separate package (namespace) for each menu? If so, then that would be the wrong approach.

What you can do, and I'm not even sure it is the best approach, is to put all the subs for a given menu in its own .pl library file and load them in the main script with a do { } block. Anything directly related to the main toplevel window should be in the main script i.e., your Create() sub should be defined in the main script instead of an external package or lib file.

e.g., TestGUI.pl

Code

use Modern::Perl '2013'; use Win32::GUI();

do { 'menu1_libs.pl'; 'menu2_libs.pl'; }

That will load the subs into the main:: namespace so you can call them without specifying a different package/namespace.

Those scripts should only contain subs. They should not execute code blocks outside of their defined subs.

The process as described below will have a multiple menu User Interface, I’d like to be able to break the coding for each menu into a separate file, PL or PM doesn’t matter. If it is PL, I can assign a simple 2 letter mnemonic prefix to all subs associated with a given menu so the names don’t collide. I’d like the Win32::GUI::Dialog(); to call the event subs in each PL file directly. The PM approach I used called the event subs in the same file where the dialog started, not the individual menu files. I will try your do{…} approach with PL files and see how that works.

Overview of the Project

The project I’m working on is to convert my manual 401K analysis process into a Perl Program. My 401K, as with most, gives me a small list of available investments. There is a performance page that tells me how well each investment did over the past 3 months, 6 months, 1, 3, and 5 years. I sort the investments and assign a rank for each percentage return category and then create an overall rank for the investment. I then display the possible investments in rank order along with how much I have invested in each. By looking at the chart I can see if my investment are in the best performing funds and also look at the investment types to insure that everything is not invested in small-cap or large-cap or international etc. I want the investment in the best funds while spread out over various investment sectors.

This process works well but requires a fair amount of time each month and also gives me no way to look at what the system would have told me 6 months ago.

The program I’m working on will have a dumb top level menu that will take me to the various actions I want to perform.

Accounts: a list of investment account that I have. Each account has a nickname for display such as his 401k or her Roth IRA, as well as a full description of the account; broker, fees, etc.

Sectors: a list of the sectors that I place each investment in; mid-cap, small-cap, international, medical, high tech, etc.

Tickers: a list of all of the ticker symbols for the stocks and funds that I can or want to invest in. This also includes a list of the accounts that can invest in each ticker and the sector of each ticker.

Investments: how much is invested in each ticker in each account.

Update: the ability to run an update as of a given date.

The normal process is to create accounts, then create sectors, assign the tickers to a sector, and manage the investment in each account. The reality is that you might be entering a new investment in an account and realize that the ticker is not in the system yet. You have to enter the Ticker menu from the investment menu instead of the top level menu. While in the ticker menu you might also decide you need a new sector. Each menu should return to its parent when it is completed and as just stated, that parent might vary.

Also, each of these menus will probably have a few pop-up menus to tell you thing like you can’t enter a date in the future for running the reports or a status bar menu to show the progress of running the reports for each account. All of the reports will be created on disk as an intranet website. All of the account data and the historical ticker prices will be stored in a local database.

I would be happy to share the final code when the project is completed.

You have been a major help and I thank you for that. Based on what you have said so far, I have experimented with a possible coding scheme. As stated, I want each menu to be contained in its own file, per your advice, a PL file. You mentioned a do loop of sorts, couldn’t get that working, but individual do’s for each menu file works great.

Here are three files that seem to work and I’d appreciate your critique of what was done so far.

TestGUI.pl contains a commented list of the basic menu structure, only two of the menus are in the test so far and each menu has a prefix letter to insure that there is no code interference. I load each menu with a do statement and then create each menu. Each menu has a local variable that hold the handle to the menu. I use the main menu handle to show the main menu and then start the dialog.

The M or main menu contains a set of buttons to call the other menus. Only the first one does anything and the list is not correct or complete yet. The open accounts event at the end of the file uses the main handle to hide that menu and the account handle to show the next menu.

The A or accounts menu only has one button so far to close it. There are two events at the end of the code. The first is to terminate the menu when the bottom is clicked which links to the code to terminate the menu when the X is hit. In either case I merely hide the pop up menu and restore the main menu.

I realize the code is very primitive and is missing large chunks, but how do you feel about the basic approach?

sub main { do 'MenuA.pl'; do 'MenuM.pl'; A_Create(); # It only creates the menu M_Create(); # It only creates the menu M_Handle()->Show(); # Displays top menu Win32::GUI::Dialog(); # And starts the dialog }

Vars should be declared in the smallest scope they require. Even though the way you're declaring and assigning $M_Menu and $A_Menu and then calling them via M_Handle()->Show(); will work, that is not the best practice. Instead those vars should be declared in their subs and returned by the subs.

Since 95% or more of the logic and functionality will be in external files, your main script should have a copious amount of POD documentation. Some of that documentation will need to be duplicated in the external scripts. That duplication is generally frowned on, but is sometimes acceptable.

You said you had problems installing Win32::GUI on your system. Mine failed the first time also. I found the solution in the thread, https://rt.cpan.org/Public/Bug/Display.html?id=60865

Half way down the thread they recommend to use the “patched2” link, and that link did fail when I tried to install it (found that link on another thread). The last post recommends using “patched3”, and that one did install on my Windows7 64 bit system.

“ Try my patched version by running the following command from command prompt:

I’m working on your suggestion. I’m going to eliminate the X_Create and the X_Handle subs and replace them with X_Menu subs. I found the “our” alternative to “my” which keeps the variable around between calls and tested how that works. Plan A, or is that up to X or Y now!, is to convert the beginning of each file from:

I’m trying to avoid the concept of creating a menu every time I want to show it, or reference it. That concept limits what I can do within the logic, things like changing the appearance or content of a menu on the fly based on the circumstances.

What I need is a variable that remains defined from one call to a sub to the next, but restricted to that sub or file alone, not visible outside the sub/file. The only way to do this is with a package, but that makes the dialog loop extremely complicated to implement.

“Perl got this one wrong from version 1 and onwards. The default variable scope in Perl 5 is the “package variable”, a kind of global variable. Define something inside a block; still see it outside.”

It looks like Perl missed the boat on that one. In order for a variable to remain defined it must be global and available to all subs at the same time.

I’ll just have to rely on a few global variables: $menu_A, $menu_B, etc

What I need is a variable that remains defined from one call to a sub to the next, but restricted to that sub or file alone, not visible outside the sub/file. The only way to do this is with a package, but that makes the dialog loop extremely complicated to implement.

This can be done without any problem (see below).

In Reply To

“Perl got this one wrong from version 1 and onwards. The default variable scope in Perl 5 is the “package variable”, a kind of global variable. Define something inside a block; still see it outside.”

Not true if you use strictures and lexical ("my") variables.

In Reply To

It looks like Perl missed the boat on that one. In order for a variable to remain defined it must be global and available to all subs at the same time.