List controls cause data to be lost

[MichaelFrame]

I have a fairly simple form that enters data into a set. Three of the fields are pulldown lists whose contents are taken from fields in the set being updated. The pulldown fills in the corresponding field in the record being created or updated (for example, a pull-down list for paper-size is populated by the set's paper-size field - user's can add a new paper-size if theirs is not in the list). The problem is that periodically (but frequently) the record being created is largely cleared - it seems to happen as we leave one of these fields, but it's claimed that sometimes the clearing occurs later - I haven't seen the latter behavior myself. We changed the fields to be simple read/write text fields and the problems have gone away. The pull-down technique is handy and we'd like to be able to keep it, though we can live without it. Any suggestions re where this problem might be coming from? Thanks in advance. I'll report if I get a solution outside this forum.

Mike

[Mike Wilson]

Re: List controls cause data to be lost

mike,
I have experienced this and have gone to a method that does not use a lookup to the same table and same field values to populate the dropdown, but instead have made a separate support table (sys_lists) that has three fields (table,field,field_values) that populates the field lookups in the field rules. That table is populated with the values as a posting with the record on save event. It works well except it does require extra coding that in the event you delete a record in the primary table having the last circumstance of a particular value you also must delete that value in the supporting sys_list table. You don't have to do the latter but if not, it will show values in the dropdown that don't really exist in your primary table. This has worked well for me and a few lines of xbasic code that might not work for you, but I thought I would throw it out as an idea.

[MichaelFrame]

Re: List controls cause data to be lost

Mike W,

Thanks so much for the idea. I'll give it a try. Did you come up with this idea because you were having a similar problem to mine, or as a better way to manage your lists? If the former, did anyone ever give you any idea of what the underlying cause of the problem was? I'm using dbf files.

Thanks again,

Mike

[MoGrace]

Re: List controls cause data to be lost

I think the problem may be that if you allow the user to enter a new paper size in your lookup list, then you are adding a new record to the table your form is based on and the other fields on the form will go blank as a result.

[Mike Wilson]

Re: List controls cause data to be lost

Mike,
I was having problems as you described. I am not certain as to the reason except I believe it was a table mode conflict, probably like Robin describes. And yes, this did evolve to a better method to maintain supporting lists... one table. I have moved away from data entry/edits using forms and browses, and do almost exclusively dialog entry/edits. For me, I have learned xdialog well enough to make this work and have chosen dialog entry because of the robustness of events you can tap into with xdialog, and the vast reduction of table conflicts of the types that is probably occurring with this issue, as Robin described, especially in a network environment. I have a UDF - sys_list_get(tablename as C,fieldname as C) that uses table.external_record_content_get() to populate a variable with the required list for the dialog combo box fields. But it works for form controls with table field rules well also.

[DaveM]

Re: List controls cause data to be lost

May sound crazy, but a similar thing here. Found it was the last field in the form. The form would go to the next record before it was saved.
Solution for me was to get the last field on the form and cause it to go to a predetermined field on exit of that field.
May not be helpful to you.

[MichaelFrame]

Re: List controls cause data to be lost

Robin,

You could be right in general, but in the case of the testing we were doing we were only picking existing values from the list. It's possible to add new values, but we weren't (intentionally) doing it at that time. There's always a possibility of typos or cursors being moved to the wrong place. Some of the testers were good typists and didn't necessarily watch the screen while typing - I, on the other hand, am hunt and peck and make sure I'm in the correct field for what I'm typing. The error occurred on all our machines.

[MichaelFrame]

Re: List controls cause data to be lost

Dave,

That sounds very similar to what we were seeing. I'm away for a few days, but I'll play with your idea when I get back. I'll post again when I've run the test and tried your solution.

Mike

[DaveM]

Re: List controls cause data to be lost

Michael,
If it happens to be the last field, you may also check the form properties/permissions and do not allow multiple entries. The default for reports is that when the last field is done and you leave it, it starts a new record.

In field rules, for a lookup, you can decide if the user can add a new lookup record, Just type anything or the input finds the closest match. If you allow them to add a record to the lookup db, it would be good to have a form built for that with an embedded browse(be sure they can not work in the browse). With the browse, they "may" see what they want is already there.