Version 13 of tk_getOpenFile

Updated 2005-04-28 18:48:50 by rgf

pop up a dialog box for the user to select a file to open.


http://www.purl.org/tcl/home/man/tcl8.4/TkCmd/getOpenFile.htm


SYNOPSIS

tk_getOpenFile ?option value ...?

DESCRIPTION

The procedure tk_getOpenFile pops up a dialog box for the user to select a file to open. The tk_getOpenFile command is usually associated with the Open command in the File menu. Its purpose is for the user to select an existing file only. 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, it calls a native file selector. 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.


tkfbox [L1 ] 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:

  • Can set background colors to the window: the built-in versions are limited to a gray background. the tkfbox version uses the default background color.
  • Doesn't fall prey to the bug in the built in version which means that double clicks on a file name are not totally consumed, and can cause a click event on a widget below the open file dialog. This can be patched, but it is a problem. -- MG recalls reading somewhere that this is now fixed, but can't remember where...
  • When you call the tkfbox tk_getSaveFile with multiple filetypes specified, and change the filetype using the filetype listitem, then the displayed filename will change its extension. E.g., changing from jpg to gif will also change the filename's extension. This doesnt happen with the built in tk_getSaveFile.
  • The real advantage is that since the tkfbox version is tcl/tk code, I can adapt it at will. If there is some feature I don't like in the built-in version, I can change/add/delete the feature.
  • SEH Allows selection of files and directories in virtual filesystems.

Mick mailto:[email protected]

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: [L2 ]

 -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 Apr 28 2005 - See the page tooltips 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: [L3 ] 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!


See also:


Category Dialog - Category Command - Tk syntax help - Arts and Crafts of Tcl-Tk Programming