TabControl is saving a record - I don't want it to

[BoSoxFan]

I inherited this code and don't quite understand how it works, so please bear with me.

I have a main form with a TabControl. The tab control holds about 30 tabs - I guess they're called "pages". On each tab is a subform which holds all the controls.

Here's the problem: I enter partial data on Tab A. I do not press Save (a cmdbutton on subForm A) and I click on Tab B. Access is saving my data (to a SQL Server database). I do not want it to do this - especially since it's only partially filled. I want to pop a msgbox informing the user to press Save or Cancel.

Where do I 'catch' the "lost focus"-type event for this kind of control? I tried the lost_focus event for the subform that sits on the tab(or page, whatever the correct terminology is) but that didn't do it.

Thank you.

 

[willir]

BoSoxFan

So how is the weqther in Boston? Wet no doubt with the hurricane.

Basically, this is a coding style, and a problem with Access's default.

When a form is created using the wizard, it allows the user to enter data, edit data at will. The problem with untrianed users is that when trying to search for a record, they end up changing the first record on a field.

As per style.
Usually, the presence of subforms indicates the presence of a relationship between the main form / main table and the subform / associated table. Your database sound complicated with so many tabs, so permit me to use a simpler model -- invoice header and invoice details.

In order to create the invoice details, to preserver referential integrity, the invoice header record must exist. The invoice number or primary key is then stored on the invoice detail records. This is how the invoice header and detail tables are linked.

Okay..
Now you enter the invoice header record. You jump to the invoice detail record. The invoice number appears on the invoice detail record (assuming the developer displays it on the subform). This is correct process -- most of the time.

First, as soon as you start entering a record, Access prepares the record for insertion -- for example, it generates the next autonumber. The user can still abort update, but the autonumber has been generated.

Switch to the subform. Access grabs the autonumber which it is using to link the tables. The invoice header record has been created. But the user can still abort entering the invoice detail.

Work arounds from this behaviour involve coding. The invoice header is committed with the "save" button per your description. But has the developer prevented the system from updating the record -- perchance not.

A work around may include creating a check box on the header record. It can be unbound. Before the insert record event, check to check box was selected. If so, allow the record to be inserted. If not, abort the update.

The check box would have to be reset for the next entry, perhaps with the "after insert", and the "load" events.

 

[BoSoxFan]

Hi,

Thanks for the info. I've tried, in essence, doing what you recommended, but I don't know how to abort the update since I can't find a Tab Control event to put the code into.

Here's my scenario; I'm writing a Human Resourses application. I've got the Demographic Header which contains Name and SSN. There are 30 tabs, such as Benefits, OSHA incidences, Training, etc.

When I click from the Training tab to the Benefits tab (with partial data entered on Training), I can catch the "exit" in the Form_BeforeUpdate event. Using a boolean (similar to the checkbox you recommended), I put a msgbox in there along with the line "Call Form_Current" if only partial data was entered.

I had hoped that calling Form_Current would keep me on the Training tab, but it's not. The record is being saved and I'm put into the Benefits tab. I don't know how to stop from going to the Benefits tab.

Does this make sense?

Oh, and I actually live in Florida (so it's HOT), but was in Boston last week - it was gorgeous!

 

[KenReay]

HI

The Tab Control as you say consists of 'n' pages. The tabl control itself has a .value property. The .value property determins the page in view, ie the pages are numbered (.PageIndex property) 0 - (n-1), and the value of the tab control equates as I say to the page in view, so if .page(1) is in view, tabcontrol value is 2, set the value to 4 and .page(4) will be in view.

I am not absolutely sure about this, but I think if in the event where you are testing the checkbox, you set the value of the tabcontrol to the page number you are 'on' this will prevent the tab in view from 'moving'

Regards

Ken Reay
Freelance Solutions Developer
Boldon Information Systems Ltd
Website needs upgrading, but for now -

http://www.kenneth.reay.btinternet.co.uk

UK

 

[willir]

BoSoxFan

You would need to do a bit of coding...

For the form control property, for the Before Update, and perhaps for the Before Insert events...

if not me.UpdateCheckBox then
cancel = true
end

Where UpdateCheckBox would be the name of the check box. You could also use other logic such as a popup message window where the user is prompted if they want to update the record.

This will undo the data entry.

Instead of using bound objects, you can also use unbound objects that match your bound objects for the table, and have an "update" button that transfers the unbound values to the bound objects and updates. Again, this requires coding.

This will perserve the data already entered when you leave the form. But you have to make sure the user updates the record.

What I use is a toggle button that switches the form from query/review to edit mode. Since I also use unbound combo boxes for finding records, I have to toggle the locked value at the field level.

Richard