Solved

Report Open screen display does not show image, Print Preview does.  Why?

Posted on 2008-06-24
11
2,133 Views
Last Modified: 2013-11-28
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.






0
Comment
Question by:nopiknik
  • 5
  • 4
  • 2
11 Comments
 
LVL 22

Expert Comment

by:Flyster
ID: 21858561
Go to Word Options - Advanced - Show Document Content. See if the "Show Picture Placeholder" is checked. If so, uncheck that. Your picture should show. Good Luck!

Flyster
0
 
LVL 74

Expert Comment

by:Jeffrey Coachman
ID: 21860415
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
0
 

Author Comment

by:nopiknik
ID: 21875554
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
0
 
LVL 74

Expert Comment

by:Jeffrey Coachman
ID: 21875691
nopiknik,

Did you see my post?
It explains your situation exactly.

JeffCoachman
0
 

Author Comment

by:nopiknik
ID: 21891118
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?  
0
Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

 
LVL 74

Expert Comment

by:Jeffrey Coachman
ID: 21892844
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
0
 

Author Comment

by:nopiknik
ID: 21894266
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
0
 
LVL 22

Expert Comment

by:Flyster
ID: 21895483
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
0
 
LVL 74

Accepted Solution

by:
Jeffrey Coachman earned 250 total points
ID: 21895486
nopiknik,

<IF I understand you correctly, it seems you are offering me a choice:>
Not me, Microsoft.
;-)

You can go to any of the MS Office/Access sites and research the differences between Report View and Print Preview. (Complicating things more is also the new "Layout View")
:-O

<I've been around Access a fair amount>
Then you know that the ability to interact with anything on a report did not exist prior to 2007 (what did you do before Version 2007, Microsoft might ask?)
;-)

Keep in mind, for the past 13 years we have launched reports from menus and buttons, without any real complaints.
Now MS gives us functionality that we never had before, and we complain that it is not perfect!
(how did you survive those 13 years of agony?)
:-)

<I am just amazed that MS would force developers to pick one or the other>
So was I, ...at first.
Then I thought about it for a while.
Print Preview was always meant to display the Report *exactly* the same way as it will look when you print it.
This means the preview engine must render all of the graphics, on every single page of the report, which takes longer.
If you think about it, if I just wanted to see if the text was properly aligned, do I really need to interact with any buttons?
Or I use print preview to see exactly how many pages the report will have. Again, no need to click any Report buttons.
Finally, if someone says: "I need another printout of that report for Fred.", do you *really* need interactive buttons?
So why bother making them active?

On the other hand, making button interactive in all views can cause problems for the "Mad Clicker". This is the user who clicks on any button just to see what it does.
;-)
Now they have the potential to screw things up by clicking buttons that might alter the DB in ways they do not understand.

Report View is a way to make Reports more like Forms.
Alternatively, if I need to open a report, from a report, I really don't care what the image looks like; I just need to open the report.
(The boss says: "Click that button on the report and tell me what the total sales are."  And I say: "Hmmm these images look fuzzy" The boss says: "I did not ask you to look at the images; I asked you tell me the total sales, if you can't do what I asked, look for another job!)
Or you say: "OK you'll have to wait 7 minutes until the report fully renders itself so I can view the graphics clearly, then I will tell you the total sales")
;-)

You can set any of these views to be Available or not.

But in all seriousness, some reports are massive, and it would take a great deal of time and processing power to fully render every object on every page. (up to 65,000 pages)

This also brings up the ultimate issue:
Why can't there just be one view for everything?
(Viewing, designing, Previewing, Interacting)
Even if this was possible, you would still need a way to differentiate between the functionalities for users who need one or the other.

To avoid this issue altogether, (and to directly address your question: "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. "  )
Most developers simply avoid using the interactive stuff in reports in the first place.
This minimizes user confusion over the views.
If I need interaction, I will use a Form, the way I always have. (This also insures full compatibility with older versions of Access)
Or the developer will restrict certain views altogether
Or educate the users on the differences between the views, so they understand what can/cannot be done in certain views)

Going a bit further, it was never an easy task to automate the sorting and filtering of a report (You had to open the report in design view, hidden, make the changes, Save, close, then reopen the report!.)

Now, with Report View, you can do this in real time.

So yes, I see the dilemma, and I feel your pain.
:-)

But I also understand what I believe to be some of the reasons for this.

(Perhaps MS will tweak some of these attributes in a future service pack)

:-)

Besides as time goes on this will become less and less of a real issue for the users

Most users will simply roll with it, and move on.
At first they will ask: "How come I cant click the button?"
You say: "You cant in Print Preview, you must use Report view. Thats the way it is, live with it"
They say: "OK."

LOL, funny but true.

If I were you, I would create a standard Report menu form, with three buttons.
1.      Print Report (Prints directly without Previewing)
2.      Preview Report (View the report as it will look when printed)
3.      Interact with Report (Views report with the primary function of being able to interact with it)

Again after a while of using this, users will figure out what view they need, select it, and move on.

Enjoy the rest of the weekend!
;-)

JeffCoachman
0
 

Author Comment

by:nopiknik
ID: 21895835
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
0
 
LVL 74

Expert Comment

by:Jeffrey Coachman
ID: 21895878
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
0

Featured Post

Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.

Join & Write a Comment

In the article entitled Working with Objects – Part 1 (http://www.experts-exchange.com/Microsoft/Development/MS_Access/A_4942-Working-with-Objects-Part-1.html), you learned the basics of working with objects, properties, methods, and events. In Work…
In a multiple monitor setup, if you don't want to use AutoCenter to position your popup forms, you have a problem: where will they appear?  Sometimes you may have an additional problem: where the devil did they go?  If you last had a popup form open…
As developers, we are not limited to the functions provided by the VBA language. In addition, we can call the functions that are part of the Windows operating system. These functions are part of the Windows API (Application Programming Interface). U…
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now