Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Clipboard fetching
8 views
Skip to first unread message
Matthew Phillips
Apr 16, 2012, 4:04:14 AM4/16/12
to
While there are such a large number of clipboard experts in the area....
For the first time I am implementing clipboard support in an application. It
doesn't seem too bad, but one thing I was concerned about is the
Message_DataRequest where AppNote 240 states that offset 20 should be the
window handle, and offset 24 an internal handle to indicate the destination.
I was wondering if bad things would happen if I did not give a window handle.
Would any clipboard owning task do anything with the window handle value
other than copy it into the Message_DataSave for the reply?
Might there be an application out there which used the window handle to
determine where to send its replying Message_DataSave, rather than using the
task handle of the task it received the Message_DataRequest from?
I was wanting to avoid giving a window handle so that the Message_DataSave
does not get picked up by my event handlers for the ordinary data trabsfer
protocol.
Does anyone have any direct experience of this which would reassure me this
is OK to do?
--
Matthew Phillips
Durham
For the first time I am implementing clipboard support in an application. It
doesn't seem too bad, but one thing I was concerned about is the
Message_DataRequest where AppNote 240 states that offset 20 should be the
window handle, and offset 24 an internal handle to indicate the destination.
I was wondering if bad things would happen if I did not give a window handle.
Would any clipboard owning task do anything with the window handle value
other than copy it into the Message_DataSave for the reply?
Might there be an application out there which used the window handle to
determine where to send its replying Message_DataSave, rather than using the
task handle of the task it received the Message_DataRequest from?
I was wanting to avoid giving a window handle so that the Message_DataSave
does not get picked up by my event handlers for the ordinary data trabsfer
protocol.
Does anyone have any direct experience of this which would reassure me this
is OK to do?
--
Matthew Phillips
Durham
Martin Wuerthner
Apr 19, 2012, 11:29:46 AM4/19/12
to
In message <63a337815...@sinenomine.freeserve.co.uk>
sent to, and since messages can be sent to windows or tasks, the
recipient could indeed choose to send it to the given window. The
usual meaning of "replying" to a message is to send the reply to the
sending task though, so that approach seems unlikely.
Interestingly enough, looking at the EasiWriter source code, there is
a comment that suggests that some ancient version of EasiWriter
(before Feb 2000) did probably send the reply to the window/icon
handles as given at offsets +20 and +24 and not back to the sending
task. Apparently, at the request of Justin Fletcher EasiWriter was
changed, so replies to DataRequest messages are sent back to the
originating task.
> I was wanting to avoid giving a window handle so that the Message_DataSave
> does not get picked up by my event handlers for the ordinary data trabsfer
> protocol.
The message reference can be used to distinguish ordinary save
requests from other applications from replies to your own DataRequest
messages. Alternatively, you could have a hidden window just as a
target for your clipboard requests.
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> While there are such a large number of clipboard experts in the area....
> For the first time I am implementing clipboard support in an application. It
> doesn't seem too bad, but one thing I was concerned about is the
> Message_DataRequest where AppNote 240 states that offset 20 should be the
> window handle, and offset 24 an internal handle to indicate the destination.
> I was wondering if bad things would happen if I did not give a window handle.
> Would any clipboard owning task do anything with the window handle value
> other than copy it into the Message_DataSave for the reply?
> Might there be an application out there which used the window handle to
> determine where to send its replying Message_DataSave, rather than using the
> task handle of the task it received the Message_DataRequest from?
Unfortunately, the protocol does not state where the reply should be
> While there are such a large number of clipboard experts in the area....
> For the first time I am implementing clipboard support in an application. It
> doesn't seem too bad, but one thing I was concerned about is the
> Message_DataRequest where AppNote 240 states that offset 20 should be the
> window handle, and offset 24 an internal handle to indicate the destination.
> I was wondering if bad things would happen if I did not give a window handle.
> Would any clipboard owning task do anything with the window handle value
> other than copy it into the Message_DataSave for the reply?
> Might there be an application out there which used the window handle to
> determine where to send its replying Message_DataSave, rather than using the
> task handle of the task it received the Message_DataRequest from?
sent to, and since messages can be sent to windows or tasks, the
recipient could indeed choose to send it to the given window. The
usual meaning of "replying" to a message is to send the reply to the
sending task though, so that approach seems unlikely.
Interestingly enough, looking at the EasiWriter source code, there is
a comment that suggests that some ancient version of EasiWriter
(before Feb 2000) did probably send the reply to the window/icon
handles as given at offsets +20 and +24 and not back to the sending
task. Apparently, at the request of Justin Fletcher EasiWriter was
changed, so replies to DataRequest messages are sent back to the
originating task.
> I was wanting to avoid giving a window handle so that the Message_DataSave
> does not get picked up by my event handlers for the ordinary data trabsfer
> protocol.
requests from other applications from replies to your own DataRequest
messages. Alternatively, you could have a hidden window just as a
target for your clipboard requests.
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
Gerph
Apr 19, 2012, 7:18:29 PM4/19/12
to
On Apr 19, 4:29 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> In message <63a3378152.Matt...@sinenomine.freeserve.co.uk>
in the message block, unless the message explicitly requires you not
to as part of its protocol. Doing anything other than that will break
recorded delivery messages and in any case would prevent the sender
from actually receiving the message.
> Interestingly enough, looking at the EasiWriter source code, there is
> a comment that suggests that some ancient version of EasiWriter
> (before Feb 2000) did probably send the reply to the window/icon
> handles as given at offsets +20 and +24 and not back to the sending
> task. Apparently, at the request of Justin Fletcher EasiWriter was
> changed, so replies to DataRequest messages are sent back to the
> originating task.
Hmm. It's quite possible that there's a record of why somewhere,
then... although before 2000 it would be tricky to find... One mail
about my MimeMap module slowing down PipeFS transfers... that's not
it. A few discussions about what applications support Clipboard,
although those are 2002. A quick roundup of the tools that supported
Clipboard, dated Mar 25, 1999 (news posting, so probably still on
google). Sorry, can't find any email or news posting in a quick
search.
That's a little disappointing, as the whole reason for keeping mail
going back years is to remind me why I might have said something. :-
( I hope I knew what I was talking about.
--
Gerph
> In message <63a3378152.Matt...@sinenomine.freeserve.co.uk>
> Matthew Phillips <spam20...@yahoo.co.uk> wrote:
>
> > While there are such a large number of clipboard experts in the area....
> > For the first time I am implementing clipboard support in an application. It
> > doesn't seem too bad, but one thing I was concerned about is the
> > Message_DataRequest where AppNote 240 states that offset 20 should be the
> > window handle, and offset 24 an internal handle to indicate the destination.
> > I was wondering if bad things would happen if I did not give a window handle.
> > Would any clipboard owning task do anything with the window handle value
> > other than copy it into the Message_DataSave for the reply?
> > Might there be an application out there which used the window handle to
> > determine where to send its replying Message_DataSave, rather than using the
> > task handle of the task it received the Message_DataRequest from?
>
> Unfortunately, the protocol does not state where the reply should be
> sent to, and since messages can be sent to windows or tasks, the
> recipient could indeed choose to send it to the given window. The
> usual meaning of "replying" to a message is to send the reply to the
> sending task though, so that approach seems unlikely.
When replying to messages you should always reply to the sender field
>
> > While there are such a large number of clipboard experts in the area....
> > For the first time I am implementing clipboard support in an application. It
> > doesn't seem too bad, but one thing I was concerned about is the
> > Message_DataRequest where AppNote 240 states that offset 20 should be the
> > window handle, and offset 24 an internal handle to indicate the destination.
> > I was wondering if bad things would happen if I did not give a window handle.
> > Would any clipboard owning task do anything with the window handle value
> > other than copy it into the Message_DataSave for the reply?
> > Might there be an application out there which used the window handle to
> > determine where to send its replying Message_DataSave, rather than using the
> > task handle of the task it received the Message_DataRequest from?
>
> Unfortunately, the protocol does not state where the reply should be
> sent to, and since messages can be sent to windows or tasks, the
> recipient could indeed choose to send it to the given window. The
> usual meaning of "replying" to a message is to send the reply to the
> sending task though, so that approach seems unlikely.
in the message block, unless the message explicitly requires you not
to as part of its protocol. Doing anything other than that will break
recorded delivery messages and in any case would prevent the sender
from actually receiving the message.
> Interestingly enough, looking at the EasiWriter source code, there is
> a comment that suggests that some ancient version of EasiWriter
> (before Feb 2000) did probably send the reply to the window/icon
> handles as given at offsets +20 and +24 and not back to the sending
> task. Apparently, at the request of Justin Fletcher EasiWriter was
> changed, so replies to DataRequest messages are sent back to the
> originating task.
then... although before 2000 it would be tricky to find... One mail
about my MimeMap module slowing down PipeFS transfers... that's not
it. A few discussions about what applications support Clipboard,
although those are 2002. A quick roundup of the tools that supported
Clipboard, dated Mar 25, 1999 (news posting, so probably still on
google). Sorry, can't find any email or news posting in a quick
search.
That's a little disappointing, as the whole reason for keeping mail
going back years is to remind me why I might have said something. :-
( I hope I knew what I was talking about.
--
Gerph
Matthew Phillips
Apr 20, 2012, 6:09:59 PM4/20/12
to
In message <a17dba65-dd1e-4e9c...@i2g2000vbd.googlegroups.com>
window handle in Message_DataSave. I'm sure that paranoia ought to be a
virtue, along with laziness, hubris and whatever the other one is in
"Programming Perl".
I did think of a neat way round the messages getting grabbed by the wrong
handler, based on Martin's suggestion of looking at the your_ref field, but
as time is short and the application works with EasiWriter (the only software
worth testing with) I may make do with what I've got for the initial release!
Thank you, experts!
--
Matthew Phillips
Durham
on 20 Apr 2012 Gerph wrote:
> On Apr 19, 4:29 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> > In message <63a3378152.Matt...@sinenomine.freeserve.co.uk>
> > Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> >
> > > Would any clipboard owning task do anything with the window handle
> > > value other than copy it into the Message_DataSave for the reply? Might
> > > there be an application out there which used the window handle to
> > > determine where to send its replying Message_DataSave, rather than
> > > using the task handle of the task it received the Message_DataRequest
> > > from?
> >
> > Unfortunately, the protocol does not state where the reply should be
> > sent to, and since messages can be sent to windows or tasks, the
> > recipient could indeed choose to send it to the given window. The
> > usual meaning of "replying" to a message is to send the reply to the
> > sending task though, so that approach seems unlikely.
>
> When replying to messages you should always reply to the sender field
> in the message block, unless the message explicitly requires you not
> to as part of its protocol. Doing anything other than that will break
> recorded delivery messages and in any case would prevent the sender
> from actually receiving the message.
So only the utterly paranoid programmer should worry about not putting a real
> On Apr 19, 4:29 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> > In message <63a3378152.Matt...@sinenomine.freeserve.co.uk>
> > Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> >
> > > Would any clipboard owning task do anything with the window handle
> > > value other than copy it into the Message_DataSave for the reply? Might
> > > there be an application out there which used the window handle to
> > > determine where to send its replying Message_DataSave, rather than
> > > using the task handle of the task it received the Message_DataRequest
> > > from?
> >
> > Unfortunately, the protocol does not state where the reply should be
> > sent to, and since messages can be sent to windows or tasks, the
> > recipient could indeed choose to send it to the given window. The
> > usual meaning of "replying" to a message is to send the reply to the
> > sending task though, so that approach seems unlikely.
>
> When replying to messages you should always reply to the sender field
> in the message block, unless the message explicitly requires you not
> to as part of its protocol. Doing anything other than that will break
> recorded delivery messages and in any case would prevent the sender
> from actually receiving the message.
window handle in Message_DataSave. I'm sure that paranoia ought to be a
virtue, along with laziness, hubris and whatever the other one is in
"Programming Perl".
I did think of a neat way round the messages getting grabbed by the wrong
handler, based on Martin's suggestion of looking at the your_ref field, but
as time is short and the application works with EasiWriter (the only software
worth testing with) I may make do with what I've got for the initial release!
Thank you, experts!
--
Matthew Phillips
Durham
Gerph
Apr 21, 2012, 4:18:41 AM4/21/12
to
On Apr 20, 11:09 pm, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> In message <a17dba65-dd1e-4e9c-85ba-06dd6a048...@i2g2000vbd.googlegroups.com>
specification and the implications of doing so. Then you will reach
true enlightenment. Or something like that anyhow.
> I did think of a neat way round the messages getting grabbed by the wrong
> handler, based on Martin's suggestion of looking at the your_ref field, but
> as time is short and the application works with EasiWriter (the only software
> worth testing with) I may make do with what I've got for the initial release!
Um... There are a slew of applications which support the clipboard,
and EasiWriter is just one of many. In '99 I did a quick survey of the
applications which supported the clipboard for an internal review
prior to implementing ClipboardHolder, and there were quite a few
applications. I've lost the report I did, but the preparation for it -
asking on newsgroups - yielded this:
http://groups.google.com/group/comp.sys.acorn.misc/msg/6a0f247f77d02f90
That's 13 years ago. You might find that there are a few more
applications out there that have support for the clipboard. I'd
suggest that being sure that things worked with Zap and StrongEd would
be wise, as would checking with Draw and Paint, if you handle non-text
formats. And of course DataPower is probably definitive.
Pragmatism shouldn't include testing with a limited subset when a
wider test set is readily available. If your time is insufficient for
testing more widely, then you are accepting that you will get a
greater number of support requests for issues that you were unaware
of, and potentially serious issues that require further development
later. If you accept that, then that's ok.
--
Gerph.
> In message <a17dba65-dd1e-4e9c-85ba-06dd6a048...@i2g2000vbd.googlegroups.com>
> on 20 Apr 2012 Gerph wrote:
>
> > On Apr 19, 4:29 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> > > In message <63a3378152.Matt...@sinenomine.freeserve.co.uk>
> > > Matthew Phillips <spam20...@yahoo.co.uk> wrote:
>
> > > > Would any clipboard owning task do anything with the window handle
> > > > value other than copy it into the Message_DataSave for the reply? Might
> > > > there be an application out there which used the window handle to
> > > > determine where to send its replying Message_DataSave, rather than
> > > > using the task handle of the task it received the Message_DataRequest
> > > > from?
>
> > > Unfortunately, the protocol does not state where the reply should be
> > > sent to, and since messages can be sent to windows or tasks, the
> > > recipient could indeed choose to send it to the given window. The
> > > usual meaning of "replying" to a message is to send the reply to the
> > > sending task though, so that approach seems unlikely.
>
> > When replying to messages you should always reply to the sender field
> > in the message block, unless the message explicitly requires you not
> > to as part of its protocol. Doing anything other than that will break
> > recorded delivery messages and in any case would prevent the sender
> > from actually receiving the message.
>
> So only the utterly paranoid programmer should worry about not putting a real
> window handle in Message_DataSave. I'm sure that paranoia ought to be a
> virtue, along with laziness, hubris and whatever the other one is in
> "Programming Perl".
As always, be pragmatic. Realise that you are accepting deviance from
>
> > On Apr 19, 4:29 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> > > In message <63a3378152.Matt...@sinenomine.freeserve.co.uk>
> > > Matthew Phillips <spam20...@yahoo.co.uk> wrote:
>
> > > > Would any clipboard owning task do anything with the window handle
> > > > value other than copy it into the Message_DataSave for the reply? Might
> > > > there be an application out there which used the window handle to
> > > > determine where to send its replying Message_DataSave, rather than
> > > > using the task handle of the task it received the Message_DataRequest
> > > > from?
>
> > > Unfortunately, the protocol does not state where the reply should be
> > > sent to, and since messages can be sent to windows or tasks, the
> > > recipient could indeed choose to send it to the given window. The
> > > usual meaning of "replying" to a message is to send the reply to the
> > > sending task though, so that approach seems unlikely.
>
> > When replying to messages you should always reply to the sender field
> > in the message block, unless the message explicitly requires you not
> > to as part of its protocol. Doing anything other than that will break
> > recorded delivery messages and in any case would prevent the sender
> > from actually receiving the message.
>
> So only the utterly paranoid programmer should worry about not putting a real
> window handle in Message_DataSave. I'm sure that paranoia ought to be a
> virtue, along with laziness, hubris and whatever the other one is in
> "Programming Perl".
specification and the implications of doing so. Then you will reach
true enlightenment. Or something like that anyhow.
> I did think of a neat way round the messages getting grabbed by the wrong
> handler, based on Martin's suggestion of looking at the your_ref field, but
> as time is short and the application works with EasiWriter (the only software
> worth testing with) I may make do with what I've got for the initial release!
and EasiWriter is just one of many. In '99 I did a quick survey of the
applications which supported the clipboard for an internal review
prior to implementing ClipboardHolder, and there were quite a few
applications. I've lost the report I did, but the preparation for it -
asking on newsgroups - yielded this:
http://groups.google.com/group/comp.sys.acorn.misc/msg/6a0f247f77d02f90
That's 13 years ago. You might find that there are a few more
applications out there that have support for the clipboard. I'd
suggest that being sure that things worked with Zap and StrongEd would
be wise, as would checking with Draw and Paint, if you handle non-text
formats. And of course DataPower is probably definitive.
Pragmatism shouldn't include testing with a limited subset when a
wider test set is readily available. If your time is insufficient for
testing more widely, then you are accepting that you will get a
greater number of support requests for issues that you were unaware
of, and potentially serious issues that require further development
later. If you accept that, then that's ok.
--
Gerph.
Matthew Phillips
Apr 21, 2012, 5:32:05 AM4/21/12
to
In message <94d31ec7-870a-4327...@f5g2000vbt.googlegroups.com>
smiley and a closing parenthesis immediately after might cause parsing
problems.
Of course, EasiWriter is one of the worst applications to test against as it
is very well written. Testing against badly-written software is more
enlightening.
--
Matthew Phillips
Durham
on 21 Apr 2012 Gerph wrote:
> On Apr 20, 11:09 pm, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
>
> > as time is short and the application works with EasiWriter (the only
> > software worth testing with) I may make do with what I've got for the
> > initial release!
>
> Um... There are a slew of applications which support the clipboard,
> and EasiWriter is just one of many.
Sorry, I wasn't being entirely serious, but I was worried that putting a
> On Apr 20, 11:09 pm, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
>
> > as time is short and the application works with EasiWriter (the only
> > software worth testing with) I may make do with what I've got for the
> > initial release!
>
> Um... There are a slew of applications which support the clipboard,
> and EasiWriter is just one of many.
smiley and a closing parenthesis immediately after might cause parsing
problems.
Of course, EasiWriter is one of the worst applications to test against as it
is very well written. Testing against badly-written software is more
enlightening.
--
Matthew Phillips
Durham
Gerph
Apr 21, 2012, 7:26:57 AM4/21/12
to
On Apr 21, 10:32 am, Matthew Phillips <spam20...@yahoo.co.uk> wrote:
> In message <94d31ec7-870a-4327-8793-964aaf652...@f5g2000vbt.googlegroups.com>
Ah, sorry! I cannot disagree with that :-)
I hope that what I said was taken as good advice and not too
patronising.
--
Gerph
> In message <94d31ec7-870a-4327-8793-964aaf652...@f5g2000vbt.googlegroups.com>
I hope that what I said was taken as good advice and not too
patronising.
--
Gerph
Rick Murray
Apr 21, 2012, 10:14:03 AM4/21/12
to
On Sat, 21 Apr 2012 10:32:05 +0100, Matthew Phillips
<spam...@yahoo.co.uk> wrote:
> Testing against badly-written software is more enlightening.
Just so long as your brain is engaged well enough to be able to tell
<spam...@yahoo.co.uk> wrote:
> Testing against badly-written software is more enlightening.
if subsequent faults are your code, the buggy other application, or
something wrong in the API itself (rare, but not impossible).
It takes me many cups of tea to reach this state, and since I now
work night shift (does wonders for the powers of concentration) I
usually just cop out and watch animé instead... or stuff like
http://www.youtube.com/watch?v=59ZYrB8Ws7Y
:-D
Best wishes,
Rick.
Matthew Phillips
Apr 21, 2012, 7:56:25 PM4/21/12
to
In message <27a8adf5-23a5-40f7...@fo16g2000vbb.googlegroups.com>
I have now fixed my code to send the correct window handle. It turned out
the convoluted handler system inside the application was going to deliver the
reply to the right place, so that's fine.
--
Matthew Phillips
Durham
on 21 Apr 2012 Gerph wrote:
> I hope that what I said was taken as good advice and not too patronising.
Yes: very good advice, and not at all patronising.
> I hope that what I said was taken as good advice and not too patronising.
I have now fixed my code to send the correct window handle. It turned out
the convoluted handler system inside the application was going to deliver the
reply to the right place, so that's fine.
--
Matthew Phillips
Durham
Matthew Phillips
Apr 21, 2012, 7:54:23 PM4/21/12
to
In message <almarsoft.5844...@news.orange.fr>
of development, and then testing against bad later will help you make your
software more tolerant.
Any recommendations for bad RISC OS software?!
--
Matthew Phillips
Durham
on 21 Apr 2012 Rick Murray wrote:
> On Sat, 21 Apr 2012 10:32:05 +0100, Matthew Phillips
> <spam...@yahoo.co.uk> wrote:
>
> > Testing against badly-written software is more enlightening.
>
> Just so long as your brain is engaged well enough to be able to tell
> if subsequent faults are your code, the buggy other application, or
> something wrong in the API itself (rare, but not impossible).
That's true. Testing against software you trust is best in the early stages
> On Sat, 21 Apr 2012 10:32:05 +0100, Matthew Phillips
> <spam...@yahoo.co.uk> wrote:
>
> > Testing against badly-written software is more enlightening.
>
> Just so long as your brain is engaged well enough to be able to tell
> if subsequent faults are your code, the buggy other application, or
> something wrong in the API itself (rare, but not impossible).
of development, and then testing against bad later will help you make your
software more tolerant.
Any recommendations for bad RISC OS software?!
--
Matthew Phillips
Durham
Rick Murray
Apr 21, 2012, 11:37:09 PM4/21/12
to
On Sun, 22 Apr 2012 00:54:23 +0100, Matthew Phillips
<spam...@yahoo.co.uk> wrote:
> Any recommendations for bad RISC OS software?!
<cough> <whistles loudly> <walks away>
<spam...@yahoo.co.uk> wrote:
> Any recommendations for bad RISC OS software?!
. . .
Best wishes,
Rick.
PS: When developing, just make it work with a useful selection and
try not to do anything too "clever" when it comes to interactions
with other things (including the OS). If, then, a problem is
reported, you can look into it on a case-by-case basis. As a
programmer, your priority is to make the best software you can, not
to take too long fixing other people's software.
One final thing that is useful: code defensively. The API might say
"should be zero" but you shouldn't actually *rely* upon it being so.
If you have a key handler, for example, be sure to cope with zero and
negative numbers and stuff wildly out of range. In a case like that,
a simple bounds check and reject anything that doesn't seem right.
Programming is like driving, you MUST assume everything else was
written by a nutjob weirdo that, rather than giving you the handle
you requested, might instead provide you with a hex encoded
representation of Kerry Katona's phone number if the API is called at
the stroke of midnight. You know, for the lulz. Validate input, give
good output, and know that sometimes it is acceptable to fail
silently if the result otherwise is a stack of errors the user can't
fix, and an effect that doesn't change much anyway...
Rick Murray
Apr 21, 2012, 11:42:02 PM4/21/12
to
On Sun, 22 Apr 2012 05:37:09 +0200, Rick Murray
<heyrickma...@yahoo.co.uk> wrote:
> Validate input, give good output, and know that sometimes it is
> acceptable to fail silently if the result otherwise is
God, I sound like I ought to be in a recliner smoking a pipe, gently
<heyrickma...@yahoo.co.uk> wrote:
> Validate input, give good output, and know that sometimes it is
> acceptable to fail silently if the result otherwise is
stroking a deck of punch card, and using a U-matic tape for a
doorstop.
"When I were a lad..."
Best wishes,
Rick.
PS: I actually *have* a U-matic tape. No idea what is on it. Probably
a long lost episode of Dr. Who...
0 new messages