nopiknik
asked on
Report Open screen display does not show image, Print Preview does. Why?
I have a relatively simple report form with an image control in a group header.
A different picture should appear for each group in the report. When I "Open" the report, the images do not appear on the screen. When I select Print Preview, the images appear on the correct pages as they should.
I am using MS Access 2007 in compatibility mode (2003)
The image properties are
"Picture Type" is Linked ,
"Mode" is Stretched.
"Visible" is Yes
In the group On Format event the following code is run:
Me![imgctrl].Picture = Me![PictureFileSpec]
where PictureFileSpec is a string full path to the .jpg image to be shown.
I am pulling my hair out trying to figure out why the screen display of the report does not show the picture. But the Print Preview does. Is there another event fired for screen use that I need to utilize that is different for printing? Is there a property setting I am missing?
please help.
A different picture should appear for each group in the report. When I "Open" the report, the images do not appear on the screen. When I select Print Preview, the images appear on the correct pages as they should.
I am using MS Access 2007 in compatibility mode (2003)
The image properties are
"Picture Type" is Linked ,
"Mode" is Stretched.
"Visible" is Yes
In the group On Format event the following code is run:
Me![imgctrl].Picture = Me![PictureFileSpec]
where PictureFileSpec is a string full path to the .jpg image to be shown.
I am pulling my hair out trying to figure out why the screen display of the report does not show the picture. But the Print Preview does. Is there another event fired for screen use that I need to utilize that is different for printing? Is there a property setting I am missing?
please help.
nopiknik,
This is a function of the new "Report View"
In Access the default view for Reports is now "Report View"
This view is meant to just show you a Quick overall picture of your report.
It may or maynot be accurate.
(The report does not "render" in this view, to save time)
Notice how in this view as you scroll down a multipage report, there are no "Breaks" where the pages should start and stop.
Also notice that at the bottom it will always say "Page 1 of 1", no matter how many pages thaer are.
For a True representation of your report use "Print Preview"
(This does force a render, but can take longer to display your report on the screen. However, but this time is negligable in most cases)
If you wish to avoid this view, you can set the "Allow Report View" property of the Report to NO.
JeffCoachman
This is a function of the new "Report View"
In Access the default view for Reports is now "Report View"
This view is meant to just show you a Quick overall picture of your report.
It may or maynot be accurate.
(The report does not "render" in this view, to save time)
Notice how in this view as you scroll down a multipage report, there are no "Breaks" where the pages should start and stop.
Also notice that at the bottom it will always say "Page 1 of 1", no matter how many pages thaer are.
For a True representation of your report use "Print Preview"
(This does force a render, but can take longer to display your report on the screen. However, but this time is negligable in most cases)
If you wish to avoid this view, you can set the "Allow Report View" property of the Report to NO.
JeffCoachman
ASKER
Responders,
Sorry for the delay. Had to go on the road.
Anyway, the information is helpful but I am not quite there yet.
Flyster, I was hoping that there is something simple like what you are suggesting. HOWEVER, in Access 2007, where is "Word Options - Advanced - Show Document Content"? I don't even find it in Word?
nopiknik
Sorry for the delay. Had to go on the road.
Anyway, the information is helpful but I am not quite there yet.
Flyster, I was hoping that there is something simple like what you are suggesting. HOWEVER, in Access 2007, where is "Word Options - Advanced - Show Document Content"? I don't even find it in Word?
nopiknik
nopiknik,
Did you see my post?
It explains your situation exactly.
JeffCoachman
Did you see my post?
It explains your situation exactly.
JeffCoachman
ASKER
JeffCoachman
Sorry for the delay again. Limited internet access (I am in Jamaica).
I get what you are saying. But it really bugs me. Here's why...
I put 2 buttons on my report form. One button closes the report, the other button will output the report direct to a .PDF file. The buttons work just fine in report mode but act like they are disabled in print preview mode. I have set them to appear for screen only because I don't want the buttons to appear in the PDF file.
So I guess my question is morphing a bit to is there a different approach to these common button operations that I should be considering? OR is there a way to force a rendering in the Open Report mode?
Sorry for the delay again. Limited internet access (I am in Jamaica).
I get what you are saying. But it really bugs me. Here's why...
I put 2 buttons on my report form. One button closes the report, the other button will output the report direct to a .PDF file. The buttons work just fine in report mode but act like they are disabled in print preview mode. I have set them to appear for screen only because I don't want the buttons to appear in the PDF file.
So I guess my question is morphing a bit to is there a different approach to these common button operations that I should be considering? OR is there a way to force a rendering in the Open Report mode?
nopiknik,
The ability to "interact" with (ex.: "Click on") buttons and other objects in Access reports is new in 2007.
The ability to interact with buttons is lost in Print Preview.
So with your current setup, all should be fine now.
What do you mean by:
"is there a way to force a rendering in the Open Report mode?"
Force a rendering of what?
What effect are you trying to achieve?
JeffCoachman
The ability to "interact" with (ex.: "Click on") buttons and other objects in Access reports is new in 2007.
The ability to interact with buttons is lost in Print Preview.
So with your current setup, all should be fine now.
What do you mean by:
"is there a way to force a rendering in the Open Report mode?"
Force a rendering of what?
What effect are you trying to achieve?
JeffCoachman
ASKER
J.,
IF I understand you correctly, it seems you are offering me a choice:
Either: (A) I can have screens that look good in Print Preview but don't function (buttons don't work)
or (B) I can have screens that function but don't show images properly.
Somehow, for as long as Access has been making reports and acting as a front end for users to get at data and all the functionality that entails, this just doesn't feel right.
I've been around Access a fair amount, just not developing apps within it. I am not saying you are wrong, I am just amazed that MS would force developers to pick one or the other. Hence the previous questions:
Is there a different way that I need to think about how buttons are used? Is there another control that should be put on the report form (e.g. hyperlink?, a hotspot? that has an On Click event so the user can close the report or send it to PDF output. )? Or is there a way to force the "Open Report" mode to fully render the screens -- with images?
You ask: What is the effect I am trying to achieve? Here is the nutshell.
User launches the application. An MS Access form appears with a series of buttons on it. Each button displays a Report Form in "Report View" mode. (Here, you are saying it should be "Print Preview" mode).
On each Report Form, I have put two buttons (each is set for "Screen Only" display): One closes the current report, the other outputs the current report to a PDF file. Some of the reports happen to have images on them.
The images appear in Print Preview mode, not Report View mode.
The buttons work in Report View mode, not Print Preview mode.
See the dilemma?
Nopiknik
IF I understand you correctly, it seems you are offering me a choice:
Either: (A) I can have screens that look good in Print Preview but don't function (buttons don't work)
or (B) I can have screens that function but don't show images properly.
Somehow, for as long as Access has been making reports and acting as a front end for users to get at data and all the functionality that entails, this just doesn't feel right.
I've been around Access a fair amount, just not developing apps within it. I am not saying you are wrong, I am just amazed that MS would force developers to pick one or the other. Hence the previous questions:
Is there a different way that I need to think about how buttons are used? Is there another control that should be put on the report form (e.g. hyperlink?, a hotspot? that has an On Click event so the user can close the report or send it to PDF output. )? Or is there a way to force the "Open Report" mode to fully render the screens -- with images?
You ask: What is the effect I am trying to achieve? Here is the nutshell.
User launches the application. An MS Access form appears with a series of buttons on it. Each button displays a Report Form in "Report View" mode. (Here, you are saying it should be "Print Preview" mode).
On each Report Form, I have put two buttons (each is set for "Screen Only" display): One closes the current report, the other outputs the current report to a PDF file. Some of the reports happen to have images on them.
The images appear in Print Preview mode, not Report View mode.
The buttons work in Report View mode, not Print Preview mode.
See the dilemma?
Nopiknik
nopiknik,
To get to Word options in 2007, click the Office Button. You'll find it in the lower left-hand portion of the dialog box, right next to exit Word.
Flyster
To get to Word options in 2007, click the Office Button. You'll find it in the lower left-hand portion of the dialog box, right next to exit Word.
Flyster
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
JeffCoachman
Thanks for the extensive response.
I will accept your response on that basis alone.
Prior to 2007, I used Access as a storage medium. App development was done in VB outside of Access. The few times I tried developing apps within Access, I would get so frustrated I would give up and switch to VB. I can't do that here.
I am dealing with an application here with very small amount of data. And it isn't likely to grow significantly with time. So the whole speed issue is moot. But your point is well taken.
I also realize I better check compatibility with the boxes this app will run on (with 2003) -- not my development box (with 2007).
As to the nice rest of the weekend. That will be spent re-figuring the entire design. So much for "Enjoyment".
Thanks for hanging with me. I may have more questions soon.
Nopiknik
Thanks for the extensive response.
I will accept your response on that basis alone.
Prior to 2007, I used Access as a storage medium. App development was done in VB outside of Access. The few times I tried developing apps within Access, I would get so frustrated I would give up and switch to VB. I can't do that here.
I am dealing with an application here with very small amount of data. And it isn't likely to grow significantly with time. So the whole speed issue is moot. But your point is well taken.
I also realize I better check compatibility with the boxes this app will run on (with 2003) -- not my development box (with 2007).
As to the nice rest of the weekend. That will be spent re-figuring the entire design. So much for "Enjoyment".
Thanks for hanging with me. I may have more questions soon.
Nopiknik
nopiknik,
Yes, you bring up a good point:
<App development was done in VB outside of Access. The few times I tried developing apps within Access, I would get so frustrated I would give up and switch to VB. >
If you are more familiar with VB and try to switch to Access, you can quickly become frustrated with the lack of "control" you have over your app's development.
(From an Access standpoint, I look at VB and go: "Man, do I really need all that?")
;-)
JeffCoachman
Yes, you bring up a good point:
<App development was done in VB outside of Access. The few times I tried developing apps within Access, I would get so frustrated I would give up and switch to VB. >
If you are more familiar with VB and try to switch to Access, you can quickly become frustrated with the lack of "control" you have over your app's development.
(From an Access standpoint, I look at VB and go: "Man, do I really need all that?")
;-)
JeffCoachman
Flyster