An old problem revisted....

[elziko]

A few month ago I posted a problem I was having. The VB IDE kept on giving me the following error:

Ambiguous name detected: ~

In thread222-91310 we found a workaround (copying the code into a new file) but that only worked temporarily. That part of the project then got shelved.

Its now back off the shelf and I stand to look a bit stupid if I can't get it working!

If anyone has any ideas what might be causing this, no matter how wild, I really need some help here!

desperate,

elziko

 

[dragnut]

sounds like you have named 2 subs/functions/somethings the same. Thats what it always is when I get this error anyway.
hope this helps
Dragnut

 

[MikeCox]

Elziko -

I've read your other thread, and recognized your frustration immediately ;-) . In my limited experience, I've seen Visual Basic do some strange things. I've copied and pasted bad code and it turned good. I've commented out a block of 4 lines of code, and unless in debug mode, VB still executed those 4 lines (proven with a message box).

It sounds to me like you need to uninstall and reinstall VB, that's been my solution more than once. I would also avoid using those old project files. If you need to copy/paste the code, paste it into a .txt file, then into a "clean" instance of VB once reinstalled to avoid corrupting something again.

Hope that does it!

-Mike
Difference between a madman and a genius:
A madman uses his genius destructively,
A genius uses his madness constructively.

 

[elziko]

Thanks. Well I have no alternative but to try this. Although I'm sure it wont work because I've tried the project on every installation of VB on every computer we have here.

Oh, and thanks dragnut but you cant name one sub/func/var with "~" let alone two! Madness I tell you, madness!

elziko

 

[MichaelRed]

This error often occurs when the names in the VB header file are inconsistient. This CAN happen when you 'change' the name of an object in the vb project file in certain ways. the only way I know to overcome it (completely) is to open the object's source code file (ususlly with WordPad) and find the two occurances of the object name in the header file, and 'synchronize' them. Be sure to use the name referenced in hte vb project file, or you will subsquently get the error " ... not found ... ", which -in turn- requires you to delete the 'not found' object and add the one you re-named to something else.

MichaelRed
mred@att.net

There is never time to do it right but there is always time to do it over

 

[elziko]

Thanks for your suggestion! It isn't something I've tried before. Apart from playing about with .frx files I've not done any manual edits. Could you please explain what you mean in a little more depth?? The first question I have is whats a VB header file?

I probably would have more questions ;-) but until I get to look inside the file you speak of I cant see what may be wrong.

Many thanks,

elziko

 

[MichaelRed]

The "header" for any "User Created" object in vb is just the part of the file you cannot see in VB.

ALL User created user objects are just "POT"s ("P"lain "O"ld "T"ext Files). It is just the IDE which hides te messy details from the grubs (e.g. bugs (or programmers) toiling in the dark?). To 'see' this other world, open ant text processor (WORDPAD?). 'Navigate' to where some vb objects exists. Pick one (.frm is perhaps the most verbose header object type). Open it (from WORDPAD / Your fav text editor). At te VERY top you will see something like:

VERSION 5.00
Begin VB.Form frmVehicleList

(Yes, it SAYS ver 5.00 -even though it is a ver 6 Form!)
The second line shows the object name frmVehicleList


Scroll down through the 'header' (sloowly please) and you will find sonething like:

Attribute VB_Name = "frmVehicleList"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False


Not the FIRST attribute VB_Name -AND the Assignmnet- Oh Look - it is (In this instance) the SAME as the Form name assigned in the second line. These are the two header items which -when they do not agree- cause the error noted previouosly.

Since mush (MOST) of my VB work experience has been in De-scrambling the trash generated by 'others', I have become somewhat cavalier in mucking about in this area of the dungeon. however I would generally encourage making a back up of what ever object(s) you want / need to change BEFORE making any change(s), making VERY few changes, saving the object (from your text editor), closing the text editor file, opening VB, CAREFDULLY inspecting the changes, and repeating for additional "SMALL" changes. Being a doufus cavalier, I often just write a new procedure in a seperate VB project (sometimes even Ms. Access) and make changes via code. I do, however, still make back up copies of each object BEFORE maknig changes. And, the changes I make in this manner are usually fairly trivial. If you look at the stttuuuuuffffffff in the 'header' (for a form) it includes mostly properties of control objects - particularly the ones which are different from the default (Backcolor, Font, ...). Retro fitting a project w/ a lot of 'creativity' can be time consuming, so it is somewhat easier to just remove the properties than to 'wrestle' them into the standard/default setting. At least you start w/o the distraction. For Your narrow purpose, I would suggest that you just find the name thinnnggggyyyyysssss and fix them. In some other situation, you may want to look into this further.

P.S. If you know of any VB work available, I would appreciate the opportunity ot offer my services.

MichaelRed
mred@att.net

There is never time to do it right but there is always time to do it over

 

[elziko]

Many thanks for your detailed explanation. Unfortunatly there seems to be no problems in the headers. So, I got a version of my control that did work and went through every change needed to bring it up to date and compiled and tested inbetween each change. This has taken many hours and I'm now on build 190 of this version!!

Anyway here is the problem:

I have many properties for the control. The problem is when I go into Tools|Procedure Attributes. If I try to change any property so that the "Property is data bound" and then check the sub-option: "This property binds to data field" and then compile I get the Ambiguous name detected: ~ which now seems to be a pretty ambigous error message;-)

I would really appreciate your thoughts on my final disection of the problem? I really need to bind this to a field!

Cheers elziko