I have Tile loaded and I am using several of its widgets such as
ttk::frame or ttk::label, but when I try to use ttk::getOpenFile, a
get an error saying that the commmand does not exist.
A page at the wiki makes it sound like it's part of Tile, but it
seems I don't have it. I'm using the standard Tcl and Tk packages
from the Debian repository, version 8.6.0.
What am I doing wrong?
Luc <[email protected]> wrote:
I have Tile loaded and I am using several of its widgets such as
ttk::frame or ttk::label, but when I try to use ttk::getOpenFile, a
get an error saying that the commmand does not exist.
A page at the wiki makes it sound like it's part of Tile, but it
seems I don't have it. I'm using the standard Tcl and Tk packages
from the Debian repository, version 8.6.0.
What am I doing wrong?
If this is the wiki page of which you speak: https://wiki.tcl-lang.org/page/File+selection+dialog+for+Tile
Then it appears that what you are doing wrong is failing to follow
these instructions located on that page:
Get the latest version here:
https://chiselapp.com/user/schelte/repository/fsdialog/tarball/fsdialog.tar.gz?uuid=trunk
Installation instructions: Dump the files in the package (not the
fsdialog directory) in a directory that is listed in $auto_path, or
lappend the directory containing the files to auto_path.
Then I tried 'package require fsdialog' in Tkcon. It prints "2.1".
But ttk::getOpenFile still doesn't exist.
Examining fsdialog.tcl, there seems to be a ttk::fsdialog::tk_getOpenFile proc.
On 06/10/2022 06:37, Luc wrote:
Then I tried 'package require fsdialog' in Tkcon. It prints "2.1".
But ttk::getOpenFile still doesn't exist.
Examining fsdialog.tcl, there seems to be a
ttk::fsdialog::tk_getOpenFile proc.
Rather than trying to read the source code, I would suggest to first
read the index page for the package on chiselapp (http://chiselapp.com/user/schelte/repository/fsdialog): "The package
is now intended to be placed in a directory under auto_path. It can
then be loaded using [package require fsdialog]. This will replace
the built-in versions of tk_getOpenFile, tk_getSaveFile, and tk_chooseDirectory."
You already did the [package require fsdialog]. So now you can just
use tk_getOpenFile as you normally would.
Schelte
Luc <[email protected]> wrote:**************************
But it still doesn't work. When it's invoked by the bind keys,
nothing happens. A second press causes this error:
----------------
can't read "hull": no such variable
can't read "hull": no such variable
while executing
"bind $hull <Destroy> {}"
Any ideas?
'hull' sounds like SNIT. Do you have Tcllib installed, which
contains SNIT? Beyond that, I'm out of ideas.
But it still doesn't work. When it's invoked by the bind keys, nothing happens. A second press causes this error:
----------------
can't read "hull": no such variable
can't read "hull": no such variable
while executing
"bind $hull <Destroy> {}"
Any ideas?
On Thu, 6 Oct 2022 16:18:48 -0000 (UTC), Rich wrote:
Luc <[email protected]> wrote:
But it still doesn't work. When it's invoked by the bind keys,
nothing happens. A second press causes this error:
----------------
can't read "hull": no such variable
can't read "hull": no such variable
while executing
"bind $hull <Destroy> {}"
Any ideas?
'hull' sounds like SNIT. Do you have Tcllib installed, which**************************
contains SNIT? Beyond that, I'm out of ideas.
Yes. Tcllib 1.18 and Snit 2.3.2.
On Thu, 6 Oct 2022 16:18:48 -0000 (UTC), Rich wrote:
'hull' sounds like SNIT. Do you have Tcllib installed, which**************************
contains SNIT? Beyond that, I'm out of ideas.
Yes. Tcllib 1.18 and Snit 2.3.2.
For example: The following works fine for me:
# Install the package
$ mkdir -p ~/fsdlg
$ cd ~/fsdlg
$ wget -qO- https://chiselapp.com/user/schelte/repository/fsdialog/tarball/trunk/fsdialog.tar.gz | tar xzv
# Use the package
$ wish
% lappend auto_path ~/fsdlg
% package require fsdialog
% tk_getOpenFile
This will replace the built-in
versions of tk_getOpenFile, tk_getSaveFile, and tk_chooseDirectory."
Can I make a recommendation? I see that the package does a [namespace
export] to replace the built-in versions. It would be better if the user
was in charge of this action instead of it being automatic. You could
even export them as "fs_getOpenFile" and so on.
On 10/6/22 3:49 AM, Schelte wrote:
This will replace the built-in versions of tk_getOpenFile,
tk_getSaveFile, and tk_chooseDirectory."
Can I make a recommendation? I see that the package does a [namespace
export] to replace the built-in versions. It would be better if the user
was in charge of this action instead of it being automatic. You could
even export them as "fs_getOpenFile" and so on.
On 10/7/22 4:24 AM, Schelte wrote:
For example: The following works fine for me:
# Install the package
$ mkdir -p ~/fsdlg
$ cd ~/fsdlg
$ wget -qO-
https://chiselapp.com/user/schelte/repository/fsdialog/tarball/trunk/fsdialog.tar.gz | tar xzv
# Use the package
$ wish
% lappend auto_path ~/fsdlg
% package require fsdialog
% tk_getOpenFile
I can confirm that this sequence works for me on MS Windows, Tcl/Tk 8.6.10.
On 07/10/2022 16:02, saitology9 wrote:
Can I make a recommendation? I see that the package does a [namespaceCitation needed, as wikipedia would say. How would that be "better"?
export] to replace the built-in versions. It would be better if the
user was in charge of this action instead of it being automatic. You
could even export them as "fs_getOpenFile" and so on.
Fsdialog doesn't use SNIT. It works with just the base Tcl/Tk. It------------
will benefit from having fswatch available, but doesn't require it.
Can you show exactly what you are doing? Based on just an error
message without information what led to the error, it is difficult to investigate.
For example: The following works fine for me:
# Install the package
$ mkdir -p ~/fsdlg
$ cd ~/fsdlg
$ wget -qO- https://chiselapp.com/user/schelte/repository/fsdialog/tarball/trunk/fsdialog.tar.gz
| tar xzv
# Use the package
$ wish
% lappend auto_path ~/fsdlg
% package require fsdialog
% tk_getOpenFile
Schelte
It works fine for me too. However...------------
I generally use tkcon rather than wish, and when I tried using tkcon
"as usual" I had the problem described by the OP.
I then tried with tkcon as follows:
$ tclsh <-- Typed into bash
% tkcon show <-- Typed to tclsh
% lappend auto_path ~/fsdlg \
% package require fsdialog > <-- typed to tkcon
% tk_getOpenFile / console
which worked just fine.
It turned out that doing things "as usual" included executing
wm withdraw .
Is the OP doing something similar? If so, then assuming he creates
another toplevel named, say, .myTopLevel then
tk_getOpenFile -parent .myTopLevel
ought to do the trick.
Alan
On 10/7/22 4:24 AM, Schelte wrote:
For example: The following works fine for me:
} elseif {[winfo ismapped .]} {88a89,103
} else {
# use first mapped toplevel found
set parent ""
foreach w [winfo children .] {
if {[winfo ismapped $w]} {
set parent $w
break
}
}
if {$parent eq ""} {
# no mapped toplevels
# deiconify the main one
wm deiconify .
set parent .
}
I'm sorry for this trouble. I've always been very good at breaking things. It's sort of a gift.
On 07/10/2022 20:23, Luc wrote:
I'm sorry for this trouble. I've always been very good at breaking
things. It's sort of a gift.
If there is a bug, I like to know about it and fix it.
As more pieces of the puzzle become clear, I have been able to evoke the error messages you reported. This is what I did:
package require fsdialog
wm withdraw .
toplevel .top
bind .top <Control-o> p.dialogFileOpen
proc p.dialogFileOpen {} {
puts [tk_getOpenFile]
}
Pressing Ctrl-O while .top has focus creates the tk_getOpenFile window.
But because the parent is withdrawn, the window is not visible. Pressing Ctrl-O again attempts to create the window once more. This fails because
it already exists. When the construction fails, the destructor is
invoked. The destructor finds the existing window and tries to destroy
it, but lacks the necessary variables because it wasn't this object that created it. That causes the error from the destructor.
The second error you get is the original error; trying to create __ttk_filedialog when it already exists. So the problem boils down to
the user trying to open the file dialog while it is already open. This
should somehow be prevented.
I don't yet understand why nothing happens when you select a file. It
seems that the dialog doesn't fully close, but somehow hangs around.
Which is why you get the errors again when you try to open the dialog a second time.
Is the window you specified in the -parent option visible? Or did you withdraw that one as well?
Schelte.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:49:17 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,972 |