On Sunday, April 19, 2020 at 12:20:20 AM UTC-4, GS wrote:
It sounds like you want to use your class as a separate object rather than
include it in each VBA Project you want to use it in. Not a good idea! Just
insert the class into each project you want to use it in so it is exclusive to
that project and NOT USED BY ANY OTHER PROJECTS!
Then you should create a variable local to each routine that uses it,
instantiate it, then destroy it when done with it after each use.
Not sure why you are going to this extent when Debug.Print works for most
developers during design time, but most will log to a text file via a central
logger component, which, in most cases is part of their error handling system.
Ideally, though, the process to write to the log file should be a stand-alone
reusable routine that accepts a FileOut, TextOut, and output mode as args.. For
example:
Sub FSO_WriteTextFile(FileOut, TextOut, ioMode)
' Reusable procedure that Writes or Appends
' large amounts of data to a Text file in one single step.
' **Does not create a blank line at the end of the file**
Dim oFSO, oFile
On Error GoTo ErrHandler
Set oFSO = CreateObject("Scripting.FileSystemObject")
If ioMode = lOpenA Then '//add to file contents
Set oFile = oFSO.OpenTextFile(FileOut, lOpenA)
oFile.Write (vbCrLf & TextOut)
Else '//overwrite file
Set oFile = oFSO.CreateTextFile(FileOut, lOpenW)
oFile.Write (TextOut)
End If
'ErrHandler:
oFile.Close: Set oFSO = Nothing: Set oFile = Nothing
End Sub
-OR-
Sub WriteTextFile(ByVal TextOut$, Filename$, _
Optional AppendMode As Boolean = False)
' Reusable procedure that Writes/Overwrites or Appends
' large amounts of data to a Text file in one single step.
' **Does not create a blank line at the end of the file**
Const sSrc$ = "WriteTextFile"
Dim iNum%
On Error GoTo ErrHandler
iNum = FreeFile()
If AppendMode Then '//start a new line
Open Filename For Append As #iNum: Print #iNum, vbCrLf & TextOut;
Else '//overwrite existing file
Open Filename For Output As #iNum: Print #iNum, TextOut;
End If
ErrHandler:
Close #iNum: If Err Then Err.Raise Err.Number, sSrc, Err.Description
End Sub 'WriteTextFile()
--
Garry
Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Thank you for looking at my posts. I believe we had a discussion before about why it was neccessary to replace Debug.Print. The reason is because I wanted the option to log the Immediate Window stream and I could not put a Debug.Print statement into a string if it contained the formatting functions Tab() and Spc(). I find these functions very useful in getting easy to read output. My class has a method to replace Debug.Print statements with equivalent dp.output_line statements.
In a perfect world PERSONAL should only contain commonly used macros that are fully debugged and therefore should not need to generate debug output. I find I tend to develop applications that rely heavily on my PERSONAL macros. So during development having the entire code body (application+ macros called from PERSONAL) output to a single disk stream is very useful. My application creates its own instance of DebugSupport and now without any coding modification in PERSONAL I get my desired logging.
The situation is less satisfactory when I want to run a PERSONAL macro stand-alone and if I want debug logging. Again I create an instance of DebugSupport. But I have to manually disable the declaration (Public dp as Variant). I see no way to do this programatically. I have the declaration in a separate module so its a quick edit. However, a more elegant solution would be more satisfactory.
I checked my last posting again. And of course, using the additional variable dp1 on the Workbook side and the PERSONAL side is completely unnecessary. So the only requirement is that the workbook passes dp ( new DebugSupport) to PERSONAL as a Variant and dp is declared as a Public Variant in PERSONAL.