Re: Existing forms to PDF or Excel

#1

Hello John,

It is very asy to write Client PC VBA (Excel or Word with chart)
application that will read data directly from D3.
I can help You. Answer directly, please.

Regards,
Grigory

#2

Hi John,

By using Briz, you can easy link up your existing program to any VB
routine to generate different kind of reports in Excel, PDF and so
on...

I am using Fast-Report Studio(www.fast-report.com). Price is
reasonable and pretty easy to convert existing line report to a
"window-look-alike" report. e.g. Preview b4 print...

Rgds,

#3

On Sun, 13 Aug 2006 03:29:47 GMT, "Excalibur"
<excalibur21 (AT) bigpond (DOT) com> wrote:

Quote:

Hi
You will find that the chap that sorted out Excel forms etc with what eventually became Visual Basic knew all about the issue and worked around it so as not to wreck all the 1980's coding. Simple rule the century has to be divisible by 400 but the guys before him did not know it.
Peter McMurray

Peter, ever thought about deleting all the non-applicable bits from
your responding posts?

Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

#4

I started out trying to do things that way, but ended up just generating
HTML without a lot of the extra crap. For number formatting, you can use
CSS with the Microsoft extensions. In particular, the
"vnd.ms-excel.numberformat" extension bears looking at. It took me quite
a while to find that baby, and it's very, very useful.

OTOH, I doubt this will be much help to John, because it means reworking
all of his report code.

Luke

Craig wrote:

Quote:

Hi John,

About 4 or 5 years ago I started to output all the companies reports to
Excel.

I first started with CSV and TAB separated. Then I started with html
formated XLS files. All I did first was go into excel put a few bits of info
into some cells put some formatting on them ( Colours / Currency/ dates /
special) some calcualtions. Then just saved them as html format.

Next I just studied what came out in the html through good old Notepad.

I then just replicated it through my programs ( no need for any thrid party
software ) It was really easy.
The main part of the html code ( the top bits ) never seemed to change so I
just dumped that text into an item, then just read it in before starting to
build the rest of the spreadsheet!

I write out the html code as an XLS extension file on the users PC then just
launch it into excel

The powers that be love it because they get nicely colours proper looking
spreadsheets

I can if you wish send some examples.

I use mvBASE but I am sure it you would be able to change the relevant bits
to work for D3!

As far as PDF goes, my windows developer wrote his own report generator that
uses XML. All I do is drop out the PICK data to the users PC in XML format
and then launch the report generator / report to run / path to xml, I can
also pass a switch for which format ( pdf / doc etc ) or allow it to come up
in the report viewer which then allows them how they want to save it or even
a choice to email it!

Craig

#5

We recently discovered another "feature" of Excel when importing
largish HTML tables - only happens (starts) around line 6682 if you
have col-spans and a few other bits & pieces ... Microsoft have
acknowledged problem & our solution so far is "see if is is fixed in
the Office 2007 Beta" ?!?!. Cosnidering the issue also applies to
Office 2000, you would have thought that a "fix" would have been
available before now

maybe we DON'T have it so bad after all ... ??

#6

"Ross Ferris" wrote:

Quote:

We recently discovered another "feature" of Excel when importing
largish HTML tables - only happens (starts) around line 6682 if you
have col-spans and a few other bits & pieces ... Microsoft have
acknowledged problem & our solution so far is "see if is is fixed in
the Office 2007 Beta" ?!?!. Cosnidering the issue also applies to
Office 2000, you would have thought that a "fix" would have been
available before now

maybe we DON'T have it so bad after all ... ??

I can't resist a comment. This is the exact situation we're rambling
about in Peter's thread. If people don't make an issue of it, the
problem will persist. After 6 years you'd think if it were important
enough someone would have asked for a fix, no? If you don't test the
issue in the Office 2007 beta then you can only blame yourself if the
issue is never fixed. Human nature being what it is I'm sure it will
be much more satisfying to wait until Office 2007 goes production and
then you can chortle at how stupid Microsoft is for not finding the
problem you've known about for so long. That seems to be the standard
here anyway.

What DOES get me though is that it seems like a very simple thing for
Microsoft to test a problem with HTML and Excel. I'm wondering why
they kicked this back to you. My guess is that your "Microsoft have
acknowledged problem" means someone in a forum tried it and suggested
that you report it through channels if it's that important to you.

T

#7

Thanks for the warning mate, I would have walked right in.
Peter McMurray
ps Hi Bruce is that better
"Albino Timberwolf" <ALBINOTIMBERWOLF (AT) TAMPABAY (DOT) RR.COM> wrote

Quote:

If you choose to export to Excel, never (and I mean never) name your first
column 'ID'. Excel does not like it. Call it ANYTHING else.
Woof!

johnmarshall (AT) xtra (DOT) co.nz> wrote in message

#8

Hi Tony
Is this why RD never released it, they were looking after your bottom line?
Peter McMurray
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Quote:

1) I have a solution which will allow you to get very pretty reports
without lines, boxes, images, even subtotals and pages breaks which
aren't in your original data - all without changing a line of your
BASIC code. It could cost a lot of money though - $15-25k or more
including software, labor, etc.. You can continue to maintain your
BASIC code and as long as the formatting of the output doesn't change
your GUI (Graphical User Interface, even if on paper) will reflect the
changes.

#9

Tony Gravagno wrote:

Quote:

. My guess is that your "Microsoft have
acknowledged problem" means someone in a forum tried it and suggested
that you report it through channels if it's that important to you.

T

No, problem was reported to/via Micrososoft support, and today we have
confirmed that problem still exists in Office 2007. We tend to report
any/all problems as we find them (except the one with UP that I can
never quite document, but keep getting forward link errorsat the most
n-appropriate times)

#10

I have no idea what that means but I'm sure it wasn't intended as a
compliment.

The product in question has nothing to do with MV and doesn't come
from RD or any other company in this space. It's a reporting solution
which is quite popular outside of this market among companies with
complex reporting needs, or migrating/integrating from legacy
environments. The only problem introducing it to this market has to
do with pricing. Surprise Surprise.

T

"Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote:

Quote:

Hi Tony
Is this why RD never released it, they were looking after your bottom line?
Peter McMurray
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote in message
news:hq2vd2dq7jnrqehtul7ui3upkhibt2vjqh (AT) 4ax (DOT) com...

1) I have a solution which will allow you to get very pretty reports
without lines, boxes, images, even subtotals and pages breaks which
aren't in your original data - all without changing a line of your
BASIC code. It could cost a lot of money though - $15-25k or more
including software, labor, etc.. You can continue to maintain your
BASIC code and as long as the formatting of the output doesn't change
your GUI (Graphical User Interface, even if on paper) will reflect the
changes.