LiveCode Forums.

Richard,

Your script is almost the same as what I already proposed earlier in this thread.

Mark

Indeed it is, yet after the subsequent posts about using the address it seemed helpful as a reminder.

You think people might forget, after reading this not-so-very-long thread?

Mark

Monte,

If I remember correctly, the revLicenseType function caused an error in standalones made with older versions. Does this function work in standalones now?

According to the dictionary, one shouldn't use this function and it would always return "Enterprise". I know that this dictionary entry is wrong, but perhaps one should refrain from using this function, just to be sure.

Kind regards,

Mark

I don't see any mention of standalones in the original question. If that's a requirement then I'm sorry. Use Richard's function instead.

..........

Thanks for all the comments and different solutions.

As usual with LiveCode many alternate ways to solve a problem..that's not a critisim by the way

AndyP wrote: As usual with LiveCode many alternate ways to solve a problem..

TMTOWTDI

A very old mantra which applies to most of dynamic modern languages
including Livecode

By the way, I like Mark's one


Regards,

Thierry

..........

[-hh] wrote:Assume there is an external to password protect scripts (Monte certainly could do this at once, right out of his brain). And if such an external is simply adding "set password" to the vocabulary of community versions of the IDE.
How would you then distinguish between commercial and community versions of the IDE?

Historically, the engine does not allow us to override built-in engine commands and functions. This is done primarily for performance reasons, but it can also be considered a security measure as well: if my library can alter the behavior of your scripts by intercepting commands you intended to be handled by the engine, the results could range from annoyance to catastrophe.

For these reasons, even when the "open language" initiative is released, I doubt they'd allow all the built-in commands to be overridable.

That said, there are legitimate reasons why one might want to protect scripts in the Community Edition, mostly to ensure their integrity against possibly alteration by other scripts with malicious intent.

This has been raised to the development team, but I suspect that if a solution is offered, or even if a solution were to come from the community, it would not affect the expected behavior of the engine's current password mechanism.

[-hh] wrote:There remains one problem.
Assume there is an external to password protect scripts (Monte certainly could do this at once, right out of his brain). And if such an external is simply adding "set password" to the vocabulary of community versions of the IDE.
How would you then distinguish between commercial and community versions of the IDE?

Monte, don't do that!

Thierry wrote:Monte, don't do that!

Relax... I think @-hh is overrating my brain here...

Relax... I think @-hh is overrating my brain here...

Oups, sorry.
Was supposed to be a joke...

Hi,

First of all, I don´t think that the externals API currently allows for properties, but I suppose that this could be changed. If there is an external that can set a password using a password property or command, this property or command should be in the externalCommands or externalFunctions, or perhaps in the externalProperties (which doesn't exist yet). If it were in the externalProperties, you'd know that it isn't in the engine and hence you'd be using the open source edition.

Kind regards,

Mark