Menu
▾
▴
#2932 Last filetype sometimes selected as default on Windows
open
5
2012-09-11
2011-10-10
No
I'm using Tcl/Tk on Linux, Windows and Mac OS, and the file type that is selected by default changes depending on the platform. On Linux, the first file type is selected, while the last one is on the other platforms. I think the behavior on Linux is wrong, since examples of code I could find on the Web all use the last type for most generic filters. Anyway, the behavior should be consistent across platforms.
I'm using Tk 8.5.9 on Fedora 15.
Steps to reproduce:
$ wish
% tk_getOpenFile -filetypes "{First {*.a}} {Last {*.b}}"
Consistency would be a good thing to aim for, but I thought the type is usually selected by the extension on the default name. Or is this just in the case where there's no other evidence to provide a better guess at default?
I don't understand. What do you mean by "type is usually selected by the extension on the default name"? If you mean the the default file name, then there isn't, since we're tying to *open* a file, not save it.
Still present on Fedora 17 with Tk 8.5.11.
Any chance to get some attention for this bug? It's probably quite trivial to fix for somebody knowing the code base (just reverse the list on one of the platforms). I'd be happy to try if you give me some guidance.
Your testing is somewhat suspect; OSX and Windows use the first item in the list by default. I just tested using the code you supplied. Tk is therefore being consistent across platforms, and I can't see anything to be fixed.
Either provide evidence of what we should be consistent with (we can easily change things if there's a good reason) or this bug will auto-close.
Sorry - I assumed too quickly that the Linux order was wrong, so I did not test wish on Windows. The incorrect behavior only happens when calling tkGetOpenFile() from the R statistical environment. The exact command is:
library(tcltk)
tkgetOpenFile(filetypes="{First {*.a}} {ALast {*.b}}")
This could be a bug in R, of course, but there are two reasons why I _suspect_ that the problem might be more general:
- R merely passes on the "{First {*.a}} {ALast {*.b}}") string to Tcl, so the order is not likely to be affected.
- The Windows open file dialog used by R and wish are different, which means two different code paths/APIs may be used. See the screenshot I'm uploading (this is on Windows Server 2008): on the left, R and the window it oepns; on the right, wish.
Screenshot of dialogs opened by R and Wish on Windows Server 2008
Ping? Do you see what could explain the difference between the two dialogs on Windows? Sorry if that's a bug in R, but I think they merely build Tcl/Tk, they don't adapt it. Thanks!
I've tried it on a number of platforms, both ones that use the native system dialog and ones that use the scripted one. They all seem to pick the first item in the list by default (I've not checked what order the list is put on the screen, but that's like totally trivial; never pick by position in a GUI, but by name and/or function). That looks consistent to me.
What is there to change? What should we be conforming to? Without knowing that, we can't even begin to figure out what the problem is!
Sorry, if I could give you more details I would, but I'm not familiar of Windows API. From what in learned in previous comments, Tk does not need to conform to a different behaviour: there simply seems to be a small bug where the ordering is not respected, i.e. the last item is selected by default instead of the first one. Maybe this is due to the way R builds Tk, I cannot tell.
What do you mean by "native system dialog" and "scripted one"? What I'm wondering is whether you are able to create the two different open dialog types that are visible on the screenshot I've attached. Do you know what difference there is between them (API calls, library version...)? Thanks for you help!
OK, I've dug a little to find out what happens, and at least I can make things more explicit. In the attached screenshot, the dialog on the right, which is created by wish, is the old-style Windows open/save dialog triggered by GetOpenFileName(). On the left, the dialog is created by R's tcltk package, and it is using the "new" open/save dialogs initiated in Vista; these can appear in response to GetOpenFileName(), or to the new IFileDialog API, depending on the libs you link to and whether you customize or not the dialog. See [1].
AFAICS, Tk only calls GetOpenFileName(). But depending on how it is built, Vista may open the "new" dialogs, normally without changing anything to the API, but... Maybe R is built in a way that allows these new dialogs to be used, and this triggers a small bug, possibly because setting the order relies on an unwarranted assumption?
If I'm not mistaken, MakeFilter() in tkWinDialog.c does not set the initial filter explicitly *if* its initialPtr argument is NULL, which is the case if no FILE_TYPEVARIABLE argument was passed to tkGetOpenFile(). So this means the default filter is left to the decision of the Win API, and I could not find an explicit mention of how the default is chosen in the "new" dialogs [2], while the first filter was explicitly chosen according to the "old" API [3]. So this can perfectly be the source of the bug.
One thing that wouldn't hurt would be to set the default filter to 1 (the first) anyways, and to overwrite this value if FILE_TYPEVARIABLE is passed to tkGetOpenFile(). That would ensure no random changes can happen.
1: http://www.codeproject.com/Articles/16678/Vista-Goodies-in-C-Using-the-New-Vista-File-Dialog
2: http://msdn.microsoft.com/en-us/library/bb775980%28v=vs.85%29.aspx
3: http://msdn.microsoft.com/en-us/library/ms646839%28v=vs.85%29.aspx
Assigning to someone who knows much more than me about things on Windows. (I have a Windows system which has ActiveTcl on it, but it's not got a toolchain and I don't really grok the Win API too well either.)