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

Embedded browse problem

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

    #16
    Re: Embedded browse problem

    "That's my two cents, but Ted & Tom have been at this a lot longer than I have, so if they comment on the issue, it's probably worth a lot more. "

    Nah! I'm an old duffer and he's a young whizz kid with a brain the size of a planet!
    See our Hybrid Option here;
    https://hybridapps.example-software.com/


    Apologies to anyone I haven't managed to upset yet.
    You are held in a queue and I will get to you soon.

    Comment


      #17
      Re: Embedded browse problem

      Nick, I just realized I failed to answer your first question in post 13. Yes, in my experience the issue you're experiencing clears up when the browse is sorted on a field from the head table of the browse. (The child table in your set, in this case.)

      Ted, a planetary brain sounds a bit cumbersome...makes you wonder how the poor fellow could ever get anything done! I know I've sure benefited from some of your posts in the past...

      -Jason

      Comment


        #18
        Re: Embedded browse problem

        Browse bug revisited:

        I've been struggling with this for 24 hrs. There are several issues regarding browse scrolling that I am encountering.

        The OP indicated he was experiencing unexpected "phantom" field changes while navigating through a browse. I'm presently experiencing that exact same problem when I add a calculated "grand total" to the form. Remove the grand total and that issue disappears.

        However, I am also experiencing some serious browse navigation issues. The largest being browse scrolling & cursor control. At first I thought it must be an error on my part. I think it is the browse. No matter what I do, I can not get the browses to scroll all the way to the bottom. All the data is there. (This problem occurs even if I just load a browse directly outside the form and apply "Quick Filter." ~ The only way to see all the records is to expand the browse window vertically. (down keys and mouse on scroll-bar won't do it)

        At first I thought it may be index related. One thing I do know is that the problem occurs when using <form>.VIEWQUERIED (or <browse>.VIEWQUERIED) methods along with the filter parameter. (I can't get the order parameter to work on these queries either, regardless of what settings I try with regards to indexes in the browse/form etc. ~ Nor can I apply the filter as a basequery via the .t. parameter.

        I also had thought that the problem may be due to the character fields beginning with an asterisk character. This does not appear to be the case here.)
        ~On a related note, I did find that Query By Form does in fact fail when your working (searching) character fields in a .dbf that begin with the asterisk character.

        Before I send in (another) bug report, can anyone help? (I'm hoping it's something I am doing, and not an a5 issue.)

        See the problem: http://screencast.com/t/9oWReKvpg5jj
        And/or download this example (most irrelevant database objects have been removed): BrowseBugs2.zip
        Last edited by SNusa; 01-20-2013, 01:39 PM.
        Robert T. ~ "I enjoy manipulating data... just not my data."
        It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
        RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

        Comment


          #19
          Re: Embedded browse problem

          Hey I have this problem also and it does not do this in version 10, I was going to ask same question

          Comment


            #20
            Re: Embedded browse problem

            I have a browse problem but it does not occur in version 10

            Comment


              #21
              Re: Embedded browse problem

              Rob, I cannot get the behaviour you see in a large data set browse.
              Build 3044
              Addins 4041

              Maybe I'm misunderstanding, but running a Qury on a field - in this case "Bungalow" returned 300 records out of about 1.3 million.
              The browse works fine and I can get to the bottom, and this is where there might be differences, I have the option to enter a new record.
              It's purely vanilla and no added constraints.

              I have tried resizing the browse and adding various queries and still cannot make it go wrong.

              Can you PM the underlying table and form?
              See our Hybrid Option here;
              https://hybridapps.example-software.com/


              Apologies to anyone I haven't managed to upset yet.
              You are held in a queue and I will get to you soon.

              Comment


                #22
                Re: Embedded browse problem

                Originally posted by Ted Giles View Post
                Rob, I cannot get the behaviour you see in a large data set browse.
                .....Can you PM the underlying table and form?
                Hello "Mr. G." ~ Hope you're enjoying the weekend!

                The entire database (stripped of most of the other "non pertinent objects") is attached to my OP.
                I realized the attachment link (BrowseBugs.zip) "appeared hidden." ~ Not anymore.

                Unless I inadvertently stripped the data while zipping it, there should be a good sized data set to work off of.
                (Using customer TRX-000002 as the filter exemplifies the problem.)

                Worth mentioning that I think part of the problem is: The browse is reacting under the assumption there are only two parent records returned in these scenarios. Also, changing the a5 browse behavior (in program settings) to 0 can make a big difference, but still does not resolve the issue entirely.

                ~Browse is not acknowledging the fact that the parent records can (and does) have many multiple child records, so it's "internal count" is off.
                Last edited by SNusa; 01-19-2013, 11:47 AM.
                Robert T. ~ "I enjoy manipulating data... just not my data."
                It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                Comment


                  #23
                  Re: Embedded browse problem

                  Robert,

                  I took a look at your sample. Testing here was limited to the green button below the black dividing line on your opening form. The problem you are bumping into results from your decision to embed a named browse into the called form when the named browse you are inserting into the form is based on the same set of tables as the form into which you are embedding it. I'm not surprised you're having trouble. I don't think this is permitted even once, and you are doing it twice. This means that there are three copies of the same set of tables open in your form. Its not clear to me why this is necessary.

                  If you open the default form for the same two table set the scrollbars in the linked child table work correctly. If you build a simple form for the same set and use an embedded browse to display ONLY the parent table records it behaves correctly too. Why? Because that browse is based on a single table, and does NOT include multiple copies of composite records as does your named browse insertion.

                  -- tom

                  Comment


                    #24
                    Re: Embedded browse problem

                    Originally posted by Tom Cone Jr View Post
                    Robert,

                    I took a look at your sample. Testing here was limited to the green button below the black dividing line on your opening form. The problem you are bumping into results from your decision to embed a named browse into the called form when the named browse you are inserting into the form is based on the same set of tables as the form into which you are embedding it. I'm not surprised you're having trouble. I don't think this is permitted even once, and you are doing it twice. This means that there are three copies of the same set of tables open in your form. Its not clear to me why this is necessary.

                    If you open the default form for the same two table set the scrollbars in the linked child table work correctly. If you build a simple form for the same set and use an embedded browse to display ONLY the parent table records it behaves correctly too. Why? Because that browse is based on a single table, and does NOT include multiple copies of composite records as does your named browse insertion.

                    -- tom
                    Hi Tom:

                    Interpreting your response has me "stymied." Unless I'm doing something completely wrong: I can't embed any "stand-alone" browses on any form unless the "calling" form is comprised of the underlying tables that exist on the "stand-alone" browse (that I am trying to embed.) ~ a5 doesn't allow it. (For example, if you have a form based on a dummy table, a5 won't even allow you to embed any "stand-alone" browses on the "dummy form" other than ones based on the "dummy table.")

                    Your reply may explain the very top button (smaller blue one). Adding this button (as an "afterthought") was the result of an attempt to find a solution (open a form based on a set, and then embedded the complete set within the form) to the original scroll issues I was experiencing. Ironically: This solution did actually appear to address/cure the "floating phantom value changes" as I click on the different fields within the browse itself!!! It (completely embedding the entire set in a table based on the same set) just didn't address/resolve the vertical scrolling issue.

                    Even if I'm not interpreting your response correctly, that still doesn't explain the problem with the blue text button (immediately above the divider line.) That button simply opens a "stand-alone" browse and exhibits the exact same scrolling problem. (I can't scroll all the way down no matter what I do, and the only way to see all the data within the browse is to vertically expand the browse window down.) ~ In fact, that was the example I used with the online video presentation. (Button on a "dummy table form" is opening a totally unrelated browse based on a totally unrelated set!) ~ RSVP! Also, remember that it's a "dummy form" based on a "dummy/empty table" that is "QueryViewing" the other forms

                    At one point (playing with indexes, names etc... I actually did successfully get the green buttons to work fine with the existing data sets. (That is why they were green.) And prior to your response I was thinking I needed to add a possibly related "thought" regarding index naming schemas.....

                    But here's the question: If you have a set composed of several tables, is it possible that "internal index resolution" can become an issue?
                    (Reason I ask is that at one point, the green buttons were exhibiting "full scroll" capabilities when I was messing around with table index names (along with browse/form sort settings.)
                    Explanation:
                    Two tables in a set contain identical named fields (very common)....
                    Thus, both of these tables may have uniquely named indexes (assigned by developer) at the table level, but are now common at the set level.
                    Since you end up with two "linked tables" (a set) sharing identically named fields and associated index names... Could this be an issue?

                    (What I'm also questioning here is): Is it necessary (or even prudent) the make sure all user assigned index names are different at the set level (in addition to the table level?) ~ This is a difficult proposition, because you never know for sure how you may end relating sets in tables as a "application" grows.
                    (Regardless of the answer to this question, it still doesn't completely explain the browse scrolling problems I am encountering.)

                    PS: I have adopted a naming schema of using a schema as follows: CUSTOMERID field gets an index named: Cstmrd__ (This creates a unique and user generated identifiable name at the table level.)
                    Last edited by SNusa; 01-19-2013, 02:15 PM.
                    Robert T. ~ "I enjoy manipulating data... just not my data."
                    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                    Comment


                      #25
                      Re: Embedded browse problem

                      @
                      Tom, I've embedded a browse in a form using the same table but usually only once and purely for quick record navigation.

                      @
                      Rob, what exactly are you planing to do? I have noticed that two of the indices have the first 7 letters the same - not a good idea and this may or may not have a bearing.
                      Without knowing what you need to display in more detail and why you need the same browse more than once I'm not sure what I'd be attempting to "fix".
                      Off to a birthday party now, so I'll look again tomorrow.

                      T
                      See our Hybrid Option here;
                      https://hybridapps.example-software.com/


                      Apologies to anyone I haven't managed to upset yet.
                      You are held in a queue and I will get to you soon.

                      Comment


                        #26
                        Re: Embedded browse problem

                        Robert,

                        When you embed a named (saved) browse in the form base that browse on a single table, not a set of tables. Alpha will use the saved layout to display the records from the tables that are already open. Do this and let us know if the scrolling issue remains.

                        -- tom

                        Comment


                          #27
                          Re: Embedded browse problem

                          Originally posted by Ted Giles View Post
                          @
                          Tom, I've embedded a browse in a form using the same table but usually only once and purely for quick record navigation.

                          @
                          Rob, what exactly are you planing to do? I have noticed that two of the indices have the first 7 letters the same - not a good idea and this may or may not have a bearing.
                          Without knowing what you need to display in more detail and why you need the same browse more than once I'm not sure what I'd be attempting to "fix".
                          Off to a birthday party now, so I'll look again tomorrow.

                          T
                          Hy guys;

                          Problem is: I have a relation data set Customer --> Keyfobs --> Invoices. (The child table "Keyfobs" is necessary because customers can have multiple Keyfobs under one account.) Thus there is no direct link from Customers to Invoices, because customer can have multiple Keyfobs assigned to their account. ~ Without modifying/adding redundant data to the Points table, the examples I provided is necessary to get the totals (combine all keyfob transactions) for a customer.*

                          Due to limitations of how a5 works with data on a form: It is necessary to open up a window (via viewqueried) to display all transactions within the same browse. If you try to do it on the form itself, you are forced to make a selection in the Keyfobs table. And in doing so, that selection displays only the points associated with one keyfob in the browse.

                          Although everything works as expected... The browse only seems to be scrolling down to the first occurrence of the last master record field it encounters. It is not scrolling down to the last record. (And that explains some of (not all) the wacky scrolling behavior when you click on an individual field in some of the browses and you "try to" move down using the keyboard keys.

                          I believe that what is actually happening here, is the browse scroll bar is not reacting to the actual quantity of records returned/displayed. Instead it is reacting to the record count of the individual master records returned. (And therefore, it "thinks" it has displayed all the data.)

                          IMPORTANT: *The browse properties browse tab has a selection for "Parent Records Only." Un-checking this is necessary to get the results I need. (And I am getting the right results.) I honestly believe that everything is working as expected, with the following exception: The a5 browse scroll area is not "taking this unchecked scenario/browse setting into account" when it displays the data in the browse! ~ I wonder if there is some setting in the a5_scroll area (XBE with form in edit mode) that can be manually set.....

                          One other thing: The a5 "Vertical Scrol Bar Behavior Setting" must be set to 1 (compatibility mode). If set to 0, it doesn't work at all on this browse!
                          With it being set to "1", if you directly open the frmCustKeyPointsCOMBINED form, everything is OK with regards to scrolling until you try this:
                          Right click on any instance of the TRX-000002 field and apply the "QUICK FILTER." The filter works fine, but here again you loose full scroll capabilities. (Also, as you are scrolling, look at the bubble scroll help as you drag the scroll bar. ~ It always shows that it is on record #2 of 2.

                          I'm almost convinced that "internally", the scroll bar is just not taking into account the browse tab setting for "Parent Records Only" when calculating the correct number of items it needs to display/scroll in the browse.
                          Last edited by SNusa; 01-19-2013, 03:28 PM.
                          Robert T. ~ "I enjoy manipulating data... just not my data."
                          It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                          RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                          Comment


                            #28
                            Re: Embedded browse problem

                            Originally posted by Tom Cone Jr View Post
                            Robert,

                            When you embed a named (saved) browse in the form base that browse on a single table, not a set of tables. Alpha will use the saved layout to display the records from the tables that are already open. Do this and let us know if the scrolling issue remains.

                            -- tom
                            Tom;

                            It's not an issue under the scenario you suggested. And even though a limitation like that would IMHO largely defeat the concept of a relational database & data "normalization"... That's fortunately not the "root of the problem" at hand here! (See above post, as I think I may have uncovered the underlying issue. ~ Browses do not fully "respect" (take into consideration) the browse tab "Parent Records Only" setting when calculating the quantity of records to be displayed.)

                            ~If I'm not mistaken, years ago in v.9, I ran into this same issue, before I "knew why." (Presumably this is an easy to address/fix browse "record set count calculation" display issue that has been around for a long, long time.) The set data is generated & presented as expected. But the resulting browse (whether or not it is embedded in a form) just doesn't know how far it needs to scroll down to "present" all the results.)

                            The other issue (order & basequery parameters not working with <browse>VIEWQUERIED() method) may OR may not be a limitation resulting from un-checking the "Parent Records Only" browse setting, but I haven't "gotten there yet." ~ But I will!
                            Last edited by SNusa; 01-19-2013, 04:13 PM.
                            Robert T. ~ "I enjoy manipulating data... just not my data."
                            It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                            RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                            Comment


                              #29
                              Re: Embedded browse problem

                              Robert, I am glad you confirmed what I thought. The use of a named (saved) browse based on a single table behaves correctly. If I were facing your project I'd probably use a form based on a three table set, using single table browses to display the child (keyfobs), and another single table browse to display the grandchild (points). Summary totals would be displayed through calculated values in the form. In my experience the use of a browse to display composite records from a set of tables is often very confusing for my users.

                              The use of single table browses (rather than browses based on composite records in a set of tables) has nothing to do with "the concept of relational databases or normalization". To my way of thinking you're confusing data display techniques with data storage techniques, and the two are not the same.

                              Comment


                                #30
                                Re: Embedded browse problem

                                Originally posted by Tom Cone Jr View Post
                                Robert, I am glad you confirmed what I thought. The use of a named (saved) browse based on a single table behaves correctly. If I were facing your project I'd probably use a form based on a three table set, using single table browses to display the child (keyfobs), and another single table browse to display the grandchild (points). Summary totals would be displayed through calculated values in the form. In my experience the use of a browse to display composite records from a set of tables is often very confusing for my users.

                                The use of single table browses (rather than browses based on composite records in a set of tables) has nothing to do with "the concept of relational databases or normalization". To my way of thinking you're confusing data display techniques with data storage techniques, and the two are not the same.
                                That's what I originally tried, and that is what I have found you cannot do.... (And that is why I "went to plan b" and am doing it this way.)

                                Unless I am missing something..... In order to "total values" in the "grandchild" table (and show all related "grandchild" records within one browse simultaneously), you must do it the way I did by opening a new form/window. ~ Incidentally, this is the reason you cannot accomplish this your way. (Unless I am missing something.)

                                Here is the problem: If you build a form based on 3 tables (as you suggested, which I initially tried), a selection on the both the "grandparent" table and the "child" table must be made on the form, in order to select (and see) a result set in the "grandchild" table browse. ~ Consequently, the "grandchild" browse only displays data from one selection in the "child" table. (So you can't get a combined total. Nor can you make one browse display all the related together on the same form.) If you ignore the middle (child) table on the form, the "grandchild" table only shows records from record #1 in the "child" table. ~ It's the second window (opened by <form>.VIEWQUERY() that provides the ability to combine the data.

                                "Note to self": I initially expected the browse "Parent Only Record" setting might enable me to build the form as you suggested, but it did not work as expected.... (I'm going to revisit this possibility in my experimentation though.)

                                Without using the <form>.VIEWQUERY() method to open a second form, (as opposed to embedding the browse within the main form): a5 applies grandparent/parent filters, so you can't get combined totals for the "grandchild." (and if you don't include a browse to select a "higher level" table filter, a5 defaults to using the first record) ~ I've already tried about every combination I can think of. Regardless, the browse always fails to show all the records when the browse "Parent Only Record" settings is left unchecked. (and more data shows up than can fit in the allocated vertical browse space.)

                                Attempting to accomplish this by doing it "your way" does not address one huge problem: You can not get all the "grandchild" records to appear within one browse on the form at the same time. (Unless that "grandchild" table has an extra field populated with a record value for each "grandchild" value that links it directly back to the "grandparent" table.) In addition to this being "redundant", it also requires an extra process to populate the "grandchild" table with data (from the "child" table) so that you can can bypass the "child" table completely. ~ That's what I was referring to with regards to relational database and data normalization. (And that's what I spent an entire day trying to do before coming up with this 99% working solution.)

                                If you look at the fields in the "grandchild table", that was one option I was already pursuing before I came to the conclusion it shouldn't be necessary, given the existing (indirect) link from "grandparent" to "grandchild."

                                I'll add that: Initially I was surprised (as i struggled with before coming to the conclusion) that I was unable to implement a solution as you suggested.

                                If I make a huge window, and make the browse tall enough to display all records without worrying about "over-filling" the browse, the solution works perfectly. ~ I believe this is certainly within the scope of what a5 is expected to be able to do. (Otherwise, why would the browse "Parent Only Record" setting exist in the first place? Besides, if the browse worked correctly here, the solution would be "near perfect." a5 actually handles the scenario perfectly, with the exception of the browse not accommodating a returned "recordset" larger than the physical allocated vertical browse space!

                                ~"THE BROWSE ONLY SEE'S X PARENT RECORDS. IT FAILS TO TAKE INTO ACCOUNT THAT YOU'VE ASKED THE BROWSE TO RETURN ADDITIONAL RECORDS
                                Last edited by SNusa; 01-19-2013, 10:44 PM.
                                Robert T. ~ "I enjoy manipulating data... just not my data."
                                It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                                RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                                Comment

                                Working...
                                X