Opinions on Form Design change

[MoGrace]

I have a rather complex form where data entry takes place at the child and grandchild levels and it uses several conditional objects to show or hide sections of the form's tables until some pertinent data is filled in. The problem I am having with this form is that currently it runs filtered by a query that seems to be what may be messing with the updating of the child table indexes. So I am trying to get rid of the need for this query as the means to show the linked records for a particular date.

One of the things I am trying out is to have a one record table (SCHEDHDR) with one field (SCHEDATE) as the header for the set. I want to initially open the form to today's date which most often will not have any linked records yet. But I also want the option to let the user pick a previous or future date from the calendar smart field and have the set links refresh. Which doesn't work directly just by changing the header date, so I recall the form in the schedate field's OnChange event and that seems to work - so far.

In the original design, I used a shared variable on the form to change the date and refresh the query. But if the user moved to a date without links the conditional objects would still display briefly or when adding multiple new child records, the query would get out of synch and the only fix was to close and reopen the form.

The other idea I tried was to prepopulate the SCHEDHDR table with business days. But that is also fraught with problems if new header dates are needed.

Changing the set header link field and recalling the form in that one place seems the easiest way to simplify this form. Is anyone else doing this OR has abandoned this idea? It would be good to know the reasons before I tackle changing a bunch of scripts...

apptsch_set.png

[MoGrace]

Re: Opinions on Form Design change

One thing I just discovered with this new set is that I am not getting the correct record pointer for the appt_hdr table that is displayed in an embedded browse, but also has some fields pulled out on the form. When I try to reference those fields from the selected browse row, I am getting data from the top record in the browse and not the one I am on.

Why is it doing this? Or better yet, how do I fix it? I need the info from the current record to use in a script that adds another record in an external table.

[MoGrace]

Re: Opinions on Form Design change

Finally found the answer HERE The trick is to set the pointer to the browse table and not the set table.

Doesn't work: hdr = table.current(2) -> always points to first record displayed in the browse

This works: hdr = browse1.table_get() -> points to the selected record

Apparently none of the 60+ people who viewed this thread knew the answer either! Hope it helps some of them...

[Mike Wilson]

Re: Opinions on Form Design change

I believe you might know my answer... perform all data entries using xdialogs. They offer complete and total control of data presentation and data processing, unencumbered by a base table connection to mess you up and having a table(s) held open because of the form-table requirement, complete control of data entry events for presentation of secondary data, and objects showing data, or for data entry, and ease of presentation of data not within the set which a form is obligatorily bound to ... dialogs are THE ticket for exquisitely fine-tuned data review and data entry processes. It is a very rare instance I use a form for data entry and I use dialogs routinely for presentation of data from mild-to-moderately complex data mining. High complexity data mining goes to temporary tables and are presented in reports linked to the temporary tables. This business needs magic and xdialogs allow you to make magic.