Problem With Unbound Forms!

[geko]

- I'm going to have to disagree with that. It is simply hubris to believe that writing potentially hundreds of lines of custom code for each unbound form is somehow better than (or even equivalent to) relying on the well known and tested, bound form solution. There is enough code to be written and tested to handle validation and formatting. There is simply no justifiable reason to duplicate the "hidden" code that Access uses to populate a bound form, navigate a recordset, and control when records should be saved. In fact, I would consider it fiscally irresponsible if you worked for me. I would not want my programmers wasting company time and money writing and testing unnecessary code.

I wouldn't be writing custom code for each form, I would be reusing the same code (cut & paste style) as often as possible, hence the reason I changed the code in my initial post, to that in my latter post!

Ok, some forms are going to require custom code, but the basics will remain the same from form to form.

I know and accept that I have much to learn, and nor do I pretend to know everything (not just about Access), but if later I learn that bound forms are the way to go in the future, then I will go with bound forms.

However, with my knowledge at present (all self-taught from books, and forums such as this etc) unbound seems easier even if more coding is required.

Perhaps you could write some tutorials to inform us as to how to use bound forms properly?

 

[Mile-O]

I would be reusing the same code (cut & paste style)

You are mad.

if later I learn that bound forms are the way to go in the future, then I will go with bound forms.

The books you mention you are self taught from - are they for Access or Visual Basic? If they are the former then I find it impossible to believe they suggest using unbound forms and writing your code* and if the latter then I can understand since Visual Basic is not Access and you have to write the code for your forms.

Perhaps you could write some tutorials to inform us as to how to use bound forms properly?

What is it that you don't understand about using a bound form?

 

[geko]

The books I use are the Sybex Access books.

I'm not syaing that they suggest using unbound forms, becasue to be honest I find it hard to study by reading, and most of my learning has come from doing.

In terms of what it is I don't understand, well in this case it would be preventing updates to data if accidently changed. i.e Me.Dirty = true, but would like to confirm with the user that they meant to make the changes, before they are saved to the table. This is just one example off the top of my head.

I did actually code a bound form using an edit button (and a nice little box that was red when editing was not allowed, and green when editing was allowed), but I found that the ppl that were using the form prefered to not have it there, as it was something else to remember.

When I make a system I try to make it is as easy as possible to use, even if that means more work for me!

I guess this is because I have used some horrible systems in my (brief) time in employment.

Or maybe as you stated I am just "mad" and like to make things harder for myself unnecessarily...

 

[Mile-O]

The books I use are the Sybex Access books.

I prefer Wroz although if I could find where I put it, my Access Developers Handbook would be my Bible.

In terms of what it is I don't understand, well in this case it would be preventing updates to data if accidently changed. i.e Me.Dirty = true, but would like to confirm with the user that they meant to make the changes, before they are saved to the table.

This is easily done in a bound form. You just use the BeforeUpdate() event of the form.

i.e.

Private Sub Form_BeforeUpdate(Cancel As Integer)
    If MsgBox("Do you want to save the changes to this record?", vbQuestion + vbYesNo, "Save Changes?") = vbNo Then
        Me.Undo
    End If
End Sub

When I make a system I try to make it is as easy as possible to use, even if that means more work for me!

Indeed.

 

[geko]

So the Before Update event happens after the user has typed in changes, but before the changes are sent to the table?

 

[Mile-O]

So the Before Update event happens after the user has typed in changes, but before the changes are sent to the table?

With respect to a form, the BeforeUpdate event is triggered before the data is changed in the table which gives you a chance to prevent saving. The BeforeUpdate event of a control allows you to check that the value being entered is legal. The BeforeUpdate event only triggers if a form is Dirty.

In the example I gave above that works for a form which is being closed and gives you the option to save changes or not. If you replace the line Me.Undo with Cancel = True then it makes use of the Cancel argument and stops the form closing completely until the person says 'Yes'.

You are probably coding all these features for your form that are already possibly but you just don't know what the events are for. Take the time to learn these and in which order the are triggered and what actually triggers them. You'll be using bound forms in no time.

 

[geko]

Well I'm trying to teach myself ColdFusion at the moment, but I will endeavour to learn the events of a form at some point.

Thanks for your help, and apologies if we started to head towards argument territory.

 

[zim_ulator]

Pat,

One main reason I use unbound forms by preference, is to inhibit users accidentally moving to a different record (and subsequently editing the wrong one)...

Cheers
John.

John,

Thanks for that question: I'd like to know as well with regard to Access 2000. I think I'm using bound forms if I understand what a bound form is.

I elected to adapt some code I found for the record count and to move the record pointer,a s well as adding and editing buttons. Letting a user have the "add new" button seems very dangerous to me.

Denis

 

[Pat Hartman]

zim_ulator,
I don't see a question in your post or in the quote. Allowing users to add records is not dangerous at all. Who else would add them? You?

It took some doing,

- that's because you had to write it yourself. It would have been a lot less coding and testing if you had used bound forms.

 

[zim_ulator]

zim_ulator,
I don't see a question in your post or in the quote. Allowing users to add records is not dangerous at all. Who else would add them? You?

I guess I wasn't clear. Must have been pretty tired, I confused myself with the last post.
note to self: stop smoking those turnip greens


I was referring to the built in button with the >* symbols on it.

zim apologises for wasting bandwidth,
and spontaneously combusts

 

[pvs]

Pat,

One main reason I use unbound forms by preference, is to inhibit users accidentally moving to a different record (and subsequently editing the wrong one) by using the page up/down keys, or scroll-point type mouse functionality.

Are you able to advise on how to circumvent such a disaster without resorting to unbound forms ?

(Using AC97 / WIN2K & WINNT)

Cheers

John.

Well, I'm not Pat, and yes, I DO realize this thread is ages-old. But I didn't want to leave it hanginglike this, so ...

use a Bound Form, but filter the underlying recordset for only the one record you wish to have the user edit. Thus, no PgUp/PgDn/Mouse Scroll functionality, since there are no other records to go to.

Easy as that

HTH Somebody....
-pvs