Update Mac menubar fails in standalone

[Shari]

>Allowing anyone with an existing
>license key to defeat the Starter Kit limits with no restrictions is a
>recipe for disaster, however, and so is not something we're willing to
>consider.
>   Regards,
>     Scott

Yes I understand this, Scott, I'm sure we all do!  Software 
protection is a major issue.  You are simply protecting yours.

I guess that's why I'm so frustrated this week.  What broke when I 
turned the stack into a standalone, among other things, was the 
registration system.  And some of the fixes weaken it.

I had intended to write a self-healing script that would check to 
make sure the script hadn't been tampered with or hacked, and then 
"fix it" or quit if it had.  But apparently it isn't possible with a 
standard license, from within a standalone.  As you can't heal the 
scripts.

I'm presuming this means you can't tamper with the scripts from 
within the program either.  But what about from outside?  That's 
apparently very common.  I'm actually planning to "hack" my own 
program and see if it can be done.  Just for my own peace of mind.

Now that I can send programs into the Windows world, that will 
attract the attention of a lot more of the bad guys.  And I want to 
be prepared.

I read many author's groups.  And it's pretty disgusting how common 
cracks are.  Some authors lose 50% of their sales when a crack comes 
out.  So I do take care with my registration system.

The whole issue of cracks is a much discussed one.  And authors are 
split as to how they handle the issue.  Some say not to spend too 
much time over your protections, to accept that cracks will happen, 
and blow it off.  Others take the opposite tack.  I'm a worse case 
scenario thinker.  I take the opposite tack.  And it's important to 
me to tighten the system for the next programs out the door, in 
anticipation of increased exposure.

I'm still learning the ins and outs of Metacard, and I LOVE the 
program.  I'm delighted overall with it.  But there is so much 
missing in the documentation, that you only learn when you try it, it 
fails, and you spend days trying to determine why.  This project has 
probably taken twice the development time for the learning curve. 
That's frustrating when you can't get the program out the door, and 
it affects the money coming in the door.

At the very least, the documentation should be very very clear about 
the standalone limitations, such as not being able to edit a script 
from within a script, or set the script of object to... or even get 
word 3 of the script of...  that "do" commands are limited to 10 
lines of code... that the LookandFeel may change the way your objects 
look, as the default setting may be different from your normal 
setting (don't assume it looks for your computer type and chooses 
that setting, that was my assumption).

Metacard has opened many doors for me.  I love the freedom it offers, 
and the simplicity of xTalk development.  I made a good choice with 
Metacard.  I am happy.

I just wish the documentation was more thorough.  You can't even buy 
better documentation.  You can look at Revolution's and see if it is 
more helpful, but often, the issues that ball me up, aren't in any 
docs anywhere, even the archives.  And I lose development time.  And 
I get frustrated.

Time is money for all of us.  I have a fella who doesn't accept the 
time I devote to software development, as I'd make a lot more money 
following a more accepted career path.  So I'm fighting like hell to 
bring the software income up to that level.  Whatever slows it down, 
frustrates the hell out of me.

So please pardon me, if sometimes I come across a little hard.

Shari C
-- 
--Shareware Games for the Mac--
http://www.gypsyware.com