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

Design help needed

  • Filter
  • Time
  • Show
Clear All
new posts

  • Design help needed

    Hi All,

    I am having a real brain block here and thought maybe someone can nudge me in the right direction.

    What I need is a grid or repeating section that would dynamically populate from records in a table and allow me to save all the rows as a new record.

    This screen is for entering inventory counts, so I need the items listed in a grid type format, enter the current count, then save all rows as new record in history table.

    Any help would be appreciated



  • #2
    Re: Design help needed

    It sounds like you want a Header/Detail setup. Two tables with your totals saved in the Header table.


    • #3
      Re: Design help needed

      Actually no ... I just want detail records .. I want to populate the grid with inventory items .. ID, Description, ect. .. from my inventory items table then add a column to enter physical count, then save all rows as new records in the history table. I can fake it by creating the records when the grid opens, but then if the user cancels out I have a bunch of blank records in the table that I then need to remove. I am trying to keep it all on screen until user hits save .. and at that point the records are created.



      • #4
        Re: Design help needed

        A repeating section, with textbox control for those columns you need data input, and label controls for all other data shown?


        • #5
          Re: Design help needed

          i think it is better you do this at the database level than in alpha.

          the grid is based on a table and it will have a maximum of all fields ( plus any calculated expression) from that table and it will save to that table. dialog on the other hand is free to save all the data to some table you assign to, but to load data that table will be bound to that dialog and it will defeat your purpose.

          you could however create a new history table in your database end with all the fields from the original table plus the count column and populate that history table with data from the original table and empty value for the count. and then design the grid based on that table and you will get all the data and of course empty count column and they will fill it out and save it.
          this seems logical to me unless there is better idea.
          thanks for reading


          version 11 3381 - 4096
          mysql backend

          [email protected]
          Skype:[email protected]
          1 914 924 5171


          • #6
            Re: Design help needed

            Scott, personally, I would take Steve's approach but handle the populate manually (not through data binding).
            I typically fall in line with Gandhi and handle this kind of request on the db side, but in this case, you don't actually want to create records until the user initiates the transaction.

            To throw one more idea out there, when the ux loads, I would make a call to the DB, get my list of records and iterate through them to create the javascript needed to 1-set the repeating section row count and 2-populate each of the repeating sections rows. The sample xbasic in onDialogInitialize illustrates this pretty clearly. For example, say you have a repeating section with a text box called Test1. You would call the following to create the rows and populate them.

            dim js as c
            js = <<%txt%
            var rows = 3;
            var setFocusToFirst = true;
            var nullOutExistingData = true;
            var repeatingSectionId = 'REPEATINGSECTION_1';
            var _d = {};
            _d['TEST1'] = 'val1';
            _d['TEST1:2'] = 'val2';
            _d['TEST1:3'] = 'val3';
            e.javascript = js
            On save, I would typically handle something like this manually as well, create an xb function to write the rows back to the db.
            Definitely more work, but keeps your db clean.
            Nate Mitchell PMP


            • #7
              Re: Design help needed

              I would use a grid and a batch process. Then when you process the batch if there are records you don't want you can delete them. My experience with the repeating section is that it is not robust enough and there is too much overhead. I just rewrote something recently taking it out of the repeating section and back to a grid. I feel like I have more power and flexibility in a grid. (There's my two cents of experience)


              • #8
                Re: Design help needed

                Is the number of item types so small that the user is really going to be able to enter all the inventory counts at one time? What if the user isn't able to enter all the counts at one time and wants to save what they have entered and then come back later to enter more item counts?


                • #9
                  Re: Design help needed

                  Originally posted by Scott Emerick View Post
                  This screen is for entering inventory counts, so I need the items listed in a grid type format, enter the current count, then save all rows as new record in history table.
                  While that sounds like a good idea, an inventory management person or auditor would reject that idea as bad practice.

                  Too easy to just enter the current count.
                  Al Buchholz
                  Bookwood Systems, LTD
                  Weekly QReportBuilder Webinars Thursday 1 pm CST

                  Occam's Razor - KISS
                  Normalize till it hurts - De-normalize till it works.
                  Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
                  When we triage a problem it is much easier to read sample systems than to read a mind.
                  "Make it as simple as possible, but not simpler."
                  Albert Einstein



                  • #10
                    Re: Design help needed

                    Thank you all for your input ...

                    Steve - That's the way I thought about going since I am dealing with a unbound format using a UX and repeating section, was just trying to see if there was a simpler way.

                    G - That's way too much to maintain but thanks for the thought

                    Nate - yes I agree with you and think the repeating section is probably the best.

                    Lee - I agree with you as far as the grid vs. repeating section, but it just might be easier to use the unbound UX in the long run.

                    Rich - Yes the item list is small because it is broken down into categories hence why I said I need to populate it dynamically.

                    Al - I totally agree with you, but this is what the client is used to with there access system that I am converting, soooo, I'm kinda stuck doing it there way. You know how that goes.

                    Thank you all for your thoughts and input, it was the nudge I needed.



                    • #11
                      Re: Design help needed

                      Scott, I think you have some great suggestions and just thought I would add a little to the mix. This is an interesting problem as you want to populate the grid/list/repeating section with data from a table different than you are saving to. Here are my additions to the mix.

                      1. Use 2 list controls - one bound to the inventory items and the second bound to inventory history. Use an unbound textbox for the count. Then use Javascript to copy the record from list 1 to list 2 adding the data from the unbound box to the count field in the new record for list 2. Selwyn did some videos on moving rows from list to list which should be helpful. List 2 would not even have to be visible in the final published version and the saving after move could all be handled by script.

                      2. If the inventory is simple as you said, an easy solution would be to use a gridlist/list/repeating section bound to the history table and populate the item fields with dropdowns or lookups bound to the item table.

                      3. I am not an SQL expert, but I believe you could also populate directly from the history table with "select unique" incorporated into the query (the way dorpdowns work). Of course, you would have to add a way for new inventory items to be added to the history table but it should not be to difficult to incorporate an "initial count" action (which could be 0). The Javascript for the save function would include adding a new record with values taken from the row and then saving that record.


                      • #12
                        Re: Design help needed


                        Thanks for your thoughts. I wish it was as simple as binding to the history table, but A) what if the table is empty? and B) the goal is to create new records, so where binding would help populating, I would still need to write code to create new records.

                        I am talking with my client to see what their needs really are and maybe I can take a different approach then what they are used to.

                        Thanks again



                        • #13
                          Re: Design help needed

                          Another idea:

                          Use a UX bound to the history table set to New Record. On the component place a list bound to the items table. On select for the list use setValue to fill the fields on the component for the history table which will leave the count field empty for filling.

                          Sorry, I like these little puzzles.


                          • #14
                            Re: Design help needed

                            The empty history table issue is why I suggested setting an action to add an "opening entry" action to add to the history table that could even have a 0 count value. But, I think you are correct and the manipulation of the new record row in this scenario might not be simple.