Certainly, I did try that as my first preference. It worked well 
until the number of pictures increased such that it became a memory 
problem. Apparently my report runs formatting through all pages 
first, I assume to determine number of pages and what fits where, 
before settling on the page to display. With a small number of 
pictures this was working. There was a delay at the start up, and at 
each page forward, but it did work.
If there is a way to stop all that preprocessing, I would say this 
will be the solution I am looking for. I am very interested to see 
an example of the code you mentioned.

Thank you.
Dean

--- In [email protected], "A.D.Tejpal" <[EMAIL PROTECTED]> 
wrote:
> Dean,
> 
>     I may be in a position to suggest a solution for your problem 
involving image control based report with large number of images 
(say in hundreds). You don't have to use OLE type controls at all. 
Stored paths to image files is considered the preferred way.
> 
>     On opening the report in print-preview, loading of images 
takes place only for the first page. Thereafter, images on each page 
get loaded progressively, as you step through the pages.
> 
>     Could you please confirm whether your report works smoothly if 
you take care to wait sufficiently at each page (for the display to 
get properly stabilized), before moving to the next page ? If this 
is the case, I might be in a position to give a programmatic 
solution. With that you should never again face a problem, even 
while stepping through the report pages in a brisk manner.
> 
> Best wishes,
> A.D.Tejpal
> 
>   ----- Original Message ----- 
>   From: dsdavids 
>   To: [email protected] 
>   Sent: Monday, October 03, 2005 00:31
>   Subject: [AccessDevelopers] Re: Formatting Report...
> 
> 
>   Thanks for considering my question A.D., I have long seen that 
you 
>   are extremely helpful in these matters. I did actually get my 
report 
>   to work. It was something trivial that escapes me at the moment, 
a 
>   formatting setting in the detail section or something that when 
I 
>   changed it, voila all was well.
>   But, while I have your attention, perhaps you have a suggestion 
for 
>   my app. This is the second time I ventured into making reports 
with 
>   large numbers of pictures and I am surprised to find it as 
difficult 
>   as I do. I have always read that it is not a good idea to save 
the 
>   picture, just the path. I first did that, assigning the pictures 
at 
>   run time to an image control on a form. It worked like a charm.
>   When I went to make a report that turned out to be 53 pages with 
80 
>   pictures I found it very difficult to get those pictures into 
the 
>   report. I used an image control again, assigned the picture in 
>   the "on format" event of the detail section. It was slow, but 
>   worked. It worked that is until the number of pictures increased 
to 
>   a point that I must have run out of memory or something and 
>   everything broke down.
>   I went back and used a OLE field to store all the pictures and 
was 
>   able to then make my report using a bound object frame, it 
worked 
>   well enough. Of course now my database is ballooned up over a 
>   gigabyte and it has only produced one report on one project. If 
I 
>   want to use it as an application for some time to come, that 
>   obviously won't do.
>   I've now started experimenting with saving only the path, then 
>   creating a temporary table at report run time, with all the 
pictures 
>   in an OLE field. I figure I can create the report off the temp 
>   table, then delete that table when the report is closed.
>   My question to you is, does this have to be that complicated? Am 
I 
>   missing something simple and making too much of it? Has nobody 
ever 
>   had to make reports with numerous pictures? It seems an obvious 
>   application of data storage. I have numerous projects with 
numerous 
>   issues and these issues may or may not have pictures associated 
with 
>   them. I am making reports where issues are printed along with 
>   related information, calculations and pictures if they exist.
> 
>   I look forward to any input you or anyone else may have on the 
topic.
>   Regards,
>   Dean Davids
> 
> 
>    --- In [email protected], "A.D.Tejpal" 
<[EMAIL PROTECTED]> 
>   wrote:
>   > Dean,
>   > 
>   >     You could consider uploading a zipped version of your db 
(with 
>   some sample data) to Files section of this group.
>   > 
>   > Best wishes,
>   > A.D.Tejpal
>   > 
>   >   ----- Original Message ----- 
>   >   From: dsdavids 
>   >   To: [email protected] 
>   >   Sent: Monday, September 26, 2005 05:45
>   >   Subject: [AccessDevelopers] Formatting Report...
>   > 
>   > 
>   >   I have a report with 2 subreports in detail section and one 
>   group 
>   >   header. The report runs fine until I change the group header 
to 
>   repeat section. I want the group info printed at the top of each 
>   page as each group has 10 or more pages. 
>   >   With repeat section enabled the status bar reads "formatting 
>   report, press ctl break to cancel" indefinitely and the preview 
pane 
>   never displays the result. I do have to press ctl break and stop 
it 
>   as I've left if for hours with no results.
>   >   Any reason this might be happening? This is AccessXP 
database.
>   > 
>   >   Thanks for any suggestions.
>   >   Dean




------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/q7folB/TM
--------------------------------------------------------------------~-> 


Please zip all files prior to uploading to Files section. 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/AccessDevelopers/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to