Ok. As I posted and others have discussed in a previous thread, filters and sorts applied in a set definition result in funky acting embedded browses. The remedy? Apparently avoid applying filters and sorts in the set definition and apply them instead in the form properties. Still I question why the ability to apply filters and sorts in the set definition is provided if it works so erratically. But I can live with the work around/fix. So let me move on to on to puzzlement #2 regarding funky embedded browses.
For the longest time, and I do mean longest time (as in oodles of hours), I�ve struggled with embedded browses for child tables that are part of a set that simply don�t properly display their content. In the application designs I have constructed and tested extensively many embedded browses get opened with row focus placed on the very last row of the browse - when in fact it should be placed on the top row. In various incarnations the embedded browses may also scroll the display to the very top of the browse object display window such that only the last row is visible, even though there are numerous records that may precede the solitary displayed row. In other instances when the last row is focused erroneously then any and all main form fields that belong to the same table that are contained in the browse may either show no content (even though there is content) or may show erroneous content relating to the record that would be the first row of the browse, i.e. the browse row that should in fact be focused. The problem further exacerbates itself if there are additional child/grandchild records related to the embedded browse table that expect to receive linked field values during their record creation. In these cases the child/grandchild records can�t be correctly created because the linking field either receives an incorrect/invalid value from the embedded browse parent record or gets no value passed at all.
Anyway I have just had a Eureka moment caused by tripping over the previously unapparent source of my frustration. Tabbed Objects! Never been on my list of suspects, but the tabbed object is indeed the guilty party. As best I can determine after myriad set and form redesigns, A5 simply can�t/won�t/doesn�t properly synchronize embedded browse views and form views of set data for child tables that resides on tertiary tab panes (any tab panes beyond the first) when the parent form is opened. What this means is that embedded browses that don�t reside on the primary tab pane may or may not present correctly and any form data associated with those same browses may or may not present correctly. The quirkiness is compounded by the fact that the behavior is really quite inconsistent. Some browses may work others may not. And, very interestingly, the browses that break will seemingly vary dependent on specific sequence or order by which they were physically placed onto the tab panes in designing the form.
Well the immediate work around appears to be to procedurally issue repetitive screen/form refreshes in the OnTabChange event. Invoking refreshes does force the embedded browse and form data to resynchronize. But the refresh only works its magic on the currently active or focused tab pane, meaning a separate refresh must be issued for each tab pane that exhibits the problem. Workable. But what I�m wondering about is how much additional overhead is introduced by this work around, especially if it need be applied to a tabbed object with more than just a couple of tabs panes � like say 7 or 8. How much extra load does refreshing the screen on each tab change impose? Does this refresh burden compound itself over a network of multiple users simultaneously invoking repetitive refreshes?
My own opinion remains that this work around shouldn�t be needed and A5 should properly handle this synchronization issue as an inherent, non-procedural event. I am sort of surprised that this bug even exists at this point in A5 since browses are such a fundamental building block of the A5 software paradigm. Perhaps I�ve missed something along the way, either in this forum or in the A5 documentation; but nowhere have I come across anything pointing out that embedded browses and tabbed objects don�t really like to play nice together. Am I the first or only A5 user to encounter this?
For the longest time, and I do mean longest time (as in oodles of hours), I�ve struggled with embedded browses for child tables that are part of a set that simply don�t properly display their content. In the application designs I have constructed and tested extensively many embedded browses get opened with row focus placed on the very last row of the browse - when in fact it should be placed on the top row. In various incarnations the embedded browses may also scroll the display to the very top of the browse object display window such that only the last row is visible, even though there are numerous records that may precede the solitary displayed row. In other instances when the last row is focused erroneously then any and all main form fields that belong to the same table that are contained in the browse may either show no content (even though there is content) or may show erroneous content relating to the record that would be the first row of the browse, i.e. the browse row that should in fact be focused. The problem further exacerbates itself if there are additional child/grandchild records related to the embedded browse table that expect to receive linked field values during their record creation. In these cases the child/grandchild records can�t be correctly created because the linking field either receives an incorrect/invalid value from the embedded browse parent record or gets no value passed at all.
Anyway I have just had a Eureka moment caused by tripping over the previously unapparent source of my frustration. Tabbed Objects! Never been on my list of suspects, but the tabbed object is indeed the guilty party. As best I can determine after myriad set and form redesigns, A5 simply can�t/won�t/doesn�t properly synchronize embedded browse views and form views of set data for child tables that resides on tertiary tab panes (any tab panes beyond the first) when the parent form is opened. What this means is that embedded browses that don�t reside on the primary tab pane may or may not present correctly and any form data associated with those same browses may or may not present correctly. The quirkiness is compounded by the fact that the behavior is really quite inconsistent. Some browses may work others may not. And, very interestingly, the browses that break will seemingly vary dependent on specific sequence or order by which they were physically placed onto the tab panes in designing the form.
Well the immediate work around appears to be to procedurally issue repetitive screen/form refreshes in the OnTabChange event. Invoking refreshes does force the embedded browse and form data to resynchronize. But the refresh only works its magic on the currently active or focused tab pane, meaning a separate refresh must be issued for each tab pane that exhibits the problem. Workable. But what I�m wondering about is how much additional overhead is introduced by this work around, especially if it need be applied to a tabbed object with more than just a couple of tabs panes � like say 7 or 8. How much extra load does refreshing the screen on each tab change impose? Does this refresh burden compound itself over a network of multiple users simultaneously invoking repetitive refreshes?
My own opinion remains that this work around shouldn�t be needed and A5 should properly handle this synchronization issue as an inherent, non-procedural event. I am sort of surprised that this bug even exists at this point in A5 since browses are such a fundamental building block of the A5 software paradigm. Perhaps I�ve missed something along the way, either in this forum or in the A5 documentation; but nowhere have I come across anything pointing out that embedded browses and tabbed objects don�t really like to play nice together. Am I the first or only A5 user to encounter this?
Comment