Actually, no.

As I said before, if you just want to pass a parameter that's fine, it goes straight into the function that is going to use it. If you want to process it later - and inevitably on Windows printing it out will mean processing it later, much later in terms of lines of code - it will have to be stored and retrieved not once but numerous times. You specified that storage when you put it in the list records, but as we have seen that is not without its limitations.

Of course _writing_ an RDBMS to just store a small amount of transient data like that would be rather wasteful, but as it happens we already have one at our disposal

If you want to see waste in modern code you should see what is involved in drawing all that pretty stuff on screen...

Regards

Then by all means use the database to make the task easier for yourself, but keep it hidden. Please don't make the user create a separate form and as a consequence a table just to enter some report parameters. The user should have access to a D-E form, the script, and layout screens which allow a report or procedure to be easily created and modified. The implementation stays behind locked doors.

And there are half a dozen other ways to do exactly the same thing without the use of a data-entry form! As long as you remain convinced that the only way to do things is with a procedure with an interactive header then you are going to be stuck in the same old rut.

Look at the Customers_view in the Demo app. Go to a record and click the List Orders button. There you have an example of how the data form can substitute for a data-entry form.

And there are other ways to do the same thing using reports rather than procedures. Look at the Print Invoice button on the Orders_view.

There are already no less than three separate ways to enter parameters direct into a procedure without creating a form.

But there are considerable benefits to creating a form for the purpose. You have to look wider than just the one procedure. It's very likely a single form will provide a standard set of 'parameters' for many procedures. Much better than having to create a separate 'interactive header' for each one. Much easier to maintain. Even if you do require variation in the parameters you can use Aspects to show the ones you want for a particular process.

In fact, some people do this right now and transfer the input to the actual processing procedure in globals or use a script and setarray/getarray.

Or, use Open Related action on a button and open a Report, which can do away with the need for a separate form and procedure entirely.

It's these techniques, which DFW and Ffenics users have evolved for themselves, which leads me to believe that if in the future we can implement something similar to 'open related' for procedures it will be the right way to go.

Best use of Ffenics (and DFW also) requires that one gets away from the idea of monolithic procedures to do everything - small reusable chunks is the way to think. Of course a beginning user isn't going to build an app like that, which is why entry-level facilities like interactive header continue to be provided - and new users seem quite happy with them. Because of course to them a data entry form is one you enter data in - they've never seen DFD.

Regards

Just noticed this fascinating discussion.

First, I find myself agreeing with quite a bit of FFRob's comments. For example, the requirement to have the selection criteria on every page.

The determinant for this is not (necessarily) the inability of a developer to change habits, but the ends user's frustration of having to flit back and forth in a multi-page report from, say, cover page to page 999 currently being reviewed. IOW, if someone in the food chain deems it required -- and that may even be the developer themselves in their role as CEO -- then the software has to do it.

New York taught me this in spades, where my end customer was sometimes Guilliani, Pataki, or even Laura Bush!

Anyway, I'm also struggling a bit to envision Pete's 'clean solution'. So let me see if I have understood. Is the idea is that there is a table/form -- let's say it is called Parameters -- with a slew of from/to dates, ID-this and ID-that, lists of Cities, Counties, States, Provinces, Countries and Planets, etc?

Presumably the Ff developer has determined what goes in here, based on the app.

And a slew of aspects over the top to only show the necessary items.

So the user saves (or updates) a record, and clicks a run proc button, and the procedure is written something like:

for Parameters with user name = current user name ;
for MYRealTarget with DateEntered between Parameters StartDate to EndDate
etc

Or maybe:

For MyRealTarget with DateEntered any GetThisUserParameters SD to ED
etc

Except maybe this form is a special form that hides the above mechanics, has no problem with the developer making changes to it while it is in use, has options to handle whether or not there is one record per user, and whether previously entered values are kept or displayed.

Or am I barking in the wrong forest?

BTW, who is FFRob?

BTW, not entirely unrelated (no pun intended) ...

Given that global variables in procedures are now session-persistent, would it be possible to extend their use to forms/aspects and reports?

Hi Adrian

I'm looking at globals/temps etc for the future - there is even a third type in the code called statics...

My idea wasn't confined to having a specific form for procedure parameters, it was just one way of using it. I was thinking you could also have a normal form or aspect used for data entry that fired up a procedure using the current record as input when you pressed save / save as / delete.

I haven't fully decided how it should work yet, (or indeed whether I will _ever_ have the time!) but it should a) use the data off the screen for subforms, _not_ a lookup to the data file which could be out of date due to on-screen modifications and b) should not enter data to the database until you tell it to (thus parameters to procedures etc. need not be actually saved unless you want them to).

Open Related Procedure might be an alternative approach, but that isn't simple either - well, not to implement. (I did try just allowing it - very nasty result )

The main point is that I believe the correct design is to have the data drive the procedure rather than have the procedure pinging for data. As already happens with Report open related.

Remember here we are talking the purist approach. I also plan to make Interactive Headers easier to use for output by the simple method of fixing 'don't print'. So you will then be able to 'list records' the data entry fields and summarize them in the headers with no problem. I don't know whether don't print should automatically shrink the field too - I'll think about that. It shouldn't shrink it to nothing because you won't be able to select it later if you change your mind

The other point that has come up in the discussion is that in order to get what you want you have to know what you are asking for. The different nature of Windows requires that 'parameters' are treated as data if you want to process them for output. That doesn't mean it has to be difficult, it does mean it will be different.

Which shouldn't be a problem because if we want to get the best from Windows and the different devices it supports - page printers in the main - compared to DOS we have to do things differently anyway.

I don't question the need to put parameters into headers, but the way it is done isn't going to be exactly the same.

Regards

If you can get DE variables in the header now with 'list records', setup summary variable, use Hide() on the DE, then why not make it simpler and more logical?

'List records' seems artificial so would it not be more appropriate to set up a new command. For example 'Reveal Variables' which would place a Hidden DE variable in the body and therefore make it selectable for summary variables.

It would be even better if all DE variables were implicitly available to summary variables.

'Who is FFRob?' A very philosophical question.

Pete,

While I think of it, and relating to a conversation with Trina last week...

Basically, whilst you can make a report run against related records, you can't do the same for filtered records. So would it not be useful, if it were possible, to take either the developer or the user-added filters and pass these to a report.

E.g. user filters records based on yesterday's date; report then runs for all records in that set.

Not unlike simply adding a filter and printing all records for that aspect, but of course the format of the report would be different.

Hi Adrian

It should be feasible.

Filters and relationships should really be almost the same thing, but they weren't implemented that way, and for reasons I hope you can imagine I'm very reluctant to make sweeping changes to the relationships mechanism - its taken 20 years to get it right

But as part of the whole idea we are discussing I have to look into ways and means of getting data 'sets' - as opposed to just related records - into procedures, so I'll bear this in mind while I'm investigating.

Hi Ffrob.

For 1.21 I've implemented Don't Print properly - it just doesn't print, rather than (as in 1.20) leaving it out of the output altogether.

So forget all the hide and everything mechanism - if you want something summarized - D-E field, temp variable whatever - just put it in the list records and flag it ''Don't print' in its display options on the body.

I don't think most people will find 'list records' too confusing, Many people still speak of reports as listings and in any case I believe in keeping the number of commands down, not increasing them.

That's amazing... I was just telling Trina last week about a conversation Phil and I were having about exactly the same thing!

This also relates to a discussion we had a couple years ago regarding features in other RDBMS products. One of the few things I find to like in Access is the ability to build a query and then place a report on top of it - somewhat akin to creating a view in SQL then using that in reports. I've often thought that would have been a better way to implement procedures in the first place.