canceling a enter new record on an embedded browse

[Alan Lee]

Greetings all.

I am confussed and frustrated trying to figure out how to cancel the entering of a new record on an embedded browse.

The form the browse is on is modal. When I enter a new record, as long as I am in the first 2 fields (dates) I can cancel or press esc and the record I am entering goes away. If I go to the 3rd field, which is a look up, when I cancel it enters the record with blank fields. But it behaves differently depending on how you cancel.

Case 1: I have a button called Cancel, on push, Cancel Changes on current form at browse level. Same behavior as above.

Case 2: Click cancel changes on toolbar first time, current record goes away and moves me to record above in change mode. Click cancel changes second time, exits change mode.

Case 3:Cancel changes is the same as pressing (esc). Enter past first 2 date fields which default to today, 3rd field press esc before selecting from lookup; field is blank, down arrow still present to choose lookup for field, press esc 2nd time current record goes away, move to record above in the same field with down arrow still present, record still in change. Press esc 3rd time record is now out of change.

Case 4: Cancel changes is the same as pressing (esc). Enter past first 2 date fields which default to today, 3rd field select something from lookup table press esc 1st time and dialog box pops up "are you sure you want to lose changes" click yes, current record goes away, moves to the record above in change mode, press esc again and exit change.

Case 5: Change action script for cancel button. action 1 give focus to first date field in browse1, action 2 send {esc} same behavior as case 1.

I hope I have made it clear what I am trying to do. I can post my app if needed. How do you cancel entering a record in an embedded browse and why does it behave so differently between using the toolbar, the keyboard, and an action script?


Alan

[Tom Cone Jr]

RE: canceling a enter new record on an embedded br

Alan,

Data entry through an embedded browse is difficult to control. The events that are available to us when working with a form and its field objects, are not exposed when working with columns in browses. The browse object is slated for major work, but ...

If the behavior you're seeing is unacceptable I suggest you use a separate form to enter / edit records in your child table. This could be called from the current form easily. In fact, this is my preferred modus operandi. I make my embedded browses read only, use them for navigation, and then use a button push to begin a new child record in a called form. Edit to existing records can use the same called form, and can be called from the OnRowDbleClick event.

-- tom

[martinwcole]

RE: canceling a enter new record on an embedded br

Tom's method is preferable, but I sometimes run into situations where i can't do that.

a way around it is to go to fields rule, and decide what constitues a blank record (preferably 2 character fields)

in record events, in field rules, in cansaverecord put
if .not. a_deleting_record
t=table.current()
if t.name="" .and. t.address=""
cancel()
end
end if
end if

this will prevent the "blank" record from being saved.

[Alan Lee]

RE: canceling a enter new record on an embedded br

Thanks for the input Gentlemen.

I decided to use a Xdialog to accomplish what I wanted. have not finished it yet, but I have made major headway.

Thanks Again,

Alan

[czar_g]

Tom's method is preferable, but I sometimes run into situations where i can't do that.
a way around it is to go to fields rule, and decide what constitues a blank record (preferably 2 character fields)

in record events, in field rules, in cansaverecord put
if .not. a_deleting_record
t=table.current()
if t.name="" .and. t.address=""
cancel()
end
end if
end if

this will prevent the "blank" record from being saved.

Excuse me - does this method have to be applied to WHAT field?
or does it not matter? Is it wothin the forms 'cansavearecord'

Getting a quick dose of this thing you all call events...

Thanx
George

[Tim Kiebert]

The field rules record events operate at the record level so it doesn't matter which field is active in the field rule editor at the time of setting it up.

[Stan Mathews]

Further.....

The field rules record events operate at the record level so it doesn't matter which field is active in the field rule editor at the time of setting it up.

Since it isn't always clear to new users the proper application of events, the CanSaveRecord, not cansavearecord, is edited/coded by hilighting a table in the control panel, right clicking, choosing Edit Field Rules, choosing the Event tab, choosing Record Events radio button, selecting CanSaveRecord in the Event: box, and entering the code desired.

[czar_g]

Thank you -

This code has been entered into my inv_tab table:

if .not. a_deleting_record
t=table.current()
if t.invoice_number="" .or. t.ticketno=""
cancel()
end
end if
end if

invoice_number and ticketno being fields within.

Strange though.. one of my codes 20 / form I have, so the user can enter only records with a code of 20 - works great.

Now switch to a different form code 21 / form. You can enter the code 2160 (say) and then it will not go any further when you hit enter. I've compared the forms and the embedded browse within that holds the records and they appear to be the same... I know this is a bit sketchy - but lemme ask is there something else I should be checking?

Thanx
Grge

[Stan Mathews]

Documentation

Check the webhelp index for

Form
Restrictions

and see the description of "Continuous Enters"

[czar_g]

Overwhelmed -
as he tilts his head sideways and mutters - HUH?

What I did do is create a routine that runs on OnExit which queries the table for blank records and deletes them - read about having it perform silently in another post.. works good so far..

Are there any draw backs to this simple solution?

George

[CALocklin]

What I did do is create a routine that runs on OnExit which queries the table for blank records and deletes them - read about having it perform silently in another post.. works good so far..

Are there any draw backs to this simple solution?

I would be concerned about deleting the last record. In my experience, deleting the last record in a table can sometimes create problems when scrolling through a browse of the data.

I think you would be better off with a routine like Martin described. This avoids saving the blank record in the first place. If the blank record is never created, there's no need to delete it.

I've compared the forms and the embedded browse within that holds the records and they appear to be the same

I'd have to believe there is something in your logic somewhere that is causing this problem. It could be in the form or in the field rules. Test it on the default form - if it stops happening, it's something in the form. Otherwise, check your field rules.

Also, make sure you compact your database periodically. If you've done a lot of development without compacting the database, all kinds of strange things can sometimes happen.

[czar_g]

Check the webhelp index for
Form
Restrictions
and see the description of "Continuous Enters"

Stan were you talking about the "setting form restrictions?"
I WANT the user to enter items in the browse table.. BUT I do not want them to change their mind click,esc out and a blank record gets saved anyway -

I did look at the field rules Tim - and forms but I honestly cannot see any difference between any of them. Just the code field that appears for the customer. Default form? sure it works BUT it also works on one of my Forms I created... The other forms work BUT as soon as you enter into the browse and put a CODE in the field you can't hit enter,tab,arrow to get out of the field.

I'm gonna have their boss just give 'em a pencil and paper.. maybe a calculator. ;) One of the folks opted to go back to the old DOS version of Alpha - she was one of the old timers - "took longer, but at least it worked" she said - She doesn't remeber why they switched - support and strange things happening on their PC's etc...

Thanx
George