CodeProject vs CurrentProject

[FancyPrairie]

I'm using Access 2010. I have 2 databases: 1) Library.accdb 2)MyDb.accdb. I set a reference to Library.accdb from within MyDb.accdb. Everything works fine (almost). From MyDb.accdb I can open forms and execute functions that reside in Library.accdb.

My problem is that within a form in MyDb.accdb I use the value CodeProject.Name with should give me the value "Library.accdb". However, it's returning the value of "MyDb.accdb". I have verified this in debug. I have decompiled both databases and compacted and repaired them. Option Explicit is set and both compile with no errors.

Anybody have any idea as to why this is happening?

 

[MajP]

That behavior is exactly what is expected.
The MS description is incomplete or almost wrong. I have seen a lot of other Access "Gurus" (or so there title implies) get this wrong. It leads one to the belief that the currentproject is your main application database and the codeproject is your library's project. This clearly cannot be correct. What would happen if you referenced 3 external libraries? Which one would be the codeproject?

In short the codeproject will return a reference from where the code is executing. It is not by default an external add-in or reference, as a lot of people say.

Simple test. In the library add this procedure.

Public Sub TestProjects()
  Dim frmObject As Access.AccessObject
  Debug.Print "The Current Project is: " & CurrentProject.Name
  Debug.Print "The Code Project is: " & CodeProject.Name
  For Each frmObject In CodeProject.AllForms
    Debug.Print frmObject.Name
  Next
  For Each frmObject In CurrentProject.AllForms
    Debug.Print frmObject.Name
  Next
End Sub

Now here is the method in the calling database

Public Sub testCurrentProject()
  Library.TestProjects
  Call HelloWorld
  Call Library.HelloWorld
End Sub

I also put helloworld methods in both the library and the main databases
And my output

The Current Project is: TestExternalClass.accdb
The Code Project is: Library.accdb
frmTest
frmTwo
Hello world inside the calling database.
Hello world in the library

So as you see codeproject returns a reference to the project where that code is running. It returns the correct forms either inside the codeproject or inside the currentproject.
So yes your code is performing exactly correct. The codeproject is the currentproject if called from within the code executing in the calling database.

 

[MajP]

If in your scenario you only ever reference one external library I think you could do something like this.
in your calling db

Public Function getcodeprojectname() As String
  Const TypeLibrary = 1
  Dim ref As Access.Reference
  For Each ref In Application.References
    If ref.Kind = TypeLibrary Then
      getcodeprojectname = Mid(ref.FullPath, InStrRev(ref.FullPath, "\") + 1)
      Exit Function
    End If
  Next ref
End Function

Or in simply in the library put a function

Public Function GetCodeProjectName() As String
  GetCodeProjectName = CodeProject.Name
End Function
[/code}

 

[MajP]

Or in simply in the library put a function

Public Function GetCodeProjectName() As String
GetCodeProjectName = CodeProject.Name
End Function

 

[MajP]

If you really want to understand how this works run this piece of code. The results may surprise you.

in the library.

Public Function GetCodeProject() As Object
 Set GetCodeProject = CodeProject
 Debug.Print GetCodeProject.Name
End Function

and in the main call it

Public Sub TestCodeProject()
  Debug.Print Library.GetCodeProject.Name
End Sub

So clearly the codeproject is a reference pointing to where execution is taking place.

 

[FancyPrairie]

Thanks for the response. I'm was very surprised to discover the CodeProject is the same as CurrentProject in a non-Library database. It's weird because my code has been running like that for a couple months (development cycle). However, one minor form kept reporting an error. But I just ingored it until I had time to visit it. That's when I discovered the problem. I initially thought it was a problem with my db becoming corrupt or something.

Anyway, I resolved the issue by creating a function within the library that returns what I want.

Ex.
Function My_CodeProject(strValue as string) as string
Select Case strValue
Case "Name": My_CodeProject = CodeProject.name
Case "Path": My_CodeProject = CodeProject.Path
etc.
End Select
End Function

Function My_CodeProject_Connection() as Connection
Set My_CodeProject_Connection = CodeProject.Connection
End Function

I just saw where MajP suggested that. Sorry, I guess I was too tired to realize it. I was up all night til 7:00 this morning trying to figure it out.

 

[MajP]

I think what is surprising is how bad the documentation in the help and MSDN is. The book I have clearly describes the codeproject as the project from where that line of code is running that references it. So to me that definition makes pretty much sense that the currentproject and codeproject are the same if called from a non-library application. That was also my point of the 15:05 post. You call the function in the library database and it returns the codeproject as the library. The function returns that reference back to the calling function in the non-library database, but since control is back to the calling database the pointer is referencing the non-library database.