Setting a report variable 2

[joebloeonthego]

Is there a way to manually set the value of a report variable (custom variable)? I can't figure it out. I'd like to just assign it a value of zero if anything.

The problem:
I have a report with grouping on partnumber, and for each partnumber, there is a header, detail bands, and a footer. I'd like the pageheader to display 'continued from last page' if we're half-way through a partnumber (rather than just reprint the header on the new page).

My problem:
It keeps printing 'continued..' on the pageheader even when starting a fresh partnumber. The 'reset on partnumber' isn't working because it isn't reset yet. So I have a variable '_overflow' that I can count/sum whatever but I'd like to reset it to zero when the group footer prints. Is this possible?

ps - what may be complicating matters is that I'm stuck with the data I'm getting out of the program, but I'm making it report a totally different way by using some counting variables, and a lot of 'print when' stuff. and because of this I'm printing the header (with no partnumber specific info), possibly ignoring 1 to many partnumbers, then printing the footer with all the header info you'd expect for the partnumber. Make any sense? I doubt it..

 

[joebloeonthego]

aircon: I will try his original suggestion letter by letter and see what happens. thanx.

 

[joebloeonthego]

aircon: you're right, I'm an idiot, it does work. Thank-you

I remember why I didn't use the group header originally though.. it was because then the header info was reprinted (not reprinting the header was the whole point) so I abandoned that idea figuring going to the pageheader would be easier... and the saga began. But now that I find out how much trouble (or impossible) it would be to have it in the pageheader, it's much much less trouble to work things around having it in the group header.

So I apologize for wasting anyone's time, although I did learn about the prg file... *sheepish grin*

thanx again to ramani for getting it right probably more than once.

 

[joebloeonthego]

Actually, I'm not done yet!

I can't have it in the group header because it just doesn't work with the header being printed every page (which is why I abandoned the idea originally).

So with more investigation into my problem, I found this juicy little nugget in the help:

To reset a variable on entry or exit of any band
<i>
In the Report Designer, open the report.
Double-click the bar for the report band.
In the Run expression area of the band's dialog box, choose the dialog button at the end of the On entry or On exit box.
Enter an expression to reset the variable each time the band is entered or exited.
</i>

OK, that last bit is the juicy part. HOW??????

 

[Mike Gagnon]

joebloeonthego

OK, that last bit is the juicy part. HOW??????

I've expained it, and nirajjobanputra has explained it, short of going into your office and doing for you...Try anything, set the variable to 0 or 1 or whatever!


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[nirajj]

Actually I tried and am facing the same problem.
In report &quot;=&quot; doesnt work like STORE command but it works like Relational Operators. And ofcourse STORE is a syntax error for report designer.

I think the only way out is to call the function and let function play with the variables. If you cant make changes to the existing code you can probably add new code just like Ramani suggested.

I also have had problems with continue but couldnt work around it without calling a function.

However, I would surely like to know how to use the STORE command in the report designer.

 

[AirCon]

Yes, you can't put STORE in the expression. Expression is logical.

Actually, using group header only or mixed it with page header always worked for me.

However this is the workaround. Create a program called &quot;ZeroVar.prg&quot; or whatever you want to name it, and put this code

LParameters tnVar
tnVar = 0

On the &quot;On exit&quot; put this expression:

ZeroVar(@_overflow)
[code]

I hope it works now
Regards

[i]-- AirCon --[/i]

 

[joebloeonthego]

aircon: you're a star. That's exactly what I needed to know. I now have my report working _exactly_ as I wanted it, AND I can do more wacky stuff in the future now that I have (practically) complete control of variables and stuff.
(it may have seemed a little too obvious to some, but I didn't know I could call homebrew functions from reports or else I probably would have figured it out - plus, even if I did, I'd probably still be here asking about scoping and whatnot) I assume the '@' is what makes it pass by reference?

I do find it rather odd, that the report designer doesn't allow any _easy_ way of assigning a variable...

one note: I had do compile the .prg into an .fxp in order for the report to find it (I got a 'zerovar.prg file not found' no matter which directory I placed it in). I don't know if that's what you meant (just to clarify it then) or that's a quirk of the program I'm dealing with)

 

[AirCon]

Joe,
Yes with '@' symbol means we want to pass by reff. Default VFP always pass by value.

It's a known problem that VFP report designer not so handy when it comes to a complex report. That's why some people use &quot;Crystal Report&quot; as a replacement.

one note: I had do compile the .prg into an .fxp in order for the report to find it (I got a 'zerovar.prg file not found' no matter which directory I placed it in). I don't know if that's what you meant (just to clarify it then) or that's a quirk of the program I'm dealing with

I assumed you run the report directly from VFP IDE. If you did, you won't get error as long as the PRG is in the same directory with report. If you run it from an application (EXE) outside VFP IDE (Runtime) then you have to compile it first to make the program as a runtime object. Sorry I didn't mentioned this earlier.

Glad you can worked it out
Regards

-- AirCon --

 

[nirajj]

I believe the variables created in the Report are by default global. So it really wouldnt matter if you pass the variable by reference or you dont pass it at all.

And joebloeonthego, as such I feel you ended up doing what Ramani suggested initially. Agreed what you do inside the function is different but basically its the same idea.

No offence to anybody, but its been the same solution that ran for almost 30 replies.

 

[joebloeonthego]

Yes this is true, as soon as someone (ramani) mentioned calling a function from the 'do this when leaving this band' I should have clued in that this is how I could do what I wanted to do - Assign a value to a variable!

-if you remember I didn't ask for help with my report, I just wanted to know how to do assignments - but since no one really knew how, the ball got rolling and....

I figured you couldn't return the value back to the report (no assignments, hence the whole problem!), and hadn't thought of being able to pass by reference or the variables having global scope.

 

[Mike Gagnon]

joebloeonthego

-if you remember I didn't ask for help with my report, I just wanted to know how to do assignments - but since no one really knew how, the ball got rolling and....

I must admit, I have to count this one as a design issue. You are trying to do something that is almost out of the realm of VFP, it may have been why the answer took so long to discover.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[joebloeonthego]

yes, I'm definitely doing things you're not supposed to do (if you want to change what it does, just change the cursor or whatever) trying to change the output IN the report instead of changing what you SEND to the report.

I super-appreciate the time everyone spent on this and on all the other problems here as I've picked up a lot from reading many of the other discussions (I'm a 'programmer' with no foxpro (or any db for that matter) experience swimming around these reports...) This is definitely the best forum I've stumbled across in my searches for foxpro info.