Ethereal-users: Re: [Ethereal-dev] Re: [Ethereal-users] error opening C:\Program Files\Ethereal-

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Wed, 17 Dec 2003 07:44:30 +0100
Guy Harris wrote:


On Dec 15, 2003, at 5:59 PM, Ian Schorr wrote:

I could be wrong, but it looks like the way the code's written, it also will error if the pref that it read in differs from default value (current ethereal dir + "asn1/default.tt"). The code actually gets the same error either way (file does not exist), but doesn't report the error unless the Ethereal dir in the pref is different than the dir you're running Ethereal out of.


The goal was to arrange that if you explicitly specified a file, you'd get an error if the file didn't exist, but if you left it as the default, it'd just drive on silently.

Unfortunately, the only way it has to determine whether you explicitly specified a file is to see whether the value from the preference file is the default. The preferences code doesn't indicate whether a given preference was actually set in the preferences file or not.

Arguably, it should, *and* that indication should be set if the user explicitly changes a preference, *and* any preference the user hasn't explicitly set should *not* be written to the preferences file.

Unfortunately, that doesn't provide any mechanism for explicitly saying "I want this particular preference item to revert to the default setting" other than "edit your preference file by hand and remove the item". We could have a "reset to default" button that resets *all* settings, but that's a bit of a crude mechanism.

Also, that raises the question of whether the default should be the compiled-in defaults or the compiled-in defaults *as overridden by any global preference setting*.

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev

Yesterday, I've changed the path seperator in "asn1/default.tt" to the GLIB define, so it will use the correct backslash on win32 systems.

This *seems* to fix the problem, at least on my machine.

Regards, ULFL