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

[4everskiff]

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

[4everskiff]

Screenshot explaining the bug

[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().

[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

[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

[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

[marcopx]

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

[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

[cmbarton]

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