Separation of Printed Forms

[cmury]

All,

My separated DB currently involves 2 files - "Data" & "Interface".

The "Interface" file currently contains layouts for printed documents/forms.

I'm planning on extracting these layouts into a new file "Forms". The intention being that this file can easily be updated or easily subtituted for different Clients.

Any thoughts on this would be greatly appreciated. I imagine a great deal of scripting is involved.

C

[T-Square]

C--

I've implemented just what you are describing for just the reasons you describe. Generally, it has worked out fine, although I haven't really done much in the way of saving individual clients' reports. It DOES allow them to make minor modifications on their own copies of the reports (I've locked down the interface file).

My reports file includes a full relationships graph to ensure that the reports work, although this would probably not be necessary for a new application (I was migrating from an earlier version of FM).

Each report has its own calling script in the reports file, and I try to use script parameters to pass report criteria to the report calling script. You could use globals, but I believe that it is cleaner to use script variables. I can't recall for sure, but I think I'm using stub scripts in my main file to call these report scripts.

I have the scripts automatically go into preview mode and pause, with a hide window as the last script step. Because of this, I have added non-printing navigation buttons to each layout to close the report if the client cancels the script.

When all is said and done, there's not much more scripting than with other techniques, I don't think. I find I have to have some sort of calling script for most of my reports anyway--to set the find and sort up, etc.

Cheers,

David

[cmury]

David,

Thanks for your response - very much appreciated.

Yes - my inital thoughts are that much of the DB structure contained in the UI file would be used in the Print file. In this respect I'm tempted to duplicate my UI file and start from there.

This leaves the question of how to pass search results from the UI to the Print file.

For instance - In a contact list scenario how do you pass a found set across to the Print file for printing?

One solution I can see is that there are set scripts in the Print file that find predetermined sets eg All contacts begining with 'c'. These scripts are executed from the UI file.

But this doesn't resolve customized search results in the UI file. For this to occur the search parameters would need to be passed to the Print file. Easy enough for single criteria but for multiple criteria eg Contacts that begin with 'C' or are 'male' .....?

I think the benefits of this additional separation are significant. Particularly when generating solutions for multiple clients. The UI & Data files mature through all client intput while the Print file can be modified to suit each client's needs.

Any thoughts would be great.

Thanks

C

[T-Square]

C--

I have a couple of thoughts. First: you could try to anticipate as much of the clients' search needs in advance, and set up a search layout that incorporates them. This layout would set global fields which could be pulled out by the reports scripts and used to build the search in the report file. That's pretty much how I've handled this in the past. I have found that most people are happy with a basic set of reports, and only a few gearheads think that they want full blown flexibility that they rarely ever use.

Second: thinking aloud, I note that there's a Modify Last Find script step, and I wonder whether there's a way to extract that information and use it in the same way as the globals approach I mentioned above. Or whether the Modify Last Find step might work in separate files (I doubt that, but hey, who knows? Not me!)

HTH,

David

[T-Square]

A quick test shows that the Modify Last Find (as expected) doesn't transfer across files, and I don't see any obvious way to extract the current search criteria, so your most obvious approach is option 1 above.

David

[cmury]

David,

After a weekend of thinking this through and working up some solutions my thoughts are as follows:

Method 1 - Your first solution involving pre-set reports seems to be the most efficient method of printing standard information. It's very quick to set up. However it does not deal with results from random search criteria in the UI file.

Method 2 - A solution to this issue seems to be the use of a global [in UI file] and find script [in Print file].

In the UI file have a global search field [eg 'gsearch']. The user enters their search criteria then clicks a neighbouring button to execute the external find script in the Print file.

This script enters 'gsearch' into various fields [you choose which ones] over multiple find requests. The script then executes the find, enters preview, prints the report and returns to the UI file.

Both methods have their merits. I'm using Method 1 to generate lists of current staff, current projects etc. However, where random user searches are required - such as contacts that are male and have a name beinging with 'C' - then Method 2 seems to be a good solution.

I'm still not familiar with script variables but I'm sure they could be implemented here. Questions I have are:

- Can script variables can be passed over multiple files?

- In a multi-user scenario are the script values held by the server or user?

These are issues for another forum.

I'll let you know how things develop. Thanks again for your input.

C

[T-Square]

With regard to your Passed parameters question, yes they can go to distant files.

I've been working a lot this weekend on my main app, and discovered that I have a workaround that I use in one situation--one that does NOT have to track the search criteria at all. (How'd THAT happen?!)

You only need one numeric field (let's call it FoundSet) in your source table (shoot! now we've got to modify the back end again!). I actually have a global FoundSetSerNum as well (to ensure that I don't accidently create Super Search Sets), but it's icing.

In your search window, let the users do whatever they want to find their records.

For the Print button, first have your script set the FoundSet field in the current found set to an arbitrary number (I set mine to FoundSetSerNum + 1 and save that number so that the search sets remain separate). I've used the Replace Contents script step for this without great pain (although remember that this step needs the field on screen). Now, call your Report file script, passing the FoundSetSerNum + 1 value.

In the Reports file, the script uses the passed variable to search for the same set of records, and once the print job is done, you clear the FoundSet value. It's kind of ugly, but it does work.

This way, you look like a psychic without having to bend spoons. (at this hour, please don't ask me to explain any pseudo metaphor I write ...)

Cheers,

David

[cmury]

David,

Sounds like a great solution! Very neat.

It does sound as though we are coming to this topic from slightly different angles.

From what you describe I understand you have specific search layouts that are entered in find mode. The user is navigated to these pages when they require a search.

My layouts remain in browse mode but have a search field at the head of each layout. The user enters their search criteria in this field and [through scripting] this criteria is entered into multiple find requests and returned to the user.

Interesting...all 3 separation solutions we've discussed will work in both of the above scenarios.

C

[T-Square]

Actually, I've gone lo-tech. My find buttons just check the current mode, and if we're in Browse mode, I chenge to Find mode. If in Find mode, I execute the find. I used to have separate Find screens, but it always seemed that my clients wanted to search on some field I hadn't counted on.