Declare parameters from form to prg file

[TheLazyPig]

Hi!

How to declare parameters from form to prg file.

When I click OK button a prg file will execute the program.

The first dropdown contains the name of my prg file this will declare what prg file will run.

This is my code for OK button..

SET CENTURY OFF
SET CENTURY ON
SET DELETED ON
SET SAFETY OFF
SET UDFPARMS TO REFERENCE

CLOSE ALL
CLEAR

LOCAL lcDir, accntGrp
*----------------------------------
lcDir	 = "C:\RECOMPUTE\RECOMPUTE2\"
*----------------------------------
DO util.prg

accntGrp = thisform.cboAccntGrp.Value

DO CASE
	CASE accntGrp = 'DEPED'
		DO (lcDir)+"code\deped_newprod.prg"
		
	CASE accntGrp = 'CAFGU'
		DO (lcDir)+"code\cafgu_newprod.prg"
		
	CASE accntGrp = 'HANJIN'
		DO (lcDir)+"code\hanjin_newprod.prg"
		
	CASE accntGrp = 'BFP'
		DO (lcDir)+"code\bfp_newprod.prg"
		
	CASE accntGrp = 'PNP'
		DO (lcDir)+"code\pnp_newprod.prg"
		
	CASE accntGrp = 'PRIVATE'
		DO (lcDir)+"code\private.prg"
		
	CASE accntGrp = 'REGULAR'
		DO (lcDir)+"code\regular.prg"
ENDCASE

I put my parameters (month,year,foldir) in bfp_newprod.prg.

When I try to test my program I get an error of

And this line is the error

 lcMonth	   = ALLTRIM(THISFORM.cboMonth.VALUE)

I used thisform to get the value of my parameters but it won't work because it's a prg file not form.

If I'll put my parameters to OK button, how will I use it to my prg file.


Thank you!

 

[mjcmkrsr]

Hi,

LOCAL lcDir, accntGrp
*----------------------------------
lcDir	 = "C:\RECOMPUTE\RECOMPUTE2\"
*----------------------------------
DO util.prg

accntGrp = thisform.cboAccntGrp.Value

DO CASE

Since you run UTIL.PRG before the local variable accntGrp is allocated a value and since we do not know what UTIL.PRG does, accntGrp may be empty or out of scope.

You may want to

invert the running order and check if that works

accntGrp = thisform.cboAccntGrp.Value

DO util.prg

or declare accntGrp private or global

or DO ThePrg WITH parameters (please have a look at the DO command in the Help File)

hth

MK

 

[Mukesh Khandelwal]

Hi

You can call your program as
( Pass "THISFORM" as parameter to PRG file.)

DO (lcDir)+"code\deped_newprod.prg" with Thisform

Code of deped_newprod.prg
Parameter oForm
lcMonth = ALLTRIM(oFORM.cboMonth.VALUE)

Thanks

Mukesh Khandelwal

 

[Olaf Doschke]

You already got what does not work.

The question is, whether the PRG code should become independent from the form or not.

Mukesh has a working solution in passing in THISFORM, as that enables you to have the form access again, you'd pass it in as toCallform, and address toCallform.cboMonth.Value instead of THISFORM.cboMonth.Value.

But actually the cboMonth.value does not change between the OK button click and that line reading the month from the combobox, does it. So pass in the month and other values you need in the PRG instead of letting the PRG get these values, that would be the straight forward decoupling of dependencies.

The other would be making the PRG part of the form.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mukesh Khandelwal]

Yes, Olaf is correct. instead of passing "THISFORM" as parameter, you can pass the value of MOnth and Year to your PRG file so that your program is not dependent on the FORM object.

You may use the same program file as a generic process just by passing Month and Year values.

Thanks


Mukesh Khandelwal

 

[Olaf Doschke]

And to address the question title, you can use the WITH syntax with DO, but you can also call a PRG by its name with the usual convention of parameters in brackets, as if it was a function:

utils(Thisform.txtYear.Value, Thisform.cboMonth.value)

It then becomes harder to see for anyone not knowing utils is a PRG, so you could start naming your PRGs with a prg Prefix to have calls to prgs as prgUtils(...), for example.

As we talk of a utils.prg in one case, I assume that has several functions and procedures defined in it. Then you would SET PROCEDURE to it once and after that be able to call the functions and procedures by their name as if they were native VFP functions you can also call anywhere in code.

Both ways enable a normal programming syntax function(params). The way working without SET PROCEDURE only allows one function per prg, the call always goes to the PRG line 1. And some even prefer that, as it gives you a list of files like a document view of a PRG with several functions defined within.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mukesh Khandelwal]

Hi

If you are not using SET PROCEDURE command and your program file contains multiple functions then you can also use
do FunctionName in utils

Thanks



Mukesh Khandelwal

 

[Olaf Doschke]

Ah, you're riught, sorry. I just never use that syntax anyway.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[TheLazyPig]

I removed util.prg it has functions that I didn't use in the form.

 

[Olaf Doschke]

You removed that line?

LOCAL lcDir, accntGrp
*----------------------------------
lcDir	 = "C:\RECOMPUTE\RECOMPUTE2\"
*----------------------------------
[highlight #FCE94F]DO util.prg[/highlight]

accntGrp = thisform.cboAccntGrp.Value

If it has several functions in it, then why did you call it that way? The call would start at line 1 despite what I learned today from Mukesh Khandelwal, because you really only call the whole PRG, not a function within it. And if utils.prg only has function declarations, that would even not call anything in it. Only any code before the first FUNCTION, PROEDURE, or also before a DEFINE CLASS would run and end at the first declaration it hits with an automatic RETURN .T.

Your error points out that something ran within a PRG. A line not shown in your posted code, though. That's a riddle left open.
Besides you have the same problem in this PRG code with the next line trying to read from a form control: accntGrp = thisform.cboAccntGrp.Value
You simply never can do such things in a PRG, THISFORM only runs in a form method or method of something within the form.

And just to tell you before you do: You can't define one method in a from and copy in all procedures/functions of a PRG to have the code in form context, each procedure will need to become its own method of a form, if you want to put this together that way.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

I don't know if you're used to Python. VFP works inverse to Python logic when it comes to definitions. Pythons' [tt]def[/tt] is actually a command defining a function, Python runs through all declarations and then following code can address them. In VFP you put declarations towards the end of a PRG after the "main" code.

Both languages also allow completely separated definitions/declarations, but then you import them in Python and in VFP you call them with full name, set current dir/default path or use a combination of SET PATH and SET PROCEDURE/SET CLASSLIB. And those SETs are only necessary once for the rest of an EXE to be able to make calls, so VFP doesn't need an import in every PRG to use other PRGs.

It's even not unusual I add some functions to main.prg at the end where they will be available no matter how often some programmers are too keen tidying up with CLEAR commands removing classlibs or PRGs from memory.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name