Page 1 of 1
Tip - Don't use Label Control for printing text in reports
Posted: Fri Aug 07, 2009 2:53 pm
by ConvertFromOldNGs
by Pam >> Wed, 4 May 2005 6:47:19 GMT
If the text includes an ampersand character the ampersand position is left blank and the next character is an underscore (as one would expect in a Label Control). It seems better to use a TextBox Control.
Re: Tip - Don't use Label Control for printing text in reports
Posted: Fri Aug 07, 2009 2:53 pm
by ConvertFromOldNGs
by
allistar >> Wed, 4 May 2005 7:12:49 GMT
One of my clients used to pre-parse the caption in the label and replaced all "&" characters with a double "&" (done in an external function call in C as it ws much much faster).
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst
allistar@silvermoon.co.nz
Auckland, NEW ZEALAND
Silvermoon Software
Specialising in JADE development and consulting
Visit us at:
http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at:
www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------
Re: Tip - Don't use Label Control for printing text in reports
Posted: Fri Aug 07, 2009 2:53 pm
by ConvertFromOldNGs
by Patwos >> Tue, 10 May 2005 5:07:13 GMT
There are some formatting advantages to using Label controls instead of TextBox controls. As Allistar has already mentioned, running code to parse the caption and turn single ampsersands into double ampersands avoids this behaviour. If you don't want to go to the trouble of an external function like Allistar, you can utilise the String::scanUntil method, which is already an external method in C++, to create a reasonably efficient JADE version as follows.
Hope that helps,
Pat.
___________________________________________________________
doubleAllAmpersands() : String ;
vars
str : String ;
pos : Integer ;
begin
pos := 1 ;
while pos > 0 and pos <= self.length do
// Scan until we find an ampersand (potentially none)
str := str & self.scanUntil( "&", pos );
if pos > 0 then
// We found an ampersand, so append two ampersands to the string we // will eventually return and increment pos to continue scanning the // source string after the point at which this ampersand was found. str := str & "&&" ;
pos := pos + 1 ;
endif;
endwhile ;
// We've now either found no ampersands, or we've "doubled" all the ampersands that were in the
// source string, so lets return the final string.
return str ;
end;
Re: Tip - Don't use Label Control for printing text in reports
Posted: Fri Aug 07, 2009 2:53 pm
by ConvertFromOldNGs
by Pam >> Tue, 10 May 2005 6:51:00 GMT
Surely it would be more efficient to sort out the formatting issues than run this method on thousands of records.
The only issue I have found is that the textbox BorderStyle has to be set to 0, which makes textboxes invisible in Painter. All we are doing is programatically setting the BorderStyle of all the controls of type textbox to 0 when we load the print forms. This method is only called once (in a Print superform), as opposed to having to call "doubleAllAmpersands" on every string attribute that might be printed.
Re: Tip - Don't use Label Control for printing text in reports
Posted: Fri Aug 07, 2009 2:53 pm
by ConvertFromOldNGs
by Andrew >> Wed, 11 May 2005 21:33:55 GMT
We use lables because they provide 7 alignment options, rather than the limited 3 of the Textbox.
Re: Tip - Don't use Label Control for printing text in reports
Posted: Fri Aug 07, 2009 2:53 pm
by ConvertFromOldNGs
by Patwos >> Fri, 13 May 2005 8:09:06 GMT
As Andrew has said, the alternate alignment options are one reason why Labels can be useful for printing. It all depends on what your end desire is as to whether or not to use this option.
As far as efficiency goes, if the TextBox suits your requirements by all means use it, I also use it where alignement or other options are not an issue.
In the bigger scheme of things, the multiple execution of thousands of doubleAllAmpersands doesn't really account for much of the overall report processing in most cases. I ran a test of 50,000 executions on a string of 25,000 characters with 6 ampersands per string that needed fixing. This meands a total of 1.25 billion characters to process, and the time take for this was still < 30 seconds. In most of my "real world" reports, profiling shows that the time spent on "doubleAllAmpersands" is normally < 1 second of the overall report time so I'm not particularly concerned about the overhead of this.
Hope that helps,
Pat.