Set children records will not display correctly

[rmcgaffic]

Re: Set children records will not display correctly

Tom Cone,

Thank you for submitting a bug report.

Yes, the issue appears to be one of synchronization. I found that when it pushed F5 that both type in fields and combo boxes displayed as they should.

Tim,

The first screen shot in my original posting shows a default A5 form, and you are correct, everthing displays correctly. This demonstrates that my data appears to be OK.

It's just that I want the option to display only a single record, because in many cases, there is only one record, but to allow for the easily accomodation of many records. The screenshot below was taken from web site of a CRM package, which shows the use of a button to display additional email addresses.

G,

Thanks for the code! I am hopeful that Tom's reporting of this bug gives us a fix sometime soon. I am reluctant to put a lot of code behind objects to force them to behave as they should. This is the kind of workaround that Alpha should not impose on developers.

All,

Have any of you noticed that the vertical alignment of the combo box does not work properly? The second screen shot shows in a large font size, type in fields and combo boxes with vertical alignments respectively of top, center, and bottom.

Note that the type in fields are correct, but that the combo boxes are not. The combo boxes all appear to be vertically aligned at TOP.

Bob McGaffic
Pittsburgh

[Davidk]

Re: Set children records will not display correctly

It may be a bug, but why would you want to do this anyway? The images attached show a form with one child record. If I were doing this in Access or A5 I'd be using sub-forms or a browse to display all related child records... not just one. In the A5 form builder, for a custom form, you get to select the parent records, then the list gives you the browses to select..

David

[Selwyn Rabins]

Re: Set children records will not display correctly

It may be a bug, but why would you want to do this anyway? The images attached show a form with one child record. If I were doing this in Access or A5 I'd be using sub-forms or a browse to display all related child records... not just one. In the A5 form builder, for a custom form, you get to select the parent records, then the list gives you the browses to select..

David

This is not a bug.

Normally, you would use a browse to show the one-to-many's. If you used embedded browses for each child table, (and still had the fields for the child tables on the form itself as well), then it would also work.

(In some way, you might consider the fact that F5 did anything - you might have expected it to do nothing).

You have created a flat form. If you open the default browse for the set, you will how the data looks. This will make it clear why you are seeing the behavior that you see.

Work around to get behavior you expect:

If you created separate forms for the 3 child tables and put those on the main form as 'sub-forms' then it would work the way you expect.




At 06:21 PM 7/7/2008, you wrote:

[G Gabriel]

Re: Set children records will not display correctly

If you created separate forms for the 3 child tables and put those on the main form as 'sub-forms' then it would work the way you expect.

Selwyn:
I did see the same behavior with embedded sub-forms. I didn't think it's a bug but an unusual behvior brought about by an unusual design. After all, if you put the child's fields on the form, how are you to know how many records are there for the child table. Not to say that there is no legitimate reasons to do that as for example if you are adding values to the child and do not wish to scroll across an embedded browse.

Can't say it's a bug when you are trying to use a spoon as a fork. About the best work-around is to place a browse (of the child table) on the form and hide it.

[Selwyn Rabins]

Re: Set children records will not display correctly

Selwyn:
I did see the same behavior with embedded sub-forms. I didn't think it's a bug but an unusual behvior brought about by an unusual design. After all, if you put the child's fields on the form, how are you to know how many records are there for the child table. Not to say that there is no legitimate reason to do that as for example if you are adding values to the child and do not wish to scroll across an embedded browse.

Can't say it's a bug when you are trying to use a spoon as a fork. About the best work-around is to place a browse (of the child table) on the form and hide it.

well put.

putting the embedded browse on the form and hiding it is clever. the embedded browse serves as a 'navigator' for the data in the one-to-many child tables, and its presence is necessary.

[Davidk]

Re: Set children records will not display correctly

Makes sense to me. Thanks.

[ChopOMatic]

Re: Set children records will not display correctly

For the record, my problem is with a plain old browse layout. The set relationships just aren't working. :-(

[G Gabriel]

Re: Set children records will not display correctly

Jerry:
There are numerous reasons why the records might not show. Quite possibly the linking fields are not of the same type and/or the same length .. or any number of other reasons.

Granted you do not wish to post the actual records. What you might do is duplicate the tables and the set to a new folder, do not duplicate the records, then post the new set without any records or with some mock records. I am pretty sure whatever it is, it won't be hard to figure out pretty quick.

[Peter.Greulich]

Re: Set children records will not display correctly

It has always been the case that in order to successfully display/navigate/edit child records, you need either an embedded browse or a child subform - unless you use Gabe's idea of hiding the browse (or not hiding it).

[rmcgaffic]

Re: Set children records will not display correctly

All,

The design objective sought by my form was a simple one.

Often for such fields as a telelphone number, many people have only a single number. Other people may have as many as five or six telelphone numbers, mulitple fax numbers, etc.

Rather than consume large amounts of screen real estate with an embedded browse on the face of a form, or waste a separate tab on a tab control for phone numbers, or worse yet create each telephone number type as a separate type-field, this approach is elegant and parsimonious. This is not an "unusual" design; but apparently not easily and directly possible with A5V9.

What I am trying to replicate with A5V9 is what is today considered by many as best practice in commercial software design.

I am disappointed that A5V9 does support such a simple and clean design. Obviously, I was overly optimistic when A5V9 did support this with the first child record of Address, and I naively assumed that it would do so with the other child records of Telephone and eAddress as well.

So it appears that the only work arounds are:

1. Write code to force F5 refreshes of child fields
2. Use an embedded browse requiring lots of careful property adjustments to achieve the same look and feel as my example.

I will report back to the forum the amount of work required for the second approach.

Bob McGaffic
Pittsburgh, PA

PS: I am curious as to why a design would permit one single child table record to be displayed, but not a single record from a second and third child table to be displayed. Wouldn't a more consistent design have been to permit none?

PPS: I will report the incorrect vertical alignment of the combo box control as a bug, hopefully easily corrected

[G Gabriel]

Re: Set children records will not display correctly

Robert:

1-Nothing wrong with your design. In fact, I have exactly the same design and it is the most efficient one that I could think of. The problem is on how you display it for viewing and/or editing. We are talking about design in terms of using a form based on a set then in that same form, place fields from the child (free-form style). That's, for the lack of a better word, the "unusual" part. Unusual in the sense that, most programmers will have the parent in free-form and the child in an embedded browse. I personally don't like browses.

2-If you want to see the values when you step into the child's fields, then use the script, if you want to see them when fetching through the parent's records, use a hidden browse. You don't need both, Either one or the other.

3-You still have to figure a way to be able to tell whether or not there is more records in the child table beyond what's visible.

[Peter.Greulich]

Re: Set children records will not display correctly

So it appears that the only work arounds are:

1. Write code to force F5 refreshes of child fields
2. Use an embedded browse requiring lots of careful property adjustments to achieve the same look and feel as my example.

3. Use subforms for each child field. Ok, it's an extra step. Selwyn gave you the hint when he said look at the default browse for your set and see the record construction (make sure "show only parent records" is unchecked). It's really not a bug, just a reflection of the set structure.

[G Gabriel]

Re: Set children records will not display correctly

PPS: I will report the incorrect vertical alignment of the combo box control as a bug, hopefully easily corrected

I am not sure what are you referring to? In any case, this should be in a separate thread as it is a completly different issue.

[G Gabriel]

Re: Set children records will not display correctly

Peter:
Whether you use a subform or just fields from the child, it will not work properly without having a browse based on the child placed on the form. In fact, with a subform alone without the browse you will even see more weired stuff, for example, the values will dissapear when you step in the subform.

[G Gabriel]

Re: Set children records will not display correctly

To help better understand this:

1-When you design a form based on a set, the data are bound and synchronized with the composite table of the set (created by alpha once you establish the relationships).

2-If on this same form you place fields from a child table, these fields are not bound nor synchronized with the composite table but rather with the child table itself.

3-When you scroll through the form, you are fetching through the composite table, not the child table. Hence, you do not see the values of the child which are bound to the child table.

4-The script I gave you forces the fields (the objects) on the form to synch with the child table.

5-Alternatively, the presence of a browse object on the form, visible or not, forces the same synchronization.

Now, this is just my explanation (my guess of what's happening) and may or may not have anything to do with reality.,