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 basics

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

  • Runtime basics

    I've gone cross-eyed trying to decipher the runtime instructions for A5. Can somebody explain the basics in 100 words or less?

    My first simple application, I have the application files already installed on a server. I want to create a runtime and install it on 2 PCs. The documentation says (not using optimization in this case, I'll tackle that later) 1. Install the application files on a shared folder on the server (which I've done). 2. Install the Run Engine files on each user's machine.

    The documentation also says we are free to make copies of the Run Engine Installation Program (setup.exe) to distribute to your users. So it sounds like I would run the A5 Runtime CD (or the setup.exe from it) on each local machine, then point the runtime program to the shared folder with the application files? Then what is the purpose of the Installation Maker? (Okay, maybe 200 words or less). I just want a basic grounding for simple multi-user installations. Thanks.

    Jack

  • #2
    Re: Runtime basics

    Then what is the purpose of the Installation Maker?
    If you are not at the end user location you can use the Install Maker to automate the install process.
    There can be only one.

    Comment


    • #3
      Re: Runtime basics

      There are a lot of help files on this and a search of this forum will bring you many posts on it.

      simply put, you install your runtime on the user machine, create a runtime by looking up the machine/folder/adb you need to run. Tell it to make the runtime and then tell it where you want it put(suggest you have a folder made for it first). Once done, make yourself a startup on the desktop and you have it.

      59 words???


      .
      Dave Mason
      [email protected]
      Skype is dave.mason46

      Comment


      • #4
        Re: Runtime basics

        Okay, excuse my density on this. I've read a lot of the threads on runtimes and run engines, but I swear the concepts of this seem harder than developing a database application.

        I have A5v9 Platinum, which I've installed on my PC. I have the A5 V9 Platinum Run-Engine, which I've installed on my PC. I have an application, which is installed on a server.

        To get two users set up to use this application, I:

        Carry the Run-Engine CD to the local machines and run setup.exe and enter the license number.

        Point the programs to the application on the shared server.

        No need to run the Installation Maker.

        Right?

        Jack

        Comment


        • #5
          Re: Runtime basics

          Right.
          There can be only one.

          Comment


          • #6
            Re: Runtime basics

            ... and performance can be improved by network optimizing after you have the workstations connected to the database.

            Comment


            • #7
              Re: Runtime basics

              Jack,

              I have no idea about network optimization per Alpha's definition. Please don't take this to understate what others may say. I have just never entered that arena.

              If you get the shadows in a local folder on a workstation, it will work. I would be careful to not let Alpha put it in a shadow folder in your folder. It will work ok, but is another layer to contend with.

              I want my app(shadowed) in a floder like:
              Code:
               c:\myapp  and not c:\myapp\shadow
              Dave Mason
              [email protected]
              Skype is dave.mason46

              Comment


              • #8
                Re: Runtime basics

                Okay, after reading the threads and replies, this concept of the runtime/run engine just kind of freaks me out a little.

                * I bought A5V9 Platinum and the A5V9 Run Engine, installed them on my machine. I'm good to go with writing apps and distributing them (using Install Maker or however I choose).

                * I write an application for a company, go there and copy the app to their shared server. I then install my copy of the Run Engine on, say, 3 machines using the license number from Alpha, then point them to the app on the server.

                * Any or all of those 3 users could now in theory go out and buy a copy of A5V9 (at least until V10 comes out), and because they have the Run Engine installed, they're good to go for developing and distributing applications, even though they didn't pay for the Run Engine.

                Or another scenario:

                The Alpha Software Run Engine documentation says:

                "You are free to make copies of the Alpha Five Run Engine Installation Program (setup.exe) to distribute to your users (each user will require a license.) You can burn your own CDs with these files."

                Say I write an app, send it to a customer along with a burned copy of the Run Engine with instructions for installation and the license key. This customer could in theory distribute the Run Engine to any number of people, who could then buy a copy of A5V9 and then develop applications without having paid for the Run Engine.

                And why does the wording in the license agreement when installing the Run Engine say:

                1. License: ALPHA hereby agrees to grant you a non-exclusive license to use the enclosed ALPHA program (the "Program") on a SINGLE computer, subject to the terms and restrictions set forth in this License AGREEMENT. If you do not agree with the terms of this AGREEMENT, do not install and/or use the software.

                ...when in fact it's apparently a license to install on unlimited computers?

                Maybe I'm misunderstanding or making more of this than it is. And I'm not suggesting I'd violate or even hint to any potential customers they could violate any Run Engine licensing agreement, I'm just trying to wrap my head around this.

                Jack

                Comment


                • #9
                  Re: Runtime basics

                  Okay, upon reflection maybe I'm making more of this than it is. If you consider the Run Engine to be the equivalent of something like the VBRUN.DLL or the .NET framework that needs to be installed for a compiled Visual Basic application to work, then the Run Engine is nothing more than a framework or shell that is useless without an application.

                  And considering the throttle feature, the developer can charge per seat/user if he chooses. And still charge per app to a company. I think I was mostly confused about the verbiage used in the documentation and licensing agreement.

                  Jack

                  Comment


                  • #10
                    Re: Runtime basics

                    Jack,

                    Most of my customers have no idea they are using Alpha on their machine. They don't know about the license number.

                    I use astrum installer in a big way and hide any references to alpha as best I can. The license number is in a file in the app so it does not need to be looked up.

                    There are many threads on here with a great deal of knowledge in the ways to do these things.

                    My main concern is my application, not the runtime. Alpha could have a problem with the runtime. It is their loss, not mine.

                    It is better if you can go to the site and install it yourself, but if not, you will figure out how to protect your apps.

                    .
                    Dave Mason
                    [email protected]
                    Skype is dave.mason46

                    Comment


                    • #11
                      Re: Runtime basics

                      My assessment of this thread is that you are correct. The process is well and truly usable to those that have the way to do so and the throttle feature easy to ignore.

                      I would simply say that if you have developed something that needs "Alcatraz" to protect it, then maybe you have made millions already. You have the option to also protect the actual DB by password. Alpha 5 DBs are are unique to the writer and usually based on the uniquness of the task, much the same as you write a book or a song. Thousands of books write the same story just in different ways. Some make money, but most don't. Only microsoft can afford to spend the money to protect copyright - guess what - they don't even bother.

                      Comment


                      • #12
                        Re: Runtime basics

                        Good point, Dave. Thanks for the comments. I'm just used to writing custom spreadsheets where Excel is already obviously installed on a machine, and Alpha 4 apps way back when, and I had purchased multi-packs of the A4 programs for the network.

                        In my situation it's probably always true that I'll be onsite for the installs, but in any event it's good strategy to protect the app and make it as customized as possible, no visible references to Alpha.

                        Jack

                        Comment


                        • #13
                          Re: Runtime basics

                          the old a4 apps I could change the exe file to run alpha to my own named exe like alpha.exe to daves.exe or whatever. that really threw them off. I have not tried that with a5

                          Alpha does have a built in security for the programmer to set up that protects access. You need to devise your own to keep them from copying to another computer/hard drive.

                          edit: I just tried changing the name of the alpha5.exe in my v7 runtime and it fired right up and ran the app. I have not tested all so far, but it is very promising.

                          renamed alpha5.exe to dave5.exe - it worked!!!

                          Works in V9 also

                          Warning!: It needs to be tested!!!

                          .
                          Last edited by DaveM; 10-13-2009, 10:13 AM.
                          Dave Mason
                          [email protected]
                          Skype is dave.mason46

                          Comment


                          • #14
                            Re: Runtime basics

                            Originally posted by DaveM View Post
                            it worked!!!
                            ...
                            Warning!: It needs to be tested!!!
                            Of course it works.:) I believe it has worked since the runtime first came out - so it doesn't need a lot of testing.

                            It also works with the full version but anyone interested in doing this should also see this thread.

                            Comment

                            Working...
                            X