Pelegrinus
asked on
Use VBA Code to Save class modules imported into Access
I have a vba routine that successfully imports modules (from .cls and .bas files) into my Access 2010 project (.accdb). I am now trying to save those modules using vba.
I have tried this command---Call SysCmd(504, 16483). Although no error occurs, none of the modules is saved.
I have an active "reference" to Microsoft Visual Basic for Applications Extensibility, and I imported the modules using the VBIDE.VBComponents object. Can anyone tell me how to use code to save modules successfully imported?
I have tried this command---Call SysCmd(504, 16483). Although no error occurs, none of the modules is saved.
I have an active "reference" to Microsoft Visual Basic for Applications Extensibility, and I imported the modules using the VBIDE.VBComponents object. Can anyone tell me how to use code to save modules successfully imported?
ASKER
Thanks! I am going to look at these in more detail but, based on a quick look, I want to clarify my question: I want to save the modules within the Access application, as if I clicked on the "Save" button in the VB Editor. As I said, I will examine the references you linked in much more detail to see if they answer that question as clarified. Thanks again.
Sorry about the confusion.
Actually, you need to look at the LoadFromText method.
Actually, you need to look at the LoadFromText method.
can you clarify this statement
<Can anyone tell me how to use code to save modules successfully imported?>
save to where ?
when you import the modules, they are saved in the access app..
<Can anyone tell me how to use code to save modules successfully imported?>
save to where ?
when you import the modules, they are saved in the access app..
ASKER
Yes, that does require clarification: When I successfully import the modules, they are visible in the VB Editor with the correct module names. BUT, they are not yet saved. When I click the "Save" button in the VB Editor, or when I close the database, I am prompted to save each module individually. The prompt gives the module's proper name, but I still have to click OK for each of the several dozen modules that I imported. What I want to do is automate that process of saving (and naming) each module.
try this codes
Sub importObjects()
Dim db As dao.Database, otherDBPath, j, modObj
otherDBPath = CurrentProject.Path & "\OtherDB.mdb"
Set db = OpenDatabase(otherDBPath)
For j = 0 To db.Containers("modules").D ocuments.C ount - 1
modObj = db.Containers("modules").D ocuments(j ).Name
DoCmd.TransferDatabase acImport, "Microsoft Access", otherDBPath, acModule, modObj, modObj
Application.RefreshDatabas eWindow
Next
db.Close
End Sub
change the variables values accordingly
Sub importObjects()
Dim db As dao.Database, otherDBPath, j, modObj
otherDBPath = CurrentProject.Path & "\OtherDB.mdb"
Set db = OpenDatabase(otherDBPath)
For j = 0 To db.Containers("modules").D
modObj = db.Containers("modules").D
DoCmd.TransferDatabase acImport, "Microsoft Access", otherDBPath, acModule, modObj, modObj
Application.RefreshDatabas
Next
db.Close
End Sub
change the variables values accordingly
ASKER
If I understand the code correctly, it assumes that the modules are in another database. I am working on a different model: namely, I'm storing the modules in text-equivalent files (.cls, .bas, etc) in an Explorer directory. I'm doing that in order to have separate text-equivalent files that can be used if my database becomes corrupted, as it sometimes does during development.
And so, having successfully imported these separate .cls and .bas files into working modules in a new database, I want to automate the processing of saving them in the database without having to go through the manual process of "naming" them before they are saved.
Here's the function I use to import a single module:
Public Function ImportModuleViaVBIDE( _
pobjVBC As VBIDE.VBComponents, _
pstrPath As String, _
pstrFile As String) As Boolean
' Comments: This processes a single code file in a directory designated _
in the calling routine. _
-- Determine whether the code already exists in pObjVBC _
-- If so, delete the code and _
import the file in place of it _
-- If not, import the code
' Params :
' Returns : Boolean
' Created : 04/05/12 16:08 JV
' Modified:
'TVCodeTools ErrorEnablerStart
On Error GoTo PROC_ERR
'TVCodeTools ErrorEnablerEnd
Dim strFName As String
Dim lngT As Long
strFName = FullPathAndFileName(pstrFi le, "", pstrPath) ' code not included in this sample
' ***** if the component exists, delete it
For lngT = pobjVBC.Count To 1 Step -1
If pobjVBC(lngT).Name = Left(pstrFile, InStr(1, pstrFile, ".") - 1) Then
pobjVBC.Remove pobjVBC(lngT)
End If
Next lngT
pobjVBC.Import strFName
ImportModuleViaVBIDE = True
'TVCodeTools ErrorHandlerStart
PROC_EXIT:
Exit Function
PROC_ERR:
MsgBox Err.Description, vbCritical, "modModulesImportExport.Im portModule ViaVBIDE"
Resume PROC_EXIT
'TVCodeTools ErrorHandlerEnd
End Function
At this point, the module is visible in the VB Editor and can be edited and executed. It's not saved, though, and that's the step I want to automate.
And so, having successfully imported these separate .cls and .bas files into working modules in a new database, I want to automate the processing of saving them in the database without having to go through the manual process of "naming" them before they are saved.
Here's the function I use to import a single module:
Public Function ImportModuleViaVBIDE( _
pobjVBC As VBIDE.VBComponents, _
pstrPath As String, _
pstrFile As String) As Boolean
' Comments: This processes a single code file in a directory designated _
in the calling routine. _
-- Determine whether the code already exists in pObjVBC _
-- If so, delete the code and _
import the file in place of it _
-- If not, import the code
' Params :
' Returns : Boolean
' Created : 04/05/12 16:08 JV
' Modified:
'TVCodeTools ErrorEnablerStart
On Error GoTo PROC_ERR
'TVCodeTools ErrorEnablerEnd
Dim strFName As String
Dim lngT As Long
strFName = FullPathAndFileName(pstrFi
' ***** if the component exists, delete it
For lngT = pobjVBC.Count To 1 Step -1
If pobjVBC(lngT).Name = Left(pstrFile, InStr(1, pstrFile, ".") - 1) Then
pobjVBC.Remove pobjVBC(lngT)
End If
Next lngT
pobjVBC.Import strFName
ImportModuleViaVBIDE = True
'TVCodeTools ErrorHandlerStart
PROC_EXIT:
Exit Function
PROC_ERR:
MsgBox Err.Description, vbCritical, "modModulesImportExport.Im
Resume PROC_EXIT
'TVCodeTools ErrorHandlerEnd
End Function
At this point, the module is visible in the VB Editor and can be edited and executed. It's not saved, though, and that's the step I want to automate.
ooh, you must use what fyed proposes "application.loadfromtext"
the syntax is
Application.LoadFromText acmodule,"NameOfModule", "c:\folder\ModuleName.bas"
the syntax is
Application.LoadFromText acmodule,"NameOfModule", "c:\folder\ModuleName.bas"
ASKER
That goes part way there, but Application.LoadFromText does not distinguish between standard modules and class modules. I loaded a class modue (and it did not need to be saved after the load was complete), but it is stored under modules rather than class modules. And the header contains language above the permissible option statementsa that (understandably) will not compile:
VERSION 1.0 CLASS
BEGIN
MultiUse = -1 'True
End
It seems as if a different approach is required for a solution.
VERSION 1.0 CLASS
BEGIN
MultiUse = -1 'True
End
It seems as if a different approach is required for a solution.
ASKER
I can't believe that I'm the first to run into this stone wall. I have the impression that it's a common practice to export modules to .cls or .bas files and then import them into new databases (and keep the distinction between standard modules and class modules).
I can easily automate that process. There must be some way also to automate the required step of SAVING the modules that have been imported.
I've looked in Application.VBE.ActiveVBPr oject.VBCo mponents and in Application.CurrentProject but have not seen anything that solves my question. (CurrentProject.UpdateDepe ndencyInfo will save the module put requires that I manually confirm the module name for each of the many modules I imported.) I REALLY would appreciate any specific suggestions.
I can easily automate that process. There must be some way also to automate the required step of SAVING the modules that have been imported.
I've looked in Application.VBE.ActiveVBPr
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
"I have the impression that it's a common practice to export modules to .cls or .bas files and then import them into new databases (and keep the distinction between standard modules and class modules)."
Well, not really. It's pretty simple to just Import into a new db container. Access handles that just fine, including maintaining the distinction between Class modules and Standard modules.
mx
Well, not really. It's pretty simple to just Import into a new db container. Access handles that just fine, including maintaining the distinction between Class modules and Standard modules.
mx
The non-standard part of what you are doing seems to be that you are doing this as part of a run-time process.
(sent from phone)
(sent from phone)
Hey Brent ... if you have time, pop over to this Q and see if you have an thoughts ... on the limitations and issues.
Here
thx.mx
Here
thx.mx
ASKER
"Well, not really. It's pretty simple to just Import into a new db container. Access handles that just fine, including maintaining the distinction between Class modules and Standard modules."
The reason I'm experimenting with .cls and .bas files stored in an Explorer directory is to "fix" a corrupted database where the corruption occurs during my development process. Although I have a lot of experience with vba coding, this part is new for me. If exporting the code to a new database container will "clean" the code, then I'd be glad to do that, because I agree (in concept, at least) that taking that route would be simpler. Does my concern about "fixing" corrurpted code make sense?
The reason I'm experimenting with .cls and .bas files stored in an Explorer directory is to "fix" a corrupted database where the corruption occurs during my development process. Although I have a lot of experience with vba coding, this part is new for me. If exporting the code to a new database container will "clean" the code, then I'd be glad to do that, because I agree (in concept, at least) that taking that route would be simpler. Does my concern about "fixing" corrurpted code make sense?
"Does my concern about "fixing" corrurpted code make sense?"
First ... are you familiar with Decompile ?
mx
First ... are you familiar with Decompile ?
mx
ASKER
This is the solution. I now do the equivalent of this code, where the mcstr variables identify the module at issue:
Application.VBE.ActiveVBPr oject.VBCo mponents.I mport mcstrImportExportModule
Application.DoCmd.Save acModule, mcstrModuleName
Application.RefreshDatabas eWindow
Application.VBE.ActiveVBPr
Application.DoCmd.Save acModule, mcstrModuleName
Application.RefreshDatabas
:-)
Application.SaveAsText method.
It is not documented in the Access Help, but there are lots of posts here on EE and elsewhere on the web:
http://blogs.msdn.com/b/thirdoffive/archive/2006/08/31/698640.aspx
http://allenbrowne.com/ser-47.html