I know I am jumping the gun here because reports are not part of current
version of pre-release. (I am hoping they will be in next release.)
In effort to get my SB2 app ready for easier conversion, I've been
diligently getting rid of globals (that are not really constants).
I'm down to 7(or I though I was down to 7), which really should be in an
INI file or something like that.
But, of course, the SB2 (and SB3) forms use globals. I had not been too
bothered by these because they are mostly just "place holders" for
buttons, as in
SET FORM USING 3
CREATE FORM "WAGE08",8000,10500
ERASE
"TheTime$","TheDate$","Tab1$","Tab2$",&q
uot;Tab3$"
GLOBAL
"TheTime$","TheDate$","Tab1$","Tab2$",&q
uot;Tab3$"
etc.
So, e.g.
ADD FORM 8,2021,0,928,344,Tab1$,9,"CALL SaveRecord()","Save
Record"
Although, they can pass "dynamic" information as in
"calculations", e.g.
ADD FORM 7,4813,3886,1084,271,TheDate$,1,"DATE$ ( TODAY )"
I never bother with these because I really don't see them per se in the
lines of program because I am just opening the already created form.
On the other hand, with reports (mostly bills for me) I am calculating
values, subtotals and grand totals, etc. within the program.
When I tried to make these calculations of fields local the reports
wouldn't work as expected. Or worse I get error 273. I have some vague
memory of running into this problem way back when and this may even been
the origin of my use of Globals.
So doing this
SUB BILL(CLI%)
DIM BLAMT%
BLAMT% = 700.00
REPORT USING "BILL"
BEFORE REPORT
SET REPORT PAGE "H_REPORT"
OUTPUT REPORT PAGE
END REPORT
....
SELECT DISTINCT ;
WHERE CMNo.CASE = CLI%
TO ASK
END SUB
Produces no value for BLAMT%, because BLAMT% in the BILL.SBV has to be a
global.
And trying to create the report on the fly
as in
DIM Totdisb%, da$, BLAMT%, Tot%, NewTitle$
REM calculate these values and try to pass
Call BILL1(Totdisb%,da$,BLAMT%,Tot%,NewTitle$)
SUB BILL1(Totdisb%,da$,BLAMT%,Tot%,NewTitle$)
SET REPORT USING 3
CREATE REPORT "BILL",7999,1541,"F_REPORT"
REM ERASE
"Totdisb%","da$","BLAMT%","Tot%","N
ewTitle$"
REM GLOBAL Totdisb%,da$,BLAMT%,Tot%,NewTitle$
etc.
END SUB
will throw ERROR 273 when I try to use the local variables.
So, obviously, I think can create a work around to avoid the GLOBALS
by putting the LOCAL variables into a table/sbf and then using
field.file in lieu of the require variable.
So instead of
ADD FORM 7,5312,2897,1605,292,BLAMT%,23,"","-$ 99999.00
"
I'd do something like
ADD FORM 6,5312,2897,1605,292,BLAMT.TempFile,23
Is that the kind of thing that I'm going to have to do for reports in
SIMPOL. Or do you have something else in mind, that will be revealed in
the near future?
|
Kromkowski wrote:
> I know I am jumping the gun here because reports are not part of current
> version of pre-release. (I am hoping they will be in next release.)
Proper reports won't be in the next release (next week), but the
planning is finally coming together. What we will put into the initial
product will be a report tool that let's you pick the fields, join the
tables, and set conditions, define groups, and allow for a small set of
aggregate calculations (like SUM, COUNT, AVG, etc.). This will output a
report to various targets (window, printer, html file, new database
table). Graphic reports will end up following on from that after the
first release and will make up part of an initial service pack. The goal
right now is to get a more or less fully usable product out to an
initial group and improve that product as rapidly as possible following
on from that.
> In effort to get my SB2 app ready for easier conversion, I've been
> diligently getting rid of globals (that are not really constants).
> I'm down to 7(or I though I was down to 7), which really should be in an
> INI file or something like that.
Good!
> But, of course, the SB2 (and SB3) forms use globals. I had not been too
> bothered by these because they are mostly just "place holders"
for
> buttons, as in
Don't be too fussed by these.
> Although, they can pass "dynamic" information as in
"calculations", e.g.
> ADD FORM 7,4813,3886,1084,271,TheDate$,1,"DATE$ ( TODAY )"
In SIMPOL we will eventually add some form of calculation support for
these, but in the interim you can do this as part of an event that fires
when the record is changed. You assign a handler and update these items
in a standard routine for that form.
> On the other hand, with reports (mostly bills for me) I am calculating
> values, subtotals and grand totals, etc. within the program.
>
> When I tried to make these calculations of fields local the reports
> wouldn't work as expected. Or worse I get error 273. I have some vague
> memory of running into this problem way back when and this may even been
> the origin of my use of Globals.
Yeah, doing these is a little tricky. You can use local variables for
your calculations, but the ones that you assign to have to be global for
them to actually be on the form. If you dimension them again locally,
they are different variables to the ones that are global. In SIMPOL, you
will have an event fire each time after a band has been drawn so that
you can make changes to it, so you will be able to assign something to
the text control that is representing your totals.
> Is that the kind of thing that I'm going to have to do for reports in
> SIMPOL. Or do you have something else in mind, that will be revealed in
> the near future?
The goal is to make the graphical report engine as powerful and flexible
as possible (which is why I don't want to rush it out the door). It will
work on the basis of events firing that call your code (if you define
any) at appropriate points to let you make changes to the chunk that is
about to be added to the page being currently built up for output. It
will eventually support various target output page szes which can also
be laid out on a given paper size (so you could define a report with an
output page the size of a label, and then define a layout that placed
them in rows and columns on the target paper, and define whether they
are output top-to-bottom and left-to-right or left-to-right and then
top-to-bottom, for example).
Ciao, Neil
|