tk_getSaveFile/tk_getOpenFile on Dual Monitors and -x -y Specification

[Sue]

Okay, I have two questions, which are related to the tk_getSaveFile/
tk_getOpenFile. When I am using dual monitors and I bring up the
tk_getSaveFile/tk_getOpenFile through the Wish console from the
secondary monitor, the tk_getSaveFile/tk_getOpenFile dialog comes up
on my primary monitor. I am specifying the -parent argument as "."
since I am calling directory from Wish console. Is there a way to
direct the dialog to come up on the monitor that has the calling
window?

Also I saw that there is a -x/-y specification available for
tk_getSaveFile/tk_getOpenFile command. It isn't documented, but if
you type an incorrect option, it will come up in the Wish console as
inline help:

tk_getSaveFile -title "Key-Command Mappings Export" -parent $_window -
defaultextension ".tcl" -filetypes {{{TCL Scripts} {.tcl}}} -
no_such_arg
bad option "-no_such_arg": must be -defaultextension, -filetypes, -
initialdir, -initialfile, -parent, -title, -typevariable, -x, -y, or -
standard.

If I try to use the -x/-y options to manually set the location when
calling tk_getSaveFile/tk_getOpenFile, it works the first time. But
then when I close the window and try again, it ignores the x/y
specification and places the window at the last known location of the
previous tk_getSaveFile/tk_getOpenFile window. Is this a bug or are
these options unsupported options?

Thanks in advance,
Sue

[Donal K. Fellows]

On 07/05/2012 17:34, Sue wrote:
> Is this a bug or are these options unsupported options?

They're unsupported. :-) The issue is that they're only used when
creating the window, but Tk reuses the built dialog as much as it can
for efficiency. They're also non-portable; the Windows and OSX native
dialogs don't give that level of control at all (and get it right
anyway, modulo the respective platforms' definition of what that is).

The good news is that the deep issue (wrong default placement on multi-
monitor setups) will be fixed in the next version of Tk; this is a key
part of Bug 533519 <http://sf.net/support/tracker.php?aid=533519>. (The
embarrassing part was how long we took to fix the bug...)

Donal.