xsharp.eu

Phil, looking forward to see your results

Phil Hepburn wrote:It really is easy to get them to produce nice results, without the need to know just how half of the methods actually work, or what they do - many methods just provide a technical service to other more common sense methods - but they are totally required for printing success.

Two remarks: placing text in the "@x, y"-mm relative to paperbounds style is still needed (just in case you shouldn't know this <g,d&r>, and:
putting all helper code in separate lib, at least separate folder, or better, in a parent class should keep the dev-user frontend small & tidy.

HAND
Karl

Hi Phil,

I'll look forward to your samples!

I'm using a 3rd party library in VO, tha gives me only a virtual printer and the possibility to render graphic elements and texts including RTF on a predefined surface, and over this library (written in C++) I have added my own report classes, that evaluates code from my applications and uses text-based report files.
The 3rd party tool (VPE from Ideal Software) is not open source (but there is a free and somewhat limited version available), and since I wrote the first interface over it, I was offering my own classes source code to everyone that was interested.

Of course, if there is something better I can switch (or better: use another tool for future prints). So I look forward to you samples.

Wolfgang

Phil,

I think Printing is a great topic for the conference. Most developers that I have met dislike creating reports, and customers love to have reports, so it is a good opportunity to make some extra money, when you have the right tools.

Having a tool that makes creating the reports easy is certainly helpful. Especially if you can also explain a little bit about what is happening "behind the scenes" so we understand the code

I have a meeting in 10 days with Meinhard, Maike and Michael (M&M&M, is that a coincidence?) to discuss next year's conference. I am sure we will discuss this as well.

Robert

Hi Karl,

I never thought of that - putting all the support methods in a separate entity so as to simplify the 'user class', in a sort of 'front-end' class.

Any more good ideas where that came from ? :whistle:

Now time to get some sleep.

Speak again soon,
Regards,
Phil.