[VB6] Event Tracing for Windows - Monitoring File Activity with ETW

May I ask you how you developed / debugged the project when you can not really debug it without it being compiled + running it with admin privileges?
You do it flying blind, right? Or is there any special way of still being able to debug it in the IDE?

Everything right up until the new thread starts could be debugged the normal way; the IDE can be run as admin (and I always run VB6 that way for hklm access).

After that, I just logged to the text box... That's what it's primarily there for, I just removed all but major steps and status info prior to release. Also logging to text file.

For the listview I had a routine to populate the event log with dummy data without starting an actual trace so I could debug in IDE. The process info stuff could be checked with manual calls from the IDE also without an actual trace session; I minimized what could only be debugged in the exe via text output. And then you go a little at a time; the initial callback just printed that it made it there, here's the event codes and some other stuff to make sure the data is as expected. Then compile and check often that new code is working.

Thank you. Can you also tell me your workflow for adding TB code? I have noticed that you use #IF then in your projects for TB, and I wonder how you currently develop your projects, serving / using both Vb6 and TB.

All of my new work is done in tB for some time now, using my WinDevLib project so all Windows APIs are already available and x64 compatible-- as is the project from the beginning. Sometimes I'll want to support vb6 too, and in that case I just avoid using new language features then when I'm done, copy everything out of WDL into conditional blocks -- with and without PtrSafe is mainly so the code is portable to VBA too; if I'm back porting originally 64bit code, might as well support 64bit VBA (though I haven't actually made a 64bit typelib for interfaces, and skip this for UCs) . Recreate form and uc designs in vb6, then copy/paste in code. Interface wise, WDL sticks close to oleexp, but there's some cases where things differ for a good reason and conditionals are needed.

With existing code, tB is still new enough I haven't settled in to a particular standard. This project was the first I ever ported, almost 3 years ago now. tB couldn't import forms or controls yet at the time, so this and other early projects completely diverged, since quite a bit of changes were made. I loved tB from the start so worked on those versions, now with this, ucShellBrowse, and some others the tB versionare several versions and feature updates ahead, without a compatible vb6 version.

Most projects have gone that way; the most common way is I prepare for import to tB by replacing self-sub/class callback methods with helper .bas based methods (if applicable), make sure that works in vb6 still, import to tB, ensure it works as is or start making bug reports (show stoppers are usually fixed quick). This is really as far as you need to go, unless you're going update to x64 compatibility. You shouldn't need any conditional compilation for a 32bit only code base you want to use in both.

Converting code to 64bit, especially code using com interfaces so WDL is a requirement (for me), while remaining vb6/oleexp compatible is where you'll see the most conditional compilations. But it's still not that much, because tB has come a really long way with compatibility, and I do try to keep WDL compatible with oleexp.

Sorry for the vague answers, wasn't sure which specific scenario you meant; can expand on any of them if you want.