there are two or three secure ways, though none are absolutely secure, they
are quite annoying if you dont have the real keys...
Remember though that these are annoying and I as a customer hate programs
that do this. You'll also have to keep up with crackers and the lot... Which
means added
Thanks to all who contributed to this thread. Using sendMail.mc without
self-configured SMTP preferences is, I fear, going to cause the potential
users too much confusion. I therefore revert to Plan B and, as suggested,
use a mailto: as the next best alternative.
Plan is to:
[1] store a generic
At 10:27 AM +0100 9/24/00, Hugh Senior wrote:
Thanks to all who contributed to this thread. Using sendMail.mc without
self-configured SMTP preferences is, I fear, going to cause the potential
users too much confusion. I therefore revert to Plan B and, as suggested,
use a mailto: as the next best
On 24/9/00 1:48 am, David Bovill [EMAIL PROTECTED] wrote:
As part of my campaign to make distributable components out of Metacard
groups... I find myself dissatisfied with the way that Metacard looks for an
object by name.
I am at the moment writing for every single object reference that I
Gary Rathbone wrote/ schreef:
If you ask users to change the resolution of the computer you're assuming
they know how to.
I'm not a fan of people having to change their set up in order to cater for
my software. I'd prefer my software catered for their machines. However you
can't please
Dave Cragg wrote/ schreef:
The basic shell command is "start mailto:". You would set it up
something like this:
snip
This should start the user's e-mail program with the to and subject
fields filled out.
To work, it requires the user to have set the default e-mail program
in the internet
David Bovill wrote:
As part of my campaign to make distributable components out of Metacard
groups... I find myself dissatisfied with the way that Metacard looks for an
object by name.
I am at the moment writing for every single object reference that I script
something like:
put
It appears that if I set the cursor to none, any scripts that rely on the
mouseLoc fail, perhaps because MC believes the cursor doesn't exist at all.
If this is true, shouldn't it be the case that setting the cursor to none
simply hides it from view while allowing scripts to poll the mouseLoc?
Recently, I wrote:
It appears that if I set the cursor to none, any scripts that rely on the
mouseLoc fail, perhaps because MC believes the cursor doesn't exist at all.
Sorry, my mistake, based on a commented script line -- the cursor behavior
does work as expected.
Regards,
Scott
