>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 _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard