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



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

Deployment Guide...

  • Filter
  • Time
  • Show
Clear All
new posts

  • CALocklin
    Re: Deployment Guide...

    I do things a little differently.

    Regarding the original item (1) - aex files:

    I don't bother with aex files. I find the maintenance aspect too much to bother with. Removing and restoring all the code is too much work. (I did create a utility to do it very quickly but even using that was too much trouble when I considered the limited additional benefit.)

    Instead, I password protect all my global scripts and functions. (Take "scripts" to mean "scripts and functions" from here on.) That password is extremely difficult to break IF you don't use it anywhere else. It's probably as difficult as decrypting an aex file - at least for most of us. DO NOT use the same password to protect forms, events, buttons, etc. because they aren't nearly as secure. Use this password ONLY on global scripts and functions (the stuff in the Code tab).

    The way to add a password to a global script or function is to put a comment beginning with 'password on line #1 of the script. Here's an example using a password of "fred":
    'password fred

    The one problem with that is that Action Scripts aren't as easy to password protect as xbasic scripts. However, one of the many utilities in my AIMS Grab Bag is designed to add/remove passwords on global scripts - including Action Scripts - and it can do 500 scripts in a few seconds. This utility will also add passwords to Action Scripts. The only thing you have to watch out for is that the passwords will be removed from an Action Script whenever it is edited. So re-run the the utility to add passwords again before distributing any update. Of course, that's a good idea even if you aren't using Action Scripts.

    Another thing you should do that makes them even more secure is to add OPTIONS Encrypted_tokens even though you aren't creating an aex file. (Thanks to Ira for this one.)

    Hiding the control panel:

    When you hide the control panel, don't forget to allow yourself a way to get back into the app EVEN when on the user's computer using the runtime. You may need to have access to the user's data to fix it or troubleshoot a problem.

    Hint: If it's running on my machine (and I use a weird machine name to help protect it), then, just to make my life easier, my "control panel access" button doesn't prompt for a password. (see api_getmachinename())

    Leave a comment:

  • csda1
    Re: Deployment Guide...

    Hi Wayne

    Protecting you Intellectual Property (IP) in Alpha Five is the exact subject of a future IADN course I will be giving. However, I'll give you a few tips, some may repeat what others have said above.

    Originally posted by WayneS View Post
    (1). One compiles the scripts into a library (aex) file.

    Should the aex file be renamed to something different? Under what conditions would you like to rename it? Pro's and Con's please.
    Name doesn't matter, except if it is the same as the application database's name and located in the same directory, it is automatically loaded.

    Originally posted by WayneS View Post
    (2). Under File -> Database properties one should hide the control panel.

    Does this do the same as a startup form that utilizes controlpanel.hide()? Are there any advantages to doing (2) as opposed to the single line of code?
    I don't believe there is any real difference, but make sure you either have a backup developer copy, or a secret way back in.

    Originally posted by WayneS View Post
    Side-step. By performing these two steps, will the developer be able to alter functionality in code such as one might do in a later release? How would you proceed?
    If you delete all the code files, you need to keep a copy. My CSDA Code Utility has a LibMake function that will allow you to select or pass code lists to compile into an AEX without deleting the original.

    Originally posted by WayneS View Post
    (3). I would ultimately like to provide a link on a web page, similar to what Alpha does, that checks for updates - either runtime or app and then informs the end user of a new update.
    All of my utilities do just that, and actually can perform the install of the update too.

    Keith said to use OPTION ENCRYPTED_TOKENS, which is correct. Get a hex file dumper and look at an AEX, and if you can see any text, then you are may be giving away IP. Take a look at my AEX's with my utilities and you will find only what I want you to see in an AEX.

    Passwords on code tab entries are good if not using in an AEX, otherwise they just get in the way. Passwords on layouts (like forms) and Operations are close to useless, and should be different from the code tab passwords.

    Licensing is another issue, and I have had good success preventing unauthorized using my techniques, but have been trying to complete an advance licensing package that does all the heavy lifting, but it's still not ready. Secure Licensing can be real tricky.

    But there are a variety of additional steps you can take to secure your app too. There is no perfection, but you can make it pretty hard.

    Leave a comment:

  • Keith Hubert
    Re: Deployment Guide...

    Hi Wayne,

    To make small changes to a clients app you should have a good look at this thread here.

    You have an export button on your machine and the import button on your clients machine, which would be on a Utility form, which could only be opened by a person with the authority to do so

    Leave a comment:

  • WayneS
    Re: Deployment Guide...

    Thanks Michael.

    So far if we put the piece together for a Deployment Guide for everyone we have:

    Phase I - Protecting Your Code

    1. OPTION ENCRYPTED_TOKENS (Contributor Keith Hubert, msg. #2)

    Put in all scripts and functions but beware of runtime delay.

    2. Export the Script (Contributor Michael Humby, msg. #4)

    Items 1 and 2 in message.

    Online info for Michael contribution:

    To export a script

    1. Display the Code tab of the Control Panel.
    2. Select Code > Export... or Function > Export... or Script > Export... to display the Export Scripts and/or Functions dialog box.
    3. Select the Scripts, Functions, or Scripts and Functions radio buttons.
    4. Enter the name of the file to export in the Filename field or click to navigate to and select a file to replace.
    5. Optionally, click Export All to display the Export Scripts and Functions to ASCII File dialog box.
    6. Optionally, click Export Selected... to display the Select Scripts and Functions dialog box.
    7. Place checkmarks to the left of each script or function that you want to export.
    8. Optionally, click the Select All or UnSelect All buttons to make your choices.
    9. Click OK.

    3. Remove all Scripts and Functions (Contributor Michael Humby, msg. #4)

    Is this acceptable and accurate so far?

    Thus far the two contributions by Keith and Mike have shed a great deal of light on the procedure(s) we all should be using or minimally consider for deploying an application.

    Are there any other suggestions for proceeding?


    PS. Hopefully by the end of this we will have developed the deployment guide that all of us can use as a "recipe" or algorithm.

    Leave a comment:

  • Michael Humby
    Re: Deployment Guide...

    This is how i handle the scripts before deploying an application.

    As Keith says i place option ENCRYPTED_TOKENS in every script

    1. Via the CP on the code tab i right click and choose Export
    (Take care here because Alpha defaults to the current folder so edit the default save path to your own choice outside of the dbase, otherwise a text file is there for the whole world to see)

    2. i then right click and compile the scripts and functions

    3. I then remove all scripts and functions

    I think i am correct in saying that using this method there is no need to further password protect your scripts by including in the first line 'password mysecretpassword -this should become redundant.

    Welcome other views on this subject.

    Last edited by Michael Humby; 02-21-2010, 12:02 PM.

    Leave a comment:

  • WayneS
    Re: Deployment Guide...

    Hi Keith,

    Thanks for the info.

    Yeap, read similar info in the online help files. Also went through many posts on this board that talked about the button with a password. I would assume that if one created a copy of the entire directory before applying any aex compiling or the database properties -> hide control panel, that a "working copy" could be used for development. After any updates are incorporated, copy that "working directory" to a "product release" directory and then do the aex and hide control panel.

    Often times when one develops an app, there are changes that need to be done at some point in the future, whether it is based on user comment or the developer wanting to add something - like a new form, report or even a table. I would consider those types of things a minor upgrade to whatever is released. The end users must then have some way to download the new updates. In my case, I would like to simply provide a method that the user can use to see if there is a new update available. This is the similarity to what Alpha already does.

    Perhaps a major update would be the jelling of two apps. Based on what I read in various discussions throughout the board, I purchased Astrum. I found InstallMaker to be unreliable, especially in making an update (minor). Of course, introducing new software also introduces new potential problems.

    From what I gather, that software sets up an xml file that is used to look at the version and some registry key. Don't exactly understand how to make that gel within an Alpha app. For instance, does one setup a button that goes to your website and check versions? Cannot phantom the code for this.

    Your guidance is appreciated.


    Leave a comment:

  • Keith Hubert
    Re: Deployment Guide...

    Hi Wayne,

    I think you need to do some experimenting on a dummy database to get the answers you are looking for.

    Here is some info for you that is in the AEX compiler dialog
    To ensure that your scripts cannot be seen by someone who opens an .AEX file in an editor, you can direct Alpha Five to encrypt all or part of each script when it is compiled into an .AEX file.
    The following two commands can be placed anywhere in the body of a script or function:




    These commands must be on line by themselves.

    Any code that follows the OPTION ENCRYPTED_TOKENS command will be encrypted. Any code that follows the OPTION PLAINTEXT_TOKENS will not be encrypted. You can choose to encrypt an entire script, or just portions of the script. There is a slight performance penalty associated with encrypting scripts because Alpha Five must decrypt the script before it can be executed.
    It does not matter which method you choose to hide the CP as long as you build into the app a secret back door. This can be as simple as a button with a password or activating a hotspot if the Administrator logs on.
    With regard to updates, if you are referring to Alpha updates then don't even think about it, unless you are introducing a new feature to the application that you could not achieve before the new update came out. In which case that would be a new install and an update of the application with the new feature you have created for the client.

    At least that has given you some things to think about.

    Leave a comment:

  • WayneS
    started a topic Deployment Guide...

    Deployment Guide...

    Looking for some expert guidance...

    Suppose that an app is completed (whatever that might mean). To protect the code, I assume that:

    (1). One compiles the scripts into a library (aex) file.

    Should the aex file be renamed to something different? Under what conditions would you like to rename it? Pro's and Con's please.

    (2). Under File -> Database properties one should hide the control panel.

    Does this do the same as a startup form that utilizes controlpanel.hide()? Are there any advantages to doing (2) as opposed to the single line of code?

    Side-step. By performing these two steps, will the developer be able to alter functionality in code such as one might do in a later release? How would you proceed?

    (3). I would ultimately like to provide a link on a web page, similar to what Alpha does, that checks for updates - either runtime or app and then informs the end user of a new update.

    I guess this is a shell for ideas. Any guidance would be appreciated as the help provided online does not really give a step-by-step approach to deployment. If it does, I missed it.

    Thanking you in advance,