How to SET PROCEDURE TO?

Topics: User Forum
Mar 8, 2013 at 1:28 PM
I cleared all contents of ActvieVFP examples and started rom scratch.

Basicaly all I have is main.prg and get_vars.prg. What I need is to SET PROCEDURE TO get_vars

Contents of main.prg:
LOCAL lchtmlout

lcHTMLout = ""

lcHTMLout = lcHTMLout + "<br>oProp.AppStartPath:" + oProp.AppStartPath

SET DEFAULT TO oProp.AppStartPath + "prg\"
SET PATH TO oProp.AppStartPath + "prg\" ADDITIVE

SET PROCEDURE TO get_vars ADDITIVE

RETURN lcHTMLout
Although path is correctly set, all I get is error Caught .NET exception
, source: MAIN.PRG 00002rs9004a err#= 1 line= 16 File 'get_vars.prg' does not exist.1 File 'get_vars.prg' does not exist. get_vars.prg .NULL. .NULL. .NULL. .NULL. C:\Inetpub\proba\activevfp.dll
message: C:\Inetpub\proba\activevfp.dll

I even tried to set procedure with full path manualy entered in code and I stili get the same error. This is really strange.

What I am doing wrong?
Mar 8, 2013 at 2:30 PM
Hmm... I had to compile get_vars.prg to make this works.
Why is that?

And why should I complie manualy. Isn't it logical that ActiveVFP compiles every PRG it loads?
Coordinator
Mar 8, 2013 at 2:43 PM
"I cleared all contents of ActvieVFP examples and started rom scratch. "
I hope you kept a copy of the examples somewhere so you can refer to them.
"What I am doing wrong?"
Is get_vars.prg compiled??

In the simplelist.avfp example, prg\pages is used. So try:
SET PROC to oProp.AppStartPath+'prg\pages' ADDITIVE &&we know this works because the simplelist.avfp example uses it
and see if that works. If it works, put get_vars.fxp and get_vars.prg in prg\pages too and see if it works.

BTW, if you intend to actively modify your function library in the development process, you'll need to release it at the end of the routine like:
RELEASE PROCEDURE oProp.AppStartPath+'prg\pages'
Coordinator
Mar 8, 2013 at 2:47 PM
Edited Mar 8, 2013 at 2:50 PM
_"Hmm... I had to compile get_vars.prg to make this works.
Why is that? "_
The scripts compile automatically as do controllers. Your libraries do not. However, you can use the new CompileIfNew function to automate this part in your code so you don't have to do it manually.
"And why should I complie manualy. Isn't it logical that ActiveVFP compiles every PRG it loads?"
Sure that would be nice too. Why don't you contribute this functionality???
Mar 8, 2013 at 4:00 PM
Sure, I would contibute if I manage to do that.

Actually I developed myself something similar to ActiveVFP years ago, but I find ActiveVFP promising in functionality I did not manage to create, so I am considering to switch to ActiveVFP. However, my web server does compile everything it loads :)

I did try autocompile and it works in some manner, but I get errors as fxp stays locked so compiler cannot replace it. I do use RELEASE PROCEDURE.

Here are two functions I wrote to make it easier to handle loading libraries. Maybe something like that could be included in main code as I guess it is frequently needed.
PROCEDURE LOADLIB
  PARAMETERS pLibName, pLibPath

  IF (! EMPTY (pLibPath))
      mLibName = pLibPath + "\" + pLibName
  ELSE
      mLibName = pLibName
  ENDIF

  IF ! FILE(mLibName +".fxp") OR FDATE(mLibName + ".prg", 1) > FDATE(mLibName + ".fxp", 1) 
    COMPILE mLibName + ".prg"
  ENDIF

  SET PROCEDURE TO (mLibName) ADDITIVE

ENDPROC



PROCEDURE UNLOADLIB
  PARAMETERS pLibName, pLibPath

  IF (! EMPTY (pLibPath))
      mLibName = pLibPath + "\" + pLibName
  ELSE
      mLibName = pLibName
  ENDIF

  RELEASE PROCEDURE (mLibName)

ENDPROC
Thing is, if I use ActiveVFP then most of my code will be in libraries, not scripts, so I have to deal with this fxp file locking.
Coordinator
Mar 8, 2013 at 7:18 PM
"Thing is, if I use ActiveVFP then most of my code will be in libraries, not scripts, so I have to deal with this fxp file locking."
Like I said above THERE IS NO LOCKING if you just RELEASE your library after the run of your code...

RELEASE PROCEDURE oProp.AppStartPath+'prg\pages'
Mar 18, 2013 at 9:55 PM
Releasing procedures works fine until code breaks before RELEASE is executed, which is often while you are coding and debugging...

I managed to reduce locking by catching errors in TRY CATCH FINALLY thus forcing releasing procedures even if error occurres. However, I still have situations that fxp stays locked.
Coordinator
Mar 18, 2013 at 11:33 PM
Edited Mar 19, 2013 at 2:24 AM
What kind of error specifically? I tested by trying to use a non-existent DBF (USE mydbf.dbf &&table doesn't exist) in pages.prg which generated an error when I ran simplelist.avfp. I then added the following to simplelist.avfp:

SET PROC to oProp.AppStartPath+'prg\CompileIfNew' ADDITIVE
CompileIfNew('pages')
SET PROC to oProp.AppStartPath+'prg\pages' ADDITIVE

I then commented out the USE mydbf.dbf in pages.prg and saved the file (no compile in IDE) and it worked! What's even more surprising is I didn't even have to put the RELEASE PROC in simplelist.avfp. It appears that the CompileIfNew command doesn't suffer any locking at all!?

Please let me know if this works for you.
NOTE: if you're using scripts, you can put all the SET PROCs (or NEWOBJECTs for class libraries) in the Header.avfp and close them in the Footer.avfp. That way you don't have to keep adding them to each individual script.
And, for controllers, you could centralize these commands in the equivalent INIT and DESTROY methods.