Using an xDialog for data entry into a set

[Ronald Anusiewicz]

For many years there have been discussions on this board about data entry into forms and browses.

Quite a few years ago Tom Cone put an example on the board of using an xDialog for data entry. It was a phone log entering records into a single table.

Well, I decided to try and take it a step further using xDialogs to enter records into a set. The reason is we were having issues using a form with an embedded browse. I'm sharing Tom's work and my changes. I hope someone will try this out and offer some constructive feedback. I think it's bug free but I'm sure it is not.

Thanks,

Ron

[Ronald Anusiewicz]

Found a number of issues with the script used to add items. Here is my updated script.

[Ronald Anusiewicz]

I think this finally addresses all bugs. I changed how pressing the enter key works. It is extremely fast now when inputting multiple items.
Open the items dialog, press enter creates a new entry. The enter key moves to the next field. When all fields are filled, the enter key move to the save button. Press enter and the entry is saved. Press enter and a new entry is started. Very fast.

[Ray in Capetown]

Hi Ron
It runs smoothly. I read all the code - VERY thorough, every possibility as far as I can see, is checked for - Buttons active or gray, entry data dirty, data changes elsewhere. Great job, but each very specific to the dbf so not usable out the box.
I don't know if I personally would code such a dialog as this for every occasion I did an overlaid entry/edit. I do many, using form dialog methods.
I looked at the possibility of making this a generic function - it would not be able to lay out the data quite so well, validate and so on.

[Ronald Anusiewicz]

Thanks Ray,

This was coded for an annual event where a hi volume of people come in and list items for sale. The people inputting the data are volunteers. Minimal use of key strokes was deemed to be very important.

In the past I tried using forms and browses and there were always issues. System lockups, weird things happening, having to restart Alpha, etc...

This xdialog method ran flawlessly. In this case it was easier to lock down the xdialog than a form. Who knows what the users are doing when pressing keys and mouse clicking about.

I agree that it's not very portable, but our results is it's user friendly.

Ron

[Ray in Capetown]

I think a lot of it can be re-used for someone willing to handcode the layout and specific data validations. What got my attention: Your wrapper code is excellent, including buttons, their awareness of editing status, pre and post entry data checking, error checking - all very well thought through - it makes sense now you explain that it came from a pressure cooker environment.

[Ronald Anusiewicz]

Thanks again. I did forget to mention that this application was networked with five computers. Another reason why the xdialog and xbasic data entry worked so well. We had lock ups when using form based lookups. Xbasic lookups worked perfectly.