[GRASS-dev] gis.m, thematic layer: You must open a display monitor

GRASS GIS GRASS GIS developer
1

Michael,

I am seeing a new error for d.vect.thematic. Trying to display a thematic layer fails with the message: *** You must open a display monitor ***

I can reproduce this with any spearfish vector layer.

The problem seems to be in lines 336-345 where it checks for the existance of an x-monitor. It seems to do this unconditionally, so even if you run it from the GIS Manager it still checks and fails if there is not monitor.

I can't find anything recent in the commit logs that would explain this, so before trying to go deeper into it, I wanted to know if you had an idea why this is suddenly happening.

Moritz

2

I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a
LOT more of these messages recently--with their deleterious effects on
scripting. Hamish says they've been there all along. I'm suspecting that the
code for the message has existed, but they did not get parsed for some
reason. But that is just speculation.

Michael

On 2/13/07 6:19 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

Michael,

I am seeing a new error for d.vect.thematic. Trying to display a
thematic layer fails with the message: *** You must open a display
monitor ***

I can reproduce this with any spearfish vector layer.

The problem seems to be in lines 336-345 where it checks for the
existance of an x-monitor. It seems to do this unconditionally, so even
if you run it from the GIS Manager it still checks and fails if there is
not monitor.

I can't find anything recent in the commit logs that would explain this,
so before trying to go deeper into it, I wanted to know if you had an
idea why this is suddenly happening.

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

3

On 13/02/07 15:29, Michael Barton wrote:

I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a
LOT more of these messages recently--with their deleterious effects on
scripting. Hamish says they've been there all along. I'm suspecting that the
code for the message has existed, but they did not get parsed for some
reason. But that is just speculation.

Well in this case, there is a change by Daniel dated Jan. 28 which might be linked:

- Added quotes in occurences of 'if [ -z "$var" ]'

But reverting back to no quotes gives the same error message.

Looking at the logic, I don't actually understand how this worked before. As I said, IIUC the x-mon test seems to be done whether you are using GIS Manager or not. But under GIS Manager there should be no x-mon...

Conditonalising the check as follows:

if [ "$GIS_FLAG_S" -eq 0 ] ; then
   if [ -z "$currmon" ] ; then
         echo ""
         echo "*** You must open a display monitor ***"
         echo ""
         cleanup
         exit 2
   fi
fi

makes the error message go away, but I get a new one:

Usage: /usr/lib/grass/etc/mon.select monitor_name

This time, however, the map and legend are displayed correctly (without the "fix" only the legend is displayed). I can get this second error message to go away by commenting line 862:

# d.mon select=$currmon

This comes from the fact that $currmon is empty in GIS Manager. Again, I don't understand why we have to deal with d.mon here if we are in the GIS Manager...and why this did not cause any problems before.

Moritz

Michael

On 2/13/07 6:19 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

Michael,

I am seeing a new error for d.vect.thematic. Trying to display a
thematic layer fails with the message: *** You must open a display
monitor ***

I can reproduce this with any spearfish vector layer.

The problem seems to be in lines 336-345 where it checks for the
existance of an x-monitor. It seems to do this unconditionally, so even
if you run it from the GIS Manager it still checks and fails if there is
not monitor.

I can't find anything recent in the commit logs that would explain this,
so before trying to go deeper into it, I wanted to know if you had an
idea why this is suddenly happening.

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

4

There should be a flag to send output to the gis manager. This flag should
cause this conditional to be skipped.

Michael

On 2/13/07 7:58 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 13/02/07 15:29, Michael Barton wrote:

I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a
LOT more of these messages recently--with their deleterious effects on
scripting. Hamish says they've been there all along. I'm suspecting that the
code for the message has existed, but they did not get parsed for some
reason. But that is just speculation.

Well in this case, there is a change by Daniel dated Jan. 28 which might
be linked:

- Added quotes in occurences of 'if [ -z "$var" ]'

But reverting back to no quotes gives the same error message.

Looking at the logic, I don't actually understand how this worked
before. As I said, IIUC the x-mon test seems to be done whether you are
using GIS Manager or not. But under GIS Manager there should be no x-mon...

Conditonalising the check as follows:

if [ "$GIS_FLAG_S" -eq 0 ] ; then
   if [ -z "$currmon" ] ; then
         echo ""
         echo "*** You must open a display monitor ***"
         echo ""
         cleanup
         exit 2
   fi
fi

makes the error message go away, but I get a new one:

Usage: /usr/lib/grass/etc/mon.select monitor_name

This time, however, the map and legend are displayed correctly (without
the "fix" only the legend is displayed). I can get this second error
message to go away by commenting line 862:

# d.mon select=$currmon

This comes from the fact that $currmon is empty in GIS Manager. Again, I
don't understand why we have to deal with d.mon here if we are in the
GIS Manager...and why this did not cause any problems before.

Moritz

Michael

On 2/13/07 6:19 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

Michael,

I am seeing a new error for d.vect.thematic. Trying to display a
thematic layer fails with the message: *** You must open a display
monitor ***

I can reproduce this with any spearfish vector layer.

The problem seems to be in lines 336-345 where it checks for the
existance of an x-monitor. It seems to do this unconditionally, so even
if you run it from the GIS Manager it still checks and fails if there is
not monitor.

I can't find anything recent in the commit logs that would explain this,
so before trying to go deeper into it, I wanted to know if you had an
idea why this is suddenly happening.

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

5

On 13/02/07 16:06, Michael Barton wrote:

There should be a flag to send output to the gis manager. This flag should
cause this conditional to be skipped.

The flag is $GIS_FLAG_S:

On line 860ff you have this:
# reset rendering for GUI use
      if [ "$GIS_FLAG_S" -eq 1 ] ; then
[...]
        d.mon select=$currmon
[...]
fi

In my understanding, unless someone works in parallel with GIS Manager and x-mons, $currmon will be empty and this is where this error message comes from.

Maybe it's just a problem of an unequal number of if and fi calls...

But I don't have the time to go into the file in detail now...sorry.

Moritz

Michael

On 2/13/07 7:58 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 13/02/07 15:29, Michael Barton wrote:

I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a
LOT more of these messages recently--with their deleterious effects on
scripting. Hamish says they've been there all along. I'm suspecting that the
code for the message has existed, but they did not get parsed for some
reason. But that is just speculation.

Well in this case, there is a change by Daniel dated Jan. 28 which might
be linked:

- Added quotes in occurences of 'if [ -z "$var" ]'

But reverting back to no quotes gives the same error message.

Looking at the logic, I don't actually understand how this worked
before. As I said, IIUC the x-mon test seems to be done whether you are
using GIS Manager or not. But under GIS Manager there should be no x-mon...

Conditonalising the check as follows:

if [ "$GIS_FLAG_S" -eq 0 ] ; then
   if [ -z "$currmon" ] ; then
         echo ""
         echo "*** You must open a display monitor ***"
         echo ""
         cleanup
         exit 2
   fi
fi

makes the error message go away, but I get a new one:

Usage: /usr/lib/grass/etc/mon.select monitor_name

This time, however, the map and legend are displayed correctly (without
the "fix" only the legend is displayed). I can get this second error
message to go away by commenting line 862:

# d.mon select=$currmon

This comes from the fact that $currmon is empty in GIS Manager. Again, I
don't understand why we have to deal with d.mon here if we are in the
GIS Manager...and why this did not cause any problems before.

Moritz

Michael

On 2/13/07 6:19 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

Michael,

I am seeing a new error for d.vect.thematic. Trying to display a
thematic layer fails with the message: *** You must open a display
monitor ***

I can reproduce this with any spearfish vector layer.

The problem seems to be in lines 336-345 where it checks for the
existance of an x-monitor. It seems to do this unconditionally, so even
if you run it from the GIS Manager it still checks and fails if there is
not monitor.

I can't find anything recent in the commit logs that would explain this,
so before trying to go deeper into it, I wanted to know if you had an
idea why this is suddenly happening.

Moritz

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

6

Hi Michael, Moritz.

I'll look at it when I get home. That's in about 10 hours.

Daniel.

BTW did you try d.vect.thematic for >20 categories? Legends now do
have their nice cut in the middle.

On 2/13/07, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 13/02/07 16:06, Michael Barton wrote:
> There should be a flag to send output to the gis manager. This flag should
> cause this conditional to be skipped.

The flag is $GIS_FLAG_S:

On line 860ff you have this:
# reset rendering for GUI use
      if [ "$GIS_FLAG_S" -eq 1 ] ; then
[...]
        d.mon select=$currmon
[...]
fi

In my understanding, unless someone works in parallel with GIS Manager
and x-mons, $currmon will be empty and this is where this error message
comes from.

Maybe it's just a problem of an unequal number of if and fi calls...

But I don't have the time to go into the file in detail now...sorry.

Moritz

>
> Michael
>
> On 2/13/07 7:58 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
>
>> On 13/02/07 15:29, Michael Barton wrote:
>>> I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a
>>> LOT more of these messages recently--with their deleterious effects on
>>> scripting. Hamish says they've been there all along. I'm suspecting that the
>>> code for the message has existed, but they did not get parsed for some
>>> reason. But that is just speculation.
>> Well in this case, there is a change by Daniel dated Jan. 28 which might
>> be linked:
>>
>> - Added quotes in occurences of 'if [ -z "$var" ]'
>>
>> But reverting back to no quotes gives the same error message.
>>
>> Looking at the logic, I don't actually understand how this worked
>> before. As I said, IIUC the x-mon test seems to be done whether you are
>> using GIS Manager or not. But under GIS Manager there should be no x-mon...
>>
>> Conditonalising the check as follows:
>>
>> if [ "$GIS_FLAG_S" -eq 0 ] ; then
>> if [ -z "$currmon" ] ; then
>> echo ""
>> echo "*** You must open a display monitor ***"
>> echo ""
>> cleanup
>> exit 2
>> fi
>> fi
>>
>> makes the error message go away, but I get a new one:
>>
>> Usage: /usr/lib/grass/etc/mon.select monitor_name
>>
>> This time, however, the map and legend are displayed correctly (without
>> the "fix" only the legend is displayed). I can get this second error
>> message to go away by commenting line 862:
>>
>> # d.mon select=$currmon
>>
>> This comes from the fact that $currmon is empty in GIS Manager. Again, I
>> don't understand why we have to deal with d.mon here if we are in the
>> GIS Manager...and why this did not cause any problems before.
>>
>> Moritz
>>
>>> Michael
>>>
>>> On 2/13/07 6:19 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
>>>
>>>> Michael,
>>>>
>>>> I am seeing a new error for d.vect.thematic. Trying to display a
>>>> thematic layer fails with the message: *** You must open a display
>>>> monitor ***
>>>>
>>>> I can reproduce this with any spearfish vector layer.
>>>>
>>>> The problem seems to be in lines 336-345 where it checks for the
>>>> existance of an x-monitor. It seems to do this unconditionally, so even
>>>> if you run it from the GIS Manager it still checks and fails if there is
>>>> not monitor.
>>>>
>>>> I can't find anything recent in the commit logs that would explain this,
>>>> so before trying to go deeper into it, I wanted to know if you had an
>>>> idea why this is suddenly happening.
>>>>
>>>> Moritz
>>> __________________________________________
>>> Michael Barton, Professor of Anthropology
>>> School of Human Evolution & Social Change
>>> Center for Social Dynamics & Complexity
>>> Arizona State University
>>>
>>> phone: 480-965-6213
>>> fax: 480-965-7671
>>> www: http://www.public.asu.edu/~cmbarton
>>>
>
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>

--
-- Daniel Calvelo Aros

7

Sorry for the awful delay. I think the problems with d.mon select are
resolved; please test. I also made the legend cuts work for ps.map and
display managers. In CVS.

Daniel.

On 2/13/07, Daniel Calvelo <dca.gis@gmail.com> wrote:

Hi Michael, Moritz.

I'll look at it when I get home. That's in about 10 hours.

Daniel.

BTW did you try d.vect.thematic for >20 categories? Legends now do
have their nice cut in the middle.

On 2/13/07, Moritz Lennert <mlennert@club.worldonline.be> wrote:
> On 13/02/07 16:06, Michael Barton wrote:
> > There should be a flag to send output to the gis manager. This flag should
> > cause this conditional to be skipped.
>
> The flag is $GIS_FLAG_S:
>
> On line 860ff you have this:
> # reset rendering for GUI use
> if [ "$GIS_FLAG_S" -eq 1 ] ; then
> [...]
> d.mon select=$currmon
> [...]
> fi
>
> In my understanding, unless someone works in parallel with GIS Manager
> and x-mons, $currmon will be empty and this is where this error message
> comes from.
>
> Maybe it's just a problem of an unequal number of if and fi calls...
>
> But I don't have the time to go into the file in detail now...sorry.
>
> Moritz
>
> >
> > Michael
> >
> > On 2/13/07 7:58 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
> >
> >> On 13/02/07 15:29, Michael Barton wrote:
> >>> I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a
> >>> LOT more of these messages recently--with their deleterious effects on
> >>> scripting. Hamish says they've been there all along. I'm suspecting that the
> >>> code for the message has existed, but they did not get parsed for some
> >>> reason. But that is just speculation.
> >> Well in this case, there is a change by Daniel dated Jan. 28 which might
> >> be linked:
> >>
> >> - Added quotes in occurences of 'if [ -z "$var" ]'
> >>
> >> But reverting back to no quotes gives the same error message.
> >>
> >> Looking at the logic, I don't actually understand how this worked
> >> before. As I said, IIUC the x-mon test seems to be done whether you are
> >> using GIS Manager or not. But under GIS Manager there should be no x-mon...
> >>
> >> Conditonalising the check as follows:
> >>
> >> if [ "$GIS_FLAG_S" -eq 0 ] ; then
> >> if [ -z "$currmon" ] ; then
> >> echo ""
> >> echo "*** You must open a display monitor ***"
> >> echo ""
> >> cleanup
> >> exit 2
> >> fi
> >> fi
> >>
> >> makes the error message go away, but I get a new one:
> >>
> >> Usage: /usr/lib/grass/etc/mon.select monitor_name
> >>
> >> This time, however, the map and legend are displayed correctly (without
> >> the "fix" only the legend is displayed). I can get this second error
> >> message to go away by commenting line 862:
> >>
> >> # d.mon select=$currmon
> >>
> >> This comes from the fact that $currmon is empty in GIS Manager. Again, I
> >> don't understand why we have to deal with d.mon here if we are in the
> >> GIS Manager...and why this did not cause any problems before.
> >>
> >> Moritz
> >>
> >>> Michael
> >>>
> >>> On 2/13/07 6:19 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
> >>>
> >>>> Michael,
> >>>>
> >>>> I am seeing a new error for d.vect.thematic. Trying to display a
> >>>> thematic layer fails with the message: *** You must open a display
> >>>> monitor ***
> >>>>
> >>>> I can reproduce this with any spearfish vector layer.
> >>>>
> >>>> The problem seems to be in lines 336-345 where it checks for the
> >>>> existance of an x-monitor. It seems to do this unconditionally, so even
> >>>> if you run it from the GIS Manager it still checks and fails if there is
> >>>> not monitor.
> >>>>
> >>>> I can't find anything recent in the commit logs that would explain this,
> >>>> so before trying to go deeper into it, I wanted to know if you had an
> >>>> idea why this is suddenly happening.
> >>>>
> >>>> Moritz
> >>> __________________________________________
> >>> Michael Barton, Professor of Anthropology
> >>> School of Human Evolution & Social Change
> >>> Center for Social Dynamics & Complexity
> >>> Arizona State University
> >>>
> >>> phone: 480-965-6213
> >>> fax: 480-965-7671
> >>> www: http://www.public.asu.edu/~cmbarton
> >>>
> >
> > __________________________________________
> > Michael Barton, Professor of Anthropology
> > School of Human Evolution & Social Change
> > Center for Social Dynamics & Complexity
> > Arizona State University
> >
> > phone: 480-965-6213
> > fax: 480-965-7671
> > www: http://www.public.asu.edu/~cmbarton
> >
>

--
-- Daniel Calvelo Aros

--
-- Daniel Calvelo Aros

8

On 02/03/07 08:59, Daniel Calvelo wrote:

Sorry for the awful delay. I think the problems with d.mon select are
resolved; please test. I also made the legend cuts work for ps.map and
display managers. In CVS.

I get the following error. The line

format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)

seems to be the problem.

Moritz

expected integer but got "1,"
     while executing
"format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)"
     (procedure "GmThematic::tlegend" line 11)
     invoked from within
"GmThematic::tlegend $mon $id"
     (procedure "GmThematic::display" line 72)
     invoked from within
"GmThematic::display $node $mod"
     ("thematic" arm line 2)
     invoked from within
"switch $type {
         group {
             GmGroup::display $node $mod
    }
    raster {
      GmRaster::display $node $mod
    }
    labels {
      GmLabels::disp..."
     (procedure "GmTree::display_node" line 7)
     invoked from within
"GmTree::display_node $n $mod"
     (procedure "GmGroup::display" line 22)
     invoked from within
"GmGroup::display "root" $mod"
     (procedure "MapCanvas::runprograms" line 64)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 38)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

Daniel.

On 2/13/07, Daniel Calvelo <dca.gis@gmail.com> wrote:

Hi Michael, Moritz.

I'll look at it when I get home. That's in about 10 hours.

Daniel.

BTW did you try d.vect.thematic for >20 categories? Legends now do
have their nice cut in the middle.

On 2/13/07, Moritz Lennert <mlennert@club.worldonline.be> wrote:
> On 13/02/07 16:06, Michael Barton wrote:
> > There should be a flag to send output to the gis manager. This flag should
> > cause this conditional to be skipped.
>
> The flag is $GIS_FLAG_S:
>
> On line 860ff you have this:
> # reset rendering for GUI use
> if [ "$GIS_FLAG_S" -eq 1 ] ; then
> [...]
> d.mon select=$currmon
> [...]
> fi
>
> In my understanding, unless someone works in parallel with GIS Manager
> and x-mons, $currmon will be empty and this is where this error message
> comes from.
>
> Maybe it's just a problem of an unequal number of if and fi calls...
>
> But I don't have the time to go into the file in detail now...sorry.
>
> Moritz
>
> >
> > Michael
> >
> > On 2/13/07 7:58 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
> >
> >> On 13/02/07 15:29, Michael Barton wrote:
> >>> I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a
> >>> LOT more of these messages recently--with their deleterious effects on
> >>> scripting. Hamish says they've been there all along. I'm suspecting that the
> >>> code for the message has existed, but they did not get parsed for some
> >>> reason. But that is just speculation.
> >> Well in this case, there is a change by Daniel dated Jan. 28 which might
> >> be linked:
> >>
> >> - Added quotes in occurences of 'if [ -z "$var" ]'
> >>
> >> But reverting back to no quotes gives the same error message.
> >>
> >> Looking at the logic, I don't actually understand how this worked
> >> before. As I said, IIUC the x-mon test seems to be done whether you are
> >> using GIS Manager or not. But under GIS Manager there should be no x-mon...
> >>
> >> Conditonalising the check as follows:
> >>
> >> if [ "$GIS_FLAG_S" -eq 0 ] ; then
> >> if [ -z "$currmon" ] ; then
> >> echo ""
> >> echo "*** You must open a display monitor ***"
> >> echo ""
> >> cleanup
> >> exit 2
> >> fi
> >> fi
> >>
> >> makes the error message go away, but I get a new one:
> >>
> >> Usage: /usr/lib/grass/etc/mon.select monitor_name
> >>
> >> This time, however, the map and legend are displayed correctly (without
> >> the "fix" only the legend is displayed). I can get this second error
> >> message to go away by commenting line 862:
> >>
> >> # d.mon select=$currmon
> >>
> >> This comes from the fact that $currmon is empty in GIS Manager. Again, I
> >> don't understand why we have to deal with d.mon here if we are in the
> >> GIS Manager...and why this did not cause any problems before.
> >>
> >> Moritz
> >>
> >>> Michael
> >>>
> >>> On 2/13/07 6:19 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:
> >>>
> >>>> Michael,
> >>>>
> >>>> I am seeing a new error for d.vect.thematic. Trying to display a
> >>>> thematic layer fails with the message: *** You must open a display
> >>>> monitor ***
> >>>>
> >>>> I can reproduce this with any spearfish vector layer.
> >>>>
> >>>> The problem seems to be in lines 336-345 where it checks for the
> >>>> existance of an x-monitor. It seems to do this unconditionally, so even
> >>>> if you run it from the GIS Manager it still checks and fails if there is
> >>>> not monitor.
> >>>>
> >>>> I can't find anything recent in the commit logs that would explain this,
> >>>> so before trying to go deeper into it, I wanted to know if you had an
> >>>> idea why this is suddenly happening.
> >>>>
> >>>> Moritz
> >>> __________________________________________
> >>> Michael Barton, Professor of Anthropology
> >>> School of Human Evolution & Social Change
> >>> Center for Social Dynamics & Complexity
> >>> Arizona State University
> >>>
> >>> phone: 480-965-6213
> >>> fax: 480-965-7671
> >>> www: http://www.public.asu.edu/~cmbarton
> >>>
> >
> > __________________________________________
> > Michael Barton, Professor of Anthropology
> > School of Human Evolution & Social Change
> > Center for Social Dynamics & Complexity
> > Arizona State University
> >
> > phone: 480-965-6213
> > fax: 480-965-7671
> > www: http://www.public.asu.edu/~cmbarton
> >
>

--
-- Daniel Calvelo Aros

9

Sorry, copy-paste introduced typo by me. Attached patch should fix
problem. Please, test and commit.

Maris.

2007/3/2, Moritz Lennert <mlennert@club.worldonline.be>:

On 02/03/07 08:59, Daniel Calvelo wrote:
> Sorry for the awful delay. I think the problems with d.mon select are
> resolved; please test. I also made the legend cuts work for ps.map and
> display managers. In CVS.

I get the following error. The line

format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)

seems to be the problem.

Moritz

expected integer but got "1,"
     while executing
"format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)"
     (procedure "GmThematic::tlegend" line 11)
     invoked from within
"GmThematic::tlegend $mon $id"
     (procedure "GmThematic::display" line 72)
     invoked from within
"GmThematic::display $node $mod"
     ("thematic" arm line 2)
     invoked from within
"switch $type {
         group {
             GmGroup::display $node $mod
    }
    raster {
      GmRaster::display $node $mod
    }
    labels {
      GmLabels::disp..."
     (procedure "GmTree::display_node" line 7)
     invoked from within
"GmTree::display_node $n $mod"
     (procedure "GmGroup::display" line 22)
     invoked from within
"GmGroup::display "root" $mod"
     (procedure "MapCanvas::runprograms" line 64)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 38)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

(attachments)

thematic.typo.patch (675 Bytes)

10

On 02/03/07 10:42, Maris Nartiss wrote:

Sorry, copy-paste introduced typo by me. Attached patch should fix
problem. Please, test and commit.

Thanks, that was it.
Committed to CVS.

Moritz

Maris.

2007/3/2, Moritz Lennert <mlennert@club.worldonline.be>:

On 02/03/07 08:59, Daniel Calvelo wrote:
> Sorry for the awful delay. I think the problems with d.mon select are
> resolved; please test. I also made the legend cuts work for ps.map and
> display managers. In CVS.

I get the following error. The line

format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)

seems to be the problem.

Moritz

expected integer but got "1,"
     while executing
"format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)"
     (procedure "GmThematic::tlegend" line 11)
     invoked from within
"GmThematic::tlegend $mon $id"
     (procedure "GmThematic::display" line 72)
     invoked from within
"GmThematic::display $node $mod"
     ("thematic" arm line 2)
     invoked from within
"switch $type {
         group {
             GmGroup::display $node $mod
        }
        raster {
            GmRaster::display $node $mod
        }
        labels {
            GmLabels::disp..."
     (procedure "GmTree::display_node" line 7)
     invoked from within
"GmTree::display_node $n $mod"
     (procedure "GmGroup::display" line 22)
     invoked from within
"GmGroup::display "root" $mod"
     (procedure "MapCanvas::runprograms" line 64)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 38)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

------------------------------------------------------------------------

Index: gui/tcltk/gis.m/thematic.tcl

RCS file: /home/grass/grassrepository/grass6/gui/tcltk/gis.m/thematic.tcl,v
retrieving revision 1.25
diff -u -u -r1.25 thematic.tcl
--- gui/tcltk/gis.m/thematic.tcl 22 Feb 2007 15:45:29 -0000 1.25
+++ gui/tcltk/gis.m/thematic.tcl 2 Mar 2007 09:39:41 -0000
@@ -619,7 +619,7 @@
    if { [winfo exists .tlegend($mon,$id)] } {return}
- set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)]
+ set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon $opt($id,1,map)]
   toplevel .tlegend($mon,$id)
     wm title .tlegend($mon,$id) $legendtitle

11

Thanks much Moritz

Michael

On 3/2/07 3:20 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On 02/03/07 10:42, Maris Nartiss wrote:

Sorry, copy-paste introduced typo by me. Attached patch should fix
problem. Please, test and commit.

Thanks, that was it.
Committed to CVS.

Moritz

Maris.

2007/3/2, Moritz Lennert <mlennert@club.worldonline.be>:

On 02/03/07 08:59, Daniel Calvelo wrote:

Sorry for the awful delay. I think the problems with d.mon select are
resolved; please test. I also made the legend cuts work for ps.map and
display managers. In CVS.

I get the following error. The line

format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)

seems to be the problem.

Moritz

expected integer but got "1,"
expected integer but got "1,"
     while executing
"format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)"
     (procedure "GmThematic::tlegend" line 11)
     invoked from within
"GmThematic::tlegend $mon $id"
     (procedure "GmThematic::display" line 72)
     invoked from within
"GmThematic::display $node $mod"
     ("thematic" arm line 2)
     invoked from within
"switch $type {
         group {
             GmGroup::display $node $mod
        }
        raster {
            GmRaster::display $node $mod
        }
        labels {
            GmLabels::disp..."
     (procedure "GmTree::display_node" line 7)
     invoked from within
"GmTree::display_node $n $mod"
     (procedure "GmGroup::display" line 22)
     invoked from within
"GmGroup::display "root" $mod"
     (procedure "MapCanvas::runprograms" line 64)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 38)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

------------------------------------------------------------------------

Index: gui/tcltk/gis.m/thematic.tcl

RCS file: /home/grass/grassrepository/grass6/gui/tcltk/gis.m/thematic.tcl,v
retrieving revision 1.25
diff -u -u -r1.25 thematic.tcl
--- gui/tcltk/gis.m/thematic.tcl 22 Feb 2007 15:45:29 -0000 1.25
+++ gui/tcltk/gis.m/thematic.tcl 2 Mar 2007 09:39:41 -0000
@@ -619,7 +619,7 @@

if { [winfo exists .tlegend($mon,$id)] } {return}

- set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon,
$opt($id,1,map)]
+ set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon
$opt($id,1,map)]
toplevel .tlegend($mon,$id)
     wm title .tlegend($mon,$id) $legendtitle

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton