I HATE ME.DIRTY

[rebelscum0000]

.....Because I do not understad it
I want to move my code to a module but I get a syntax error due the
Me.Dirty
Me.Dirty what? Invalid use of Me keyword

Forms![MainExclude_Form], Dirty or
Forms![MainExclude_Form]![Keyword].Dirty?

In addition, I set to If Me.Dirty Then Me.Dirty = True and too many
times is that correct?

This is in order to avoid Writing Conflicts

This is my code;

Private Sub Form_Open(Cancel As Integer)

Dim MyKeywordDeSe
Dim SQL1, SQL2 As String 'Select Query
Table
Dim Msg, Style, Title, Response, MySelection

On Error GoTo ErrorHandling

'Initialize Variables
MyKeywordDeSe = Forms![MainExclude_Form]![Keyword]
msg1 = "[ " & MyKeywordDeSe & "]" & " is your Default Search, Would you
Like to Change it?"
Style1 = vbYesNo + vbInformation 'Define buttons
Title1 = "Changing the Default Search" 'Define title.

If IsNull(MyKeywordDeSe) Then
Exit Sub
Else
Response = MsgBox(msg1, Style1, Title1)
If Response = 6 Then 'User chose Yes.
MySelection = "Yes" 'Perform some action.

This SQL Statement RESET Or DELETE All the Records from the field
MyKeyword OF THE 'Tbl MainExclude_Tbl

MsgBox "Reset your Default Key", vbOKOnly + vbInformation, "Deleting
Default Seach"

SQL1 = _
"UPDATE MainExclude_Tbl SET MainExclude_Tbl.MyKeyword = Null;"

If Me.Dirty Then Me.Dirty = False

CurrentDb.Execute SQL1, dbFailOnError

If Me.Dirty Then Me.Dirty = True

'This SQL Statement RESET Or DELETE All the Records from the field
MyAppz OF THE 'Tbl MainExclude_Tbl
SQL2 = _
"UPDATE MainExclude_Tbl SET MainExclude_Tbl.MyAppz = Null;"

If Me.Dirty Then Me.Dirty = False

CurrentDb.Execute SQL2, dbFailOnError

ElseIf Response = 7 Then 'User chose No.
MySelection = "No" 'Perform some action.
MsgBox "No Changes in your Default Search", vbOKOnly + vbInformation,
"Sa" & _
"ving Default Search"
Exit Sub
End If
End If
Exit Sub
ErrorHandling:
MsgBox "Numero Error: " & Err & " Descripcion " & Err.Description
End Sub

 

[Lynn Trapp]

ME is a reference to the currently active form. Your module will not know
about that. Yu will need to use Forms!YourFormName.Dirty instead.

 

[Jerry Whittle]

You have three "If Me.Dirty Then Me.Dirty = " statements in your code with no
End IFs after them.

 

[Dirk Goldgar]

You have three "If Me.Dirty Then Me.Dirty = " statements in your code
with no End IFs after them.

No End If statement is required for a one-line If ... Then statement.

 

[Jerry Whittle]

That fills my "learn something new every day" requirement.

Thanks!

 

[Douglas J. Steele]

There should be no need to worry about Me.Dirty in a form's Open event: that
code runs before you've had a chance to change any of the data on the form.

Yes, you're making updates to tables, but that doesn't mean that the form is
dirty.

You really should type your variables more strongly.

Of all the variables you've declared, only one of this is typed (although I
suspect you probably think two of them are).

Dim SQL1, SQL2 As String

declares only declares SQL2 to be a string: SQL1 is a variant, since you
haven't set a type for it. You need:

Dim SQL1 As String, SQL2 As String

for both to be strings.

 

[David W. Fenton]

You have three "If Me.Dirty Then Me.Dirty = " statements in your
code with no End IFs after them.

Er, so what? There are two forms of If/Then statement:

If .. Then ..

and

If .. Then ..
..
End If

It's perfectly allowable to have a single-line If/Then statement,
though many people caution against using that format on some vague
stylistic ground that has never been particularly clear to me.

But it certainly does work.

 

[Tony Toews]

No End If statement is required for a one-line If ... Then statement.

And just to confuse things I prefer the following syntax to make it
somewhat clearer. Although that may only be in my own mind. <smile>

If me.dirty then _
me.dirty = false

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Dirk Goldgar]

And just to confuse things I prefer the following syntax to make it
somewhat clearer. Although that may only be in my own mind. <smile>

If me.dirty then _
me.dirty = false

It is ... in your own mind. <g>

 

[David W. Fenton]

And just to confuse things I prefer the following syntax to make
it somewhat clearer. Although that may only be in my own mind.
<smile>

If me.dirty then _
me.dirty = false

I don't use line continuation characters at all because of the
history of corruption with them.

 

[Dirk Goldgar]

I don't use line continuation characters at all because of the
history of corruption with them.

That's a new one to me. What history? I've never experienced any
corruption that seemed related to line continuations.

 

[David W. Fenton]

That's a new one to me. What history? I've never experienced any
corruption that seemed related to line continuations.

I don't recall the specifics or if it has been fixed or not, but
there was a bug where line continuations would corrupt your VBA
project, and you'd end up losing it. I don't like them, anyway.

It would be nice if the VBE offered a wrap-to-window view, the way
HTML editors like HomeSite do. That would basically make line
continuation characters completely obsolete, except as a formatting
tool (like indentation).