Here is how to reproduce the problem:
1. Create a C# COM server
- Create a new DLL, with register for COM interlop
- Add the code (available below).
2. Test
- In Excel-Tools-AddIn-Automation, choose TestServerCom.TestServerCom
- In cell B1, type =Hello("niels").
- the value of B1 will be: "Hello niels!";
3. Test the crash
- Select A1
- Define the name of the cell A1 this way: on the left of the formula
bar, there is a white box where A1 is written. Change it to Hello.
- Excel crashs.

Notes:
Different behaviours:
- If the user changes the name the following way, it does not crash:
Insert-Name-Define- Hello
- With C++ XLL, it productes #ref, but do not crash
- With 'standard' functions (SIN, MAX, ...), it works. If you define A1 to
SIN as stated in point 3, then =SIN(3) refers to the formula, =SIN*3 refers
to the cell.

Config:
- C#2, Visual 2005 patched with 908002
- Excel 2002 English SP3, under Windows XP

I would like you to confirm that it is a bug, and to know if a patch exists.

I google, but could not find anything (too many results with "excel",
"name", "COM", ...).

Here is the code to build a simple COM server:

using System;
using System.Runtime.InteropServices;
namespace TestServerCom{
[ClassInterface(ClassInterfaceType.AutoDual)]
[ComVisible(true)]
public partial class TestServerCom {
public string Hello(string your_name)
{ return "Hello, " + your_name + "!";}

[ComRegisterFunctionAttribute]
public static void RegisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.CreateSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}
[ComUnregisterFunctionAttribute]
public static void UnregisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.DeleteSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}}}

Thanks

Niels,
A quick test with a VB6 COM add-in also crashes Excel. Upon recovery I get a
MsgBox saying "Type Mismatch", so it seems the function is called instead of
the named range referenced.
No solution yet, but seems it's excel rather than the nature of C++/Interop.
This was only a very basic DLL and I do not know enough about COM addins to
say if any extra coding is required.

NickHK

"Niels Van Vliet" wrote in message
...
Here is how to reproduce the problem:
1. Create a C# COM server
- Create a new DLL, with register for COM interlop
- Add the code (available below).
2. Test
- In Excel-Tools-AddIn-Automation, choose
TestServerCom.TestServerCom
- In cell B1, type =Hello("niels").
- the value of B1 will be: "Hello niels!";
3. Test the crash
- Select A1
- Define the name of the cell A1 this way: on the left of the formula
bar, there is a white box where A1 is written. Change it to Hello.
- Excel crashs.

Notes:
Different behaviours:
- If the user changes the name the following way, it does not crash:
Insert-Name-Define- Hello
- With C++ XLL, it productes #ref, but do not crash
- With 'standard' functions (SIN, MAX, ...), it works. If you define A1 to
SIN as stated in point 3, then =SIN(3) refers to the formula, =SIN*3
refers
to the cell.

Config:
- C#2, Visual 2005 patched with 908002
- Excel 2002 English SP3, under Windows XP

I would like you to confirm that it is a bug, and to know if a patch
exists.

I google, but could not find anything (too many results with "excel",
"name", "COM", ...).

Here is the code to build a simple COM server:

using System;
using System.Runtime.InteropServices;
namespace TestServerCom{
[ClassInterface(ClassInterfaceType.AutoDual)]
[ComVisible(true)]
public partial class TestServerCom {
public string Hello(string your_name)
{ return "Hello, " + your_name + "!";}

[ComRegisterFunctionAttribute]
public static void RegisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.CreateSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}
[ComUnregisterFunctionAttribute]
public static void UnregisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.DeleteSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}}}

Thanks

Nick & Neils,

That doesn't sound good!
I can't test as my xl2k doesn't support automation functions.

It might indicate where the trouble lies if crash also occurs if the
function contains no arguments at all or only optional arguments.

The box left of the input bar is a dual purpose "Goto" and if nothing found
define a range name. Goto includes procedure names in any module in any open
workbook, perhaps this aspect is linked.

If there's no way to catch the problem in the function one solution might be
something like this -

When the Com connects load an xla containing dummy routines with same names
as the functions in the com, eg

Sub Hello()
' don't attempt to define a name called "Hello" in the Goto box
' as this will conflict with a similarly named function in the Com
End Sub

Regards,
Peter T


"NickHK" wrote in message
...
Niels,
A quick test with a VB6 COM add-in also crashes Excel. Upon recovery I get
a
MsgBox saying "Type Mismatch", so it seems the function is called instead
of
the named range referenced.
No solution yet, but seems it's excel rather than the nature of
C++/Interop.
This was only a very basic DLL and I do not know enough about COM addins
to
say if any extra coding is required.

NickHK

"Niels Van Vliet" wrote in
message
...
Here is how to reproduce the problem:
1. Create a C# COM server
- Create a new DLL, with register for COM interlop
- Add the code (available below).
2. Test
- In Excel-Tools-AddIn-Automation, choose
TestServerCom.TestServerCom
- In cell B1, type =Hello("niels").
- the value of B1 will be: "Hello niels!";
3. Test the crash
- Select A1
- Define the name of the cell A1 this way: on the left of the formula
bar, there is a white box where A1 is written. Change it to Hello.
- Excel crashs.

Notes:
Different behaviours:
- If the user changes the name the following way, it does not crash:
Insert-Name-Define- Hello
- With C++ XLL, it productes #ref, but do not crash
- With 'standard' functions (SIN, MAX, ...), it works. If you define A1
to
SIN as stated in point 3, then =SIN(3) refers to the formula, =SIN*3
refers
to the cell.

Config:
- C#2, Visual 2005 patched with 908002
- Excel 2002 English SP3, under Windows XP

I would like you to confirm that it is a bug, and to know if a patch
exists.

I google, but could not find anything (too many results with "excel",
"name", "COM", ...).

Here is the code to build a simple COM server:

using System;
using System.Runtime.InteropServices;
namespace TestServerCom{
[ClassInterface(ClassInterfaceType.AutoDual)]
[ComVisible(true)]
public partial class TestServerCom {
public string Hello(string your_name)
{ return "Hello, " + your_name + "!";}

[ComRegisterFunctionAttribute]
public static void RegisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.CreateSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}
[ComUnregisterFunctionAttribute]
public static void UnregisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.DeleteSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}}}

Thanks

Peter,
I tried function signatures of no arguments and optional only, but still the
same.
Whilst I'm used to write VB6 DLLs, I don't have much experience of writing
Excel COM add-ins. As such I can say if any extra coding is required to
cover this point.
However, standard VB coding/error handling does not seem to prevent this.

NickHK

"Peter T" <peter_t@discussions wrote in message
...
Nick & Neils,

That doesn't sound good!
I can't test as my xl2k doesn't support automation functions.

It might indicate where the trouble lies if crash also occurs if the
function contains no arguments at all or only optional arguments.

The box left of the input bar is a dual purpose "Goto" and if nothing
found
define a range name. Goto includes procedure names in any module in any
open
workbook, perhaps this aspect is linked.

If there's no way to catch the problem in the function one solution might
be
something like this -

When the Com connects load an xla containing dummy routines with same
names
as the functions in the com, eg

Sub Hello()
' don't attempt to define a name called "Hello" in the Goto box
' as this will conflict with a similarly named function in the Com
End Sub

Regards,
Peter T


"NickHK" wrote in message
...
Niels,
A quick test with a VB6 COM add-in also crashes Excel. Upon recovery I
get
a
MsgBox saying "Type Mismatch", so it seems the function is called
instead
of
the named range referenced.
No solution yet, but seems it's excel rather than the nature of
C++/Interop.
This was only a very basic DLL and I do not know enough about COM addins
to
say if any extra coding is required.

NickHK

"Niels Van Vliet" wrote in
message
...
Here is how to reproduce the problem:
1. Create a C# COM server
- Create a new DLL, with register for COM interlop
- Add the code (available below).
2. Test
- In Excel-Tools-AddIn-Automation, choose
TestServerCom.TestServerCom
- In cell B1, type =Hello("niels").
- the value of B1 will be: "Hello niels!";
3. Test the crash
- Select A1
- Define the name of the cell A1 this way: on the left of the
formula
bar, there is a white box where A1 is written. Change it to Hello.
- Excel crashs.

Notes:
Different behaviours:
- If the user changes the name the following way, it does not crash:
Insert-Name-Define- Hello
- With C++ XLL, it productes #ref, but do not crash
- With 'standard' functions (SIN, MAX, ...), it works. If you define
A1
to
SIN as stated in point 3, then =SIN(3) refers to the formula, =SIN*3
refers
to the cell.

Config:
- C#2, Visual 2005 patched with 908002
- Excel 2002 English SP3, under Windows XP

I would like you to confirm that it is a bug, and to know if a patch
exists.

I google, but could not find anything (too many results with "excel",
"name", "COM", ...).

Here is the code to build a simple COM server:

using System;
using System.Runtime.InteropServices;
namespace TestServerCom{
[ClassInterface(ClassInterfaceType.AutoDual)]
[ComVisible(true)]
public partial class TestServerCom {
public string Hello(string your_name)
{ return "Hello, " + your_name + "!";}

[ComRegisterFunctionAttribute]
public static void RegisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.CreateSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}
[ComUnregisterFunctionAttribute]
public static void UnregisterFunction(Type t)
{
Microsoft.Win32.Registry.ClassesRoot.DeleteSubKey(
"CLSID\\{" + t.GUID.ToString().ToUpper() +
"}\\Programmable");
}}}

Thanks