Re: [python-win32] Calling unregistered COM libraries via Python

[Mark Hammond]

On 12/01/2016 4:21 AM, Manowitz, David wrote:

Is it possible, either via the win32com extensions or the comtypes
package (or some other package), to call to an unregistered COM
library?  It doesn’t seem so, but I wanted to check.


COM uses the registration info to locate and load the library, so in 
general it's not possible. You could always just register it though...


Mark





Thanks,

David Manowitz

Office of Petroleum, Natural Gas, and Biofuels Analysis

Energy Information Administration 

U.S. Department of Energy

1000 Independence Ave S.W.

Washington, DC 20585

Tel: +1-202-586-2815





___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32



___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Have icon overlays persist after machine restart in Python

[Mark Hammond]

setup_2.py has:

> setup(console=['overlays.py'])

So that's going to create a console program with no COM support. 
setup.py has:


># specify which type of com server you want (exe and/or dll)
>create_exe=True,
>create_dll=False

So you are only going to get a COM object that can be created as a .exe. 
Explorer wants only inproc objects (ie, those hosted in a DLL), so you 
want create_dll=True and create_exe=False - you should then get a DLL 
you can register with regsvr32.


HTH,

Mark


On 12/01/2016 4:44 AM, Alexander Jewell wrote:

Hi Mark,

I followed your suggestion and the SO threads touching on this area.
(http://stackoverflow.com/questions/4619701/python-64-bit-dll-com-server-registration-problem-on-64-bit-windows-7)
Using py2exe I generated a dist folder with an exe of my overlay script.
Running this on a machine without Python installed shows all of the
proper log messages being generated and registry entry created for my
overlay handler, however there's no indication that explorer is loading
and running the overlay handler.

Following the SO examples I instead generated a COM DLL from the same
source. I can copy this dist directory and new DLL over to a machine
without Python and use regsrv32 to register the DLL without errors, but
it doesn't run the main method which is what sets the required registry
entries and calls UseCommandLine so it doesn't look like it's being
registered correctly at all.

Sorry for the newb questions, but I seem to have a big gap in my
understanding of the mechanism.

So, the way that I'm using it at least, py2exe is either generating an
EXE that will register correctly but not provide a COM object with the
correct environment for explorer to run the overlay handler, or a DLL
that should be self contained and functional but not provide the
registration functionality.

I've attached my primary script (Overlay Handler + logging and some
helper objects) as well as 2 py2exe setup scripts I've tried.

I'm hoping you can point out a huge flaw in my thinking, or an obvious
step that I'm missing in the registration process.

Thanks again for any help you can provide.


On Fri, Jan 8, 2016 at 3:30 PM, Alexander Jewell > wrote:

I created a fresh Python 2.7 environment with pywin and py2exe and
stripped down my overlay handler to the basics to better troubleshoot.

Running my script (command line or in PyCharm) registers everything
correctly, just like before, but running the py2exe generated EXE
seems to be registering but no overlays are appearing, which looks
just like what happens when I restarted explorer.exe in my previous
attempt (logged messages during registration, plus a manual check of
the registry look good but nothing generated by IsMemberOf.

I'm going to try generating a DLL and manually registering following
the example
here: 
http://stackoverflow.com/questions/4619701/python-64-bit-dll-com-server-registration-problem-on-64-bit-windows-7

It looks like this example came out of a mail thread with you back
in 2011 so I'll try to follow the advice there and report back.

Thanks again for the help Mark.

On Wed, Jan 6, 2016 at 7:19 PM, Mark Hammond
> wrote:

On 7/01/2016 6:21 AM, Alexander Jewell wrote:

Unfortunately my end goal was to bundle the entire
application as an exe
with PyInstaller so that the end user does not actually have
Python
installed.

Do you think it would be possible to package the overlay
handler in such
a way that explorer would not need access to an installed Python
interpreter?
Embedding(https://docs.python.org/3.4/extending/embedding.html)
seems
to still require a Python interpreter but Cython sounds
promising.


I've used py2exe for this in the past and it works fine - you
need to end up with a stand-alone directory that functions
independently of any installed Python - py2exe bundles Python
itself, pywin32, etc in just this way. Last I tried though, it
only worked with python 2.x

Mark


-Alex

On Wed, Jan 6, 2016 at 5:37 AM, Mark Hammond

>> wrote:

My guess is that the environment (eg, PATH, PYTHONPATH
etc) for the
new explorer instance isn't setup correctly - how is the
explorer.exe process started when it *does* work? It's
hard to
answer without more info, but Python ends up inside
explorer.exe, so
the environment that 

Re: [python-win32] Have icon overlays persist after machine restart in Python

[Alexander Jewell]

Hi Mark,

I followed your suggestion and the SO threads touching on this area. (
http://stackoverflow.com/questions/4619701/python-64-bit-dll-com-server-registration-problem-on-64-bit-windows-7
)
Using py2exe I generated a dist folder with an exe of my overlay script.
Running this on a machine without Python installed shows all of the proper
log messages being generated and registry entry created for my overlay
handler, however there's no indication that explorer is loading and running
the overlay handler.

Following the SO examples I instead generated a COM DLL from the same
source. I can copy this dist directory and new DLL over to a machine
without Python and use regsrv32 to register the DLL without errors, but it
doesn't run the main method which is what sets the required registry
entries and calls UseCommandLine so it doesn't look like it's being
registered correctly at all.

Sorry for the newb questions, but I seem to have a big gap in my
understanding of the mechanism.

So, the way that I'm using it at least, py2exe is either generating an EXE
that will register correctly but not provide a COM object with the correct
environment for explorer to run the overlay handler, or a DLL that should
be self contained and functional but not provide the registration
functionality.

I've attached my primary script (Overlay Handler + logging and some helper
objects) as well as 2 py2exe setup scripts I've tried.

I'm hoping you can point out a huge flaw in my thinking, or an obvious step
that I'm missing in the registration process.

Thanks again for any help you can provide.


On Fri, Jan 8, 2016 at 3:30 PM, Alexander Jewell 
wrote:

> I created a fresh Python 2.7 environment with pywin and py2exe and
> stripped down my overlay handler to the basics to better troubleshoot.
>
> Running my script (command line or in PyCharm) registers everything
> correctly, just like before, but running the py2exe generated EXE seems to
> be registering but no overlays are appearing, which looks just like what
> happens when I restarted explorer.exe in my previous attempt (logged
> messages during registration, plus a manual check of the registry look good
> but nothing generated by IsMemberOf.
>
> I'm going to try generating a DLL and manually registering following the
> example here:
> http://stackoverflow.com/questions/4619701/python-64-bit-dll-com-server-registration-problem-on-64-bit-windows-7
>
> It looks like this example came out of a mail thread with you back in 2011
> so I'll try to follow the advice there and report back.
>
> Thanks again for the help Mark.
>
> On Wed, Jan 6, 2016 at 7:19 PM, Mark Hammond 
> wrote:
>
>> On 7/01/2016 6:21 AM, Alexander Jewell wrote:
>>
>>> Unfortunately my end goal was to bundle the entire application as an exe
>>> with PyInstaller so that the end user does not actually have Python
>>> installed.
>>>
>>> Do you think it would be possible to package the overlay handler in such
>>> a way that explorer would not need access to an installed Python
>>> interpreter?
>>> Embedding(https://docs.python.org/3.4/extending/embedding.html)  seems
>>> to still require a Python interpreter but Cython sounds promising.
>>>
>>
>> I've used py2exe for this in the past and it works fine - you need to end
>> up with a stand-alone directory that functions independently of any
>> installed Python - py2exe bundles Python itself, pywin32, etc in just this
>> way. Last I tried though, it only worked with python 2.x
>>
>> Mark
>>
>>
>>> -Alex
>>>
>>> On Wed, Jan 6, 2016 at 5:37 AM, Mark Hammond >> > wrote:
>>>
>>> My guess is that the environment (eg, PATH, PYTHONPATH etc) for the
>>> new explorer instance isn't setup correctly - how is the
>>> explorer.exe process started when it *does* work? It's hard to
>>> answer without more info, but Python ends up inside explorer.exe, so
>>> the environment that explorer.exe starts with is important.
>>>
>>> Mark
>>>
>>> On 6/01/2016 8:29 AM, Alexander Jewell wrote:
>>>
>>> So, thanks to the Tim Golden guide
>>> <
>>> http://timgolden.me.uk/python/win32_how_do_i/add-my-own-icon-overlays.html
>>> >
>>> (
>>> http://timgolden.me.uk/python/win32_how_do_i/add-my-own-icon-overlays.html
>>> )
>>> and
>>> other questions
>>> <
>>> http://stackoverflow.com/questions/4775020/icon-overlay-issue-with-python#
>>> >
>>> on
>>> Stack Overflow I have a script that will show overlays on files
>>> and
>>> folders based on their "state" similar to Tortoise SVN or
>>> Dropbox. Works
>>> great.
>>>
>>> My problem is that once I restart the explorer.exe process or
>>> the OS
>>> itself and open explorer there are no longer any overlays.
>>>
>>> My first thought:
>>>
>>>   * Have the service that actually manages file state detect
>>> that 

[python-win32] Calling unregistered COM libraries via Python

[Manowitz, David]

Is it possible, either via the win32com extensions or the comtypes package (or 
some other package), to call to an unregistered COM library?  It doesn't seem 
so, but I wanted to check.

Thanks,
David Manowitz
Office of Petroleum, Natural Gas, and Biofuels Analysis
Energy Information Administration
U.S. Department of Energy
1000 Independence Ave S.W.
Washington, DC 20585
Tel: +1-202-586-2815

___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Calling unregistered COM libraries via Python

[Manowitz, David]

Since I knew the path to the library, I wasn't sure if that was the case, but I 
guess so.

--David



 Original message 
From: Mark Hammond 
Date: 1/11/2016 5:55 PM (GMT-05:00)
To: "Manowitz, David" , 
"'comtypes-us...@lists.sourceforge.net'" 
, "'python-win32@python.org'" 

Subject: Re: [python-win32] Calling unregistered COM libraries via Python

On 12/01/2016 4:21 AM, Manowitz, David wrote:
> Is it possible, either via the win32com extensions or the comtypes
> package (or some other package), to call to an unregistered COM
> library?  It doesn’t seem so, but I wanted to check.

COM uses the registration info to locate and load the library, so in
general it's not possible. You could always just register it though...

Mark

>
>
>
> Thanks,
>
> David Manowitz
>
> Office of Petroleum, Natural Gas, and Biofuels Analysis
>
> Energy Information Administration 
>
> U.S. Department of Energy
>
> 1000 Independence Ave S.W.
>
> Washington, DC 20585
>
> Tel: +1-202-586-2815
>
>
>
>
>
> ___
> python-win32 mailing list
> python-win32@python.org
> https://mail.python.org/mailman/listinfo/python-win32
>

___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] [ANN] pywin32 build 220 released.

[Mark Hammond]

Hi all,
  I'm happy to announce the release of pywin32 build 220.  This release 
has addressed a number of bugs with previous builds (most notably 
failure to install in Python 3.5) and has added a few new features - 
I've appended the change log at the end of this mail.


Downloads are available at:

  https://sourceforge.net/projects/pywin32/files/pywin32/Build%20220/

For initial support (eg, to ask questions about the release etc), please 
contact this mailing-list (python-win32@python.org).  If you want to 
report a bug, please do so at https://sf.net/projects/pywin32.


As always, thanks to everyone who contributed to this release, both in 
terms of code and reporting bugs to the tracker.  As usual, Roger Upole 
contributed a huge number of fixes and enhancements for this release - 
thanks!


(Regarding SourceForge - I'm hoping to start a discussion soon about 
moving away from their platform due to some high-profile issues with 
their site. Given Python itself is moving to github in the future, it 
may make sense to move pywin32 there too. But in the interests of 
getting a build out that works with Python 3.5, I decided to stick with 
SourceForge for now. If your browser or adblocker reports the site as 
malicious, then you probably need to add an exception)


Cheers,

Mark

Changes:

Since build 219:

* win32com - sys.argv[0] may be set to a bytes object instead of a
  string on Python 3 when implementing an in-process COM object.

* Fix that allows a property to be fetched on COM objects to work in
  more cases (Fredrik Orderud via patch #155)

* Disabled exchange and exchdapi modules on Python 2.5 due to unresolved
  build issues.

* Fix potential crash in SHGetIDListFromObject and SHGetFileInfo issues
  (rupole)

* Allow GetShortPathName to handle long paths in unicode mode (ruple)

* Fix intermittent crash in win32cred.CredRead() (bug #670, rupole)

* Support PT_MV_BINARY MAPI properties, (patch #37) and many other MAPI
  improvements (Nick Czeczulin)

* Fix username used with EvtOpenSession (bug #688, rupole)

* Fix OutputDebugString encoding in wide builds (patch #142, rupole)
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] looking for testers

[Ulli Horlacher]

I have written a Python client for F*EX(*). It is designed for Windows
users, though it runs on UNIX, too. I am now looking for testers. If you
are interested, I will give you an account. 


(*) Frams' Fast File EXchange is a service to send files of any size to
any user anywhere in the internet: 
http://fex.rus.uni-stuttgart.de:8080/index.html

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum IZUS/TIK E-Mail: horlac...@tik.uni-stuttgart.de
Universitaet Stuttgart Tel:++49-711-68565868
Allmandring 30aFax:++49-711-682357
70550 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20160112074628.ga28...@rus.uni-stuttgart.de>
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32