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

Interface Question

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

    Interface Question

    I have read (re: index resync error) that it is best to use a form based on a set solely for the purpose of display and navigation and that data entry and editing is best done by popping up separate forms based on the target tables. Does this mean for a parent and child table with a one to many relationship that I would have to create a button on my main display/navigation form to call up a form designed for the entry/editing of the parent table and another button to call up a form designed for the entry and editing of each child item? I find the process rather clumsy but a solid app wins over a shaky one.

    I'd like to get this clear before I get myself in mega trouble. Currently I have an invoicing application built primarily around what could be a "complex set". I don't know if it is or what I am setting myself up for.

    The parent table is Sales_order two child tables, salesord_trans and invoices are linked one to many to the parent. The invoices table is linked one to many to a child invoice_detail. The idea is that sales orders are made by the sales staff and each item sold is entered into the salesord_trans table. As we send out batches of items sold we generate invoices by posting the records from the salesord_trans table to the invoice_detail table.

    The interface design is based on a 2 tabbed form. the first tab contains the Sales_order table and a browse containing the salesord_trans table. The second tab contains the invoice table and its invoice_detail child.

    The design can go one way or the other at this moment and I can use any bit of wisdom people can offer at this point. Thanks in advance.

    #2
    RE: Interface Question

    Hi Greg,

    Yes, I've read that too and that is a method that many use. This is my take which, no doubt, not all will agree. If all you are entering is one record at a time such as a new customer, a pop up entry form or a specific entry form is the way to go.

    On the other hand, if you need to enter several items, such as items purchased by a single customer, then I would use a browse. This provides a clear view of previous entrys for the invoice and to popup and close a form for several entries is, as you say, clumsy. (You could have a popup form containing a browse). I've never had a problem entering data via a browse.

    You might want to take a look at the invoice app that comes with A5 and see how that is set up.

    Hope this helps,

    kenn
    TYVM :) kenn

    Knowing what you can achieve will not become reality until you imagine and explore.

    Comment


      #3
      RE: Interface Question

      Greg,

      As a follow up, I use the tabbed subform a lot in the same manner you are describing. Works great and I would not use a popup form to enter a new client. If you app don't make use of the tabbed subform, then the popup forms are a preferred method, at least to me.

      But, I really like the tabbed subform. It's very clean and less work to set up than using several popup forms. I have found, however, that at times, it's better to put a subform on a tab rather than just the fields in certain situations such as:

      I have some tabs where I have a read only browse on the left side and use a subform placed on the right half of the tab for data entry. This works well and there has never been a problem.

      kenn
      TYVM :) kenn

      Knowing what you can achieve will not become reality until you imagine and explore.

      Comment


        #4
        RE: Interface Question

        >>Does this mean for a parent and child table with a one to many relationship that I would have to create a button on my main display/navigation form to call up a form designed for the entry/editing of the parent table and another button to call up a form designed for the entry and editing of each child item? I find the process rather clumsy but a solid app wins over a shaky one.
        Peter
        AlphaBase Solutions, LLC

        [email protected]
        https://www.alphabasesolutions.com


        Comment


          #5
          RE: Interface Question

          I don't disagree with any of these comments but I would like to note that people are saying it CAN be problematic; not it WILL be problematic.

          I have many situations where I simply use a form based on a one-to-many set and use an embedded browse to fill in the child data. Most of them work fine.

          Comment


            #6
            RE: Interface Question

            Can anyone tell me why there is the potential for problems. And as for the additional work involved in setting up pop-up forms; what would it entail to produce a professional product. Wouldn't opening up a set for display and then opening one of its' member tables for data entry or editing cause problems? One suggestion involves a read only browse on the left side and a subform on the right( sounds like a cool idea to play with) but why is simply an embedded browse not safe?

            Comment


              #7
              RE: Interface Question

              Greg:

              Your question taps into a long-running conversation on this board.

              I really subscribe to Cal's comment.

              I've done it both ways.

              In one case I have users (15) simultaneously entering data into not one but *three* child tables. That is, the parent is linked 1:N to three child tables each of which displays in an embedded browse on a form based on the set. Two of the three browses are on tabs of a tabbed subform.

              It works just fine and has done so for three years.

              I should add that the data entry is done by picking items off table lookups defined in field rules. No typing is allowed. This may have been my salvation, but who knows.

              In another application data is entered into a table based on the child table. The extra work is that I have to somehow make sure that the child table's field which will link to the parent is correctly filled. I do this by hanging on the the parent's linking field in a variable and automatically adding this to any new record in the child table. It's not that big a deal, but *you* have to make sure it happens whereas in a form based on a set the A5 engine does it for you.

              My advice is to go slowly and test. Dummy things up and avoid premature committment to any one approach.

              Bill
              Bill Hanigsberg

              Comment


                #8
                RE: Interface Question

                Greg,

                >>Can anyone tell me why there is the potential for problems. >And as for the additional work involved in setting up pop-up forms; what would it entail to produce a professional product. Wouldn't opening up a set for display and then opening one of its' member tables for data entry or editing cause problems? > One suggestion involves a read only browse on the left side and a subform on the right>but why is simply an embedded browse not safe?
                Peter
                AlphaBase Solutions, LLC

                [email protected]
                https://www.alphabasesolutions.com


                Comment


                  #9
                  RE: Interface Question

                  I hope you find time to post a sample set with dialogue input form. I am very interested in seeing how the parent data is transfered to the child along with a unique Child_id.

                  Thanks

                  Tom

                  Comment


                    #10
                    RE: Interface Question

                    Attached is a pared down version of my ClientContacts set. Many of the buttons don't work, but you can add/edit clients and contacts.

                    Peter
                    Peter
                    AlphaBase Solutions, LLC

                    [email protected]
                    https://www.alphabasesolutions.com


                    Comment


                      #11
                      RE: Interface Question

                      Bill, that's well put.

                      Greg, data entry into a complex form based on a multi-table set involves lots and lots of ways the user can navigate throughout the current composite record. In and out of tables. In and out of tab pages. In and out of browse controls. This of course is what is often most appealing to the end user. However, Alpha Five uses its own rules for 'safe-handling' of your data when these jumps happen. Most are pretty obvious, but some, especially those involving embedded browses, are not. These happen when the user changes rows within the browse. When the user leaves the browse control. When the user tabs through the last field in a single row of a browse. And so on. The result can be that your end user winds up saving a bunch of blank records unexpectedly. At other times, undesired duplicates can be created.

                      In version Four the embedded browse control is not as robust as I would like. The list of available 'actions' to which you can hook validation scripts is more limited than is true for the form itself. (I understand that this is receiving attention by the designers of version Five.)

                      While it can seem (on the surface, or at least so I'd argue) to a newbie that set based data entry is a snap... I find it the most difficult to do well. It's really hard to bullet-proof the data entry process in that environment. I therefore often recommend that folks learning the language try a different approach first. Use the set based form to display and navigate among the records. But call other data entry forms from the set based form when you're ready to enter or change records. Wherever possible have the data entry form based on a single table.

                      Learning to pass values from one form to another is essential. There are three ways that I can think of quickly. Others may have still more suggestions:

                      1) Store current values in global variables; then use OnInit or OnActivate event scripts in the called form to retrieve the globals when the second form opens.

                      2) Load the called form and assign values to fields on that form directly, before 'showing' the form.

                      3) Open the called form, and use OnInit or OnActivate event scripts there to look back at the calling form and retrieve values directly from that form.

                      All are possible in Xbasic.

                      While the end user may feel a bit constrained in this kind of approach, your job as the designer is much, much easier. Provide only one way out of the data entry form, returning to the calling form when the called form closes, and you'll find that your end user data entry questions (and errors) vanish.

                      -- tom

                      Comment


                        #12
                        RE: Interface Question

                        Thanks for the files! I had a chance to incorporate your "New Client" button script into my system and things are working very well. I now understand how you go about pre-entering and saving a record for the user so that he believes he is entering a new record when in fact he is merely editing one. My one problem is understanding the last part of your code. I have tried to pseudo-code it as follows:

                        'Copy client name to variable
                        vClient = f:Client.value

                        'Totally close dialog opened form
                        f.close()

                        'Fetches pointer from primary table of open set in this case 'clients
                        tbl = table.current(1)

                        'Finds variable value and finds it using primary index of primary table

                        'Moves pointer to new record
                        tbl.fetch_find(vClient)

                        Browse1.refresh()

                        ERROR_MAN:
                        'Restore the form
                        this.enable()
                        END

                        When I got to this part of the code in my app I got a couple of errors so I tried to cycle through this one line at a time on the interactive screen and I ended up with the same. I have yet to get my head around the debugger. Anyway I tried to run your button script through the interactive screen and to my dismay found the same errors. They are as follows:

                        tbl = table.current(1) 'To get current table pointer
                        ? tbl ' I ended getting the following block of text

                        = V Append()
                        V Batch_Begin()
                        V Batch_End()
                        ....goes on for 146 lines ending with:
                        NAME = "Silver Alpha Logo "
                        TYPE = "ICON"
                        VENDOR = ""

                        The following are the two errors. Remember these are visible only when running in the interactive screen of the code editor but not when running your app. However, I get these errors while running in my app as well as in the interactive screen.

                        'Finds variable value and finds it using primary index of primary table
                        tbl.fetch_find(vClient)
                        ERROR: conflicting expression data types

                        Browse1.refresh()
                        ERROR: Argument is incorrect data type

                        Comment


                          #13
                          RE: Interface Question

                          Greg,

                          I haven't downloaded the example but I can help with a couple of points.

                          -you can't use the interactive window (at least I can't)to test code which uses the table_current() method because there is no current table in the interactive window. It is possible that using the obscure table.reset() method you may be able to establish the proper context but I haven't mastered that particular technique. It may be time to dip a toe into the chill waters of the debugger. (Actually, it is not that difficult a tool and it is said to be much improved in version 5.) To be serious, the debugger is essential if one is to keep track of variables being passed back and forth, etc.

                          -Browse1.refresh() is an incomplete address to the browse. Don't you need f:browse1.refresh()? Unless this is just a typo on the board.

                          Bill
                          Bill Hanigsberg

                          Comment


                            #14
                            RE: Interface Question

                            Hello Greg,

                            >>Can anyone tell me why there is the potential for problems

                            Comment


                              #15
                              RE: Interface Question

                              Greg,

                              I beleive my sample works correctly. Perhaps in your set some of your objects are named differently? f.client.value refers to the name of that field object. Browse1 is the parent form browse, and the set structure must be accounted for in the tbl.fetch_find(vClient) method. Bill H's post above is well advised with regard to using the debugger. That is how I ususally find my own (numerous) bugs.

                              Good luck!
                              Peter
                              Peter
                              AlphaBase Solutions, LLC

                              [email protected]
                              https://www.alphabasesolutions.com


                              Comment

                              Working...
                              X