>> The change  handler actually has a Target parameter. [...]
>
> That's what I said ...

Well, no, it isn't. :-)

You said "The change event  properly captures the changed cell(Range) in the
variable "Target" then the _Change event fires ..." and this isn't quitre
the same thing.

There is no variable called Target that is used to captuyre this
information. There is a parameter called Target that passes a reference to
the cell  that has been changed.

I updated the information so that the original requester wouldn't go looking
for a global variable called Target.

It is also worth remembering, though, that Target doesn't contain
information captured from the changed cell. It is a reference to the
changed cell itself. This is significant. It means that you can change the
contents of the target cell directly (through the reference) instead of
needing to navigate back to the cell (by asking Target for its location) and
then changing it.

> ... and it is working now (Auto-correcting an entry
> when user  hits enter  or "arrows" out of a cell). Using "Target" did
> the trick.

Good to hear.

> If I read that, it is strange, but my stuff  works ok now.

No, it's probably the way I wrote it. Part of my reply was discussing
whether you should get the "before" contents  or the "after" contents from
the cell. When that becomes a problem is when you want to say "you
shouldn't have changed that and I'm going to change it back". You don't
have access to the original contents of the cell. On a small number of
occasions, the lack of the original value has been a pain for me.

> The original question -- I was trying to use ActiveCell in the _Change
> () event handler sub and I was getting the cell changed TO rather
> than the cell changed FROM (Enter changes cell). I ASSUMED that if
> the _Change() event fires when a value in a cell changes (not all
> that poor an assumption) that the cell just changed would still be
> the ActiveCell when you are *IN* the _Change() sub... but
> Noooooo. Target refers to the cell changed, but ActiveCell is the
> new cell. I guess the cell is changed first *THEN* the value is
> changed in the previous cell... Crummy Microsoft.

There are possibly two separate questions here.

First question is whether the event should fire before the focus changes or
even before the cell changes. In my opinion, yes, as early as possible.
The earlier it's done the more opportunity you have to reject (a) the change
of contents, and (b) the focus change.

(While the actual need for that question was sort-of removed by the Target
parameter, it's still a valid question. Other languages give earlier
"change" events - Excel is a bit lacking in this. Perhaps they can give us
a "BeforeChange" event to go with the other "Before" events.)

Second question is whether you should be given the "before" or the "after"
of the cell. Actually, it would be nice to get both - a copy of the
"before" and a reference to the cell so that the "after" can be adjusted.

Unfortunately, it's easier to simply pass a reference to the changed cell,
so that is what you get. Fortunately, the Target parameter passes the cell
and the cell can tell you almost everything you need to know (except its
"before" contents.