Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Runtime vs. Run Engine

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Re: Runtime vs. Run Engine

    Just to add some background.

    We have had runtime licenses for Alpha Five for many years allowing developers to distribute desktop applications that they had developed.

    When version 9 shipped we introduced a variation called run engines which were designed to accommodate SQL tables that were supported through "active links" that were new to version 9.

    After a few months of v9 being on the market, we decided that it would be beneficial for all to introduce an attractively priced license that was very very straightforward to understand and that would apply to both dbf and SQl tables. This license is called the unlimited distribution license for desktop applications and in most cases is the most economical way for developers to distribute desktop applications.

    here is the description we used to introduce the unlimited distribution license for desktop applications

    Distributing your desktop applications just got a whole lot easier!


    With the new Alpha Five v9 Unlimited Distribution License, once you have built your application in Alpha Five v9 Platinum you can:

    Distribute your applications freely with no restrictions.

    Make an unlimited number of copies of your application, including trial or demo copies
    Develop an unlimited number of applications (each with an unlimited number of copies)
    Thanks to all of you who completed our survey. (Yes, we really do take this stuff seriously!)

    Your feedback told us that you felt that Alpha Five V9 was the ultimate tool for building web and desktop applications. You also told us that that you wanted a low cost, unrestricted and simple way to distribute an unlimited number of custom Alpha Five applications that you create.

    As a result of your input, we are delighted to introduce the new Alpha Five v9 Unlimited Distribution License for deploying desktop applications.

    For one low price with the new Alpha Five v9 Unlimited Distribution License, you can distribute as many applications as you like - for as many people as you like. The people to whom you distribute your application do not need to have Alpha Five installed. (It's also ideal for creating demo or trial versions of your commercial software.)

    The Unlimited Distribution License works for both SQL and non-SQL desktop applications. It does require that you first develop your application using a copy of Alpha Five V9 Platinum Edition. (If you already have Alpha Five V9 Standard, you can upgrade to V9 Platinum without having to modify anything.)



    Features of the Unlimited Distribution License

    Create as many applications as you need. Distribute as many copies as you need.
    Works with both .DBF based and SQL based applications (such as SQL Server, MySQL, Oracle, Postgres, Access and more)
    Includes software for building your own custom installation program.
    Restricts users from editing (and possibly breaking) your application.
    Allows users to create and edit their own reports, labels and letters (if you wish to allow them).
    Create your own custom splash screen that appears when the software starts
    Everything you need to distribute your Alpha Five applications, without paying royalties to Alpha Software.
    Ideal for creating demo or trial versions of your commercial software.
    Frequently Asked Questions
    Q: Does this mean that you have discontinued Runtimes and Run Engines?
    A: No. Those products are still available, however, if you plan on distributing your software to more than five people, you'll find that the Unlimited Distribution License is a better deal. For five or fewer people, see our online shop as well as additional offers below.

    Q: Can I use the Unlimited Distribution License with applications developed in the Standard Edition?
    A: No. You need the Platinum Edition to use the Unlimited Distribution License - however you can upgrade to the Platinum edition from the Standard edition. We will give credit for what you paid for the standard edition. Please contact sales to arrange this.

    Q: Are other bundles available besides the ones listed above?
    A: Yes. Please call sales at: +1 781.229.4500 x1 or send an email to [email protected]

    Q: I already own a V9 runtime/run-engine package - can I upgrade to the Unlimited Runtime Distribution license?
    A: Yes. Please contact sales for pricing (see above). You will receive credit.
    Richard Rabins
    Co Chairman
    Alpha Software

    Comment


    • #17
      Re: Runtime vs. Run Engine

      I own 2 x Platignum Full Versions on different PCs but only one Unlimited Runtime Engine, does it make any difference which Platignum Full version that I use to develop and distribute the Runtime applications? What would happen if say one of my customers already had a V9 Full unlimited version already installed on their PC?

      Michael

      Comment


      • #18
        Re: Runtime vs. Run Engine

        Originally posted by Michael Humby View Post
        I own 2 x Platignum Full Versions on different PCs but only one Unlimited Runtime Engine, does it make any difference which Platignum Full version that I use to develop and distribute the Runtime applications??
        No. In fact, you could use both of them. Of course, that would make it more difficult to keep both copies in synch but it could be done.
        Originally posted by Michael Humby View Post
        What would happen if say one of my customers already had a V9 Full unlimited version already installed on their PC?
        They could open your application and make changes to it.

        This is one reason I, and many others, believe in putting all significant code in a global script or function and calling that script/function from the appropriate button or event. That way all significant code can be protected. [Edit: see below for more details.]

        My philosophy is that anyone can see the forms and copy them based on what they look like on the screen so there's really very little point in password protecting the forms themselves. The real key to protecting your work is in protecting any significant code. (Something like "parentform.close()" is not significant so I'd just put that in the OnPush event of my button.)

        There are two ways to protect the global scripts/functions that are in the Code tab:

        The method I always use is just password protecting all my code. This is done by adding one "comment line" like this at the top of the script:
        'password MyPassword
        This works in xbasic scripts. I also know it can be added to Action Scripts but, since I never use AS, I'm not sure whether or not it can be done in a "normal" manner. I created an utility that will add the password to all my xbasic global scripts and functions and discovered that this procedure also works with the Action Scripts. (If anyone is interested, this is part of my Grab Bag addin - a compilation of misc utilities I've created for myself over the years.)

        The important thing to remember when password protecting global scripts/functions (the ones in the Code tab) is that all other passwords are far less secure. For that reason, the password used for the global scripts/functions should ONLY be used in the global scripts/functions. Nothing else in the application should use that same password.

        [Edit: The forms, tables, buttons, etc. can also be password protected but those passwords are actually fairly easy to break. In my opinion, password protecting those things does more to annoy the developer than it does to improve security. The passwords in global scripts/functions are much, much harder to break. FYI: NEVER password protect a scripted field rule event because field rule events don't recognized the password - anybody with a full version of A5 can open the field rule event, read the password, and use it to open any other event script that uses the same password.]

        The other way to protect the code in the Code tab is to create an aex file from them and then delete all the scripts and functions from the Code tab. Making an aex file is easy. Removing all the code from the Code tab can be the hard, or at least time consuming, part. This also creates another issue related to removing the code - how to either restore the code or keep two copies in synch where "development copy #1" contains the code and "development copy #2" is used just for creating the distribution files.

        Frequently asked questions I've received about aex files from other users:

        Do I have to remove the code from the Code tab? The whole purpose in creating the aex file is to protect the code from curious eyes. Leaving the code in the Code tab would defeat that purpose.

        Can't I just restore the code from the aex file? Again the whole purpose of the aex file is to protect the code. Allowing it to be restored from the aex file would defeat that purpose. One way to restore code is to export it to a text file before removing it - this is a built-in feature of A5.

        What if I have a script in the aex file and another by the same name in the Code tab? The one in the Code tab will take precedence over the one in the aex file.

        Is there an easy way to remove the code from the Code tab? Yes and No. I and a few others have created utilities that do this very quickly but it requires a good understanding of the data dictionaries to create something like this. Most people I've talked to have been leery of doing it this way and tend to use the "two development copies" method. For that reason, I've never taken the time to "finish" mine so that it would be appropriate for general distribution. There may be something in the Code Archive but I haven't checked. Of course, one way of keeping a copy of the code to restore later is to export the code to a text file - that's a built-in feature of A5. (My own utility also restores the code and does it much faster than copying it back in from the text file.)

        Breakfast time! over and out.:)
        Last edited by CALocklin; 12-14-2008, 11:50 AM.

        Comment


        • #19
          Re: Runtime vs. Run Engine

          Cal,

          Is the only way to remove scripts from the code tab by right clicking and delete one by one? There does not seem to any way of highlighting multiple scripts. Dr Wayne explains a method compiling the script .aex to the same folder containing the dbase then deleting the alb library via the dbase properties. I can never get this to work, OK the scripts all disappear but they re-appear again the next time that I open the dbase.


          Also you did not mention the 'Option ENCRYPTED_TOKENS' function to place in a script, I am not certain, but my understanding, if you place this in a script before compiling then this will lock the .aex from prying eyes without the need to ' password mypassword. I would like clarity on this from someone in the know and also does Option ENCRYPTED_TOKENS need to be in all the compiled scripts or is it OK to have with only one.

          Michael
          www.instantnurserymanager.co.uk

          Comment


          • #20
            Re: Runtime vs. Run Engine

            Originally posted by Michael Humby View Post
            Is the only way to remove scripts from the code tab by right clicking and delete one by one?
            No but it's the only "built-in" method.
            Originally posted by Michael Humby View Post
            There does not seem to any way of highlighting multiple scripts.
            True.
            Originally posted by Michael Humby View Post
            Dr Wayne explains a method compiling the script .aex to the same folder containing the dbase then deleting the alb library via the dbase properties. I can never get this to work, OK the scripts all disappear but they re-appear again the next time that I open the dbase.
            This works - with some reservations. First, you have to delete all 3 files - the .alb, .alm, and .alx files. Second, you need to be aware that this will remove EVERYTHING stored in those files. That includes A5 security settings, user defined toolbars and menus, the network optimize number, any user-defined settings (a5_save_settings()), backup settings(?), certain (all?) saved queries, and possibly a few other things.

            Originally posted by Michael Humby View Post
            Also you did not mention the 'Option ENCRYPTED_TOKENS' function to place in a script, I am not certain, but my understanding, if you place this in a script before compiling then this will lock the .aex from prying eyes without the need to ' password mypassword.
            Password protection is not required when you compile the scripts to an aex file.

            The aex file is fairly hard to decrypt even if you do not use that option. However, some parts of the code will still appear as plain text which, in some cases, may allow someone to figure out something that you didn't want them to know. If you do use the ENCRYPTED_TOKENS option, none of the code will appear as plain text.
            Originally posted by Michael Humby View Post
            also does Option ENCRYPTED_TOKENS need to be in all the compiled scripts or is it OK to have with only one.
            I'm pretty sure it needs to be in each script.

            Here's another potential issue with using password protection on Action Scripts. First, as mentioned in the previous post, I don't know if there is a "normal" way to add passwords to an Action Script but the utility that's in my Grab Bag will do it. Second - and this is the issue - editing an Action Script that was password protected with my utility will remove the password. As a result, I would always need to run the utililty again to add the password just before making a new installation/update file. That's not a big deal as long as I don't forget it - the whole process takes about 5 seconds to add/remove passwords from 566 scripts and functions. (Passwords in xbasic scripts - which is all I use now - are not removed as a result of editing the script.)

            FWIW: There seem to be two basic philosophies about protecting scripts and I believe the choice is a matter of personal preference. Which is better for you depends on your feelings about how much security you need and how much work you are willing to go through to get it. Personally, I do not compile my application scripts to aex files anymore. Instead I feel that password protecting my global scripts is adequate - not as secure as an aex file but adequate. The issues with removing and restoring scripts plus the simplicity and security of adding password protection is enough for me.

            An aex file is even more secure than password protected scripts and an aex file created with OPTION ENCRYPTED_TOKENS is even more secure. However, neither is 100% secure.

            I should also point out that most of my generic apps are sold to smaller companies who don't really have an IT group (heck, it sometimes seems like they are lucky to know how to turn on their computer!) so the chances of them trying to hack my code is pretty remote. When I build an application for a specific company I do not protect the code at all unless I feel there is a reasonable chance that they will try to sell the app themselves. Some companies have expressed a desire to sell the app and, in that case, (a) I get a written agreement that it will not be sold without my knowledge/consent and (b) I explain to them all the issues I've gone through trying to build other generic apps and they usually decide not to do it.

            FWIW: A generic app that does something very simple might not be an issue. However, some customer(s) will want to see new features and if you build a complex app there will be even more demands for changes and new features plus more issues just due differences in computers. I've been amazed at the differences I've seen in problems using exactly the same application at different companies.

            Cal's Programming Rules:
            1. Every time you fix/update something for someone, something else will go wrong.
            2. The more complex the application gets - i.e., the more fixes and updates you do - the more things will go wrong AND the more likely that it will have different errors on different systems.
            3. Every time you fix something that went wrong with the previous update, something else will go wrong.
            GOTO #1.
            If you eventually get to step 4, take a rest and don't change ANYTHING for a few months:D....
            4. It's working correctly on all systems.

            Comment

            Working...
            X