tk_getOpenFile , a Tk command, presents a dialog to the user in order to open or save files.
tk_getOpenFile is usually associated with Open in the File menu. Its purpose is for the user to select an existing file. If the user enters an non-existent file, the dialog box gives the user an error prompt and requires the user to give an alternative selection. If an application allows the user to create new files, it should do so by providing a separate New menu command.
On Windows, a native file selector is used. You can get the Tcl-coded "original" as used on Unix/Linux by explicitly calling:
set filename [::tk::dialog::file:: open arg arg..]
Note that the command name is the empty string in its namespace. Any other value than open for the first argument calls the equivalent of tk_getSaveFile. (RS)
Some folks on Windows use a script version of tk_getOpenFile/tk_getSaveFile because there is an odd Windows bug that can cause your application to misbehave. If you double-click to select a file name, the dialog consumes only 1.5 clicks (<down><up><down>), then the dialog closes, and the remaining 0.5 click (<up> event) gets delivered to whatever widget was underneath. This can cause buttons to activate or focus to change. You might want to Drain The Event Queue. Note that this is bug 611615, fixed in Tk 8.4.8.
bll 2020-2-7: A little helper procedure to set the fonts appropriately for tk_get(Open|Save)File.
proc getOpenFileHelper { {count 0} } {
font configure TkDefaultFont -size 11
if { $count > 2 } {
# probably not linux
return
}
if { ! [info exists ::tk::dialog::file::__tk_filedialog] } {
after 100 ::uiutils::getOpenFileHelper [incr count]
return
}
$::tk::dialog::file::__tk_filedialog(dirMenu) configure -font TkDefaultFont
$::tk::dialog::file::__tk_filedialog(ent) configure -font TkDefaultFont
$::tk::dialog::file::__tk_filedialog(typeMenu) configure -font TkDefaultFon$
$::tk::dialog::file::__tk_filedialog(icons) configure -font TkDefaultFont
}
after idle ::getOpenFileHelper
set fn [tk_getOpenFile ...]tkfbox is a nifty little portable bundle for extending get{Open,Save}File capabilities.
This grabbed my attention because of my recent TIP regarding sub-classing the file dialogs on UNIX (well, non-Windows platforms). But there isn't enough documentation to tell what the benefits of this file are. -- CLN 2001-10-19
tkfbox was originally from sun, but partially reworked by me (Mick O'Donnell). I was recently asked why I used it rather than the now standard tk_getOpenFile/tk_getSaveFile. Well, I have so far found 4 advantages of pure the tcl/tk code versions:
DKF: As the maintainer of (the script versions of) the standard dialogs, I'd love to have suggestions of how to improve them, so long as these improvements are things that are not too hostile to operating in a cross-platform manner (note that the official script-level API is pretty-much fixed; the Windows native dialogs are not very capable!)
MGS: With tk_getSaveFile and tk_chooseDirectory, you should be able to create directories.
DLR: Suggestions for improvement: Change the default icons for folders and files, they look rather ugly. I use the ones that come with BWidgets. Ability to select multiple files.
JBR 2003-09-08: I have extended the tkfbox code to include some new options. You can find it here: [L1 ]
-blueplate separates the dirs into one IconList and the files into another.
-colormap allows the file dialog to use the colormap of a parent window.
-dirslist take a list of "standard" directories and puts them at the top of the dir popup.
-filetype enables a secret global parameter controlled by an additional file type popup menu.
-infoproc an experimental feature to allow a proc to be called when the button one is pressed and help over an item.
I have just recently merged these extensions with the 8.4 tkfbox that allows multiple files to be selected. We use all these extended options in the ds9 image display program. The idea with the info proc feature is to allow the user to get some more info about the file before commiting to opening it. In the case of our image files a single image may contain many images of various types, the info proc can display additional data about where and when the images in the file were obtained and popup a menu allowing the user to select and image within the file.
2005-04-27 - I would like to use something like a 'tooltip' to display the modification date when the cursor is placed over file names in the tk_getOpenFile dialog box. Any suggestions on how to approach this would be appreciated.
MG 2005-04-28: See the page balloon help for some basic code for doing them. To explain it basically, though, you just need to bind to the label widgets (or whatever's used) listing the file names, for <Enter> and <Leave>. On the <Enter> binding, you create a toplevel widget with the decorations off (using wm overrideredirect), and pack a label widget inside the toplevel with the info you want (which can be obtained with clock format [file mtime $file]). Then bind to the <Leave> event, and have that binding destroy your new toplevel widget. If you need any more help with it, post back, and I'll take a look at the code for it and throw an example together.
Might this be something worth adding as standard? On Windows XP, for instance, moving over a file (in tk_getOpenFile or Explorer, etc) shows a tooltip with "Type" (probably not much use on other platforms?), the Modified date, and the file size. (Oh, for shortcuts, it just shows the directory of the file linked to, either relatively if it's below the directory the shortcut itself is in, or absolutely, otherwise.)
MG adds, a couple of hours later: I played around with this a little, and added tooltips to it. They look pretty crude, but it's easy enough to edit. The code is probably quite crude too, though (I guessed largely at how some of the internals, particularly for option parsing, worked), but it does at least seem to work. It's a complete replacement for the tkfbox.tcl file included in $tclHome/lib/tk8.4/ (mine is from ActiveTcl 8.4.9) - if you just save it, and source it before using tk_getOpenFile, it'll have the changes. Some primitive docs are at the bottom of the page. (On Windows XP, where I tested it, it doesn't pick up shortcuts properly, because file type doesn't recognise them.) You can find the file on my website, here: [L2 ] Oh, incidently, it should work as tk_getSaveFile, too, though I didn't test it as such.
I tried the code from MG's reference above - looks like the file was truncated, but after comparing it with the standard tkfbox.tcl (thanks for the reference!) and pasting in the remainder of the file, the example ran and I'm able to tweak the changes a bit for personal preferences. Thanks for the help!
MG: Woops :) It's no longer truncated. If you've made any changes to the tooltip that improve the appearance (I basically got it working and didn't go any further), feel free to add the changes here or email me them ([email protected]) and I'll add them into the code on my site, if you'd like to.
LES 2005-09-09: When I select files with tk_getOpenFile, I can select .DOC files in the drop-down box and have all and only *.DOC files visible, ready for selection.
Or I can select .RTF files in the drop-down box and have all and only *.RTF files visible, ready for selection.
Or I can select * files in the drop-down box and have ALL FILES WHATSOEVER visible, ready for selection.
How do I get both and only .DOC and .RTF files available for selection?
RS:
tk_getOpenFile -filetypes {{Text {.doc .rtf}}}DRS 2006-11-16: Is there a way to get the dialog to sort the filenames by date? I did find [L3 ] tip #271 with an improved dialog but I need a cross-platform solution that doesn't require a custom version of tcl/tk.
TML 2008-07-07: I tried to access ::vfs::urltype mounted ftp files served by ::ftpd via tk_getOpenFile, which works fine on Linux, but fails on Windows. Am I right to suppose the native Windows getOpenFile dialog just doesn't go with VFS at all? As a workaround, I'm using the undocumented "::tk::dialog::file:: open ..." which creates the Unix tk_getOpenFile dialog on all platforms. (There's an intentional blank before the "open" - the proc name really is the empty string!)
MG: That's correct. On Windows (and MacOS, I think?) a native dialog is called by tk_getOpenFile, which can't see inside a VFS. The ::tk::dialog::file one which is used on Linux is pure-Tcl, so can see all the files Tcl can. If you need to access things in the VFS, either what you're doing now, or the File selection dialog for Tile are probably your best bet.
LV: recently on comp.lang.tcl someone asked a question about tk_getOpenFile that triggered a question in my mind.
What would be an example of the safe way to use the results of tk_getOpenFile -multiple 1 on Windows, knowing that in all likelihood the files will have spaces in them?
package require Tk
set types {
{{Text Files} {.txt} }
{{TCL Scripts} {.tcl} }
{{C Source Files} {.c} TEXT}
{{GIF Files} {.gif} }
{{Text Files} {} TEXT}
{{All Files} * }
}
set filenameList [tk_getOpenFile -filetypes $types -multiple true ]
foreach filename $filenameList {
if { [file readable $filename] } {
puts "I found $filename"
}
}I thought the above code should work. However, I am missing something, because when I select 2 files, I get an error saying that the file (followed by the 2 file names) does not exist.
LV 2009-05-07:
For someone using tk_getOpenFile with the -multiple true option, here's a note about the actual keyboard behavior of the dialog, at least in Tk 8.5.4.
witek 2011-06-12
Is there a way to disable displaying of hidden directories in Linux (starting with a dot ".") when file sector dialog opens?
idg 2011-06-12:
Not conveniently, but the necessary hooks are already in place in the file tkfbox.tcl. This file lives in your tcl installation which, depending on the distribution, is:
Ubuntu: /usr/share/tcltk/tk8.5/
Fedora: /usr/share/tk8.5/
Slackware: /usr/lib/tk8.5/Find the line
namespace eval ::tk::dialog::file {about 1/3 of the way through this file. Then, a couple of lines down,
set ::tk::dialog::file::showHiddenVar 0
will turn off the hidden file display. If you want to make this user-selectable at run time,
set ::tk::dialog::file::showHiddenBtn 1
in the same area. This is easy on your own system, a headache if you want to distribute code to others. I wish this would be made an official part of Tk...
witek 2011-06-12:
Great! It works. It should be set like this for Linux/Unix by default. It would give much better experience to the user.
Googie 2011-June-13:
It's enough to just set those variables manually after loading Tk package. You don't need to edit tkfbox.tcl (which is usually read-only to Unix users).
Just use lines:
set ::tk::dialog::file::showHiddenVar 0 set ::tk::dialog::file::showHiddenBtn 1
after
package require Tk
or just at the very begining of your script if you're running script with wish (or wish-like) interpreter. Important is that Tk is loaded before you change these variables.
KD 2011/06/13: That won't work, you first have to force the auto-loader to load tk_getOpenFile, for example with a dummy call:
catch {tk_getOpenFile foo bar}witek 2011-06-13:
Thanks Googie. Why didn't I think about it myself?! Anyway, it's a bit ugly; having an option like "-disable_hidden" for tk_getOpenFile would be more cleaner way to do it.
RJM 2012-09-04: About encoding of returned filenames: Here some ambiguities were apparent. This was revealed after trying to establish a full utf-8 command line argument for the exec command (which will be discussed on a separate page - Tcl fails here). I experimented with the return value of tk_getOpenFile and wrote it under different conditions in a file, to allow exact examination of the encoding result. Here is a table:
| encoding system ... | utf-8 | utf-8 | cp1252 | cp1252 | |
|---|---|---|---|---|---|
| file attr. | w | wb | w | wb | field comment |
| w/o conversion | OK | less | ?less | less | ? means: true '?'-substitution |
| convertto utf-8 | more | OK | false | OK | false: same length, but |
(less = less characters than utf-string; more = more...)
The code framework:
encoding system [utf-8|cp1252] set filename [tk_getopenFIle] set fid [open fn.txt w] puts -nonewline $filename close $fid
Comment: The test path from tk_getopenFile contained several international characters. The variable filename outputs to file as correct utf-8 while using non-binary file I/O only when encoding system is utf-8. When the system encoding is not utf-8, multibyte characters are represented as plain '?'-characters. Hence in a non-utf-8 system, a encoding convertto utf-8 makes sense. Here, a binary file I/O always ensures a correct result. Non-binary file-I/O fails in this case! I'm tempted to treat it as a bug. It is this latter result that also applies, when an utf-8 string is used as argument in exec <program> (even when system encoding is set to utf-8).