It would be nice if there was a Basic Form Management Utility included for keeping track form source code .pp6 files and has a table to track comments and versions.

I think that a small database with a table containing a list of forms/versions that you connect to with the design tool. You would select the version and check it out. If it automatically created a new version it would be nice. One of the fields needs to be a comments field and another needs to be a status field such as old/development/production.

I figure that the database would reside on the Watch/Server side and each design tool would query it to open up forms from one of three sources. Local forms such as the current method, the Basic Form Management Utility, or a connection to a full featured version Control package.

We've had a few similar requests in the past and we've analyzed the feature extensively. Any way we look at it, we always come to the same conclusion: might as well use a specialized package to do this because any attempt we make at duplicating this kind of functionality would always come short of those specialized packages.

There are many Version Control packages out there that would allow you to manage your document templates appropriately, without requiring interaction with PPWatch/PPDesign. This is pretty similar to what you would have to do if you wanted to version-control, say, your MS-Word documents or your PhotoShop templates.

There are certain items - like this one - that we believe fall outside of our core comptencies and that should therefore be dealt with using tools that have been created by people who specialize in these matters.

Hope that won't stop you from sending us any additional feature requests!

I have an idea for a feature request. Can Server be made to use a Document as long as it's listed in the Document tree instead of having to drag and drop the document on every Printer Queue whether using a Windows Queue, LPR or Send to Folder? We use dozens of printers and I have to drag a complete set of forms from the document list to every printer queue in order to use the forms on that output, and the tree auto expands which makes it incredibly long to scroll through, and difficult to tell if I'm missing a form on any given queue.

I agree that browsing through the documents/forms can be difficult at times, but I really like having only the eligible documents/forms show up when I select them in a printer output. I have several large installations where this feature has proved to be very valuable.

I would like to see a better method to manage the available documents/forms to reduce the scrolling, but I don't like the idea of making every form available for every printer automatic.

Perhaps, there could be a properties page for each printer that displayed all of the documents/forms with check boxes to make them available for that printer. There could be a select all button. This way the tree would not automatically expand, the form could be made available only to specific printers, and all forms could be easily made available to all printers.

Have you looked at the "Add Document" action? We never install documents on printers. I have printers scattered all over Connecticut. If I had to repopulate their forms each time a printer was replaced or repaired I'm sure I'd never catch up! Watch remains the sole repository for forms. No need to push a form out to 50 printers just because someone found a spelling error.

There is a downside to this approach... network bandwidth consumption.

While these suggestions are all valid, you may just want to take advantage of the native ability to call any document from the Printer Queue Output.

With V6.2.1, you can specify a dynamic Document Name in the Printer Queue Output. If that dynamic name is resolved within the list of documents associated with that printer queue, then that's what gets printed. If it isn't found, the task then looks in the full list of documents for a match and if it finds one, that's what gets printed.

So it's not mandatory anymore to associate your documents to printer queues, unless you want to specify different printing modes for different printers (i.e. Printer-Centric vs. Optimised PostScript). When a document is pulled from the overall list, the printer queue output always uses the default print settings set for that document.

Hope that helps,

Phillipe,

I need a few things for a couple of data center printers.

• Banner Pages
• Insert a %%For:(%9)
• Insert a %%Title:(%8)
• Insert a %%KDKChargeNumber:(%7)

The Banner Page would be a seperate PlanetPress form that exits with a $$EOJ$$.

This is what I needed to know, and exactly what I was looking for.

Ian: glad I could help.

Uomo: please don't mix issues within the same thread, it makes it difficult to follow or trace back. And from what I can see, this isn't a feature request, it's something someone can help you with from one of the standard forums.

Phillipe,

I'm sorry I didn't realize that I had submitted the post. I got side tracked and wasn't completely finished with my question. I'm not looking for assistance on how to create my complex trigger.

I was just wondering how my requirements would relate if I used the Dynamic Document Name. I'm assuming that Dynamic Document Name will not work for this situation.

I've also found that using a sub or inline form do not work well with optimized postscript. (at least on the printers that I'm using the first form does not appear to release control to the second form) I've found that I really do need to compile the forms directly to the printers for this situation.

The Dynamic Document Name however is a great idea for several other situations.