>>In the grid simulation I was doing back then in FPD6, it took two calls on the return stack per level; that was not the problem. It was the bunch of arrays I used at each level to keep all the visible values at hand, their record numbers etc. That was eating quite a few kilos each time.
>
>Don't forget to send some info to Fernando on FPD6; you hold some unique product here ! {g}
Sure did (i.e. still do, but who needs it now). The beast was fiddled with until it was faster than browse. It generated three routines per instance - one to draw the frame, one to refresh the arrays, and one to display the current line. You simply coded the call to it, and it would detect that it's being called without the generated code, and then it modified the call (replaced the first parameter from alias to a number, which was then a part of the generated routines), commented the old call out, checked if there was a previous version of the routines in the source, edited them out (leaving the header comment of the first one only for documenting purposes), generated new ones, and issued a message to re-run the same thing again. It actually modified the prg which called it (because it was actually the .fxp, so prg was available). Too bad I don't have the original complete source here (I do have some) nor do I have the original FPD2.6 to run a few. Just to satisfy your curiosity, here's the sample of how it displayed the multiple levels. The bolded part is the name of the routine to be called on Enter - itself, in this case.
Proc ShNextL
Priv _s, _mat, cu
_copy=.f.
if _start=_nivo
_nazad=mtip<=3
_mat=mat
_naz=trim(mat.nazmat)
else
_nazad=stip<=3
_mat=smat
_naz=trim(nazsmat)
endif
if _nazad
retu
endif
cu="sklop_"+chr(64+_nivo)
do dok2curs with "sklop",cu,_mat
inde on smat tag smat
inde on nazsmat tag nazsmat
Private C5_Proc, c5_ins
C5_proc="<b>ShNextL()</b>"
Private C_24
C_24="Enter - dalja sastavnica (gde ima), Esc - prethodni nivo"
Do Catal6 with cu, "3002", _ord
sele (_s)
retu
Proc s_3002
Parameter _c6
external Array c6_f, c6_r
c6_f(_c6,1)=smat
c6_f(_c6,2)=nazsmat
c6_f(_c6,3)=norma
c6_f(_c6,4)=rnorma
c6_f(_c6,5)=statc(stip,@l_mtip)
c6_r(_c6)=Recno(_alr)
Proc w_3002
external Array c6_f, c6_r
Privat wname
_wtitle=" Sastavnica za "+_naz+" ("+_mat+") "
External array atag, dxname
_NFields=5
_lastteg=2
sche_nor=20
sche_cur=6
_gloffset=3
_grmargin=0
rwidth=1
_cr_exit=.F.
Dimension c6_col(_NFields), c6_wid(_NFields)
c6_wid(1)=6
c6_col(1)=0
c6_wid(2)=31
c6_col(2)=c6_col(1)+c6_wid(1)+3
c6_wid(3)=8
c6_col(3)=c6_col(2)+c6_wid(2)+1
c6_wid(4)=8
c6_col(4)=c6_col(3)+c6_wid(3)+1
c6_wid(5)=15
c6_col(5)=c6_col(4)+c6_wid(4)+1
_sirina=c6_col(5)+c6_wid(5)
wname=alias()
Define Window (wname) ;
From _nivo*2-4,_nivo*2-6 Size _brlin, _sirina+_grmargin;
Title _wtitle Shadow Color Sche Sche_nor
Acti Wind (wname)
@ 0, c6_col(1) Say Padr("çifra",c6_wid(1))
@ 0, c6_col(2) Say Padr("naziv",c6_wid(2))
@ 0, c6_col(3) Say Padr(" norma",c6_wid(3))
@ 0, c6_col(4) Say Padr(" realna",c6_wid(4))
@ 0, c6_col(5) Say Padr("tip",c6_wid(5))
Proc B_3002
Parameters _r6,_sche
external Array c6_f, c6_r
@ _r6+1, c6_col(1) Say c6_f(_r6,1) Size 1,c6_wid(1) ;
color sche _sche
@ _r6+1, c6_col(2)-3 say iif(_sche=sche_cur, aTag(_teg)," ") ;
Color sche _sche
@ _r6+1, c6_col(2) Say c6_f(_r6,2) Size 1,c6_wid(2) ;
color sche _sche
@ _r6+1, c6_col(3) Say c6_f(_r6,3) Size 1,c6_wid(3) ;
color sche _sche Picture "9999.999"
@ _r6+1, c6_col(4) Say c6_f(_r6,4) Size 1,c6_wid(4) ;
color sche _sche Picture "9999.999"
@ _r6+1, c6_col(5) Say c6_f(_r6,5) Size 1,c6_wid(5) ;
color sche _scheYes, it's long, but I didn't care - it wrote itself :). Of course, there was some code which read the inkey()s and called these little routines when needed.
>Now I think of it (see my earlier comment directly below) my "arrays" were easy to deal with because it was MUMPS back there. The "bunch" would be only one and these kinda things can be beautifully held there. It was 1980 and ran on a PDP11 at Shell; I wonder whether this PDP had 4 MB of memory ...
My PDP in 1986 had 2 megs :).
In 1998, when the first meeting of computing veterans in my city was held (I was an apprentice veteran and a friend of the host, so I sort of qualified - most of the guys there were working with the experimental 2nd generation machine installed in the bank in 1962 or so), the guy who came first began his line with "sclerosis is a beautiful disease - you learn something new every day, and get surprised at every step". We still don't seem to qualify as veterans, we still remember too much :).
>>Even using strings as arrays (did even that once) but I think the limit Hilmar suggests is not inspired by computing or any other technical reasons - it's the people who would eventually have to get the data in, look at them, and have a say in whether the data are right or not. With so many levels, it would just be too huge for anyone to keep track of. OTOH, for practical (i.e. human-sized) purposes, the tree could be chopped into branches, so nobody would have to deal with more than 4-5 levels at a time. Top guys wouldn't need to go into detail, and the guys in the basement needn't know they're seeing 4th level branch as root.
>
>Dragan, I think you are wrong here; (okay I know ;)
>Think of the recipe again; each level is held by a product and it can always be seen as elementary. So whether it's the cake, the flower, the caramel, all are products and they all hold one level of products. The maintenance is always performed on this one level i.e. the recipe for the caramel or the cake at the higher level. Difficult to expain further; you 'd have to see it.
Theoretically yes, take your keyboard and dismember the recipy until you get to raw oil, ore and minerals. I was thinking of practical, not necessarily logical limits: the practical definition of raw material is "what we use to build something". The accent is on "we", i.e. the user of the data - the baker doesn't necessarily produce wheat, fertilizers, machinery to produce fertilizers, nuts and bolts to produce that machinery etc etc. He starts with flour and yeast, and complex as they may be, they are raw materials for him. An assembly list doesn't go into details beyond what is assembled inside the house; whatever is bought as raw material is such a material by definition, even if it's a motherboard with processor, fan and sound card.
But you may be right about space shuttle, you know. They seem to produce a lot of low-level gadgets themselves, so this beast may have more than 8 levels.
>>Makes sense to me, and made sense to chief accountants - but not to their clerks. Few whites in my beard come from that :)
>
>Your beard could still have been beautifully black, brown, blond or even red (but white looks okay too;) when all was done with templates. I mean, the modern accounting app works with templates for bookings only, and nothing is done directly. Now don't ask me what is modern, where we had this 14 years ago (back then I never saw it before). Further, all is initiated by the according subsystem. F.e., complete logistics have some 100 interfaces to financials, and all run real-time without notice.
So would daddy, son. "Real time, without notice" is blasphemy for any red-blooded Yugoslav accountant. They want to be in charge and to know what's going on. I've written a dozen of automatic procedures which booked events which happened elsewhere (in other apps) - but they all had to be manually launched, repeatable (the definition of automatic procedure is "a routine which propagates errors from one app to another, but propagates fixes as well"), and reversible. And they had to print a standard booking order so the chief accountant could use his pocket calculator and do some checking. Once they learned to trust this, it was great - but never worked without them pushing the buttons.
