Cancelling new record entry on embedded browse

[enstorms]

I am about to give up trying to find a work-around for this problem. Have an embedded browse of one table and one field on browse. Records already entered. On entering a new record, press enter and record saved and ready for next entry. Press Esc, new record entry canceled and last record of browse has focus.
Now, if there was a way to code in pressing the esc key, all would be fine and dandy. Sys_send_keys("{Esc}") doesn't work in the field rules CanSaveRecord event. Have tried all the suggestions found so far on this "problem":

t=table.current() ' or t=table.get("dailyentries")
if t.fieldone="" .and. t.fieldtwo="" '(two fields are blank)
if is_object("dailyentries")
:dailyentries:browse1.cancel()
end if
end
end if

t=table.current() ' or t=table.get("dailyentries")
if t.fieldone="" .and. t.fieldtwo="" '(two fields are blank)
cancel()
end if
end
end if

Doesn't seem to make any difference whether the form is modal or modeless, or whether "continuous enters" is checked or not.
Has anybody found a way around this problem that works?
Thanks.
Ernie

[Tom Cone Jr]

Sorry, I've read your post twice and still don't know what the problem is.

Here are some possibilities, all of which fit what you've described so far:

a) you're trying to prevent blank records from being saved in an embedded browse?

b) you're trying to prevent focus from shifting to a "new record" in the browse when the user presses ENTER key?

c) you're trying to prevent focus from shifting to a "new record" when the user saves a row in the browse?

[enstorms]

a) is correct.

[Tom Cone Jr]

Ok. A technique that's often recommended is to use the cancel() statement in a CanSaveRecord field rule event script. The save for the pending new record would be canceled by the script if the trimmed field length is zero. This has been discussed in lots of other threads, so you might try searching for example code.

[enstorms]

Tom,
The two quoted scripts in my first post above is what I have found in my search and they don't work.

t=table.current() ' or t=table.get("dailyentries")
if t.fieldone="" .and. t.fieldtwo="" '(two fields are blank)
     if is_object("dailyentries")
          :dailyentries:browse1.cancel()
     end if 
     end
end if

t=table.current() ' or t=table.get("dailyentries")
if t.fieldone="" .and. t.fieldtwo="" '(two fields are blank)
     cancel()
     end
end if

Guess I should have used the "Code" wrap instead of "Quote".

[Tom Cone Jr]

Ernie,

your second script would work if you trimmed the field values.

Alpha's native format (DBF) uses fixed width fields. When the user doesn't supply field values from keyboard alpha supplies blanks. Just as though the user pressed the spacebar over and over. These blanks fill up the fields and maintain the fixed width format. The point is that a field that "looks empty" will always have blank spaces within. Trimming removes the blank spaces. The same thing happens if the user enters 4 keystrokes into a field that is structured to hold 10. Alpha "pads" the input value with 6 blanks to maintain fixed width field structure. Surely, you've bumped into this before, right? Does this make sense?

Anyway, here's an easy example for you. Try to enter a record to the invoices table that has an empty inv_desc field.

Hope this helps.

-- tom

[enstorms]

Tom,
Makes perfect sense. But I did not realize that if you didn't enter anything, something was entered, even if you can't see it.
Thanks a bunch.
Ernie

[enstorms]

Tom,
Your example works like I want it to. Mine doesn't and can't figure out why. Could you take a look when you get time?
There are two tables. The stock_classes is the one I'm working in. Two forms. Open the wiz_livestock form. Click on <Add new Class> then click the next button to open another form. You'll notice that the new record is still there when the other form is opened. And when you close the other form, the wiz_livestock form is still in edit mode with the new record showing.
I tried this in your example by putting a button on My_form and called a form for customers I created. When you push the button on yours to open a customer form, the new record disappears. I think I've got the same code in the CanSaveRecord event. But I'm starting to see double.
Thanks. Appreciate your help.
Ernie
P.S. I'll be out for awhile, so no hurry.

[MikeC]

Ernie,
I took a short peek....you did not trim as Tom indicated to do....

dim t as p
t = table.current()
if alltrim(t.ACCT_NAME )= "" then
    cancel()
end if

Also, seems like a missing table that you have a posting rule for that brings up an error which prevents any testing....guess I could take it out but try using the alltrim() first.

[Tom Cone Jr]

Ernie, I took a long look and cannot get the browse to behave correctly using vers 9. Data entry through browse objects is difficult to control at best, and I often avoid it. If you must, perhaps this alternative approach will work for you... perhaps not.

I've abandoned the field rule (cansaveevent record event), and now do all the work in the button push. Basically, I let alpha save the empty record and then delete it. Clumsy.

-- tom

[enstorms]

Tom,
I thought yours might have been done in v10 since the icon was red. Wasn't sure if it would be different or not. I had thought about your solution, but had read a post in my searching where someone steered away from doing that, so thought I'd see if I could find other options. Guess not with v9.
Really do appreciate your help, as always.
Ernie

[Tom Cone Jr]

Ernie, my preferred solution for this kind of situation is to force the user to cancel or save any pending edits before shifting to a new form. This is made more difficult when one uses a browse object for data entry. I've begun using browses for navigation and display. But then use table based forms when entering or editing a record.

[Tim Kiebert]

tested the following code placed on the CanDepart event of the browse in v9 using your sample and it seems to do what you want.

t=this.Table_Get()
if alltrim(t.stk_class) = "" .and. alltrim(t.notes) = ""  then
    this.cancel()
end if

[Tom Cone Jr]

Thanks, Tim. Good idea.

[enstorms]

Tim,
Thanks for the idea. I'll put that in my code bank. I can see where it would work if I went directly to the "Next" button, but if I pressed the up key to go to the previous record, it would still enter the blank record. However, I think my code prevents moving off the record to another record with the up/down keys. So only two options, press the Esc key or something other than on the browse itself. Would be nice to be able to code in a pressed Esc key. I think that would solve this whole issue.
Thanks again for taking a look.
Ernie

[Ted Giles]

Don't know whether this is covered or not Earnie, but I've added a "Save Record" when moving away from Browses and more importantly, Memo fields. Its easy to lose the data if you don't.

Don't understand why the field rules requiring data doesn't work though.

Thanks for the info Tom. I bet a few don't know about the field "padding".

[enstorms]

Ted,
I think I had topparent.commit() on the button that moved to next form. I've moved on to adding records to a browse with a form. I thought once you moved off the browse record, it was automatically saved/committed, therefore making my first sentence un-needed. It's still a mystery to me.
Ernie

[Ted Giles]

Have you got it sorted Ernie? I'm back home and developing a software robotics test management suite as fast as my fingers can press the keys!
Give me a shout if you are still struggling.

[enstorms]

Sorry Ted. Just now found your reply. The way I sorted it was to just upgrade the app to ver. 10.5. I feel the browse issues with ver. 9 are just too non-reliable to deal with at this time.
Now I'm having an issue with the 10.5 browse, but is just too sporadic to get anyone to test.
Ernie

[Ted Giles]

Well I'm taking my laptop to work next week, and have V9 and v10 loaded, so gimme a shout if you want to.

[johngtatp]

I have a form based on a set. The top table is a dummy table with a date. There is a one to many browse on the form. There are many fields also on the form from various one to one linked tables as well. If I enter any data in one of the fields from a child record, a record is created in that child table. I tried, as a test, in the child table to use both of the two examples above in the cansaverecord event in the field rules.

Using:
t=this.Table_Get()
if t.resnum<=0 then
this.cancel()
end if

does not stop a record entry if I use a pull down or text box. If I try to edit a field it still does not stop it as I jump from field to field. If I try to close the form, then I get an error:
Property not found
t.resnum subelement not found.

If I try:
dim t as p
t = table.current()
if isblank(t.resnum) then
cancel()
end if

Nothing seems affected in the form based on the set. If I open up just the table itself and attempt to change a record with a blank resnum field I get:

it tells be that isblank (t.resnum) that the argument is the incorrect data type.

I am a bit frustrated here, if anyone has and idea, that would be great.

[Ted Giles]

The Help format suggests that the syntax is
if isblank("t.resnum") then
Is appropriate.
You are testing the content of the Field, not the value.

[Tom Cone Jr]

John,

Is the "resnum" field the "link" field in your child table?

If so, remember that your set based form will autofill that field when you begin data entry into any field of the linked table. So, it won't ever be blank.

-- tom

[johngtatp]

True, the resnum is the link field, however, it does not fill in nor is any other record created except within the table in which the data is entered. After a record is created if I view the individual table, the resnum field is indeed blank. If I try to manipulate the data in that table, not in the set form, I can change anything and nothing happens. If I try to create a record in that table, it will not let me leave the record without canceling it. I cannot save it, but I cannot navigate away from the record either, it is quite strange.

[Tom Cone Jr]

John, it sounds like your script is sending Alpha to lala land. It's time to post a sample of your database here, with instructions for us to follow to see the behavior you're describing. I have to tell you in advance that your form design is the likely culprit. Data entry in Alpha Five is done in tables, not in sets. It's very likely that if you use the default form for your set you won't have the same issues.