Re^2: Assistance fixing a "format" call

Hmmm thanks for that Marshall. I had had a look at printf, but by that point I'd already gone down the format path as it was the first recommendation I'd received - and it seemed to work fine for me first up.

I should certainly be able to modify some printf calls to get the output I'm after. Just need it to look all purdy on-screen so the user can browse the data relatively easily to pick out the one they're after. Edit: modified my code while I was drafting up this response, and it does indeed do what I'm after, so thanks again for that.

Having said that... I'd still love to know why it is that what I'm using at present isn't working as expected. I'm sure it must be something fundamental I'm doing wrong - but it would be nice to know for future reference (if not only for myself, but others that might be looking at doing similar) what it is. It's certainly been rather frustrating to try and work it out ;)

Comment on Re^2: Assistance fixing a "format" call Select or Download Code

Replies are listed 'Best First'.
Re^3: Assistance fixing a "format" call by Marshall (Canon) on Apr 02, 2012 at 03:23 UTC
well one possibility is that "write" writes to the currently selected filehandle. Try "write STDOUT;" But since you say that you are getting at least some kind of line, the leading spaces in the 2nd format statement may also be an issue - this is a finicky critter - one reason why I don't recommend it. The first answer on Monks is not always the "best answer" - and I would include myself in that general statement also!. In the future, I think you will wind up being much happier with printf(). Anyway, the difference that I see is this: (2nd format does not start in column 1). `format STDOUT = @<<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<< +<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<< @row . not the same as: format STDOUT = @<<<<<<<<<<<< @<<<<<<<<<<<< @<<<<<<<<<<<< @<<<<<<<<<<<< @<<<<< +<<<<<<< @rows .` [download] Update: After looking at the doc's, the "." - to end the format - has to be in column 1. It doesn't say that the format itself must start in column 1, but at the moment I am at a loss for any other ideas. The two statements appear to be so similar that that's the only thing I can think of at the moment. I did look at what it will do if "the data doesn't fit" and you get #'s in that field. This is almost always not what is desired. I wrote a recent post at printf exact field width of floating point number that talks about using sprintf() to decide how wide a field will actually be printed and how to use a different format spec in printf() if it "doesn't fit" within a fixed number of characters (in this case using %g instead of %f). This is extremely rare. (update: I liked BrowserUK's answer in that thread also, if you give %g "enough room to work", it will do a "good job"). All of which will be better than the "format" idea for numeric values. For strings, this whole idea of how to display the decimal number is mute. For strings, the issue is whether you are going to truncate the string or allow the columns for that line to "go astray" if the value doesn't "fit". In general printing "something" is better than printing "nothing or just #'s". But almost always, print the data to the precision needed and if some weird line doesn't line up, then so be it. Always add an explicit space between format specifications to ensure at least one blank space between values. In summary, this "format" idea was a good one, but it doesn't work out well in practice.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Assistance fixing a "format" call
by Marshall (Canon) on Apr 02, 2012 at 03:23 UTC

But since you say that you are getting at least some kind of line, the leading spaces in the 2nd format statement may also be an issue - this is a finicky critter - one reason why I don't recommend it. The first answer on Monks is not always the "best answer" - and I would include myself in that general statement also!.

In the future, I think you will wind up being much happier with printf().

Anyway, the difference that I see is this: (2nd format does not start in column 1).

            format STDOUT =
@<<<<<<<<<<<<<<<<<<<<<<<<<  @<<<<<<<<<<<<<<<<<<<<<<<<<  @<<<<<<<<<<<<<
+<<<<<<<<<<<<  @<<<<<<<<<<<<<<<<<<<<<<<<<
@row
.

not the same as:
        format STDOUT =
    @<<<<<<<<<<<<  @<<<<<<<<<<<<  @<<<<<<<<<<<<  @<<<<<<<<<<<<  @<<<<<
+<<<<<<< 
    @rows
.
[download]

I did look at what it will do if "the data doesn't fit" and you get #'s in that field. This is almost always not what is desired. I wrote a recent post at printf exact field width of floating point number that talks about using sprintf() to decide how wide a field will actually be printed and how to use a different format spec in printf() if it "doesn't fit" within a fixed number of characters (in this case using %g instead of %f). This is extremely rare. (update: I liked BrowserUK's answer in that thread also, if you give %g "enough room to work", it will do a "good job").

All of which will be better than the "format" idea for numeric values. For strings, this whole idea of how to display the decimal number is mute. For strings, the issue is whether you are going to truncate the string or allow the columns for that line to "go astray" if the value doesn't "fit".

In general printing "something" is better than printing "nothing or just #'s". But almost always, print the data to the precision needed and if some weird line doesn't line up, then so be it. Always add an explicit space between format specifications to ensure at least one blank space between values.

In summary, this "format" idea was a good one, but it doesn't work out well in practice.

[reply]
[d/l]