On 4/07/2009 8:48 PM, Gertjan Klein wrote:
Mark Hammond wrote:
I haven't caught up with the rest of the thread yet, but in my
experience, the shell keeps objects alive for as shorter time as
possible. So you may find a completely new instance is requested for
each context menu request (or for
Mark Hammond wrote:
>I haven't caught up with the rest of the thread yet, but in my
>experience, the shell keeps objects alive for as shorter time as
>possible. So you may find a completely new instance is requested for
>each context menu request (or for each different item selected, or
>some
Mark Hammond wrote:
>I haven't caught up with the rest of the thread yet, but in my
>experience, the shell keeps objects alive for as shorter time as
>possible. So you may find a completely new instance is requested for
>each context menu request (or for each different item selected, or
>some
On 30/06/2009 5:09 AM, Tim Roberts wrote:
Gertjan Klein wrote:
It doesn't over here, but another poster has shown me how to circumvent
this. If this is the only way to do that I will; there is no way to tell
PyWin32 to reload the extension? (I know reloading in Python is tough,
I'm expecting a "
Tim Roberts wrote:
>Gertjan Klein wrote:
>> (I wish I could somehow pass icons to the
>> submenus, but it seems that for that you need completely owner-drawn
>> menu items, and that seems like a daunting task!)
>
>Correct. I decided against that in my own version.
Well, I might have a go at it j
Gertjan Klein wrote:
> Yes. However, pywin32 is the one that holds the pointer to the object,
> not Windows COM (at least, I assume this is the case).
Well, only at the most technical level. The most useful mental model is
to think of the Python object as being the thing that gets passed to the
C
Tim Roberts wrote:
>It's not that easy. In Python, an object's method functions are just
>another piece of data in the object. When a client instantiates your
>COM object, the Python code creates an instance of your object,
>including pointers to the intermediate language for the method
>functio
Gertjan Klein wrote:
> Ah, but this is what confuses me. I don't have a DLL: I have a .py file,
> which gets interpreted by python. The DDLs that get loaded are
> python25.dll and two pywin32 dlls (don't remember offhand which). So,
> when the extension is first loaded, pywin32 must load python, co
Tim Golden wrote:
>And also the win32traceutil facility which comes with the pywin32
>extensions can help you out here.
[...]
>Insanely helpful when you're trying to debug, an ISAPI extension
>module.
Thanks for that, I just tried it and it works as advertised. Very useful
indeed!
Regards,
Gertj
Gertjan Klein wrote:
Randy Syring wrote:
Maybe I am missing something, but I use the "Open Command Window Here"
power toy from:
You're missing something. ;-) I have used that one too, for years, and
it works reasonably well -- until you have multiple Python versions
installed, and w
Randy Syring wrote:
>Maybe I am missing something, but I use the "Open Command Window Here"
>power toy from:
You're missing something. ;-) I have used that one too, for years, and
it works reasonably well -- until you have multiple Python versions
installed, and want to compile extensions for a
Vernon Cole wrote:
>sys.stdout works like a normal Python file, so you should be able to assign
>a new file object to it.
Yes, that looks like a clean and simple approach, that I may end up
using, if nothing else for debugging.
Thanks,
Gertjan.
___
p
Tim Roberts wrote:
>I was going to respond "no" immediately, but now you've got me
>thinking. Explorer loads the DLL, instantiates the COM object, and
>keeps it loaded forever. I think that fact alone makes it impossible;
>even if you added a backdoor to reload the module, you still have an
>obj
Tim Golden wrote:
Thomas Heller wrote:
Gertjan Klein schrieb:
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
Thomas Heller wrote:
Gertjan Klein schrieb:
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 w
Gertjan Klein schrieb:
>>> 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
On Mon, Jun 29, 2009 at 12:17 PM, Gertjan Klein wrote:
> Tim Roberts wrote:
>
> >Gertjan Klein wrote:
> >> 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 the
Gertjan Klein wrote:
Tim Roberts wrote:
Gertjan Klein wrote:
(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.)
Maybe I am missing something, but I use the "Open Comma
Gertjan Klein wrote:
> It doesn't over here, but another poster has shown me how to circumvent
> this. If this is the only way to do that I will; there is no way to tell
> PyWin32 to reload the extension? (I know reloading in Python is tough,
> I'm expecting a "no" here. ;-))
>
I was going to r
Tim Roberts wrote:
>Gertjan Klein wrote:
>>(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.
I
Kevin Horn wrote:
>In case explorer doesn't restart automatically, you can easily start it up
>again manually from the task manager (which you should have open from
>killing the process).
Thanks, that tip just saved me! If I kill explorer.exe from task
manager, my taskbar and desktop icons disapp
Just an aside on restarting explorer...
In case explorer doesn't restart automatically, you can easily start it up
again manually from the task manager (which you should have open from
killing the process).
File->NewTask, then type explorer.
I'm sure this isn't news to most people here, but I'm
Gertjan Klein wrote:
> I've checked with Process Explorer, but even if I use the Windows
> Explorer setting "Launch folder windows in a separate process" there is
> still only one explorer.exe visible, which is at the root of everything
> I have open. I wouldn't want to kill that one...
>
That'
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
Mario Alejandro Vilas Jerez wrote:
>Did you try killing all instances of explorer.exe instead of rebooting? That
>might do the trick and it's faster.
I've checked with Process Explorer, but even if I use the Windows
Explorer setting "Launch folder windows in a separate process" there is
still onl
Did you try killing all instances of explorer.exe instead of rebooting? That
might do the trick and it's faster.
On Sun, Jun 28, 2009 at 9:10 AM, Gertjan Klein wrote:
> Hi,
>
> I am trying to write a shell context menu handler, based on the example
> I found in Lib\site-packages\win32comext\shel
Hi,
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
27 matches
Mail list logo
