Discussion at Report..Unwanted Footer gave me cause to ponder .... Just some idle thoughts about this ......

I am now looking at applications where multiple users may be running a report from different work stations.  Since I cannot control their default browser, then I cannot control their printing.  Even if could control the default browser, I cannot control their print settings.  They may prefer some settings as default, but need  different settings for some Sesame reports.

I think we are going to need some functions that allow us to define the browser to be used (we can program to check for it and respond accordingly:abort, second choice browser, print anyway, etc.).  We will also need something to save the current registry settings for that browser, run the Sesame Print Report job, and write the original browser registry settings back to the registry. 

If those functions cannot be provided in the future, then perhaps you can provide us a list of the settings that are know for the common browsers and their multiple versions.  I would think at least we should be looking at MSIE, Mozilla, Netscape, FireFox, Opera, AOL.

----------------------
Maybe Lantica can create a Sesame database that we can download and do XLUs for when we write programming for Reports?

Fields:
Browser/Version/Path/Executable/Function/RegKey/RegValue.

Broswer=MSIE/Net/Moz/ etc.
Version = 5.5/6.0/4.79/7.0/etc.
Path = Normal default path of this versions executable file.
Executable = Name of executable file to launch browser.
Function = BroswerPrint Setting, ie:Header/Footer/etc.
RegKey = Full registry path with key
RegValue = default value for that registry key

You could provide the default values for Browser Printing registry settings, and we can update our copies for the actual Path if different.

We can save a registry tree branch, parse it in Sesame, upload the new version to registry by executing *.reg files
-------------------
And/or we could use new functions that you can create for us.  Something like these:

vVar = @RegistryReadKey(key_root_path, key, value, entry)
Read the value of an entry from the registry. The result is stored in the variable.

RegistryWriteKey(key_root_path,key,value,entry)
Create or modify a registry entry. If the key and value do not exist they would be created and the new entry would be assigned to the entry. If the key and value already exist, the existing entry would be changed to the entry provided in the function. The function would create integer entries if the value specified is an integer, or else the new value would be a string.

RegistryIntToString()  Setting of 1 would force an integer value to be written as a string.  This would be called before calling RegistryWriteKey.

RegistryDelKey(key_root_path,key)
Remove a key from the registry

RegistryDelValue(key_root_path, key,value)
Remove a value associated with a key

So the programming structure would look like this:
Define Browser
Select Browser
Save Browser Registry Print Settings
Print Report
Restore Browser Registry Pring Settings.

All of the appropriate warnings about modifying the registry can be in the documentation.  If you provide the functions then we are responsible for their correct usage, but at least we have the choice to use the tools.
------------------
(I have used Registry.... in function names vs. Reg....., to allow for future use of Regular Expression functions ( It's good to dream.  Just want to eliminate possible confusion in the future).