John Colby
jwcolby at ColbyConsulting.com
Fri Jan 13 09:11:37 CST 2006
It appears that Access is getting confused as to where the class is being built. I have a framework linked in to my FE and apparently the add-in can't figure out what container the class belongs in. When I create the class and go look at it (it opens so I can see it) but up at the top it says the container is the Add-In. The save button is not grayed out but if I try and click it, nothing happens. If I then cut the code out and insert another class and paste the code back in, I still can't save it. If I open a module inside the actual application first, then insert a new class and paste in the code, I can now save it (prompted for the class name of course) and it saves in the application. So it appears that the code that actually creates the class is creating it inside of the Add-In container and it is illegal to save changes to that from the app using the Add-In. The odd part is that somehow, someway (and VERY briefly) at the very beginning I was able to create the module in the application container and MANUALLY save it by clicking the save icon. Very frustrating. Again, the code for creating the module is: Function AddModule() As CodeModule On Error GoTo Err_AddModule Dim lVBCmp As VBComponent Set lVBCmp = mVBProj.VBComponents.Add(vbext_ct_ClassModule) Set mMdl = lVBCmp.CodeModule mMdl.Name = mstrClassName mMdl.CodePane.Show mMdl.AddFromString mstrModule Set AddModule = mMdl Exit_AddModule: On Error Resume Next Exit Function Err_AddModule: MsgBox Err.Description, , "Error in Function basVBE.AddModule" Resume Exit_AddModule Resume 0 '.FOR TROUBLESHOOTING End Function The mObjects are dimensioned in the header of the class, and mVBProj is instantiated in the Init: Set mVBProj = CurrentProject.Application.VBE.ActiveVBProject I thought that CurrentProject was the application and thus would cause an instance of the application even if run in a lib or add-in. John W. Colby www.ColbyConsulting.com