Moritz, I'm glad that you've been able to verify the select issue and find out more about how it happens.
There have been no changes to gis.m that might cause this as far as I know. I made some changes to select.tcl several months back to fix the multi-select option that had been broken by updates several months before that. In the part that I changed, I replaced unix-based regexp statements with pure TclTk list parsing. If anything, this should make the selection tools work better with Windows. But this all was some time ago. If there have been any changes by others that might cause this, I'm not aware of them. We've now encountered a couple of other items, even though select is working, at least in some settings. It appears that r.mapcalc is NOT working. We get an error with even the simplest of mapcalc statements. Javi will send the error message tonight or tomorrow, but it is a red herring IMHO, stating that it is missing an "=". We have the same error if we run r.mapcalc via the TclTk interface (r.mapcalculator) or run it from the console command line. Other commands work find from the console command line. This is *critical*, of course, as r.mapcalc is very important to GRASS analysis and map management. Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy anything from the error message box or even make the box bigger so as to show more of the error details. Is there a way to log this to send to you, as it is quite long? Interestingly, we are getting the *same* error produced by v.in.db when running r.contour. We did NOT get an error running r.to.vect, v.in.region, or v.random. So it is not just something that happens anytime we try to create a vector. Maybe this is helpful. Thanks for taking the time to help troubleshoot this. Michael On 11/10/07 5:10 PM, "Moritz Lennert" <[EMAIL PROTECTED]> wrote: > On Sat, November 10, 2007 17:37, Michael Barton wrote: >> We tried installing twice the old way. Then when Isaac had him install the >> other way, it worked. Isaac said that there were some files preceded by 2 >> dots (i.e., ..file) that *didn't* get copied the first times. He is >> guessing >> that there are some Unix files that don't get installed properly under XP >> by >> simply opening the zip file and dragging the content. It needs to be >> completely unzipped. >> > > Today, I suddenly have seen the problem appear and I don't really > understand where this comes from: > > The only situation where I get the select window to work, is when I launch > grass via a shortcut to the grass63.bat and this shortcut is configured to > use c:\ as the working directory. Any other working directory (including > the default of the shortcut which is c:\grass\bin) gives me the empty > select window Javi as been seeing. The same when I click directly on > c:\grass\bin\grass63.bat. When I start grass in text mode and then launch > gis.m from the command line, it is exactly the same: I can only see the > maps in the select window if the current directory is c:\ when I launch > gis.m. > > So it seems to be linked to gis.m. Have there been any changes recently > that might explain this ? I have never even worried about the working > directory before, except for testing whether setting %USERPROFILE% in the > shortcut properties works and it did at the time. Now it doesn't > anymore... > > Javi and Michael, could you also test whether this corresponds to what is > happening in your case ? > > Moritz > __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies 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 _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
