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

embedded browse & .refresh()

  • Filter
  • Time
  • Show
Clear All
new posts

    embedded browse & .refresh()

    I am using xbasic to write from one child to another in a set.
    When the script has run to include a .refresh()for the browse that
    was written to, I still only see 1 record.

    If I close the form & re-open it all of the records in the browse are there.
    I have a feeling that this has been an issue with about some
    feedback from someone who has worked through this?


    RE: embedded browse & .refresh()

    Hi Doug,

    There has been a ton of discussion of this, but I do not remember a simple resolution. You had best search the board. Meanwhile, what about resynch rather than refresh for the browse? But there is probably more to the matter than this.

    All the best,
    Bill Hanigsberg


      RE: embedded browse & .refresh()

      I might have missed the point here, but this code is on a button in a form to add a record to an embedded browse ( child one to many). I'm not taking from one child and adding to another, but the child records do appear.

      T = table.get("lines")
      T.order = order.value
      T.line = RIGHT("000" + LTRIM(STR(VAL(LOOKUPC("L",ORDER.VALUE , "LINE", "LINES", "Order_no"))+1)),3)
      T.item = "TESTING"



        RE: embedded browse & .refresh()

        Hey Bill....

        I did search the board a bit I even looked in the "archive". The only
        thing I came up with was a similar problem but with dialog forms. The
        solution is a bit awkward. In the script used to write the data to the
        child table, I have to include lines that close the form & use script_play()
        to call a script to re-open it? Otherwise I get an error if I try to use
        the button (script) to write the next parent record.

        This method works, but it sure seems like I'm having to trick the software
        into doing something that it should be able to handle on it's own. The other
        thing (which may be more likely)is that there is a better method for doing
        what I need to do. I just haven't been able to discover it, not that I'm
        complaning but Alpha5 has a long list of functions & methods in it's arsenal.
        Choosing the right one can make all the difference!

        Basically what I am doing is taking data from the "source browse" child table,
        doing some numeric calculations on some of the fields & writing it to the "target
        browse" child table of the set for the current parent record. Both tables are
        linked to the set one to many in the same way.

        If anyone can suggest a better method that will eliminate the need to close &
        re-open the form in order to see all of the records written to the target browse
        or even some infor on why this is even necessary...... Please share it!

        Bill, thanks for your response! It is good to get the chance to say Hi!



          RE: embedded browse & .refresh()


          Thanks for your response! I am not real sure why the target browse dosen't
          display all the data when the script finishes. It may be because I am writing
          from one table to another that are linked to the parent in the same way. I do
          think that closing & re-opening the form is something that shouldn't have to be
          done in order to display the new data.

          The bottom line is..... doing what I am doing is making the application more
          relational & adding to its depth. I will take the "hit" on the form thing if
          I have to but I would like to know why?


            RE: embedded browse & .refresh()


            Are you using a concactenation of fields and/or functions to link the two one to many's to the parent, a filter with formula calculations or both. Reason for asking is that on my test tables I had no problem getting data from "one to many child browse one" and ADDING and DISPLAYING a record in "one to many child browse two". I had the same single field link between the parent and both one to many child tables with no filters. I only grabbed one field from the source browse, that should not matter, and the script worked as a button on the form and as a doubleclick event on the source browse. What you are doing really seems like it ought to work.

            Also, did you try parentform.fetch_prev()followed by parentform.fetch_next() as an alternative workaround to closing and opening the form? If that doesn't work as a part of your new record script, does it work as a button on the form itself after the record is added?



              RE: embedded browse & .refresh()

              Thanks for you input, the set linking is very basic, just a single field 
              for all of the links in the set. The 2 browses in question are named "spool"
              and "pup", below is an image of the set structure.  
              The "spool" table(Pup1 TAB) will have many records linked to 1 "ISO". 
              In the field spool it is likly to have multiple records with
              the same pup number. (look at pup #6) in the image below .
              Below is an image of the "PUP" browse (Pup lengths TAB), the first field 
              is the link to the set, same as the "Pup1 TAB" browse (although the link is 
              not shown in that browse). Anyway, I am fetching through the browse above &
              writing to the browse below. I write the "Dimension" field as is, the "length"
              field is added together with all pups that have the same pup # & written to 
              the browse below in the "Fittings" field.  Then I subtract the "Fittings field
              from the "Dimension" field & write the difference to the browse below in the 
              "Pup_Length" field.  There may be a better way of doing this, mayybe in the
              field rules but I would have to be able to group all of the pups with the same
              pup # before I calculate the total for that field. 
              When I was developing the script, I would (in the script) zap the target table
              before I wrote any data. That may have been where the problem lays....The data
              was being written correctly, but only 1 record would show in the target browse
              when the script finished.  I went over the script & even wrote it with different
              syntax ..... I spent an embarrassing amount of time with the script....Everything
              looked OK but still only 1 record showed up in the browse when the script ran.
              Then I closed the form & check the table from the control panel....& the expected records were all there.  I tried everything you mentioned before
              I went directly to the table's default browse.  After I figured out that the 
              script was OK I remove the "zap" & just deleted the records in Pup_Length Tab
              that matched the linking field of the current record. (to allow for changes)
              Zap is supposed to have exclusive RW in order to work but it did work from
              within the open set.  I'm now thinking that was the reason for the target
              browse not refreshing.  I will try it again without closing & re-opening
              the form later this evening. Once I removed the "zap" from the script closing
              & re-opening the form looks no worse than refreshing the form!
              I appreciate your intrest & your comments, I will let you know if the 
              zap was in fact the problem.  
              If anyone can give me other alternitives to this please advise!!


                RE: embedded browse & .refresh()

                I don't have an answer. My thought would have been to try John Zaleski's suggestion - fetch_first/last or force a pg_up/dn, and/or maybe browse.activate + sys_send_keys("{F5}"). But tell me the secret. How do you imbed those great graphics on this web site?

                PS I love the sheet metal background. Totally cool!
                AlphaBase Solutions, LLC

                [email protected]


                  RE: embedded browse & .refresh()

                  Hi again Doug:

                  I'm like Peter; just want to applaud that virtuoso presentation. Hats off.

                  Bill Hanigsberg


                    RE: embedded browse & .refresh()

                    I feel your pain. Took a while, but I found a workaround. I have a set that links the same table 4 times to the same parent. (Don't ask why - it would take too long to explain) If I use xbasic to add records to the child, they don't display. It seems to be a problem with the indexes not being able to update correctly if another instance of the child table is open as it is when the set is open. The only solution was to close and reopen the form. Then the indexes are ok and the records display. I created a small message form to tell the user what is happening. At the end of the xbasic script that adds records, I get the record number of the parent and save it to a variable. I also set a logical variable I call reload to .T. Then I open the message form and close the main form with the script. On the OnTimer event for the message, I reopen the main form. I set the timer for 1 to 2 sec. On the main form OnInit I check the variable Reload and if it is true, I use the saved record number to find the record I was working on. I also close the message form with the main form OnInit event.

                    Kinda messy, but it works and the process is transparent to the user. No other approach worked. On my app, I get a similar problem as well as heap lock failures and other fun if I delete a child record. After a delete, I use the same process and add a reindex to the child records before the message closes. I haven't tried V4.5 yet to know if the changes to the indexing will help these problems.



                      RE: embedded browse & .refresh()

                      It looks to me like Doug has two different tables being linked to the ISO parent, "SPOOL" and "PUPS", and that he is trying to write records from the spool table to the pups table with the potential for some of the spool records to be summarized into a single record in the pups table. Do you think the problem you encountered with multiple instances of the same table is applicable here?


                        RE: embedded browse & .refresh()

                        Thanks guys for your input, I am sure that the mistake was
                        on my part. I was using "zap" to empty the target table without
                        exclusive RW access. I know that is why the browse did not
                        show all the records written to it. Once the script was to
                        my liking, I removed the zap statment & the target browse
                        refreshed the new data without a problem!

                        BTW the zap function worked even without exclusive RW access.....
                        but if you use it that way you will probably get more than you
                        barganed for!!



                          RE: embedded browse & .refresh()

                          Glad everything worked out
                          My guess is that when you opened the table in your script you used something like:
                          T = table.get("lines")
                          All you are doing here is getting a pointer to a table already opened. Therefore the zap was allowed because no other instance of the table was opened. My guess is that if you used something like:
                          T ="lines")
                          and then tried to zap it you would get an error because at that time you do not have exclusive access to the table. In my experiences, I've seen a little different behavior from Alpha in forms when there are no records in a table (like you had after the zap).


                            RE: embedded browse & .refresh()

                            "In my experiences, I've seen a little different behavior from Alpha in forms when there are no records in a table (like you had after the zap)."

                            For example, I know but sometimes forget that a browse based on an empty table goes into enter mode when opened. Probably this applies as well to an embedded browse.

                            I wondered whether this might have been related to the goings on in this case but who knows?

                            Bill Hanigsberg