If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
For all of you with Paper Size issues
I have had a paper size (Legal/Landscape) issue with a report in a .mde
application for some time. After several unsuccessful attempts to find a solution in the Newsgroups I pestered Microsoft support until I got the corrrect answer and again an unsuccessful/no solution. The issue involves something called prtDevMode, this is supposedly some group of control characters obtained from the print drivers of the default printer. It does not matter how you have defined the report before converting to a .mde, Microsoft claims they cannot change the paper size code in the .mde/runtime application. This situation exists in ALL versions of ACCESS, there are no service packs that fix it and it has not been fixed in OFFICE/ACCESS 2003 as MS Support originally tried to tell me. I don't know all of the background code of course but it does not make sense that you can design a report and save the page orientation correctly and not the paper size. I was just notified by MS Support that they cannot create a hot fix and there will probably not be anything done to correct this. They offered another soultion, they made reference to some code that will let you set the paper size programmatically but the catch is it only works in a .mdb. Their solution to protecting mine and your valuable proprietary source code is to distribute a password protected .mdb. Now I don't know about any of you but I have gone to the web and downloaded free password cracking software that is designed specifically to decode ACCESS passwords and they work very well. Personally I don't think this is an acceptable solution, I'm sure Microsoft would not distribute any of their proprietary code this way. I suggest that everyone that is having an issue with this contact Microsoft support and start a case regarding this issue. it was my impression that they feel there is not enough need or concern about this BUG to work on it. |
#2
|
|||
|
|||
Hi cafr
Interesting thread. I've never chased this issue as far as you have, but I'm not aware of a solution that works with MDE files. Not sure I'd call it a bug: more the omission of a feature that's rather basic and quite limiting. IMHO, a missing feature does not rank as importantly as the many bugs where Access actually gives you wrong answers, e.g.: - incorrect comparison: http://members.iinet.net.au/~allenbrowne/bug-11.html - missing records: http://members.iinet.net.au/~allenbrowne/bug-10.html - basic sorting wrong: http://members.iinet.net.au/~allenbrowne/bug-08.html - wrong display of data: http://members.iinet.net.au/~allenbrowne/bug-06.html - filtering wrong in forms and reports: http://members.iinet.net.au/~allenbrowne/bug-02.html and so on. Surely a program that gives you wrong answers is worse than one that crashes, because you can't trust its results. If Access crashes, they fix it. If it gives wrong answers, they don't care unless it has a 'business impact', i.e. enough people do complain. AFAIK, the PrtMip stuff works only with the MDB as you say. It's not the simplest thing to work with, and MS got the Help file examples wrong in A95, A97 and 2000, and I gave up checking them after that. For anyone researching that approach, see: http://www.microsoft.com/AccessDev/A...s/GetzCh10.HTM -- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "cafr2000" wrote in message ... I have had a paper size (Legal/Landscape) issue with a report in a .mde application for some time. After several unsuccessful attempts to find a solution in the Newsgroups I pestered Microsoft support until I got the corrrect answer and again an unsuccessful/no solution. The issue involves something called prtDevMode, this is supposedly some group of control characters obtained from the print drivers of the default printer. It does not matter how you have defined the report before converting to a .mde, Microsoft claims they cannot change the paper size code in the .mde/runtime application. This situation exists in ALL versions of ACCESS, there are no service packs that fix it and it has not been fixed in OFFICE/ACCESS 2003 as MS Support originally tried to tell me. I don't know all of the background code of course but it does not make sense that you can design a report and save the page orientation correctly and not the paper size. I was just notified by MS Support that they cannot create a hot fix and there will probably not be anything done to correct this. They offered another soultion, they made reference to some code that will let you set the paper size programmatically but the catch is it only works in a .mdb. Their solution to protecting mine and your valuable proprietary source code is to distribute a password protected .mdb. Now I don't know about any of you but I have gone to the web and downloaded free password cracking software that is designed specifically to decode ACCESS passwords and they work very well. Personally I don't think this is an acceptable solution, I'm sure Microsoft would not distribute any of their proprietary code this way. I suggest that everyone that is having an issue with this contact Microsoft support and start a case regarding this issue. it was my impression that they feel there is not enough need or concern about this BUG to work on it. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Printing on 5.5(w)x8.5(l) size paper | Craig | General Discussion | 1 | July 1st, 2004 09:29 PM |
Choosing paper size | socaltech62 | General Discussion | 0 | June 21st, 2004 08:10 AM |
Changing Paper Size | Lisa Greene | Publisher | 1 | May 12th, 2004 06:25 PM |