VFP 6 with Fox 2.6 screens over terminal services [b] [/b]

[dagair]

We have a medical provider management suite partially in OOP (VFP 6 SP5) but much of the data entry forms are FoxPro 2.6 rendered screens from metadata in flat dbfs, which are read and each object painted on the screen is from a macro-expansion. It was an absolutely brilliant design back in 1997 and we are still getting good use from it. However, one of our customers is running Windows Server 2008 and the clients access our DBC and flat tables from a TS farm from our exe. What is happening is that our screen rendering is not always complete and if the user attempts to enter data in an incompletely rendered screen, they crash with a syntax error #10. It's as if the variable of the macro code exists, but the contents when expanded are incorrect or lost. Do you suppose there may be some kind of bizarre memory leak? I have tried BITMAP=OFF in the config, but that killed our rendering altogether. I also have played with various setting in SYS(3050) and using SYS(1104) for garbage collection to no avail. I have combed the internet for anyone rendering foxpro screens in VFP and it seems there are none. Any advise will be greatly appreciated.

 

[GriffMG]

I was wondering if the move to the server 2008 perhaps introduced a situation where the macros can't be executed reliably.

Maybe the paths are now url based (\\servername\share or somesuch) or perhaps they have slipped in ones with periods in them.

The periods might trigger VFP to stop evaluating the macro.

Could you replace the macro substition with EVAL() instead?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[dagair]

I am going to give this a try - thank you

 

[dagair]

within the last year I added some code like, m.modify=@cEForm..modify I change this to an eval and it seems to work - however, the true test is letting our customers pound on it. Thanks again Griff

 

[GriffMG]

dot dot

kills macros

Well done for spotting it!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

No, dotdot is correct!

@ is wrong. & is macro substitution.

create cursor curTest (id I)
insert into curTest Values (1)
lcAlias = "curTest"
* works:
? &lcAlias..id
* doesn't work:
? &lcAlias.id

Because what is not well known: A dot ends macro substitution, but is optional, when the end of the variable name is obvious anyway, eg by a space or " after it. The problematic case would be addressing curTest2 as &lcAlias2, it would be unclear if 2 is part of the variable name lcAlias2 or the substituted variable should be lcAlias and the 2 should stay. It's even unclear, if there is no variable lcAlias2, it still could be meant that way.

Therefor &lcAlias.id is expanded as curTestid and fails and &lcAlias..id is expanded as curTest.id - the first dot is swallowed as end of substitution, the second dot stays as seperator to the field name.

The only thing wrong is @, if it's about macro substitution.

In this case @cEForm seems to address a form object. If that is the case there is no variable name starting with @, @ is there to pass something by reference, but only needed when the name is used as parameter in a call, at the function/method called you don't add @ to a parameter name, you simply use it as is, so cEForm.modify would address the modify property or method of cEForm.

Bye, Olaf.

 

[dagair]

Thank you Olaf!

Actually the code is m.modified=&cEForm.modified. I was just in a hurry when I wrote that post. I have used reference to Table.Field as @TableVar..FieldName in many places. This macro of table name seems to work, but it seemed that Griff sort of suggested that with Server 2008 and terminal services that the macro may not be appending the field name. I am considering replacing all of this code with Eval() where I can. What do you think?

Thanks so much for your interest and input.

I am also working in asp.net, C#, SQL server and use the '@' symbol frequently. oops....

 

[Olaf Doschke]

Well, I don't think MAcro substitution works differently on any OS, it's a foxpro internal thing and not depending on any system DLLs.

to set m.field to a table field you can of course also

SELECT (TableVar)
SCATTER FIELDS field MEMVAR

or

SELECT (TableVar)
m.field = field

I wouldn't create variables named like fields, even as it is a feature of SCATTER, it makes the name ambigous and that in itself can lead to problems.

Bye, Olaf.

 

[GriffMG]

I wasn't suggesting the OS was changing things, only that perhaps in the move to a new
server the environment had changed slightly - different paths and perhaps other things.

As macro substitution, as Olaf says, is terminated by a period, the replacing some with Eval()
function and looking at the result might help.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[dagair]

Thank you gentlemen! One solution that I found to improve performance and reduce errors was to do a garbage collection prior to beginning a Fox 2.6 form-paint. Sys(1104) and Sys(3050) had no effect, but I found this API very effective: SetProcessWorkingSetSize

Code:
* Begin Code
proc CutWinMem
Declare Integer SetProcessWorkingSetSize In kernel32 As SetProcessWorkingSetSize ;
Integer hProcess , Integer dwMinimumWorkingSetSize , ;
Integer dwMaximumWorkingSetSize
Declare Integer GetCurrentProcess In kernel32 As GetCurrentProcess
nProc = GetCurrentProcess()
* param2 = minimum set size, param3 = max set size --> -1 is to reclaim as much page memory as possible
bb = SetProcessWorkingSetSize(nProc,-1,-1)
* End Code


Can either of you tell me where I could post this so it might be helpful to others???

 

[GriffMG]

Create yourself a FAQ

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.