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

Luc <no@no.no> 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.

On Thu, 6 Oct 2022 03:37:07 -0000 (UTC), Rich wrote:

> Luc <no@no.no> 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.
>
**************************

I've done that. It still tells me the command doesn't exist.

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.

When I try that command in Tkcon, it doesn't say the command doesn't exist.

But Tkcon freezes and I have to kill it, and my Tkcon command history file
gets truncated.

When I try to load ttk::fsdialog::tk_getOpenFile from my script, nothing
happens.

--
Luc
>>

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

On Thu, 6 Oct 2022 09:49:07 +0200, Schelte wrote:

> 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
>
**************************

Thanks.

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> {}"
(class "::tk::MegawidgetClass" destructor line 7)
invoked from within
"next"
(class "::ttk::fsdialog::chooseDirectory" destructor line 5)
invoked from within
"next"
(class "::ttk::fsdialog::getSaveFile" destructor line 3)
----------------

I click OK and a second error pops up:

----------------
window name "__ttk_filedialog" already exists in parent
window name "__ttk_filedialog" already exists in parent
while executing
"toplevel $w -class TkFDialog"
(class "::ttk::fsdialog::getSaveFile" method "CreateHull" line 3)
invoked from within
"my CreateHull"
(class "::tk::MegawidgetClass" constructor line 12)
invoked from within
"next {*}$args"
(class "::ttk::fsdialog::chooseDirectory" constructor line 4)
invoked from within
"[self] create $w {*}$args"
(class "::tk::Megawidget" method "unknown" line 3)
invoked from within
"$cmd $w {*}$arglist -resultvariable $var"
(procedure "dialog" line 18)
invoked from within
"dialog getOpenFile __ttk_filedialog $args"
(procedure "tk_getOpenFile" line 2)
invoked from within
"tk_getOpenFile -filetypes $_filetypes -initialdir [file normalize $::MyApp::basedir ] -title "Open file..." "
(procedure "p.dialogFileOpen" line 12)
invoked from within
"p.dialogFileOpen"
(command bound to event)
----------------

Any ideas?

--
Luc
>>

Luc <no@no.no> 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.

On Thu, 6 Oct 2022 16:18:48 -0000 (UTC), Rich wrote:

> Luc <no@no.no> 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.

--
Luc
>>

At Thu, 6 Oct 2022 13:52:50 -0300 Luc <no@no.no> wrote:

>
> On Thu, 6 Oct 2022 16:18:48 -0000 (UTC), Rich wrote:
>
> > Luc <no@no.no> 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.

So somewhere, you have a bad (buggy) SNIT Widget or WidgetAdaptor...

>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On 06/10/2022 18:52, Luc wrote:
> 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.
>
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

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 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 07/10/2022 16:02, saitology9 wrote:
> 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.
>
Citation needed, as wikipedia would say. How would that be "better"? The
package is presented as a drop-in replacement for the various file
selection commands. Your suggestion would require the user to do extra
work to replace the original commands, or modify all calls from
tk_getOpenFile to fs_getOpenFile, etc. The user is in charge, by
deciding to load the package or not.

I fail to see a scenario where someone would want to mix the two
implementations in a real application. Perhaps someone may like to
evaluate the package by comparing the two versions. But that can be done
by renaming the original commands before loading the package, or using
separate interpreters.

Schelte.

On 07/10/2022 14:58, saitology9 wrote:
> 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.
>
>
>
>
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 07/10/2022 15:02, saitology9 wrote:
> 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.
>
>
I think I disagree.

I would argue that be executing

package require fsdialog

the user is requesting that tk_getOpenFile (and friends) should be replaced.

I wasn't sure at first, but on checking, I see that the manual pages are
pretty explicit about this - it's the first sentence of the description
after all.

On 10/7/22 11:02 AM, Schelte wrote:
> On 07/10/2022 16:02, saitology9 wrote:
>> 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.
>>
> Citation needed, as wikipedia would say. How would that be "better"?

Indeed :-)

I wasn't really sure what it was or why it was needed. I was just
surprised that it took over a core feature. which turned out to be its
main goal.

This conversation has become more interesting than I expected.

First...

------------
On Fri, 7 Oct 2022 10:24:51 +0200, Schelte wrote:

> 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
------------

Thank you for your attention, Schelte.

Well, yes. When I write a very bare bones script with fsdialog, it works
as expected. I've finally seen what it looks like. But it won't work in my
application.

"Show exactly what I'm doing" is complicated because it's an application,
it's a lot of code for me to post here and for anyone to pore over for free.

But then...

------------
On Fri, 7 Oct 2022 17:16:14 +0100, Alan Grunwald wrote:

> 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
------------

That did do the trick. I declared the top level again and alas, it works.

Or does it?

No. The open file dialog pops up, but then I select a file and... nothing
happens. The content of the file was supposed to be inserted into a text
widget, which works as expected with stock Tk. The file is not loaded with
fsdialog.

Plus, the open dialog only pops up once. If I try to open it a second time,
the same two errors I had reported previously happen again. It doesn't
matter whether I do select a file or rather dismiss the dialog with Esc.

I'm sorry for this trouble. I've always been very good at breaking things.
It's sort of a gift.

--
Luc
>>

On 10/7/22 9:58 AM, saitology9 wrote:
> On 10/7/22 4:24 AM, Schelte wrote:
>>
>> For example: The following works fine for me:
>>

I had some free time this afternoon :-)
I found a bug in fsdialog: in the proc ttk::fsdialog::dialog. If the
-parent option is not specified, it simply defaults to ".". This is
fine if the window is mapped. If not, then fsdialog causes weird
errors. It locks up tkcon, it messes up the main application, etc.

Here is a solution that will fix it, as reported by diff:

87c87
< } else {
---
> } 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 .
> }

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.

On Fri, 7 Oct 2022 22:12:38 +0200, Schelte wrote:

> 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.

I'm really glad you figured all out and that my incident turned out to be
useful in some way.

Yes, I do wm withdraw . right in the beginning of everything.

--
Luc
>>