Opened 12 years ago

Closed 11 years ago

#127 closed defect (fixed)

WinGRASS Tcl/Tk GUI - Text formatting error in Output window

Reported by: 4everskiff Owned by: grass-dev@…
Priority: minor Milestone: 6.4.0
Component: Tcl/Tk Version: 6.3.0
Keywords: Text output, winGRASS Cc: marco.pasetti@…
CPU: Unspecified Platform: Unspecified

Description

Tested with WinGRASS-6.3.0RC6 on Windows XP

Tcl/Tk? GUI Output window

After running a command, with every text output that doesn't start with an icon (such as error or alarm icon), the firt letter of the output is placed in the upper line, instead to appear in *its* line.

Screeshot example attached

Marco

Attachments (1)

bug001.png (156.6 KB) - added by 4everskiff 12 years ago.
Screenshot explaining the bug

Download all attachments as: .zip

Change History (9)

Changed 12 years ago by 4everskiff

Attachment: bug001.png added

Screenshot explaining the bug

comment:1 Changed 12 years ago by pkelly

Does this really apply to every command? Can you give another example other than "g.region -p"?

Also, how was the location created? Does the same behaviour occur in a location that wasn't created using WinGRASS (e.g. does it happen with spearfish?)

Potential technical explanation: I suspect it might just be another example of G_getl() needing to be replaced by G_getl2() when reading the projections file and creating the PROJ_INFO - the newline character is stripped off but the carriage return isn't.

IMHO the best solution to this is to audit all occurences of G_getl() and replace them with G_getl2() if there are no potential problems, then replace G_getl() itself with a wrapper to G_getl2().

comment:2 in reply to:  1 Changed 12 years ago by 4everskiff

Replying to pkelly:

Does this really apply to every command? Can you give another example other than "g.region -p"?

Also, how was the location created? Does the same behaviour occur in a location that wasn't created using WinGRASS (e.g. does it happen with spearfish?)

Potential technical explanation: I suspect it might just be another example of G_getl() needing to be replaced by G_getl2() when reading the projections file and creating the PROJ_INFO - the newline character is stripped off but the carriage return isn't.

IMHO the best solution to this is to audit all occurences of G_getl() and replace them with G_getl2() if there are no potential problems, then replace G_getl() itself with a wrapper to G_getl2().

Hi Paul,

I confirm that I dedected the same bug with other commands (such as r.horizon, for example) and also with spearfish.

Marco

comment:3 Changed 12 years ago by hamish

before ripping lots of code apart and applying a sledge hammer solution in the vague hope it might solve the problem, I think it better to look at the Tcl code and try to track down exactly what the problem is. (first step is to identify where in the code this is; 2nd is why)

Of course fgets() + G_getl() -> G_get2() needs to be done in many places. Also we need to determine if all grass text files (including WIND and raster cellhd files, etc) are specified as using UNIX newlines or native newlines for strict writing. (keep reading loose)

Is there any reason to keep the current G_getl() beyond backwards compatibility? (ie any reason not to make it a wrapper for G_getl2())

Hamish

comment:4 Changed 12 years ago by neteler

Milestone: 6.3.06.4.0

comment:5 Changed 12 years ago by cmbarton

I've committed a change to gronsole.tcl that I hope fixes this. It is not a problem on the Mac, and maybe only on Windows. I moved the linefeed for command output text from after the text line to before the text line. I'm assuming that Windows will read "\n" as a line feed. Could someone please test in Windows. I'm not changing this ticket to resolved yet to see if it actually works.

Michael

comment:6 in reply to:  5 ; Changed 12 years ago by marcopx

Version: 6.3.0 RCs6.3.0

Replying to cmbarton:

I've committed a change to gronsole.tcl that I hope fixes this. It is not a problem on the Mac, and maybe only on Windows. I moved the linefeed for command output text from after the text line to before the text line. I'm assuming that Windows will read "\n" as a line feed. Could someone please test in Windows. I'm not changing this ticket to resolved yet to see if it actually works.

Michael

Very good. It seems that I definetly need to build upon the SVN trunk. It will take 3 hours or more here :-( BTW, the windows (working) code for the Carriage Return & Linefeed is \r\n, but probably the \n suffices

Marco

comment:7 in reply to:  6 Changed 12 years ago by martinl

Very good. It seems that I definetly need to build upon the SVN trunk. It will take 3 hours or more here :-( BTW, the windows (working) code for the Carriage Return & Linefeed is \r\n, but probably the \n suffices

r31351 is related to 'develbranch_6' it wasn't committed to trunk.

Martin

comment:8 Changed 11 years ago by cmbarton

CPU: Unspecified
Platform: Unspecified
Resolution: fixed
Status: newclosed

As far as I can see in the reports above, this is fixed.

Note: See TracTickets for help on using tickets.