Home > Archive > Visual Basic > April 2006 > Problem compiling ActiveX EXE
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Problem compiling ActiveX EXE
|
|
|
| I don't really know if I'm going about this the right way, so perhaps someone
will help. I want to set up a middleware component which presents the same
copy of the underlying data to all clients. I assume that therefore my
component must be an ActiveX EXE. (Please tell me if that's correct or not!)
My object model contains a number of collection classes, and they all have a
method named 'Item', which is always the default member so that clients can
access individual members of the collections in the usual shorthand way.
When I try to compile the component, I get the error message
Ambiguous name detected: Item
I suppose I could rename the Item methods so that they are all named
uniquely - but surely I shouldn't have to do that? I can imagine it will
give me the same error when it finds the 'Add', 'Remove' and 'Count' methods,
and I wouldn't expect to have to name them uniquely either.
What am I doing wrong?
| |
| Ken Halter 2006-04-26, 6:56 pm |
| "Andy" <andrewjellis@hotmailnospam.com> wrote in message
news:017FA06F-2F01-4882-97BF-31AFBFDB5A13@microsoft.com...
>I don't really know if I'm going about this the right way, so perhaps
>someone
> will help. I want to set up a middleware component which presents the
> same
> copy of the underlying data to all clients. I assume that therefore my
> component must be an ActiveX EXE. (Please tell me if that's correct or
> not!)
>
> My object model contains a number of collection classes, and they all have
> a
> method named 'Item', which is always the default member so that clients
> can
> access individual members of the collections in the usual shorthand way.
>
> When I try to compile the component, I get the error message
> Ambiguous name detected: Item
>
> I suppose I could rename the Item methods so that they are all named
> uniquely - but surely I shouldn't have to do that? I can imagine it will
> give me the same error when it finds the 'Add', 'Remove' and 'Count'
> methods,
> and I wouldn't expect to have to name them uniquely either.
>
> What am I doing wrong?
Can you post the declaration for your Item method (property)? Did you set
the procedure attributes correctly?
For Each with collection class
http://groups.google.com.my/group/m...dbb78093b43335/
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
| |
|
| Ken,
Here's one of the collections in full...
Option Explicit
Private mCol As Collection
Public Sub Add(ByVal NewCompany As Company)
mCol.Add NewCompany, "K" & CStr(NewCompany.ID)
End Sub
Public Property Get Item(vntIndexKey As Variant) As Company
Set Item = mCol(vntIndexKey)
End Property
Public Property Get Count() As Long
Count = mCol.Count
End Property
Public Sub Remove(ByVal OldCompany As Company)
mCol.Remove "K" & CStr(OldCompany.ID)
End Sub
Public Property Get NewEnum() As IUnknown
Set NewEnum = mCol.[_NewEnum]
End Property
Private Sub Class_Initialize()
Set mCol = New Collection
End Sub
Private Sub Class_Terminate()
Set mCol = Nothing
End Sub
As a matter of course, I always set the Procedure Attributes for collections
as follows:
Item : Set Procedure ID to (Default)
New_Enum : Set Procedure ID to -4, check 'Hide this member'.
(The member object for this collection, i.e. 'Company', has a number of
public properties, including ID, which is a long integer and matches the
Identity field in the database table from which the collection was built. I
precede this with "K" when adding the object to mCol so that the key is
always alphanumeric, and so that I can subsequently go straight to any member
when I know the ID.)
"Ken Halter" wrote:
> "Andy" <andrewjellis@hotmailnospam.com> wrote in message
> news:017FA06F-2F01-4882-97BF-31AFBFDB5A13@microsoft.com...
>
> Can you post the declaration for your Item method (property)? Did you set
> the procedure attributes correctly?
>
> For Each with collection class
> http://groups.google.com.my/group/m...dbb78093b43335/
>
> --
> Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
> DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
>
>
>
| |
| Ken Halter 2006-04-26, 6:56 pm |
| "Andy" <andrewjellis@hotmailnospam.com> wrote in message
news:7CCD1F27-5422-439A-9D5E-B0116F6FFD9C@microsoft.com...
> Ken,
>
> Here's one of the collections in full...
>
Well... all I can say is... "works fine here" <g>. I pasted your code
exactly as shown, added a class called 'Company' with a property called ID
and it compiled fine (didn't actually try to use it). Have you ever been
able to build this project? The next time you try, wait for VB to stop on
that error (which isn't an error but something's up) and change the name of
that single Item to anything else and see if VB accepts the change. There
may be some strange hidden attribute somewhere causing the greif.... which
you can get rid of by opening the class in Notepad and looking for the
attributes. Once you mess with them, you'll have to double-check your
procedure attribute settings again... just in case.
You can also try dragging a copy of a couple of those classes to a new Std
EXE, DLL or UserControl project and see if you still get complaints.
What you're trying to do shouldn't be giving you the problems you're having.
Your code looks very close to the code the Class Builder utility generates.
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
| |
|
| Ken
> Well... all I can say is... "works fine here" <g>. I pasted your code
> exactly as shown, added a class called 'Company' with a property called ID
> and it compiled fine (didn't actually try to use it). Have you ever been
> able to build this project?
Actually, no - the project was until recently stand-alone, and I've just
gone through the lengthy process of splitting out the object classes into a
middleware project, and creating new classes in a data services layer project
(ActiveX DLL) to do all the database work. Previously it was a Standard EXE.
> The next time you try, wait for VB to stop on
> that error (which isn't an error but something's up) and change the name of
> that single Item to anything else and see if VB accepts the change.
One problem I have here, is VB doesn't actually highlight one of the Item
methods when it gives me the error message. So I don't know which one causes
the problem (if there's only one).
> There
> may be some strange hidden attribute somewhere causing the greif.... which
> you can get rid of by opening the class in Notepad and looking for the
> attributes. Once you mess with them, you'll have to double-check your
> procedure attribute settings again... just in case.
I'll try that.
> You can also try dragging a copy of a couple of those classes to a new Std
> EXE, DLL or UserControl project and see if you still get complaints.
>
> What you're trying to do shouldn't be giving you the problems you're having.
> Your code looks very close to the code the Class Builder utility generates.
OK - thanks for your help.
Andy
| |
|
| Ken
I found the cause of the problem - and it was rather obscure. In one of my
collection classes, I had New_Enum set to be the Default member *in addition*
to item being the Default member. I'm surprised VB allowed me to set the
second as Default when one was already marked as such. Anyhow, fixing that
has allowed the project to compile.
Andy
| |
| Ken Halter 2006-04-26, 6:56 pm |
| "Andy" <andrewjellis@hotmailnospam.com> wrote in message
news:2C124F04-99E7-44B4-BB29-0648A604D973@microsoft.com...
> Ken
>
> I found the cause of the problem - and it was rather obscure. In one of
> my
> collection classes, I had New_Enum set to be the Default member *in
> addition*
> to item being the Default member. I'm surprised VB allowed me to set the
> second as Default when one was already marked as such. Anyhow, fixing
> that
> has allowed the project to compile.
>
> Andy
Yeah... too bad the procedure attributes dialog doesn't replace the
properties window when you're looking at code. It is a pain to cycle through
procedures one at a time with that little dialog.
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
| |
|
|
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:%23ac2XcVaGHA.1192@TK2MSFTNGP03.phx.gbl...
> "Andy" <andrewjellis@hotmailnospam.com> wrote in message
> news:2C124F04-99E7-44B4-BB29-0648A604D973@microsoft.com...
the[color=darkred]
>
> Yeah... too bad the procedure attributes dialog doesn't replace the
> properties window when you're looking at code. It is a pain to cycle
through
> procedures one at a time with that little dialog.
>
There is a reason Bruce McKinney called it the "Dialog From Hell".
That phrase has always stuck with me and it is a good thing to remember
everytime you have to mess with it. <g>
-ralph
|
|
|
|
|