Hello all
I returned to this problem because I noticed there was still some unpredictable behaviour on Windows and we never really solved it.
On Sun, 20 May 2007, Michael Barton wrote:
It seems like the issue is that this method to check to see if a variable
has been set won't work under windows.
if {[info exists VAR]} { do something }
Yes indeed. After a bit more web searching I found some discussion of a specific problem with using "info exists" on the env array on Windows. Seemingly related to the fact that Windows handles the unsetting of an environment variable by setting it to an empty string, and the way Tcl maps the env array directly to the environment on the system it is running on gets confused by this.
Maybe if I wrap it in a catch statement...? Anyone have a suggestion about
this.
Yes, exactly! That was the workaround that was suggested in the discussion thread I found:
Change
[info exists env(GRASS_FONT)]
to
![catch {set env(GRASS_FONT)}]
This works because set env(GRASS_FONT) tries to read the variable - if it doesn't exist, throws an exception, which is caught by the catch command. And if there is no catch (! negation operator used), then it means the variable does actually exist.
If the diagnosis is correct, it is a fairly major projblem. This same method
of testing if a variable exists is sprinkled throughout the GUI code, so we
need to find an alternative. I don't know what it would be at the moment.
It seems the problem is specifically related to using info exists on the env array on Windows. So not too widespread. I have changed all the occurences in gis.m to the workaround and committed it to CVS.
I also changed the text of the font selection box from "Select default font for GRASS displays" to "Select GRASS display font", as the former text was quite confusing seeing as the font select box is also used in the widgets for d.text, d.histogram etc. to select a temporary fault to override the default. I also found a related bug there, which I now know how it's caused but don't know enough Tcl/Tk to fix it:
When clicking the font button in d.histogram for example, it will default to having the default font (loaded from the GRASS_FONT environment variable) selected, not the last font that was selected for d.histogram - a little confusing there, but not a big deal. However the main problem is that if you just click OK here, you would expect the font that was displayed as selected in the select box to be set as the font for d.histogram to use. But it is not, unless you first go and click on it (and nothing *appears* to change, because it was already selected). Very confusing. The reason seems to be that the command that sets the font to the one selected is bound to the <<ListboxSelect>> event, which is only triggered when the font selection is *changed*. Clicking on it again triggers this event, but it's not reasonable to expect users to do that when it already is selected. I think it would be more logical (and solve this problem) if the command that sets the font from the select box was instead bound to the OK button, but I don't know enough to see how to change this...
Paul
