Ye old HTML as report language question

Hello all,

Do any of you happen to know whether or not it's possible to cause the web
browser control to print a header and hopefully a footer on every page that
it prints?  Any idea how to do it?

I will need to print some lengthy documents that need page headers, and HTML
would be my first choice for a poor-man's way to solve it.  Failing that, I
can induce Word to do the job.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Do any of you happen to know whether or not it's possible to cause
> the web browser control to print a header and hopefully a footer on
> every page that it prints?  Any idea how to do it?

The control uses the same print engine as InternetExplorer so if you
alter the "page setup" in IE it should be reflected by the control [1].
I don't know if you can get at the header/footer programmatically
though - if that's what you mean?

[1] It appears to work that way in IE6 anyway.  I set up a header and
footer in IE.  Opened DSDN, selected a html page and then print from the
context menu.  The resulting page had the new header and footers.

--
Ian

Ian,

> > Do any of you happen to know whether or not it's possible to cause
> > the web browser control to print a header and hopefully a footer on
> > every page that it prints?  Any idea how to do it?
>
> The control uses the same print engine as InternetExplorer so if you
> alter the "page setup" in IE it should be reflected by the control [1].
> I don't know if you can get at the header/footer programmatically
> though - if that's what you mean?

That's basically it.  I'll have to try it to see if it has enough
flexibility, but thanks for the push in the right direction!

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill -

Unless there has been a recent update, you'll find somewhere in the docs
that the "hack" is to remember the old header and footer setting, change the
registry key that holds them, print, then set the registry key back so the
user doesn't hate you.

Perhaps 6.0 has improved this situation, but that was the state of things a
couple years ago -

jlo

"Bill Schwab" <[hidden email]> wrote in message
news:b74bvh$anapc$[hidden email]...

Jeff,

> Unless there has been a recent update, you'll find somewhere in the docs
> that the "hack" is to remember the old header and footer setting, change
the
> registry key that holds them, print, then set the registry key back so the
> user doesn't hate you.
>
> Perhaps 6.0 has improved this situation, but that was the state of things
a
> couple years ago -

Thanks to you and Ian (and anyone else I might be forgetting).  Our database
guy (Steve) is helping me with this, and he found something similar.  Do you
know whether the header can include a table, or even just multiple lines?
Steve found some justification commands that could leave the impression that
it's one line or bust.

Another idea we're kicking around is to generate HTML and (via Automation)
paste that into a Word document, or just teach the system to add data
directly into Word.  Having lots of HTML generating code, I'd rather use
that if possible.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

My sense is you get one line - perhaps you can try stuffing it HTML or Crs
or something.

Pagination in general is the biggest drawback to using HTML for reporting.
It is too bad, because otherwise it is pretty easy to generate and
obsequious.

jlo

"Bill Schwab" <[hidden email]> wrote in message
news:b77arm$bn8fo$[hidden email]...
> Jeff,
>
> > Unless there has been a recent update, you'll find somewhere in the docs
> > that the "hack" is to remember the old header and footer setting, change
> the
> > registry key that holds them, print, then set the registry key back so
the
> > user doesn't hate you.
> >
> > Perhaps 6.0 has improved this situation, but that was the state of
things
> a
> > couple years ago -
>
> Thanks to you and Ian (and anyone else I might be forgetting).  Our
database
> guy (Steve) is helping me with this, and he found something similar.  Do
you
> know whether the header can include a table, or even just multiple lines?
> Steve found some justification commands that could leave the impression
that

Jeff,

> My sense is you get one line - perhaps you can try stuffing it HTML or Crs
> or something.

Steve is reaching the conclusion that it does not work - the header gets
interpreted as literal text :(


> Pagination in general is the biggest drawback to using HTML for reporting.
> It is too bad, because otherwise it is pretty easy to generate and
> obsequious.

True.  Word might end up being the answer, at least to get this off the
ground.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

How about generating it to HTML and opening it with Word instead of the
browser?  Simple, but perhaps effective.

A corollary - I once created a lovely framework to write data, using the COM
objects, to build Excel spreadsheets from VA Smalltalk.  It hid all the
implementation details and was pretty good - so I'm patting myself on the
back.

However, every time the spreadsheet needs a tweak, I, the developer has to
go to work and change it.  I have to make sure the right versions of Excel
are on the machine.  Office COM objects don't always behave and occasionally
leave "phantoms" around.

On a later project, I took a cue from an experience report from Joseph
Pelrine and just dumped the data in csv format.  Trivially easy.
Furthermore, usually Excel is associated with the .csv extensions, so it
opens right up on the file, even thought it is not in Excel's native format.

Then, my spreadsheet users, who are used to getting data dumps all the time,
create spreadsheets that read the data from my data dump, and massage it any
way they wanted.  When more data is added to my system, they rerun the
extract to csv, it replaces the csv file, and their spreadsheets are
immediately updated.

Also, now, whenever they wanted a spreadsheet tweak, they just do it.  And
the Smalltalk code is minimal.  No wrestling with COM.  Excel is not even a
requirement.

Maybe there is a similarity here - use HTML to generate the document, and
link it to Word documents outside of your application to provide pagination,
etc.

jlo

"Bill Schwab" <[hidden email]> wrote in message
news:b77hfi$c1jr6$[hidden email]...
> Jeff,
>
> > My sense is you get one line - perhaps you can try stuffing it HTML or
Crs
> > or something.
>
> Steve is reaching the conclusion that it does not work - the header gets
> interpreted as literal text :(
>
>
> > Pagination in general is the biggest drawback to using HTML for
reporting.

Jeff.

> How about generating it to HTML and opening it with Word instead of the
> browser?  Simple, but perhaps effective.

We had a similar idea, but what about the headers and footers?  Are there
HTML tags that would make Word do that?


> A corollary - I once created a lovely framework to write data, using the
COM
> objects, to build Excel spreadsheets from VA Smalltalk.  It hid all the
> implementation details and was pretty good - so I'm patting myself on the
> back.
>
> However, every time the spreadsheet needs a tweak, I, the developer has to
> go to work and change it.  I have to make sure the right versions of Excel
> are on the machine.  Office COM objects don't always behave and
occasionally
> leave "phantoms" around.

I was afraid of that :(   But thanks for the warning.   All the more reason
to view using Word as a temporary solution.


> Maybe there is a similarity here - use HTML to generate the document, and
> link it to Word documents outside of your application to provide
pagination,
> etc.

It's a good idea, and I'll keep it in mind.  Long term, I plan to get Word
out of the picture anyway.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> > How about generating it to HTML and opening it with Word instead of the
> > browser?  Simple, but perhaps effective.
>
> We had a similar idea, but what about the headers and footers?  Are there
> HTML tags that would make Word do that?

Don't have a specific answer, but I'll chime in anyway. ;-)

I do know that doing a save as HTML in Word retains enough information to
seemingly reproduce complex documents exactly. So if nothing else, you should be
able to add headers and footers in Word and save it as HTML to see what Word
puts into the file. Be warned though that Word generates a lot in the HTML for
even the simplest of documents, setting up styles (whether they're used or not),
etc.

I ended up doing something similar with Word recently, only using RTF. I
intended to just print RTF directly, using Ian's goodie. But I needed more
complex table support than the early (or any?) rich text controls had, so as an
expedient decided to use Word as my print engine. I used the RTF framework found
at http://smalltalking.net/Goodies/Dolphin/index.htm and wrote RTF to a temp
file. (Including headers and footers, BTW). Then used simple automation to get
Word to print the file, or to just open the file as a "preview". It's working
well, after figuring out some workarounds so the it would act right whether or
not the user already had Word open. (Let me know if you're interested, and I can
send the bit of automation I used for Word print/view).

regards,
-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

The Excel approach works nicely for us, although I've taken to using a
template file (.xlt) for reports.  We set up the report just as we want it
(mainly pivot tables in our case), and just open the file with Excel, put
the data in place, refresh the pivot tables, and make the Excel instance
visible.  To put the data in place you can use either the clipboard or grab
a range and stuff values into its SAFEARRAY.  We do the latter, but if
you're not averse to using the clipboard, that approach is simpler.

The advantage with Excel is that you can set anything you want in the page
setup from within Dolphin, and, depending on your needs, you could even get
away with just setting it up in the template file.

If you use this approach, you probably want to avoid generating classes for
the whole Excel object model, though.  It's huge (8+ MB I believe), and
mostly superfluous for any particular task.

HTH,

Don

I've done it both ways--generated the entire Excel spreadsheet from within
the app, and had an existing Excel spreadsheet access data my app provides
it.

I like the latter approach better, since it nicely separates presentation
from data. And it's a big plus when the user can modify the presentation
without my assistance.

You still start up the Excel spreadsheet from your app, so to the user who
doesn't care about customization, it looks the same as if you generated it.

Don,

> The Excel approach works nicely for us, although I've taken to using a
> template file (.xlt) for reports.  We set up the report just as we want it
> (mainly pivot tables in our case), and just open the file with Excel, put
> the data in place, refresh the pivot tables, and make the Excel instance
> visible.  To put the data in place you can use either the clipboard or
grab
> a range and stuff values into its SAFEARRAY.  We do the latter, but if
> you're not averse to using the clipboard, that approach is simpler.
>
> The advantage with Excel is that you can set anything you want in the page
> setup from within Dolphin, and, depending on your needs, you could even
get
> away with just setting it up in the template file.

Are you suggesting printing the documents using Excel, or simply using a
similar approach with Word and document templates for it?  Either way, it's
something to consider.  However, the headers can't be completely static
because they need to contain document-specific data.


> If you use this approach, you probably want to avoid generating classes
for
> the whole Excel object model, though.  It's huge (8+ MB I believe), and
> mostly superfluous for any particular task.

Agreed.  I already have a partial package for MS Word, and would probably
just extend it.  It might be different if the type libraries contained
useful help, but most of it simply restates the method names, and gives no
clue re the values of arguments, etc.  It doesn't give the type library
analyzer much to work with.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,
"Bill Schwab" <[hidden email]> wrote in message
news:b7f9p0$bops$[hidden email]...
[...]
> Are you suggesting printing the documents using Excel, or simply using a
> similar approach with Word and document templates for it?  Either way,
it's
> something to consider.  However, the headers can't be completely static
> because they need to contain document-specific data.
[...]

For our purposes, just putting the data into a workbook based on our
preformatted template works, since our stuff is intended as the beginning of
an ad hoc analysis.  In our case, our application doesn't actually print
anything; the user ultimately chooses what's printed.  Nevertheless, we do
care about the appearance and printability.  Excel makes it fairly simple,
and gives the user the option of modifying to a significant extent, without
needing a new version of our application.

I was thinking, though, that Excel is pretty handy for tabular data in
general, while Word always seems more difficult to get just right.  From
within Dolphin, you can make things auto-fit, you can modify pretty much any
part of the page set-up, e.g., fit to x pages wide, fit to y pages high,
headers, footers, etc.  I haven't used it specifically for routine, fully
automated reporting, but it seems well-suited.

For what it's worth,

Don