I encountered a problem in 2007 which I believe is a bug. Just wondering if
this is a known issue or not. When we programatically delete a row using
rows(X).entirerow.delete we noticed that in 2007, that a named range that was
a row beneath the deleted row did not shift up. In 2003 and with insert in
both editions and going through the Excel UI, named ranges shifted when rows
were inserted/deleted, just programatically deleting rows/columns did not
shift the named ranges. Am I missing something or is this a bug?

--
*********************
J Streger
MS Office Master 2000 ed.
MS Project White Belt 2003

User of MS Office 2003

I assigned a name to cell A10 and ran this code:

Rows(5).Delete

After that the name referred to A9. Looks okay here.

--
Jim
"J Streger" wrote in message
...
|I encountered a problem in 2007 which I believe is a bug. Just wondering if
| this is a known issue or not. When we programatically delete a row using
| rows(X).entirerow.delete we noticed that in 2007, that a named range that
was
| a row beneath the deleted row did not shift up. In 2003 and with insert in
| both editions and going through the Excel UI, named ranges shifted when
rows
| were inserted/deleted, just programatically deleting rows/columns did not
| shift the named ranges. Am I missing something or is this a bug?
|
| --
| *********************
| J Streger
| MS Office Master 2000 ed.
| MS Project White Belt 2003
|
| User of MS Office 2003
|

A single cell works fine. It's when you have a named range that defines an
entire row where it doesn't shift up. Can you test to see if an entire row
set as a named range shifts up when you programatically delete a row above it?

--
*********************
J Streger
MS Office Master 2000 ed.
MS Project White Belt 2003

User of MS Office 2003



"Jim Rech" wrote:

I assigned a name to cell A10 and ran this code:

Rows(5).Delete

After that the name referred to A9. Looks okay here.

--
Jim
"J Streger" wrote in message
...
|I encountered a problem in 2007 which I believe is a bug. Just wondering if
| this is a known issue or not. When we programatically delete a row using
| rows(X).entirerow.delete we noticed that in 2007, that a named range that
was
| a row beneath the deleted row did not shift up. In 2003 and with insert in
| both editions and going through the Excel UI, named ranges shifted when
rows
| were inserted/deleted, just programatically deleting rows/columns did not
| shift the named ranges. Am I missing something or is this a bug?
|
| --
| *********************
| J Streger
| MS Office Master 2000 ed.
| MS Project White Belt 2003
|
| User of MS Office 2003
|

Can you test to see if an entire row set as a named range shifts up when
you programatically delete a row above it?

It works perfectly. Can you reproduce the problem when you start with a new
workbook? Oftentimes there is something funny in an existing workbook that
causes problems that do not occur elsewhere. If a new, simple example does
repro the problem I'd like to look at it if you care to send it.

--
Jim
"J Streger" wrote in message
...
|A single cell works fine. It's when you have a named range that defines an
| entire row where it doesn't shift up. Can you test to see if an entire row
| set as a named range shifts up when you programatically delete a row above
it?
|
| --
| *********************
| J Streger
| MS Office Master 2000 ed.
| MS Project White Belt 2003
|
| User of MS Office 2003
| |