OK, I've built my "cycling" GUI and I get all the data I want into a nice list, something like this: {WARM 5 30 80 100} {BLCK 30 0 150 85} {COOL 5 100 80 80}
Where WARM mean warmup and the figures are:
mins secs start_power end_power (I could have another figure at end for cadence, but optional).
So, I can read those and write to my workout file, then the steady block, then the cool-down. (I can have other more complex stuff like intervals that ramp up in power etc).

Now, I double click on WISH and get a wish & associated tcl shell, I "source"
my top level file, and all works fine.
BUT, if I open my script by "open with" Wish Application, I get "permission denied" when I try to write my output file.

Is this something to do with Windows 10.
This is the last step that I need to get it all to work.

On Friday, November 11, 2022 at 10:47:47 AM UTC+1, snosniv wrote:
> OK, I've built my "cycling" GUI and I get all the data I want into a nice list, something like this: {WARM 5 30 80 100} {BLCK 30 0 150 85} {COOL 5 100 80 80}
> Where WARM mean warmup and the figures are:
> mins secs start_power end_power (I could have another figure at end for cadence, but optional).
> So, I can read those and write to my workout file, then the steady block, then the cool-down. (I can have other more complex stuff like intervals that ramp up in power etc).
>
> Now, I double click on WISH and get a wish & associated tcl shell, I "source"
> my top level file, and all works fine.
> BUT, if I open my script by "open with" Wish Application, I get "permission denied" when I try to write my output file.
>
> Is this something to do with Windows 10.
> This is the last step that I need to get it all to work.
I never use that option, but I can imagine that the program then starts in a directory that is indeed protected. Can you print it - puts [pwd] - in the console?

Regards,

Arjen

On Friday, 11 November 2022 at 10:07:27 UTC, arjen.m...@gmail.com wrote:
> On Friday, November 11, 2022 at 10:47:47 AM UTC+1, snosniv wrote:
> > OK, I've built my "cycling" GUI and I get all the data I want into a nice list, something like this: {WARM 5 30 80 100} {BLCK 30 0 150 85} {COOL 5 100 80 80}
> > Where WARM mean warmup and the figures are:
> > mins secs start_power end_power (I could have another figure at end for cadence, but optional).
> > So, I can read those and write to my workout file, then the steady block, then the cool-down. (I can have other more complex stuff like intervals that ramp up in power etc).
> >
> > Now, I double click on WISH and get a wish & associated tcl shell, I "source"
> > my top level file, and all works fine.
> > BUT, if I open my script by "open with" Wish Application, I get "permission denied" when I try to write my output file.
> >
> > Is this something to do with Windows 10.
> > This is the last step that I need to get it all to work.

> I never use that option, but I can imagine that the program then starts in a directory that is indeed protected. Can you print it - puts [pwd] - in the console?
>
> Regards,
>
> Arjen

Yes, if I type puts [pwd] I get;
C:\ActiveTcl\User_files\MY_WORKOUT
which is the dir where my 4 tcl files are. (I "open" f00.tcl which sources the other 3 files, (f00 is not the real file name))

On Friday, 11 November 2022 at 10:07:27 UTC, arjen.m...@gmail.com wrote:
> On Friday, November 11, 2022 at 10:47:47 AM UTC+1, snosniv wrote:
> > OK, I've built my "cycling" GUI and I get all the data I want into a nice list, something like this: {WARM 5 30 80 100} {BLCK 30 0 150 85} {COOL 5 100 80 80}
> > Where WARM mean warmup and the figures are:
> > mins secs start_power end_power (I could have another figure at end for cadence, but optional).
> > So, I can read those and write to my workout file, then the steady block, then the cool-down. (I can have other more complex stuff like intervals that ramp up in power etc).
> >
> > Now, I double click on WISH and get a wish & associated tcl shell, I "source"
> > my top level file, and all works fine.
> > BUT, if I open my script by "open with" Wish Application, I get "permission denied" when I try to write my output file.
> >
> > Is this something to do with Windows 10.
> > This is the last step that I need to get it all to work.
> I never use that option, but I can imagine that the program then starts in a directory that is indeed protected. Can you print it - puts [pwd] - in the console?
>
> Regards,
>
> Arjen

Yes, that works OK;

puts [pwd] ;# responds with:-

C:/ActiveTcl/User_files/MY_WORKOUT

I'm using this proc as a quick debug to try & get the write-file to work, "fname" comes from an entry widget, and I'll be writing data from a global list.
Probably not very elegant but the whole thing is moderately simple, but falling at last hurdle it seems.

proc build_workout {} {
global fname
set fout_name "CLUB_$fname.txt"
set fout [open $fout_name w]
puts $fout "dogs" ;# Try and write something!
close $fout
}

* snosniv <nivparsons@gmail.com>
| proc build_workout {} {
| global fname
| set fout_name "CLUB_$fname.txt"

Might be a good idea to include the full path of the file instead of
relying on where the app starts by coincidence:

set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"

Maybe make the directory part configurable.

R'

On Friday, 11 November 2022 at 12:35:23 UTC, Ralf Fassel wrote:
> * snosniv <nivpa...@gmail.com>
> | proc build_workout {} {
> | global fname
> | set fout_name "CLUB_$fname.txt"
> Might be a good idea to include the full path of the file instead of
> relying on where the app starts by coincidence:
>
> set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
>
> Maybe make the directory part configurable.
>
> R'
OK, thanks, will try that.
However, I've just found that if I "freewrap" myfiles into a single executable, it works, which was my final goal.
BUT, I will try your suggestion as I'd like to know why it worked or not depending on how invoked!

snosniv <nivparsons@gmail.com> wrote:
> On Friday, 11 November 2022 at 12:35:23 UTC, Ralf Fassel wrote:
>> * snosniv <nivpa...@gmail.com>
>> | proc build_workout {} {
>> | global fname
>> | set fout_name "CLUB_$fname.txt"
>> Might be a good idea to include the full path of the file instead of
>> relying on where the app starts by coincidence:
>>
>> set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
>>
>> Maybe make the directory part configurable.
>>
>> R'
> OK, thanks, will try that.
> However, I've just found that if I "freewrap" myfiles into a single
> executable, it works, which was my final goal.
> BUT, I will try your suggestion as I'd like to know why it worked or
> not depending on how invoked!

If you were really trying to load files by relative name (your set
fout_name) above has no directory string, so it is a "relative" name)
then whether the "open" succeeds depends upon what "default directory"
is used to look for the files.

That "default directory" being the "current working directory" which
you can retreive using the "pwd" command (most likely short for (P)rint
(W)orking (D)irectory).

Upon startup, your script is assigned a current working directory by
the OS. MSWin seems to like to assign different current working
directories depending upon whether you launch from a cmd shell, a
shortcut, or let windows file extension lookup pick an executable.

The failures were likely due to MSWin giving you a current working
directory that was different from the directory where your scripts were
stored. So if your scripts were stored at c:\user\snosiv\script\ but
windows gave the process a current working directory of
c:\programs\tcl\bin then all your relative file accesses were looking
in c:\programs\tcl\bin for the filenames your script was trying to
open, and as they were not there, all the opens failed.

On Friday, 11 November 2022 at 22:14:13 UTC, Rich wrote:
> snosniv <nivpa...@gmail.com> wrote:
> > On Friday, 11 November 2022 at 12:35:23 UTC, Ralf Fassel wrote:
> >> * snosniv <nivpa...@gmail.com>
> >> | proc build_workout {} {
> >> | global fname
> >> | set fout_name "CLUB_$fname.txt"
> >> Might be a good idea to include the full path of the file instead of
> >> relying on where the app starts by coincidence:
> >>
> >> set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
> >>
> >> Maybe make the directory part configurable.
> >>
> >> R'
> > OK, thanks, will try that.
> > However, I've just found that if I "freewrap" myfiles into a single
> > executable, it works, which was my final goal.
> > BUT, I will try your suggestion as I'd like to know why it worked or
> > not depending on how invoked!
> If you were really trying to load files by relative name (your set
> fout_name) above has no directory string, so it is a "relative" name)
> then whether the "open" succeeds depends upon what "default directory"
> is used to look for the files.
>
> That "default directory" being the "current working directory" which
> you can retreive using the "pwd" command (most likely short for (P)rint
> (W)orking (D)irectory).
>
> Upon startup, your script is assigned a current working directory by
> the OS. MSWin seems to like to assign different current working
> directories depending upon whether you launch from a cmd shell, a
> shortcut, or let windows file extension lookup pick an executable.
>
> The failures were likely due to MSWin giving you a current working
> directory that was different from the directory where your scripts were
> stored. So if your scripts were stored at c:\user\snosiv\script\ but
> windows gave the process a current working directory of
> c:\programs\tcl\bin then all your relative file accesses were looking
> in c:\programs\tcl\bin for the filenames your script was trying to
> open, and as they were not there, all the opens failed.

Thanks Rich, it's definitely something to do with the path.
After a bit of debugging this morning, I invoked my script from where it resides in C:\ActiveTcl\User_files\CYCLE
with the "Open with Wish application" after I added the following code:

set my_path [pwd]
set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
set f_out [open $my_path/$my_name w]

And I get this message:

couldn't open "C:/Windows/System32/CLUB_testwr.zwo": permission denied.

So, I now see what's going on, thanks for the help in resolving that. :-)
BUT, I want to keep the script flexible such that whatever directory it's in,
file writes are to the same directory, I don't want to put a hard path to the directory.

I'm sure it's a simple fix, but can't seem to sort the wood from the trees.

Thanks, Kev P.

On Saturday, 12 November 2022 at 07:55:54 UTC, snosniv wrote:
> On Friday, 11 November 2022 at 22:14:13 UTC, Rich wrote:
> > snosniv <nivpa...@gmail.com> wrote:
> > > On Friday, 11 November 2022 at 12:35:23 UTC, Ralf Fassel wrote:
> > >> * snosniv <nivpa...@gmail.com>
> > >> | proc build_workout {} {
> > >> | global fname
> > >> | set fout_name "CLUB_$fname.txt"
> > >> Might be a good idea to include the full path of the file instead of
> > >> relying on where the app starts by coincidence:
> > >>
> > >> set fout_name "c:/where/the/files/should/go/CLUB_$fname.txt"
> > >>
> > >> Maybe make the directory part configurable.
> > >>
> > >> R'
> > > OK, thanks, will try that.
> > > However, I've just found that if I "freewrap" myfiles into a single
> > > executable, it works, which was my final goal.
> > > BUT, I will try your suggestion as I'd like to know why it worked or
> > > not depending on how invoked!
> > If you were really trying to load files by relative name (your set
> > fout_name) above has no directory string, so it is a "relative" name)
> > then whether the "open" succeeds depends upon what "default directory"
> > is used to look for the files.
> >
> > That "default directory" being the "current working directory" which
> > you can retreive using the "pwd" command (most likely short for (P)rint
> > (W)orking (D)irectory).
> >
> > Upon startup, your script is assigned a current working directory by
> > the OS. MSWin seems to like to assign different current working
> > directories depending upon whether you launch from a cmd shell, a
> > shortcut, or let windows file extension lookup pick an executable.
> >
> > The failures were likely due to MSWin giving you a current working
> > directory that was different from the directory where your scripts were
> > stored. So if your scripts were stored at c:\user\snosiv\script\ but
> > windows gave the process a current working directory of
> > c:\programs\tcl\bin then all your relative file accesses were looking
> > in c:\programs\tcl\bin for the filenames your script was trying to
> > open, and as they were not there, all the opens failed.
> Thanks Rich, it's definitely something to do with the path.
> After a bit of debugging this morning, I invoked my script from where it resides in C:\ActiveTcl\User_files\CYCLE
> with the "Open with Wish application" after I added the following code:
>
>
> set my_path [pwd]
> set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
> set f_out [open $my_path/$my_name w]
>
> And I get this message:
>
> couldn't open "C:/Windows/System32/CLUB_testwr.zwo": permission denied.
>
> So, I now see what's going on, thanks for the help in resolving that. :-)
> BUT, I want to keep the script flexible such that whatever directory it's in,
> file writes are to the same directory, I don't want to put a hard path to the directory.
>
> I'm sure it's a simple fix, but can't seem to sort the wood from the trees.
>
> Thanks, Kev P.

I could use the command "tk_chooseDirectory", but that requires more user input (OK, not much),
but I'd much prefer to write to same dir as script resides, or possibly a sub-dir of script.

Kev P.

snosniv <nivparsons@gmail.com> wrote:
> On Friday, 11 November 2022 at 22:14:13 UTC, Rich wrote:
>> snosniv <nivpa...@gmail.com> wrote:
>> > BUT, I will try your suggestion as I'd like to know why it worked
>> > or not depending on how invoked!

>> If you were really trying to load files by relative name (your set
>> fout_name) above has no directory string, so it is a "relative"
>> name) then whether the "open" succeeds depends upon what "default
>> directory" is used to look for the files.
>>
>> That "default directory" being the "current working directory" which
>> you can retreive using the "pwd" command (most likely short for
>> (P)rint (W)orking (D)irectory).
>>
>> Upon startup, your script is assigned a current working directory by
>> the OS. MSWin seems to like to assign different current working
>> directories depending upon whether you launch from a cmd shell, a
>> shortcut, or let windows file extension lookup pick an executable.
>>
>> The failures were likely due to MSWin giving you a current working
>> directory that was different from the directory where your scripts
>> were stored. So if your scripts were stored at
>> c:\user\snosiv\script\ but windows gave the process a current
>> working directory of c:\programs\tcl\bin then all your relative file
>> accesses were looking in c:\programs\tcl\bin for the filenames your
>> script was trying to open, and as they were not there, all the opens
>> failed.
>
> Thanks Rich, it's definitely something to do with the path.
> After a bit of debugging this morning, I invoked my script from where
> it resides in C:\ActiveTcl\User_files\CYCLE with the "Open with Wish
> application" after I added the following code:
>
>
> set my_path [pwd]
> set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
> set f_out [open $my_path/$my_name w]
>
> And I get this message:
>
> couldn't open "C:/Windows/System32/CLUB_testwr.zwo": permission denied.
>
> So, I now see what's going on, thanks for the help in resolving that. :-)
> BUT, I want to keep the script flexible such that whatever directory it's in,
> file writes are to the same directory, I don't want to put a hard path to the directory.
>
> I'm sure it's a simple fix, but can't seem to sort the wood from the trees.

It is a simple fix, and there are two simple ways to fix it.

For Tcl code files, one fix is to make the files you are sourcing into
packages or modules (read the 'package' or 'tm' man pages) and then add
the location of the packages or modules to the auto_path or tm::path add
and then 'package require' the additional code.

The second fix, is to ask Tcl where the main script file is located,
and use that path for opening all the other files. And if you plan to
write files where the script resides, then this is your only option.
To do this you do:

# somewhere early in startup, you grab the directory part of the
# location of the script itself

set script_dir [file dirname [info script]]

# then, everywhere you 'source' a script file or open a file to write
# into, you do this, instead of what you have been doing:

set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
set f_out [open [file join $script_dir $my_name] {WRONLY CREAT TRUNC}]

And your file 'CLUB_$woname.zwo' will be created in the same directory
where your script resides. For accessing/creating files in sub-directories, do:

set f_out [open [file join $script_dir $special_sub_dir $my_name] {WRONLY CREAT TRUNC}]

Note also, when combining paths and filenames, it is best to use
[file join ...] as it will take care of any of the various platform
differences.

On Saturday, 12 November 2022 at 12:52:30 UTC, Rich wrote:
> snosniv <nivpa...@gmail.com> wrote:
> > On Friday, 11 November 2022 at 22:14:13 UTC, Rich wrote:
> >> snosniv <nivpa...@gmail.com> wrote:
> >> > BUT, I will try your suggestion as I'd like to know why it worked
> >> > or not depending on how invoked!
>
> >> If you were really trying to load files by relative name (your set
> >> fout_name) above has no directory string, so it is a "relative"
> >> name) then whether the "open" succeeds depends upon what "default
> >> directory" is used to look for the files.
> >>
> >> That "default directory" being the "current working directory" which
> >> you can retreive using the "pwd" command (most likely short for
> >> (P)rint (W)orking (D)irectory).
> >>
> >> Upon startup, your script is assigned a current working directory by
> >> the OS. MSWin seems to like to assign different current working
> >> directories depending upon whether you launch from a cmd shell, a
> >> shortcut, or let windows file extension lookup pick an executable.
> >>
> >> The failures were likely due to MSWin giving you a current working
> >> directory that was different from the directory where your scripts
> >> were stored. So if your scripts were stored at
> >> c:\user\snosiv\script\ but windows gave the process a current
> >> working directory of c:\programs\tcl\bin then all your relative file
> >> accesses were looking in c:\programs\tcl\bin for the filenames your
> >> script was trying to open, and as they were not there, all the opens
> >> failed.
> >
> > Thanks Rich, it's definitely something to do with the path.
> > After a bit of debugging this morning, I invoked my script from where
> > it resides in C:\ActiveTcl\User_files\CYCLE with the "Open with Wish
> > application" after I added the following code:
> >
> >
> > set my_path [pwd]
> > set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
> > set f_out [open $my_path/$my_name w]
> >
> > And I get this message:
> >
> > couldn't open "C:/Windows/System32/CLUB_testwr.zwo": permission denied.
> >
> > So, I now see what's going on, thanks for the help in resolving that. :-)
> > BUT, I want to keep the script flexible such that whatever directory it's in,
> > file writes are to the same directory, I don't want to put a hard path to the directory.
> >
> > I'm sure it's a simple fix, but can't seem to sort the wood from the trees.
> It is a simple fix, and there are two simple ways to fix it.
>
> For Tcl code files, one fix is to make the files you are sourcing into
> packages or modules (read the 'package' or 'tm' man pages) and then add
> the location of the packages or modules to the auto_path or tm::path add
> and then 'package require' the additional code.
>
> The second fix, is to ask Tcl where the main script file is located,
> and use that path for opening all the other files. And if you plan to
> write files where the script resides, then this is your only option.
> To do this you do:
>
> # somewhere early in startup, you grab the directory part of the
> # location of the script itself
>
> set script_dir [file dirname [info script]]
>
> # then, everywhere you 'source' a script file or open a file to write
> # into, you do this, instead of what you have been doing:
> set my_name "CLUB_$woname.zwo" ;# woname is set in an entry box, in this instance as "testwr"
> set f_out [open [file join $script_dir $my_name] {WRONLY CREAT TRUNC}]
>
> And your file 'CLUB_$woname.zwo' will be created in the same directory
> where your script resides. For accessing/creating files in sub-directories, do:
>
> set f_out [open [file join $script_dir $special_sub_dir $my_name] {WRONLY CREAT TRUNC}]
>
> Note also, when combining paths and filenames, it is best to use
> [file join ...] as it will take care of any of the various platform
> differences.

Many thanks for all your help Rich, very kind of you.
Pretty sure I'm just about there now. (I had a silly error with a nested loop, I used the same index for both, "i" DOH!, but now "i" & "j"
bit of a novice error, but this is my first script since retiring July '17! so somewhat rusty to say the least!

snosniv <nivparsons@gmail.com> schrieb:

Hi,
say, your script(s) are in c:/some-path/your-directory. Then you are
currently probably in that directory (because you edited some files or
whatever). Then all you need to do is
- open a console in c:/some-path/your-directory
OR
- open a console where ever and navigate to
c:/some-path/your-directory
AND THEN
- type 'wish <your source file>'

This way you start wish with 'c:/some-path/your-directory' as current
directory.
HTH
Helmut