Default start value not resetting

[Nick Oldfield]

Re: Default start value not resetting

OK, I am really struggling with this trying to develop a workaround. As I said, I can't really put a dummy record as the first record because the quote is used to develop all sorts of other forms. So I need to look for a programmatic workaround. First question is how do I know I am dealing with the first quote? The start default number will be different system-by-system since the user has the option to set the start quote number anywhere he wants. I guess I could read the default from the field rule and see if my quote number was the same?
Second, assuming that this will allow me to know that this is the first quote, how do I work around the problem? What is it that will allow me to delete the first record while still retaining the default for the new first record? Zapping the table seems to work fine as far as I can see, so possibly if I close the table and then zap it?
Any comments or other suggestions?

[Nick Oldfield]

Re: Default start value not resetting

I am now looking at trying to solve this problem in the "create new quote" logic. I am carrying the required start quote number setup by the admin during system setup as a global variable. The idea is that in the "new quote" form I will check on exit to see if the quote number is less than the global variable, and if it is I will set the quote number equal to the global variable. Hopefully that will solve the problem, and I can avoid the bug.

[del025]

Re: Default start value not resetting

Nick:

I have found a rather simple method of avoiding the bug. The bug appears when the initial starting default value of the table is deleted mistakenly while attempting to delete the initial record of the table. This Default value is able to be deleted because it is displayed and highlighted on the form after deleting the initial record.

To correct the problem:
1. Be sure your table is zapped and verify that it is working properly.
2. Go to the table field rule editor and go to the data entry tab of your auto increment field. Scroll down to the bottom where it says "Position cursor at:" now select from the drop down box "End of selected text".
3. Save your changes and try it.

Now after deleting the first record the default value will not be highlighted so mistakenly pressing the delete button again won't allow deletion of the default number. I've zipped up a sample for you to play with but it works for me every time. I do admit it is not full proof since someone could after deleting the initial record, highlight the default value using the mouse, press delete again to remove the value. Although this is possible it's not likely to occur since it is only possible on the initial record.

[Tim Kiebert]

Re: Default start value not resetting

On the Data Entry tab in field rules set the Skip expression to .t. That way a user can never enter that field.

[Nick Oldfield]

Re: Default start value not resetting

Neither of these have any effect. My cursor setting was already as suggested. "delete" is only happening once because it is xbasic on a button. Also the quote number field on the form is read-only.

[del025]

Re: Default start value not resetting

The form where I create the quote has an embedded browse (for quote items - child records) so when I exit to cancel the quote I can't be certain whether the quote has already been saved (if focus has moved to the child the parent will have been saved). When I push the button for "Cancel and Exit" the following occurs;
'write the record in case it hasn't been
parentform.commit()
'delete the current record in parent
(this is the AlphaScript code for that action)
'close the form
parentform.close()

As I said, this mechanism works fine except if I cancel the very first quote I am in the middle of entering.

Any ideas?

Nick:

I altered my original autonum test data base to a parent Child set as you describe above with an embedded browse on the form. Open the form and test it, I haven't been able to make it fail. The buttons on this one all use the action scripting only. I have successfully canceled out of the first form, added several forms and deleted them all, canceled 1/2 way through, canceled after adding multiple child records to the first form etc.. Each time the autonumber field properly numbers.

If you feel this sample is not similar enough to yours could you post a sample?

Paul

[Nick Oldfield]

Re: Default start value not resetting

your sample got me thinking and doing some more analysis and the problem is SOLVED - well, it's still a bug, or a documentation issue, or both.
I noticed with my code if I went to enter a new quote 1000 and did not enter any data at all, the quote number successfully reset to 1000. If I entered any data, either in the child or parent, the quote number briefly changed to 0000 as the form was closed. Almost as if the form were being refreshed after it was closed. This does not happen in your example. So I started to compare your example with my code. First, just to be sure, I changed the name ID field to character, since that was the same as mine. That had no effect. Then I started to look at the field rules. I noticed that in the field rule where you set the default, you had checked "set default value at start of data entry". I had not checked that box - according to the documentation that should only be checked if you want the same default value to appear in every new record, which I don't. And without it checked, the default value appears correctly when you enter the first record, so I had assumed things were OK. BUT if you DO check the box, that solves the 0000 quote number problem when you cancel the first record, and does not screw up any of the subsequent records! Despite having checked the box that supposedly sets the default to be the same on every record, it does not happen that way. There is obviously something in the interaction between the default and increment field rules that isn't clear.

So the problem could at least be be avoided by changing the text on the field rule. On the "tip" for the autoincrement field rule, should be added "and make sure the 'set default value at start of data entry' box is checked"

Thanks for the help!!

If I have any more problems with this I will post back.

[del025]

Re: Default start value not resetting

you had checked "set default value at start of data entry". I had not checked that box - according to the documentation that should only be checked if you want the same default value to appear in every new record, which I don't. And without it checked, the default value appears correctly when you enter the first record, so I had assumed things were OK. BUT if you DO check the box, that solves the 0000 quote number problem when you cancel the first record, and does not screw up any of the subsequent records! Despite having checked the box that supposedly sets the default to be the same on every record, it does not happen that way. There is obviously something in the interaction between the default and increment field rules that isn't clear..

Nick:
I'm glad you have the problem corrected. I will agree there is a bug in the autonum for sure. You are a little off on the "Set default value at start of data entry" check box though. I read the help file on this and I see what your saying, it's just documented in a confusing way. Without that box checked the default value will be set on that field on receiving the focus. With the box checked the default number will be set on the start of data entry - Won't use the same number it just determines when it is entered into the field - autonumber still applies and all records should have a different number with or without the check box selected.

I agree this also does not respond quite how it should but it certainly does help us avoid the autonum problem.

Let us know how you make out


Tim:

I had tried skipping the field with .t. but for some reason it doesn't resolve the problem and I'm not sure why - believe it is part of the bug as well. Even with the above work around adding the .t. in the skip box forces the autonum to fail - the autonum seems a little buggy regarding removal of the first record - I hope Alpha takes a look.