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

Copy Form to - a bug?

  • Filter
  • Time
  • Show
Clear All
new posts

    Copy Form to - a bug?

    Can someone else try this and let me know the results?
    Take two very similar tables. Almost the same fields in both.
    Copy a form from one table to the other.
    Put an action button on the new copied form.
    Go into action scripting and define an "on push" event.
    Select "Set Values" for the action.
    Look at the field choices you have to select from. Are they the ones from the original form? Mine are. I can change the fields on the form to refer to the fields of the "copied to" table but I can't get the right fields to select from in the SET VALUES choices for the onpush event of the button.
    Jim Belanger

    Re: Copy Form to - a bug?


    When you copied over the form to the new table with similar fields, when you first opened the form based on the new table you should have received error messages that the fields did not match.

    You then go to the form in design mode and right click on each field and then assign them the new field names - you should also change the object name to the new field name - ie if the old field was lastname and the new field is just name, after you changed the field from lastname to name, the object name would have remained lastname unless you change it to the new fieldname.

    So when you change the field names to the new names in that table you should change the object names also.

    This will allow you to see the object names in the set values for fields genie.

    Tom Baker

    Edit: I wouldn't classify this as a bug.
    Last edited by Tbaker; 06-27-2008, 10:18 PM. Reason: One last thought


      Re: Copy Form to - a bug?

      Thanks Tom but, I did that already. My last sentence in my post was:

      I can change the fields on the form to refer to the fields of the "copied to" table but I can't get the right fields to select from in the SET VALUES choices for the onpush event of the button.

      I have the form working fine with the correct fields and no errors. It's the action script with the SET VALUES function that has the problem. From what you said, I don't think you tried that.
      Jim Belanger


        Re: Copy Form to - a bug?


        I tried to use set values in action script first and got the same thing you did. Then I did what appears next.

        Not only change the field name on the form by using properties, but also change the object name in the properties to that field name. After that the action scripting for set values will include the new names of the objects.

        The set values property in AS does not show the field name, it shows the name of the object, so if you just change the field name the objects names stays as it was from the earlier form and that will show up in the set values properties in AS.

        In other words in the old form the name of the field was last_name, the object name for that field, by default, was "last_name". When you copied that form to use the new table and just changed the field name to the field in the new table (say Surname) the object would still be "last_name" and that it what would show up in set values in AS.

        You need to change the properties of the form field in two places - 1. change the field to the new field in the new table and 2. change the name of the object to reflect that new name - you can name it anything that you wish as long as it means something to you.

        Tom Baker


          Re: Copy Form to - a bug?

          OK, I tried what you said. First, I deleted all the titles of the fields. Then, I checked all the fields and they were from the correct table. No good.
          Then, I dragged and dropped all the field titles from the correct table onto the form. Now, both the fields themselves and the titles are from the right table. Still the same results.

          Go ahead and play with it. I really want to know what I'm doing wrong if this is not a program problem. Try to program the button on the bottom of the B/O Receipt form.
          Jim Belanger


            Re: Copy Form to - a bug?


            You are using the term "field title" which confuses me a bit. Are you referring to the field label? If so, that is not what Tom said. He is referring to the object name. Right click on one of the data objects and select properties. On the Setup tab you will see Object Name.


              Re: Copy Form to - a bug?


              I have attached an update of your zip file

              First I took of the restrict enter in the form's properties

              then- I opened the form in the design mode, right clicked on each field - then changed the "Object Name" to a new name in each field.

              I then click on the button chose on push event then action scripting
              set values for fields - then selected the fields in the genie which now display the names that I have given each field (not the field_name) and gave a value for each one of them.

              As Doug pointed out and from reading your last post - you said you used drag and drop to move the titles over to the form - that does not change the object name, which the genie uses to display each field available in the form.

              I hope my explanation is clearer now.

              Tom Baker

              Open the B/O receipts form and click to enter a new record - then push the B/O receipts button. That will enter a record into the field based on the values that I gave them in the "set values for fields" based on the object names I gave them. I set the values for each field since there was a table missing called "B/O receipts" which I guess would have entered the data for the fields that were read only.


                Re: Copy Form to - a bug?

                Yes, I was looking at the field label. I apologize for not understanding. But, the object name comes from the name given in Field Rules and I don't think it makes any difference to the problem. In the zip example you sent back to me, go to the B/O Complete button again. then go into the action script and click on the plus sign to add more values to set. You will see there the field with the name "complete". It does not exist in the backorders table. It exists in the orders table from which the form was copied. So, as I said (unless I'm still mistaken) the fields shown are those of the other table. I really appreciate your help but your zipped file still has what I perceive to be my problem.
                Jim Belanger


                  Re: Copy Form to - a bug?


                  When you open the "set field values" the list that you are seeing to set values are the name of each individual object as shown in the properties for that field.

                  In the case of complete, it came from the orders forms that was copied however when you changed the field to reflect the equivalent field in your new table, you changed the field to what it should be (in this case "on_backorder" (a logical field). The object name was still "Complete".

                  If you opened the "set field values" and clicked on the "plus sign" you could have set that field value to "true or false" and that is what would have been entered into the field on the form called "on_backorder"


                  In design mode for the new form, right click on the field in form called "on_backorder", select properties, then the setup tab and in the box for object name, change the name to "On_backorder". Now when you open the set field values genie and click the plus sign, "complete" would not be there anymore, "on_backorder" would be since you changed the object name to that in the set up properties.

                  In otherwords, you can open the properties for each field and change the object name to anything you want it to be that make sense to you - however - whatever is in that object name will show in AS Set Field Values genie when you click the plus sign.

                  Jim, you are right when you copy a form from one table to a similar table, the names in the AS Set field Values still hold the object name of those fields in the old table - but before you could use that new form, you would (and you did) went into properties and set the fields to the equivalent field in the new table. Now when you open the AS Set field value genie, even though those names shown (object names) are the same as the original table, they point to the field in the new table.

                  It took me a long time to understand the difference between fields on a form and object names of those fields - If you wanted you could have a table field called Job_class and you could call the object name "Profession". "Profession is what would show in AS Set Field Values but it still would point to the field on the form and the table field "Job Class".

                  Hope that makes sense to you.

                  Tom Baker


                    Re: Copy Form to - a bug?

                    Originally posted by Beltronics View Post
                    the object name comes from the name given in Field Rules....
                    Form the documentation.
                    Object Names

                    An object name must be alphanumeric, can contain �_�, must start with a letter, and must be unique in its container. For example, if a form has two buttons, the buttons must have different names. But if you have two different forms, the buttons on each form can have the same name. Alpha Five will automatically fix object names that break these rules. For example if you open two copies of the Customer form, the objects will be named Customer and CustomerN (where N is an additional character that makes the name unique, e.g. Customer1).
                    The object name may come from the name given in the field rules, originally, but nothing requires is to stay that name and once changed, nothing changes it again unless you do or as noted above. As Tom states, copying a form to another table does nothing that requires renaming form objects which still point to fields named the same as the original table fields.
                    There can be only one.


                      Re: Copy Form to - a bug?

                      NOW I see what Tom is trying very hard to teach me. I never noticed that the on_backorder field had a name of Complete as the object name. I kept seeing that Complete field and thought it was pointing to a field from the other table. I need to study some more on this and will. I guess then, the only bug is in my head and not in the program. It's odd that I have copied forms before and never had a problem. I guess I had never change the object names before. Now, if I could put a button on a form to click which would append only the record I'm on to another table, I would be golden. Right now, I do an append operation and ask that only unique records be appended but the program still looks at all the records in the transaction table only to append the one. Seems like a lot of program work when I know which one I want to append. I thought about setting a variable from the record I'm on but I have nothing unique enough so I use the on_backorder field to append only that record. The program still must check all other records to see if the on_backorder field is true or not. Anyway, I appreciate all the help and I'm sure that I now see the light on copying a form. I'll have to email Selwyn and tell him "There is no bug" and eat crow for a while.
                      Jim Belanger


                        Re: Copy Form to - a bug?


                        I have attached

                        there is a new table called tomtest

                        On the B/O receipts form, I added a button to copy the record you are viewing to tomtest.

                        All it does is takes the current record (the record you are viewing) and in xbasic copies the field values of that record into the tomtest table. There is no filter on it so it copies what you are seeing.

                        The only problem, it is written in Xbasic and I didn't know if you used xbasic since your form buttons are done with AS.

                        It is a very simple program that shows table.enter_begin() - the records to be appended to tomtest and table.enter_end().

                        I couldn't tell from the tables you sent with your zip where the records would go or what fields were to be appended to which file.

                        But what you want to do is easily doable (maybe not in AS) but it can be done.

                        If you need help - let me know

                        Tom Baker


                          Re: Copy Form to - a bug?

                          OK, I've saved your file and will work with it. I am not good at composing xbasic but I am much better at understanding what someone else wrote. Basically, here is what I do.
                          We have an inventory set. The technicians use parts and enter a "need" number when they run low. Once a week (or more often) the buyer reviews the "needs" and clicks a logical field to order. Then he invokes a "create Purchase order" action script which creates a Purchase order header and purchase order details as a parent table. Then Purchase orders are printed and Qty on order is posted to inventory. Now, what you were seeing is the processing of incoming purchase orders. If all parts are in, we are golden. If some parts get back ordered, I need to append that part to a backorder table. Let me see what I can do with your xbasic and I might even be able to use it in other places.
                          Jim Belanger


                            Re: Copy Form to - a bug?


                            I have added an action scripting to do the same thing as the xbasic. It the AS Append button on the form.

                            I added a form global variable called recnum to hold the current record

                            then in AS, I used "Set the value of one or more variables" to set the value of recnum to current record "recnum=recno()"

                            I also created an append operation called tomtest1, to append the same fields as the xbasic version with a filter of "recno()=Var->recnum" which is the current record.

                            The AS Append button does exactly the same as the XB append button but is action scripted.

                            Just thought I would send this along to give you an idea of how to do it in action scripting (I don't use action scripting that often now so it was nice to try it again).


                            Tom Baker