Windows XP to me has a very special sense of humour
when it comes to what to set as initial directory for
the file open dialog. See 'lpstrInitialDir' on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/CommonDialogBoxLibrary/CommonDialogBoxReference/CommonDialogBoxStructures/OPENFILENAME.asp
This patch forces the dialog to always open in the
current directory. So now, if you change the directory
via 'cd' the file open dialog opens where I would
expect it to.
On the other hand this introduces the alien concept of
a 'current directory' to the common windows user, who
are used to the weird windows behaviour.
initial patch
Logged In: YES
user_id=1333817
Confirmed working as expected, but I have no strong opinion
whether it is the expected behaviour. Can be included in 4.2.
Logged In: YES
user_id=1333817
Confirmed working as expected, but I have no strong opinion
whether it is the expected behaviour. Can be included in 4.2.
Logged In: YES
user_id=31505
I think this patch should come in, if it makes gnuplot on
WXP compatible to gnuplot on other W*.
Notes:
1. Please change CRLF => LF in your patch.
2. When compiled by mingw, the compiler reports:
win/wmenu.c: In function `SendMacro':
win/wmenu.c:402: warning: passing arg 1 of `_getcwd' from
incompatible pointer type
Please fix this.
Logged In: YES
user_id=27517
The problem, Petr, is that there are two wildly conflicting
goals here. Should wgnuplot behave like gnuplot on other
platforms, or should it feel like a typical Windows
application? Both positions have strong arguments speaking
for them. The code has behaved as it does now since just
about forever, and hardly anybody found that behaviour
strange enough to complain to us about it.
As I've said before about this issue, Microsoft has gone to
such trouble to come up with this unbelievably bizarre
behaviour that we really shouldn't deprive users from
reaping its benefit in the fullest. People believe M$ is a
good thing --- let them get what they asked for.
IMHO this is not a decision to be taken lightly, on a tight
schedule. This can easily wait till after the release. I'm
rating this down to priority 5 on that basis.
Logged In: YES
user_id=31505
As I understand from the patch report, this patch makes
wgnuplot's "Open" menu item on Windows XP working in the
same way on other versions of Windows. I've tried the patch
on Wine, and I don't see any different behaviour between
patched and unpatched wgnuplot's. So it is a WXP-specific
fix (someone else can proove it?), that's why it should go
in. (Note: WXP was a very fresh software when gnuplot 4.0
appeared.)
Logged In: YES
user_id=27517
> As I understand from the patch report, this patch makes
> wgnuplot's "Open" menu item on Windows XP working
> in the same way on other versions of Windows.
Not really. It would make wgnuplot behave like non-Windows
gnuplot, and completely different than wgnuplot used to
behave until now, on any version of Windows.
And no, it's not a "WXP-specific fix". It's not a fix at
all. It's a deliberate change of a behaviour that's not
broken. And I really think this is not the time to check in
such changes.
Logged In: YES
user_id=235620
Revisit post-4.2
Logged In: YES
user_id=1180072
Oter platforms do not even have a "file open" dialog. So
in no way wgnuplot can behave like other platforms in
this respect.
But anyway consistency is a good thing in my opinion. ;)
Look at the following example: Let's say a user changes
directory using the "cd" command or the "change directory"
dialog. The he would like to "load" a certain file.
Wgnuplot does not have command line completion so he
opts for the dialog. But wait: that shows a completely
different directory. :(
I think that behaviour is broken. In fact it annoys me
quite a bit. And yes, its a change in behaviour. And yes,
it really is specific to 2000/XP in the case described
above. Microsoft changed the behaviour of it's dialog
(see the link in my original post), which makes it
inconsistent with gnuplot current directory. That may
just as well be a called a fix then.
I still vote for inclusion in 4.2.
Logged In: YES
user_id=31505
I propose to submit the patch into cvs (now, not after 4.2...).
Logged In: YES
user_id=31505
Committed to cvs.