gjgerson74
asked on
Microsoft Access 2003 Registry Settings/Custom Forms
Does anyone know where Microsoft Access stores the page setup settings when you customize a report? I have a report that uses a custom form size and I would like to know EXACTLY where Access saves those settings, what is saved, and how it is saved. I a very specific problem and I have been trying to figure it out for a long time and this information would be very helpful. I am using Access 2003 will all of latest updates, and this is not the auto-naming problem.
I have 1 application that is used on multiple networks (it resides on the clients) each of the reports have been formatted to use the default printer and use the custom form for page width and height settings. In the registry of the print servers where the custom form is listed, I see the same entries, but the hexidecimal data values are different in some cases. In the cases where the data values are the same I can move the Access application between the clients on different networks and the reports print fine, but as soon as I move the Access file to clients that use a different print server, where the hexidecimal value for the custom form is different, the reports stop printing correctly. When I go into the design view of the report and view the page setup settings, the custom form I created and used is not selected. I have 24 print servers 7 of them have matching hexidecimal data values for the custom form and the Access application will print correctly from any client that uses any one of those print servers. If I move the Access application to a client that uses a print server where the hexidecimal data value does match, the reports will not print. In all 24 networks, it is the absolute same, if the hexidecimal values match everything prints fine, if they don't it won't print - it is very consistent!!! There is not one case in which the registry values are different and it still prints fine.
This leads me to believe that Access is using the registry values for the custom forms in order to determine which form to use, not the actual name of the custom form.
So again, my question is exactly where does Access save the page setup settings, how does it save them, what does it save and how does it call those settings?
I have 1 application that is used on multiple networks (it resides on the clients) each of the reports have been formatted to use the default printer and use the custom form for page width and height settings. In the registry of the print servers where the custom form is listed, I see the same entries, but the hexidecimal data values are different in some cases. In the cases where the data values are the same I can move the Access application between the clients on different networks and the reports print fine, but as soon as I move the Access file to clients that use a different print server, where the hexidecimal value for the custom form is different, the reports stop printing correctly. When I go into the design view of the report and view the page setup settings, the custom form I created and used is not selected. I have 24 print servers 7 of them have matching hexidecimal data values for the custom form and the Access application will print correctly from any client that uses any one of those print servers. If I move the Access application to a client that uses a print server where the hexidecimal data value does match, the reports will not print. In all 24 networks, it is the absolute same, if the hexidecimal values match everything prints fine, if they don't it won't print - it is very consistent!!! There is not one case in which the registry values are different and it still prints fine.
This leads me to believe that Access is using the registry values for the custom forms in order to determine which form to use, not the actual name of the custom form.
So again, my question is exactly where does Access save the page setup settings, how does it save them, what does it save and how does it call those settings?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Here's some links regarding PrtDevMode:
http://support.microsoft.com/?kbid=210283
http://www.mvps.org/access/reports/rpt0009.htm
Here's a link to a 3rd party item of interest:
http://ourworld.compuserve.com/homepages/attac-cg/acgsoft.htm - On The Fly printing library for Access
http://support.microsoft.com/?kbid=210283
http://www.mvps.org/access/reports/rpt0009.htm
Here's a link to a 3rd party item of interest:
http://ourworld.compuserve.com/homepages/attac-cg/acgsoft.htm - On The Fly printing library for Access
ASKER
Great. I did the SaveAs Text command to look at the settings for the report and I see the PrtDevMode and PrtMip settings, but they are all in hexidecimal format. For example:
PrtMip = Begin
0xe3000000e3000000e3000000
0x010000006801000000000000
End
PrtDevMode = Begin
0x000000000000000000000000
0x010400049c00b80203620100
0x580202000000416972547261
0x000000000000000000000000
0x000000000000000000000000
0xa00000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000001000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000180000000000
0x000000000000000000000000
End
PrtDevNames = Begin
0x080016002500010000000000
* 0x000000000049505f3139322e
End
I noticed that the line with the astrisk changes depending on the printer selected and saved to the report.
I kept looking for the custom form name I am using but didn't find it. I am checking now to make sure that the Genicom 3860D print driver that we are using supports the use of a custom form; that is what I have been using, but if the driver doesn't fully support its use I might have a bigger problem.
These are new servers, all configured exactly the same with the exact same print driver. If the print driver doesn't support custom forms, there will really be no use is writting code to control the printing.
PrtMip = Begin
0xe3000000e3000000e3000000
0x010000006801000000000000
End
PrtDevMode = Begin
0x000000000000000000000000
0x010400049c00b80203620100
0x580202000000416972547261
0x000000000000000000000000
0x000000000000000000000000
0xa00000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000001000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000000000000000
0x000000000000180000000000
0x000000000000000000000000
End
PrtDevNames = Begin
0x080016002500010000000000
* 0x000000000049505f3139322e
End
I noticed that the line with the astrisk changes depending on the printer selected and saved to the report.
I kept looking for the custom form name I am using but didn't find it. I am checking now to make sure that the Genicom 3860D print driver that we are using supports the use of a custom form; that is what I have been using, but if the driver doesn't fully support its use I might have a bigger problem.
These are new servers, all configured exactly the same with the exact same print driver. If the print driver doesn't support custom forms, there will really be no use is writting code to control the printing.
Hi, as I said above, there is no need to look at hex strings. They can easily be converted to a usable structure. Just loop up help, copy and paste the provided example.
Good Luck!
(°v°)
Good Luck!
(°v°)
One other thing: You really don't want to muck around in the file that's produced by the SaveAsText command ... you would be far better off using the PrtDevMode within Access to manipulate your settings.
ASKER
Excellent. Thanks again for your help.
ASKER
Found an msdn reference article on PrtDevMode: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbaac11/html/acproPrtDevMode_HV05187912.asp
Only problem is that the application that I am using is an .mde so I won't be able to use this approach. Here's something interesting:
FormName: A string with a maximum of 16 characters that specifies the size of paper to use; for example, "Letter" or "Legal".
Here are two registry key values (the first one is from a print server where the report prints correctly, the second is from one that does not) for the custom form on my print servers.
5c,4b,03,00,5c,4b,03,00,00
5c,4b,03,00,5c,4b,03,00,00
Notice that of the last 16 characters, there is one set that is different 0F and 0b. I have found that this position represents the order in which the forms are added. As I add additional custom forms, the character in that position increases by 1.
I found how I can prove that this registry value is used and not the name of the form. I found a print server that has the correct registry value, but the form name is different. I named the custom form AirTranXP and it is the only custom form on the print servers and I was supposed to name it the same on each server. However, I found that on server I named the form AirTraxXP instead of AirTranXP, but it has the correct registry value so it prints properly. Go figure.
My conclusion is that the custom forms are assigned a value based on the order they were added (at least that is one value that is assigned), but if the rest of the properties of the custom form are the same (height width) then the only difference in the registry key would be the order in which it was added value.
My new solution should be to figure out how to change this registry value so that they all match - don't you think??
Only problem is that the application that I am using is an .mde so I won't be able to use this approach. Here's something interesting:
FormName: A string with a maximum of 16 characters that specifies the size of paper to use; for example, "Letter" or "Legal".
Here are two registry key values (the first one is from a print server where the report prints correctly, the second is from one that does not) for the custom form on my print servers.
5c,4b,03,00,5c,4b,03,00,00
5c,4b,03,00,5c,4b,03,00,00
Notice that of the last 16 characters, there is one set that is different 0F and 0b. I have found that this position represents the order in which the forms are added. As I add additional custom forms, the character in that position increases by 1.
I found how I can prove that this registry value is used and not the name of the form. I found a print server that has the correct registry value, but the form name is different. I named the custom form AirTranXP and it is the only custom form on the print servers and I was supposed to name it the same on each server. However, I found that on server I named the form AirTraxXP instead of AirTranXP, but it has the correct registry value so it prints properly. Go figure.
My conclusion is that the custom forms are assigned a value based on the order they were added (at least that is one value that is assigned), but if the rest of the properties of the custom form are the same (height width) then the only difference in the registry key would be the order in which it was added value.
My new solution should be to figure out how to change this registry value so that they all match - don't you think??
ASKER
One last tidbit - - the whole reason I am going through all of this is because I have 24 servers/Networks that use this same application and I want to be able to roll out new version of the application to all the networks withouth having to copy the .mdb file to each print server, open the reports in design view and reset the page settings before deploying it out to all of clients that use the application on each network.
I want to be able to make the changes on a lab server i have setup save the page settings, create the .mde and deploy it out to the servers without having to do anything else.
If I can't get any of this to work, I will have to approach management about change the form size of the report to use Letter or something other than 8.5 x 8.5. When using letter as the form size, I do not have any problems, it's just with the custom forms.
I want to be able to make the changes on a lab server i have setup save the page settings, create the .mde and deploy it out to the servers without having to do anything else.
If I can't get any of this to work, I will have to approach management about change the form size of the report to use Letter or something other than 8.5 x 8.5. When using letter as the form size, I do not have any problems, it's just with the custom forms.
I'm not sure ... what registry key is this?
ASKER
HKEY_LOCAL_MACHINE\SYSTEM\
ASKER
If those two registry keys match (which i have a couple of servers where the key matches) I can move the access file to the network that uses that print server and the settings stay in place.
I am investigating using a group policy object to overwrite the registry keys and make them all match. There is no "correct" registry entry, they all just need to match.
Pretty cryptic huh...lol.
I am investigating using a group policy object to overwrite the registry keys and make them all match. There is no "correct" registry entry, they all just need to match.
Pretty cryptic huh...lol.
ASKER
if you care to recreate the problem - take two machines and create a custom form on both machines (can be servers or XP clients) set the form name to AirTranXP and set the height and width to 8.5 x 8.5 on each (start>printers and faxes>file>server properties>forms tab). Then Go to HKEY_LOCAL_MACHINE\SYSTEM\
Be interesting to see if your approach works ... keep us posted.
ASKER
I will.
You can also access PrtDevMode programatically through the property of that name, e.g. Reports(0).PrtDevMode. Read the help on that property, there is a full example on how to manipulate this structure through code, along with a brief explanation of each item. Also look up the related PrtDevNames and PrtMip properties.
I second Scott, unless programmed manually, Access applications, let alone reports, store no information whatsoever in the registry. However, there are obviously interractions between the page setup of the report and the available forms on the selected print driver.
Happy hacking!
(°v°)