"Next record" form navigation button annoyance

[[email protected]]

brett,
Did you try changing your form to modal?

Bill Belanger

[brett s]

Bill, no I didn't. I avoid using modal forms in my applications to the greatest extent possible. I just use them as dialog boxes informing of errors during data entry.

[rfha]

FWIW, I'd like to add my 2 cents worth to this discussion. My systems are based on one concept when it comes to my users - if it can be screwed up, it will be screwed up, and the system had best accept and overcome that if possible.

I've run into this "next record adds a record" situation with A5v7 and for the life of me, cannot see why it should be the default action here. And, no, I have not considered modal design because:

1. I didn't know, until reading this thread, that it did not act this way, and

2. A system design should not have to be modified to overcome something that makes no sense in the first place.

I vote for the folks at Alpha patching the code to fix this cuz that makes a lot more sense than workarounds for a bad situation.

[[email protected]]

Richard,
If your goal is to keep users from "screwing things up", why do you want the modeless entry? Modeless allows them to change the data in a field without even confirming that. That was one of my gripes with Filemaker, is that users could just click on a field, (usually trying to do a find) change it, go to another record, and nothing asked them if they wanted to save the change.

View>Settings>Data Entry

gives you that option. Why is it upsetting that it is not "the default"?

Bill Belanger

[rfha]

Bill,

I appreciate your point about modifying fields, though that is a separate issue.

Allowing blank records to be inserted is totally pointless, to me. Perhaps someone could tell me the value of such things, for my feeble thought processes cannot conceive of why this should be.

[[email protected]]

Actually, it's all the same issue. If you use modal entry forms, blank records will not be added and fields cannot be modified without confirmation. I don't like modeless entry either, but I'm happy I have the simple option. Now if you've already designed an entire database with modeless forms, I can understand your disappointment.

Bill

[Tom Cone Jr]

Allowing blank records to be inserted is totally pointless

Richard,

this behavior has been part of Alpha Five in all previous versions with which I'm familiar. I suppose the designers had to make a choice when the user got to the end of the table and then tried to move beyond it. One choice would be to do nothing. Force the user to initiate a new record with a special keystroke or key combination. Another would be to assume the user knows what they're doing and wants to begin a new record. The designers chose the latter, possibly in the interest of speeding data entry. The point I've tried to make several times in this thread is that while a new record is begun, it does not cause the blank record to be inserted in the table, as your comment suggests. Nothing is committed to the table until the user does something else after the new record is begun. If the user has permission to enter records they can always enter a blank record whenever they want anyway. This is just one form in which that becomes possible.

I'm not saying this is right or wrong. It's just the design choice that appears to have been made long ago. If it were reversed I'm certain we'd hear folks complaining that they now have to take extra steps to begin a new record when it used to be "automatic".

I've found Martin Cole's approach to solving the problem of the accidental save to be solid. It helps in this situation and in cases where the user begins a new record, leaves it blank, and then navigates away from it.

-- tom

[sdramey]

refresh bug?

Do you have any 'refresh' commands in your event scripts? I was getting the same behaviour in a form (with data entry set to modal and continuous enters restriction checked) on a button (to cancel entry of a new record) with the following action script:

set value of variable 'to show/hide conditional object
refresh display 'to send new var. values to conditional object
cancel changes 'basically, a cancel()
set fill style 'I'm changing the background color of the form
send keys 'I send a tab to get the cursor where I want it

When I enter a new record, then immediately hit my cancel button a new blank record is added. But when I comment-out the 'refresh' command, voila! it works as planned (it turns out I didn't need the refresh to make the conditional object see the new variable values).

On the same form, the refresh can prevent the form from returning to modal after a new or change record command, depending on where it's at. With the following script, the form remains modeless even after a cancel command is executed in the action script:

Cancel changes
set value of variable
set fill style
refresh display
send keys

When I moved the refresh and cancel commands as shown at the top of my reply (cancel after refresh), the cancel button returned the form to modal as it should. Of course, that's when I discovered new records being added automatically, & I eventually commented-out the refresh command, which made everything work beautifully (until the next bug is found).

What is it with the refresh command?

[rfha]

Nope, I haven't used any refresh commands.

My solution to the issue, though I really would prefer another way, is to make one of the fields required. This causes an warning, requiring the blank record to be deleted before anything else can be done.

[sdramey]

I found why the refresh action script does what it does after looking at the code (duh), which is:

'Refresh data in current form at parent level.
'Can only resynch data in View mode, so save record first to be sure that layout is in View mode.
topparent.Commit()
topparent.Resynch()
topparent.Refresh_Layout()

[rfha]

Revisiting unwanted record additions

I've been experimenting with ways to try to get around this bug regarding the unwanted addition of blank records when a user clicks next record several times.

There should be a simple fix, but what I see above doesn't seem to work for me.

I've a situation where there are a number of tables that have a calculated field made up of the first name, mi, last name and suffix for a person. The various tables deal with info like birth, death and marriage certificate information. Each table contains a field called "Person" that contains the calculated result.

The various forms contain custom navigation buttons for reasons not germain here.

Here is my latest effort for a common script executed OnPush when the user exits any of the forms:

dim name as C
dim tbl as P
dim fld as P

tbl = table.current()

'Check to see if required field is filled in
tbl.fetch_first()
count = tbl.records_get()
for i = 1 TO count
tbl.fetch_next()
fld = tbl.field_get("Person")
name = fld.value_get()
if name=" " then
tbl.delete_record()
end if
next i

It doesn't work because of the tbl.delete_record() not being in correct <OBJECT>.delete_record() form. It may give someone an idea, however.

Your help is appreciated, as always.

[Tom Cone Jr]

Possible solution ???

Richard, I don't know if this will play well with your other field rules, but in testing with a simple table here it seems to work reliably.

For the CanEnterRecord Record Event in field rules:

tbl = table.current()
if tbl.mode_get() <> 0 then  'table is in change or enter mode, so block new record
	cancel()
end if

Here if the user navigates to the last record in the table and begins a new record by navigating further a new record is begun, but is NOT automatically committed when further navigation is attempted.

BTW, I don't consider the default behavior to be a bug, for the reasons outlined elsewhere in this thread. I hope you'll agree that labelling the behavior as "bug" or "not bug" won't help us find a solution to the interface problem your customers present.

-- tom

[rfha]

Thank you, Tom. This is helpful.

As for my labeling it a bug, I did read all the other posts carefully. I can appreciate a long-standing situation being difficult to resolve, especially when many have developed workarounds that might be compromised.

I find it difficult, however, to understand or accept how someone clicking on a next record link while moving through a table can reasonably expect to create blank, and almost undeniably unwanted records. Several others spoke to that situation specifically.

If the undlerlying software permits this situation, long-standing or not, I consider it to be a bug in that software. And that is not meant to be in any way disrespectful to those who have expressed their opinions in this thread. I respect their comments and yours immensely. This forum is most helpful, especially in situations like this. The very length of the thread, to me, is an indication of the depth and impact of the problem. Just look at all the suggested solutions - to something that should not ever happen.

This is my considered opinion, and I think that Alpha should do something about it.

[Tom Cone Jr]

Richard, you're welcome.

I guess where we differ on this is that to me the user is no longer "moving through a table" when they reach the end and then try to keep going. Simple as that. You would prefer that the user not be permitted to continue automatically, I prefer otherwise.

Instead of calling our respective preferences names, I tend to think of a bug as a situation in which the program behaves differently than has been documented by the developers. In other words, behavior not as designed.

The User Guide covers this situation pretty concisely:

Add a New Record

To add a new record, you need to open a blank record. Do any of the following to open a blank record:

Click the New Record button on the toolbar.

Select Records > Enter New Record.

Use the keystroke: CTRL E.

Navigate to the last record in the table, and press Enter.

I can understand a desire to change the default behavior. The New Feature Wishlist forum is designed for just that sort of request. But calling the documented behavior a "bug" isn't consistent with my understanding of the term.

--tom

[rfha]

Tom,

I yield - sort of... ;)

I suppose a documented fault cannot be defined as a bug in the literal sense, but it is still a fault, IMNSHO. My experience shows that one can expect users to do exactly what they are not supposed to do, or supposed to be able to do. That is the basis for my carping.

I'll add this to the Wishlist, though somehow I doubt that anything will happen, but who knows!