Can someone with the appropriate knowledge please clarify for me whether it is safe to issue a Copy command from within a Wimp task (written in BASIC) simply from an OSCLI?
I've searched on the web but I can't see a conclusive answer.
Since I want the Copy operation to be silent, and not to interrupt operation of the main programme other than for the time taken to copy (in this case move) the file, I gather that the other option is to do a Wimp_StartTask for a wrapper task that issues Wimp_CommandWindow, -1 before issuing the Copy command.
In article <19bfa7a650.davehig...@dsl.pipex.com>, Dave Higton <davehig...@dsl.pipex.com> wrote:
> Can someone with the appropriate knowledge please clarify for me whether > it is safe to issue a Copy command from within a Wimp task (written in > BASIC) simply from an OSCLI?
Yes, it's safe. Try to avoid the "quicker" option, as there have been reports that that causes problems.
> Since I want the Copy operation to be silent, and not to interrupt > operation of the main programme other than for the time taken to copy (in > this case move) the file, I gather that the other option is to do a > Wimp_StartTask for a wrapper task that issues Wimp_CommandWindow, -1 > before issuing the Copy command.
If you are moving a file, you should probably try to rename first, then copy if that fails (which will be much faster if the rename succeeds). Look up OS_FSControl in the PRMs or StrongHelp OS manuals.
Ta,
Steve
-- Steve Revill @ Home Note: All opinions expressed herein are my own.
In message <50a6aa311bst...@revi11.plus.com> "Ste (news)" <st...@revi11.plus.com> wrote:
> In article <19bfa7a650.davehig...@dsl.pipex.com>, > Dave Higton <davehig...@dsl.pipex.com> wrote: > > Can someone with the appropriate knowledge please clarify for me whether > > it is safe to issue a Copy command from within a Wimp task (written in > > BASIC) simply from an OSCLI?
> Yes, it's safe. Try to avoid the "quicker" option, as there have been > reports that that causes problems.
Thanks for that very prompt and authoritative answer!
> > Since I want the Copy operation to be silent, and not to interrupt > > operation of the main programme other than for the time taken to copy (in > > this case move) the file, I gather that the other option is to do a > > Wimp_StartTask for a wrapper task that issues Wimp_CommandWindow, -1 > > before issuing the Copy command.
> If you are moving a file, you should probably try to rename first, then > copy if that fails (which will be much faster if the rename succeeds). Look > up OS_FSControl in the PRMs or StrongHelp OS manuals.
In article <7d79aaa650.davehig...@dsl.pipex.com>, Dave Higton <davehig...@dsl.pipex.com> wrote:
> In message <50a6aa311bst...@revi11.plus.com> > "Ste (news)" <st...@revi11.plus.com> wrote: > > If you are moving a file, you should probably try to rename first, then > > copy if that fails (which will be much faster if the rename succeeds). > > Look up OS_FSControl in the PRMs or StrongHelp OS manuals.
> Never thought of that. Thanks for the tip, Steve.
Specifically, OS_FSControl 25 and 26 are the direct equivalents to *Rename and *Copy (they are what the *commands call). The PRMs/StrongHelp manuals are a bit cryptic about what the flag bits actually do, however. For example, I have no idea what "Given times in block" means or why "Look at destination first" would be an option.
Ta,
Steve
-- Steve Revill @ Home Note: All opinions expressed herein are my own.
The following bytes were arranged on 7 Oct 2009 by Dave Higton :
> Can someone with the appropriate knowledge please clarify for me > whether it is safe to issue a Copy command from within a Wimp > task (written in BASIC) simply from an OSCLI?
I hope so - I've just written a backdrop chooser which does just that. My computer hasn't exploded yet...
-- __<^>__ "Your pet, our passion." - Purina / _ _ \ "Your potential, our passion." - Microsoft, a few months later ( ( |_| ) ) \_> <_/ ======================= Martin Bazley ==========================
In message <19bfa7a650.davehig...@dsl.pipex.com> Dave Higton <davehig...@dsl.pipex.com> wrote:
> Since I want the Copy operation to be silent, and not to > interrupt operation of the main programme other than for the > time taken to copy (in this case move) the file, I gather > that the other option is to do a Wimp_StartTask for a wrapper > task that issues Wimp_CommandWindow, -1
... which, experiments show, causes the entire screen to be redrawn. Not very nice. Just in case anyone is thinking of using the technique.
In message <50a6ab159est...@revi11.plus.com> "Ste (news)" <st...@revi11.plus.com> wrote:
> In article <7d79aaa650.davehig...@dsl.pipex.com>, > Dave Higton <davehig...@dsl.pipex.com> wrote: >> In message <50a6aa311bst...@revi11.plus.com> >> "Ste (news)" <st...@revi11.plus.com> wrote: >>> If you are moving a file, you should probably try to rename first, then >>> copy if that fails (which will be much faster if the rename succeeds). >>> Look up OS_FSControl in the PRMs or StrongHelp OS manuals.
>> Never thought of that. Thanks for the tip, Steve. > Specifically, OS_FSControl 25 and 26 are the direct equivalents to *Rename > and *Copy (they are what the *commands call). The PRMs/StrongHelp manuals > are a bit cryptic about what the flag bits actually do, however. For > example, I have no idea what "Given times in block" means or why "Look at > destination first" would be an option.
"Given times in block" is indeed cryptic in StrongHelp. The PRM explains that flag though and in my opinion, it is misnamed in StrongHelp ("in block" usually means stored in a memory block pointed to by a register). This flag means that only files are copied whose time stamps fall inside the range defined by r4/r5 and r6/r7 (each register pair defines a 5 byte time stamp in low/high order).
"Look at destination first" tells the command to first check the destination to find out whether the source file needs to be copied at all (e.g., in case it is not newer if the Newer flag is set), before loading any data from the source file.
Martin -- --------------------------------------------------------------------- Martin Wuerthner MW Software http://www.mw-software.com/ ArtWorks 2 -- Designing stunning graphics has never been easier spamt...@mw-software.com [replace "spamtrap" by "info" to reply]
> "Look at destination first" tells the command to first check the > destination to find out whether the source file needs to be copied at > all (e.g., in case it is not newer if the Newer flag is set), before > loading any data from the source file.
This primarily helped with really slow file systems such as Econet, where you really don't want to pointlessly load data. Alan
a...@genesis.net.au wrote: >> "Look at destination first" tells the command to first check the >> destination to find out whether the source file needs to be copied at >> all (e.g., in case it is not newer if the Newer flag is set), before >> loading any data from the source file.
> This primarily helped with really slow file systems such as Econet, > where you really don't want to pointlessly load data. > Alan
Not sure why you'd say this: avoiding copying files you already have is clearly a huge gain in many cases, especially if you have most of them already, no matter how fast your filesystem is.
On Oct 14, 1:49 am, Peter Naulls <pe...@chocky.org> wrote:
> a...@genesis.net.au wrote: > >> "Look at destination first" tells the command to first check the > >> destination to find out whether the source file needs to be copied at > >> all (e.g., in case it is not newer if the Newer flag is set), before > >> loading any data from the source file.
> > This primarily helped with really slow file systems such as Econet, > > where you really don't want to pointlessly load data. > > Alan
> Not sure why you'd say this: avoiding copying files you already > have is clearly a huge gain in many cases, especially if you have > most of them already, no matter how fast your filesystem is.
I agree with you entirely.
The reason I said this is that while I was working for Acorn in Australia, this particular option was explained to me by somebody from Acorn UK as existing specifically to help with Econet.
Its just a little historical background rather than anything that makes much sense in the modern world.
Ste (news) wrote: > In article <19bfa7a650.davehig...@dsl.pipex.com>, > Dave Higton <davehig...@dsl.pipex.com> wrote: >> Can someone with the appropriate knowledge please clarify for me whether >> it is safe to issue a Copy command from within a Wimp task (written in >> BASIC) simply from an OSCLI?
> Yes, it's safe. Try to avoid the "quicker" option, as there have been > reports that that causes problems.
It used to cause application workspace to be used in the copy which definitely would not be safe. I can't remember if it still does this.
In message <4ADCA9CC.6090...@druck.freeuk.com> druck <n...@druck.freeuk.com> wrote:
> Ste (news) wrote: >> In article <19bfa7a650.davehig...@dsl.pipex.com>, >> Dave Higton <davehig...@dsl.pipex.com> wrote: >>> Can someone with the appropriate knowledge please clarify for me whether >>> it is safe to issue a Copy command from within a Wimp task (written in >>> BASIC) simply from an OSCLI?
>> Yes, it's safe. Try to avoid the "quicker" option, as there have been >> reports that that causes problems. > It used to cause application workspace to be used in the copy which > definitely would not be safe. I can't remember if it still does this. > ---druc
I have assumed that when the 'quick' option was added then it only trampled over workspace if you used the 'quick' option but never saw any confirmation of this.
|
