View Single Post
  #7   Report Post  
Posted to microsoft.public.excel.programming
Desmond Walsh Desmond Walsh is offline
external usenet poster
 
Posts: 28
Default Problem with class variable and Personal.xlsb

On Monday, April 20, 2020 at 1:21:02 PM UTC-4, GS wrote:
Thanks for the detailed explanation. While your detailed explanation makes
sense in concept, I'm having difficulty understanding the following leading
comments.

Tab and spaces are normal string content and so if you build a string
containing them it can be output to a text file and/or the ImmediateWindow at
any time.

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.


If you are trying to 'collect' progressive Debug.Print outputs for a design
session (as I sometimes do so I can review 'actual' outputs), your class seems
like a lot of work unless you are using it as a subclassing component where
each project instantiates its own instance independant of any other projects
using it simultaneously; - in this case it makes sense to go the distance!

My approach is project-centric in that any D.P statements get passed to a
function similar to the WriteTextFile ones I posted earlier; the output to the
log is same as how error.log stuff gets done, but the new text also goes to IW.
I suppose having a 'globally available' solution is not much different (and
cudos to you for doing that), I just prefer my approach because it's integrated
with my central error handling system in every project.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion


This is the problem I had with handling Debug.Print statements ;

Sub testz()
Dim line As String
Debug.Print "Hello World"
line = "Hello World"
Debug.Print line
Debug.Print "Hello"; Tab(10); "World"
line = "Hello; Tab(10); World"
Debug.Print line
End Sub

Output:
Hello World
Hello World
Hello World
Hello; Tab(10); World

Once I put the statement in a string, I seem to lose the Debug.Print ability to parse Tab() and Spc() correctly.

I apologetically must provide another flip flop on my found solution to passing a global class variable to PERSONAL.xlsb. The use of the Public variable dp1 is essential on the PERSONAL side. If LinkToDebugSupport's input parameter is named dp then dp behaves correctly in LinkToDebugSupport (dp.output_line works) but causes a runtime error in any other PERSONAL macro using it. I don't really understand what is going on here and am amazed that I stumbled on something that works !.

In MyWorkbook
Public dp as new DebugSupport (Global class variable)
call LinkToDebugSupport (dp) (A PERSONAL subroutine)

In PERSONAL
Public dp as Variant (Declared outside macros)
Sub LinkToDebugSupport (dp1 as Variant) (Declaring dp as the parameter makes
dp local to this subroutine)
set dp = dp1
End Sub