When zTrace is disabled (when building release), all calls to zTrace are ignored

[John Thompson]

I just started using zTrace and really like it.  I was curious if it would be possible to ignore all calls to zTrace if support is no longer enabled (when building a release version) in project properties?  zTrace is so quick and simple to use it would seem a lot cleaner (from my side) than doing the whole #IF #ENDIF around each zTrace... especially when a lot of calls are made.

[Paul Squires]

Not sure how to accomplish this..... maybe if zTrace is not enabled then I could output a "dummy" zTrace function in the generated source code so that any calls already in your code would call this empty zTrace function rather than look to Patrice's DLL.

Come to think of it, try adding the following code to one of your Modules or Forms and see if it solves the problem:

Code Select Expand


#If Not %Def(%FIREFLY_ZTRACE)
Function zTrace (zTmp As Asciiz) As Long
End Function
#EndIf


[Paul Squires]

I just modified the code generation so that the zTrace declaration line in the CODEGEN*.BAS now reads as follows:

Code Select Expand


#If %Def(%FIREFLY_ZTRACE)
   Declare Function zTrace Lib "zTrace.dll" Alias "zTrace" (zTmp As Asciiz) As Long
#Else
   Function zTrace (zTmp As Asciiz) As Long
   End Function
#EndIf


This appears to deal with the situation where you have zTrace enabled or disabled and saves you from having to #If/#EndIf your zTrace calls.

The fix will be in 3.04.

[Guenter Fuessner]

The following macros have almost no speed effect with debug statements in production code (due to the fact that I use these macros with my own "zTrace" like DLL, I had to make some conversions. Hope it will work ok with zTrace...).

'Example:   mSub
'           dPrt ("X =" & STR$(X))
'           dPrt ("gPgm.Path: " & gPgm.Path)

'this gives you something like this:
'
'18:46:11  INITSYST                        CallPath: WINMAIN 
'18:46:11    (INITSYST) X = 0                                 >0.016
'18:46:11    (INITSYST) gPgm.Path: K:\MyPgmPath\              >0.000

Code Select Expand


'----------------------------------------------------------------------------------------------------------------------

'%DbgMode = 0   'generate production code without debug info
%DbgMode = 1 'generate code with debug info

'----------------------------------------------------------------------------------------------------------------------
Macro mSub
'to be inserted once at the very beginning of a Function or Sub
'shows actual function name and the function we have been called from

    #IF %DbgMode     
        MacroTemp AktZSubInfo
        MacroTemp AktDbg2Info 
        MacroTemp KlPos 

        Local AktZSubInfo AS ASCIIZ * 4096
        Local AktDbg2Info$       
        Local KlPos AS LONG
       
        AktDbg2Info$ = CallSTK$(2)
        KlPos = Instr(AktZSubInfo, "(")
        If KlPos > 0 Then
          AktDbg2Info$ = Left$(AktZSubInfo, KlPos -1)
        End If
        AktDbg2Info$ = Left$(FUNCNAME$ & Space$(36), 36)  & "CallPath: " & AktDbg2Info$       
        AktZSubInfo = AktDbg2Info$

        zTrace AktZSubInfo
#ENDIF   
END Macro
'----------------------------------------------------------------------------------------------------------------------
Macro dPrt (WindowText)
    'these macro prefix every debug text with the function name it has been called from
    #IF %DbgMode 
      MacroTemp AktZInfo
      Local AktZInfo AS ASCIIZ * 4096
      AktZInfo = "(" & FUNCNAME$ & ") " & WindowText
      zTrace AktZInfo
    #ENDIF   
End MACRO
'----------------------------------------------------------------------------------------------------------------------
Macro dPrtD (FncDbgFlag, WindowText)
     'to make it possible to debug a complex function with many debug lines,
     'I use a second constant "%FncDbgFlag"   
     '%FncDbgFlag can be switched on/off if you have the need to do a very intensive debug analysis
     'if you switch it off, no speed degradiation will happen within your function

    #IF %DbgMode 
     #IF %FncDbgFlag Then 'only compiled/active if local function FncDbgFlag > 0
      MacroTemp AktZInfo
      Local AktZInfo AS ASCIIZ * 4096
      AktZInfo = "(" & FUNCNAME$ & ") " & WindowText
      zTrace AktZInfo
     #ENDIF
    #ENDIF       
End MACRO
'----------------------------------------------------------------------------------------------------------------------



have fun,
Guenter Fuessner

[Michael Stefanik]

Just a suggestion, but rather than bind the zTrace.dll to the application using declare, load it dynamically using LoadLibrary and GetProcAddress. This would allow the program to gracefully handle the situation where the executable is distributed without the DLL (if the DLL couldn't be loaded, calls to zTrace would just return, effectively being a no-op). It could also allow developers to "enable" it dynamically in their applications simply by providing the DLL to their end user, rather than shipping them a separate build of the executable.

[Patrice Terrier]

When checking/unchecking zTrace in FF3, then the DLL is removed form the release folder.
This is a problem when zTrace is being used in another DLL for the purpose of debugging.

...

[Paul Squires]

Thanks Patrice,

I have removed the code that deletes the zTrace dll from the release folder.

The fix will be in v3.04.

[David Kenny]

I just put ztrace.dll in the path (C:\windows\ is a good place most of the time).  You don't have to give a path when using it either.

Code Select Expand

Declare Function zTrace Lib "zTrace.DLL" Alias "zTrace" (zMessage As Asciiz) As Long
in each program is all that is needed.

Is there some reason to put it in the release folder at all?

David

[Michael Stefanik]

I just put ztrace.dll in the path (C:\windows\ is a good place most of the time).  You don't have to give a path when using it either.

Code Select Expand

Declare Function zTrace Lib "zTrace.DLL" Alias "zTrace" (zMessage As Asciiz) As Long
in each program is all that is needed.

Is there some reason to put it in the release folder at all?

David

While it used to be common to put application DLLs in \windows or \windows\system32, that practice is generally frowned upon today. The official guidelines from Microsoft is that those are protected system folders and only windows executables and shared components should go there. Application specific DLLs should be installed alongside the executable, avoiding "DLL Hell" scenarios where one program inadvertantly ends up loading a different version of the DLL than what it shipped with. Even with ActiveX controls, which are commonly installed in \windows\system32 and registered from there, are now supposed to be instantiated using reg-free COM so they can be installed and loaded with the program that uses them (and so they can also be installed with xcopy or ClickOnce style installations without any registration requirements, but that's a different issue).

If you do install the ztrace.dll in \windows\system32 (or \windows\syswow64 on 64-bit systems), you should make sure the installer flags it as a shared DLL. If you don't and the user uninstalls your software, it would remove the DLL and potentially break other applications that reference it.

[Rolf Brandt]

There is a very good article on MSDN about Registration-Free Activation of Com Components:

http://msdn.microsoft.com/en-us/library/ms973913.aspx

Rolf

[David Kenny]

Mike,

The content of your post suggests that you would be installing that on user machines?  Not saying you shouldn't, but I don't know why anyone would ever do that.  It's a debugging tool exclusively for me.  I was only talking about how I use it on my development computer.  My post was only addressing that type of use.

Best regards,

David

[Michael Stefanik]

The content of your post suggests that you would be installing that on user machines?  Not saying you shouldn't, but I don't know why anyone would ever do that.

Given that it can support debug output in a popup or a text file, I could see a lot of reasons that you'd want to provide it to an end-user. An example would be a bug that they're reporting, which you can't reproduce on your system. Enable a debugging option in your software (configuration file, whatever) and it generates a logfile that they send back to you. With the popup window, you could even do it interactively with them or use something like GoToAssist, run the program and watch the debug output yourself, without having to send them a completely different/new build of the application first. That sort of thing.

In SocketTools (a suite of Internet components and libraries my company makes), we have a DLL that hooks into our code that can dump all network API calls and a hexdump of the data to a logfile. It's something that we use internally, but also something that a lot of our developers really appreciate because they can a) use it to diagnose problems on their customer's systems, b) send the log back to us to analyze if the problem is complex. The more complex your application, the more beneficial it is to have facilities like this integrated into the program.

[David Kenny]

Thanks for the insight Mike, those are valid reasons for doing that.  I am a utility programmer myself. I write things that help me and my coworkers get our jobs done.  I am usually the only user, but other times the other users are all in the same company.  I am also a hobby programmer.

I can see how Ztrace would be useful in your (and similar) situations.  I was going to suggest a possible enhancement to Patrice for Ztrace.  I think it would help you in the way you use it also. I can take care of that right now.

Patrice,

How about being able to insert user comments into the recorded stream? For example the user could click on ztrace and tell it to add a comment before (or after) a line of generated output - documenting behavior of the program just prior to that line, options they selected that produced that line, that they expected X instead of Y, Etc.

I do that now by jotting down notes as they occur to me.

David