Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Best method of calling programs from form ?

Status
Not open for further replies.

Raccoon

Programmer
Aug 18, 1999
92
0
0
US
I have 8 programs that I want to call from a single form. The form is simple, with a couple of data input fields, 8 buttons to call programs, and a quit button.

My question:
What is the best method of calling the 8 programs?

For example:

In the click put a DO PROGNAME ?

Add the programs as new properties of the form ?

Combine programs in a Procedure file and call as procedures ?

All input is welcomed. Thanks
 
If the programs can easily be 'turned' into procedures, you could simply copy the code for each one instead into new methods on your form.

Then you would call them with THISFORM.NewMethod1().

This would make also your form self-contained, but if you need to share your programs at a later stage with other forms, etc you would possibly be better leaving them as programs.

Neil "I love work. I can sit and stare at it for hours..."
 
HI Raccoon,

1. If the code is small and you dont need them again in some other PRG or form.. then.. simply add suitably in the BUttons Click event code..

2. If you want to use them from different places within the form.. then.. Create Methods in the form.. and then call them in the Click Event
ThisForm.MyMethod()

3. If you need the repeat use of the procedures from different forms.. then.. code these procedures are .PRG and add them in your project. You can then call them in the click event by..
DO myPrg1

4. If the procedures are often repeated ones and want to keep them as a single procedure.. you can add them at the end of your Main.Prg and then call them as in 3.

5. If they are database events, you can even add them in stored procedures of the DBC.

Choice is yours. :)

:) ramani :)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
Happy New Year [bigears] [party] [2thumbsup]

 
I would want to remind everyone of the one big catch in using forms and new methods, or even calling to procedures. Always remember that variable scope remains the same with methods as with other called functions and procedures. Private and local variables exist only so long as the methods. This cause me no end of problems when first using Screens and reports until I got this though my thick head!

Declare your privates before opening a screen in modal mode and they will retain scope. for modeless screens you need to declare them in the main program.

Frank
 
What Frank says is true, and is a very common problem when converting Foxpro DOS screens to VFP Forms.

However, using variables in this manner violates several OOP principles, such as Encapsulation and Abstraction.

In general, you should not use variables this way throughout the methods (custom or otherwise) on a form: Use Form Properties instead.
 
Also note that form properties and methods are not available in an external program called with "DO MyProg". Therefore, THIS and THISFORM objects don't exist.

However, it sounds to me like this form is simply a main menu. If that is the case, then the procedures don't really interact with the form at all, and they would be safe in external .PRG files.

I try to avoid global/public variables at all costs. They make debugging insanely hard in larger projects.

Ian
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top