[python-win32] Shell extension debugging

[Tim Roberts]

Gertjan Klein wrote:
> I am trying to write a shell context menu handler, based on the example
> I found in Lib\site-packages\win32comext\shell\demos\servers. My
> ultimate goal is to have a single top-level menu, with a number of
> submenu entries determined at runtime. (I want to make a launcher for
> command prompts, so I can open a command prompt at a given directory
> with appropriate settings for python: path, C compiler, etc.)
>   

Interesting!  I wrote basically that same extension (in C++) about 5
years ago.  It is incredibly handy.  It lets me gather my applications
into folders on the desktop, and launch using right-clicks without
wading through the Start menu.  I have all of my compiler shells in one
folder, all of my DDK shells in another folder, all of my SSH
connections in a third, and all of the Office apps in a fourth.

> Anyway, I have noticed that once I register the shell extension,
> unregistering, changing the code, and reregistering doesn't work: I get
> the old code. On top of that, I have managed to mess up the code so the
> message box no longer appears when I click the menu item. I need to find
> a way to debug my code!
>
> So, two questions:
>
> 1) Is it possible to completely unload the shell extension, so that
> registering it again gets me the newer version? I'd rather not reboot
> after every code change.
>   

Yes, it is possible, but you have to restart the root Windows Explorer
shell.  You can bring up the Task Manager and kill the Explorer
process.  All of your icons and your start bar will briefly disappear,
but Windows is stubborn and will immediately restart it.

> 2) I see print statements in the source code, but I have no idea where
> they go; I checked the event log, but they are not there. Are they
> logged anywhere? If not, why are they there to begin with?
>
> Any other tip on how to effectively debug this stuff would be most
> welcome as well.
>   

The print statements go into empty space because there is no stdout for
that process.  You can try using the logging module to log to a file, or
you can use ctypes to write to kernel32.OutputDebugString and using a
kernel debug log monitor to read them.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.