xsharp.eu

In an old VO application that I maintain, we use ReportPro 2 for hard coded reports. In some circumstances we need to print multi-line text using RpPrinter:DrawText, but DrawText isn't wrapping the text correctly. If you look at the attached example the word "WHICH" is truncated on the first line. The width of the area to print is clearly being calculated correctly as the printing is lying within the column area, but the text is not being properly wrapped and instead the first line is simply truncated instead of being wrapped after the word "DESCRIPTION". Any ideas on how to correct this behaviour?

Thanks

Nick

Hi Nick,

I have all sorts of ideas since I have written all this type of stuff myself, in my Printing class. Its actually all built on/around the same stuff - from VO to .NET WinForms, to WPF stuff for printing. A graphics surface onto which graphics objects are placed. I can go into this a lot more on a personal communication level.

What would be interesting to know is what happens when you remove the italic style, and then also when you go that bit further and replace upper case with lower case.

To me it looks as if the RHS limit for printing is within the columns on the right of screen.

I have lots more to say - BUT - give me an email if you are interested. This is a complex business.

Can you answer my questions here in the Forum please ?

Cheers,
Phil.
Wales, UK.

Hi Nick,

I checked some old code of mine, what I am doing is just divide the text into words, then check how many words fit in each line and print them, then leave the rest for the next line etc. Apparently I had been facing the same problem that you do and had not found a way to do it with standard RP functionality.

I'm attaching the original code, in case you find it useful. Please don't mind the incredibly bad style of coding, I was very young and reckless when I wrote that! I assure you, the quality of code I am writing for x# has improved since then

Chris

ps. just noticed, "grammes" == "lines" in Greek

Chris/Phil,

Thanks for the replies. I'll have a look at your code Chris. What I really need is a drop-in replacement for the DrawText function, as I try desperately to not change anything in this program as it's very old code and very flaky (not done by me I hasten to add!) and I long ago learnt that making any significant changes tends to break loads of stuff elsewhere...

Chris, now that you folks are handling RP as well, any chance of you looking at the DrawText function itself in ReportPro to see if there is a problem there that can be fixed?

Thanks

Nick

Hi Chris,

Got it working much better using your code, and I can adapt it to make it more or less a drop-in replacement.... Thanks!

Nick

Morning Nick,

Glad to hear that all is now well and you are up and running.

I think your strategy is wise and correct - change as little as possible - EVERYWHERE!

Although your solution sounds a bit of a 'hack' I would stick with it. Remember I have been honing my Printing Class over ten years as I recall ;-0)

Good Luck, and don't forget to email me directly if you need to discuss more about printing - you never know, it may give me some material ideas for Cologne 2018.

Cheers,
Phil.
Wales, UK.

Hi Nick,

Great, glad to hear it worked! Good point also about checking the DrawText() function, we'll have a look.

Chris

Hi Chris,

Just an FYI.

I've been digging further into the reporting in the application and find the same issue occurring with ReportPros RTF:DrawText as well - I don't have the source code but I imagine that under the hood this is using the same internal methods (or at least logic) as the RpPrinter:DrawText.

Nick

Nick, all,

If I remember correctly from ten years back, the 'DrawText' method is a fundament method of the Base class for drawing on the graphical surface to be printed.

When I wrote my VO Printing class it appeared in a whole heap of methods I built up.

HTH,
Phil.

Hi Nick,

Thanks! Yes, from what I remember, at least when I was hunting some RP bugs in the vulcan days, at least in the vulcan RP code the various drawing methods were all using common code under the hood. Been very busy in the last days working on a new build release so we haven't looked into it yet, but will do later.

Chris