From sakoosh@uark.edu  Thu Feb  7 21:37:03 2002
From: sakoosh@uark.edu (Sayed A. Kooshesh)
Date: Thu, 7 Feb 2002 15:37:03 -0600
Subject: [python-win32] Help Excel Python Setting the Active Worksheet
Message-ID: <KAELKMKOKGCCOFGFCNHBCEKFCBAA.sakoosh@uark.edu>

Hi again,
I can't seem to find the object that will set the active worksheet. 

xl.ActiveWorkSheet is readonly

any ideas?
thanks
-Ari

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What's the difference between fate and destiny?

Your destiny is determined by your actions. 
Your fate is determined by your destiny. 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 


From kwa@crf-vogler.com  Fri Feb  8 13:23:22 2002
From: kwa@crf-vogler.com (Frank Jacques)
Date: Fri, 08 Feb 2002 14:23:22 +0100
Subject: [python-win32] Help Excel Python Setting the Active Worksheet
References: <KAELKMKOKGCCOFGFCNHBCEKFCBAA.sakoosh@uark.edu>
Message-ID: <3C63D14A.6ABB00D9@crf-vogler.com>

Hi,

You've got to use the Activate Method:
xl.Worksheets("Sheet1").Activate()

Good luck,
Frank



"Sayed A. Kooshesh" wrote:

> Hi again,
> I can't seem to find the object that will set the active worksheet.
>
> xl.ActiveWorkSheet is readonly
>
> any ideas?
> thanks
> -Ari
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> What's the difference between fate and destiny?
>
> Your destiny is determined by your actions.
> Your fate is determined by your destiny.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> Python-win32 mailing list
> Python-win32@python.org
> http://mail.python.org/mailman/listinfo/python-win32



From noah@sfbags.com  Thu Feb 14 01:29:35 2002
From: noah@sfbags.com (Noah Spurrier)
Date: Wed, 13 Feb 2002 17:29:35 -0800
Subject: [python-win32] Calling Python from Access forms
Message-ID: <CDEMJIJCPELOLONMFIKGGEJNCDAA.noah@sfbags.com>


I have no problem creating Python apps that create COM objects to work with Access database, but
right now I have to run an external application to process the data in my Access tables.
I want to be able to call Python FROM Access and not call Access from Python.
I would like to be able to click a button on an Access form and have the Python script run.
Can Python be setup as a scripting language from within Access? Can modules contain Python code
instead of VBA? It would be cool to be able to use Python instead of VBA right inside of Access.

Yours,
Noah


From mjw@pearson.co.uk  Fri Feb 15 18:29:17 2002
From: mjw@pearson.co.uk (Matthew Woodcraft)
Date: Fri, 15 Feb 2002 18:29:17 -0000
Subject: [python-win32] Invoking methods from different COM interfaces
Message-ID: <009401c1b64e$ada9df60$0674c10a@mill.pearson.co.uk>

I have used makepy to build a type library for 'Microsoft XML, v3.0
(3.0)'. Now I've done this, I find that some of the DOM methods, eg
'createNode', return values of type
<win32com.gen_py.Microsoft XML, v3.0.IXMLDOMNode>.

In some cases, I know that the COM object returned also supports the
IXMLDOMElement interface - but Python raises an exception if I try to
invoke methods of this interface directly.

Is there a way to 'cast' the object to one representing an
IXMLDOMElement, or otherwise invoke the methods of IXMLDOMElement, from
Python?

If I don't build the Python type library, the objects I get from methods
like createNode have types like <COMObject createNode>, and happily let
me invoke methods of both IXMLDOMNode and IXMLDOMElement.


Example:

import win32com.client
doc = win32com.client.Dispatch("Msxml2.DOMDocument")
NODE_ELEMENT = 1
NAMESPACE_URI = "http://foo.invalid/"
el_a = doc.createNode(NODE_ELEMENT, "el-a", NAMESPACE_URI)
print el_a.tagName


Without building a type library, this works. With a type library, I get
AttributeError for the last line.

In most cases, I can work around this. But it seems like there ought to
be a way to choose from the different interfaces supported by a COM
object. What am I missing?

I am using Python 2.1 from PythonLabs, and the corresponding win32all
supplied by ActiveState.

-M-





From me@mikerobin.com  Mon Feb 18 22:33:23 2002
From: me@mikerobin.com (Michael Robin)
Date: Mon, 18 Feb 2002 14:33:23 -0800
Subject: [python-win32] MsgWaitForMultipleObjects timeout
Message-ID: <DHEEKAFNPOKNEBEBLCIAOEMHCHAA.me@mikerobin.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0055_01C1B889.3853F060
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


I'm having the problem of getting a timeout every
200 ms or so, no matter what I use as the timeout
argument for MsgWaitForMultipleObjects. Anyone see 
a problem here? Can someone
else run this and see if they get the same results?

thanks,
mike

---------------------------------

import win32event
import pythoncom
import time

def messagePump():
	timeout = win32event.INFINITE
	event = win32event.CreateEvent(None, 0, 0, None)
		
	while 1:
		start = time.time()
		
		rc = win32event.MsgWaitForMultipleObjects(
			(event,), 
			0, # wait all
			win32event.QS_ALLEVENTS, 
			timeout) 
			
		if rc == win32event.WAIT_TIMEOUT:
			print "messageloop: Timeout %d" % int(1000 *
(time.time() - start))
	
if __name__ == '__main__':
	messagePump()


------=_NextPart_000_0055_01C1B889.3853F060
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IhcWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgASAA4AIQAAAAEAHQEB
A5AGAEgGAAAjAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMANgAA
AAAAHgBwAAEAAAAiAAAATXNnV2FpdEZvck11bHRpcGxlT2JqZWN0cyB0aW1lb3V0AAAAAgFxAAEA
AAAWAAAAAcG4zEYdf3FK3kx8Qp2w3MacDZranwAAAgEdDAEAAAAWAAAAU01UUDpNRUBNSUtFUk9C
SU4uQ09NAAAACwABDgAAAABAAAYOAHZFOMy4wQECAQoOAQAAABgAAAAAAAAA7ChsRurGN0SgXRKF
LQdYRsKAAAALAB8OAQAAAAIBCRABAAAAjQIAAIkCAAB7BAAATFpGdZNUbSUDAAoAcmNwZzEyNRYy
APgLYG4OEDAzM08B9wKkA+MCAGNoCsBzsGV0MCAHEwKAfQqBknYIkHdrC4BkNAxgPmMAUAsDC7YK
sQqASSccbSAQ8BIgDyAgdGhYZSBwA2ACYGUUQG+oZiBnETB0FJJhFMCnB3EIYAVAZXYEkHkTxBsB
0BFQbQQgBbFzbyxoIG5vF8BhAkAEkCDGdxDwBUBJIHURIBYwnwQgFNIWZRPECsBndQeAjQIwIAIQ
BcFzZ1cLcMR0RgWwTXVsFfALUBBlT2JqBZB0cy75EWBueQIgFPARIBTwGqXHFQcU4AlwPyBDA5EY
MCcWgR3AE8RlbBmRcnX/A6AU0AQAFjASgB3jBpAUwuZ5FbIUw3NhB4Ag4AeQeRyBcz8TxBPEFNAA
cGvEcywTxG1payA1E8TeLSZvJ20j2gdwcAkRGQA5C4AzMhbhAjAo23B59xTQAiAFoG0o2xZiI9oB
AS8XwAeQIwAVwFAbMHAoXCk6I9UBkRZXPSmZLohJTkYwkElURS6ZmynzL7xDCXAYsGVFKgJsKE4d
sRhQMDPzM7Ipvy6YDIMuqBkQAxAU8DEuib0u83MBkClxL8AWYi4WYucuYDTPNwpyYy+8G98c5pYo
OP0vAigp8ywpGFB3PW8vIDQRIxkAPAEWMGwHCVA/Ty/aUVNfQUyATEVWRU5UUz8ffS8JKUPvOb8i
ATrCL8tXAkEw4F9USU1FT3xVVDbNLvMVEAuABUAiwy21CQBvcDogB2IWovglZCJMsCHwM4EPQBeh
pio+gDhJIC03tCk46uMo5BWgX19uIxFQYEgS3idQYADAC4BQYCcuii27LyPYCzET4hHhAFSgAAAA
CwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAQ
hQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgAJgAggBgAAAAAAwAAAAAAA
AEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwA6
gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADyACCAGAAAAAADAAAAAAAAARgAAAAARhQAA
AAAAAAMAPYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwBSgAggBgAAAAAAwAAAAAAAAEYA
AAAABoUAAAAAAAADAFOACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAIB+A8BAAAAEAAAAOwo
bEbqxjdEoF0ShS0HWEYCAfoPAQAAABAAAADsKGxG6sY3RKBdEoUtB1hGAgH7DwEAAABUAAAAAAAA
ADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAYzpc
bWlrZXJvXERhdGFcb3V0bG9vay5wc3QAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMAAAADxESEVF
S0FGTlBPS05FQkVCTENJQU9FTUhDSEFBLm1lQG1pa2Vyb2Jpbi5jb20+AAMABhCXGJbfAwAHEEMC
AAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASU1IQVZJTkdUSEVQUk9CTEVNT0ZHRVRUSU5H
QVRJTUVPVVRFVkVSWTIwME1TT1JTTyxOT01BVFRFUldIQVRJVVNFQVNUSEVUSU1FT1VUQVJHVU1F
TlRGT1JNU0dXQUlURk9STQAAAADxdg==

------=_NextPart_000_0055_01C1B889.3853F060--



From me@mikerobin.com  Wed Feb 20 18:24:36 2002
From: me@mikerobin.com (Michael Robin)
Date: Wed, 20 Feb 2002 10:24:36 -0800
Subject: [python-win32] MsgWaitForMultipleObjects timeout
In-Reply-To: <3C728F92.2C93ACE0@noaa.gov>
Message-ID: <DHEEKAFNPOKNEBEBLCIAIENMCHAA.me@mikerobin.com>

I originally got my code from timer_demo.py included in ..\win32com\test.
It looks like the argument order does not match TestMarshal.py (same place)
and SingleThreadedApartment, below.

# Timer_demo.py:
# This module, and the timer.pyd core timer support, were written by
# Sam Rushing (rushing@nightmare.com)
		rc = win32event.MsgWaitForMultipleObjects(
			(g.event,), # list of objects
			0, # wait all
			win32event.QS_ALLEVENTS, # type of input
			500) # timeout

# TestMarshal.py
		rc = win32event.MsgWaitForMultipleObjects(events, 0, 2000,
win32event.QS_ALLINPUT)

The correct (win32) order agrees with the latter. (I should have realized
this
as I've used the call from C in the past.)
Given that win32event.QS_ALLEVENTS == 191, the behavior I observed
makes sense.

It looks like timer_demo.py needs to be fixed.

This looks like one of those cases that pychecker (or even C) wouldn't
be able to see and that is hard to see in testing as well.
(In this case, the difference between 500 and 191ms timeout,
and the fact the ersatz message mask happened to work out.)

mike



-----Original Message-----
From: Jim Vickroy [mailto:Jim.Vickroy@noaa.gov]
Sent: Tuesday, February 19, 2002 9:47 AM
To: Michael Robin
Subject: Re: [python-win32] MsgWaitForMultipleObjects timeout


You are welcome.

I've done a brief search, and here is sample code from "Python Programming
on
Win32" by Hammond and Robinson.

Note, the comment:
        # A quirk in MsgWaitForMultipleObjects means we must wait
        # for each event one at at time

Let me know if this helps.


# begin
script ---------------------------------------------------------------
# SingleThreadedApartment.py
# Demonstrate the use of multiple threads, each in their own
# single-threaded apartment.

# As we do not set sys.coinit_flags=0
# before the Pythoncom import, Python
# initializes the main thread for single threading.
from pythoncom import \
     CoInitialize, CoUninitialize, IID_IDispatch,\
     CoMarshalInterThreadInterfaceInStream, \
     CoGetInterfaceAndReleaseStream, \
     PumpWaitingMessages

from win32event import \
     MsgWaitForMultipleObjects, \
     QS_ALLINPUT, WAIT_TIMEOUT, WAIT_OBJECT_0

from win32com.client import Dispatch
from win32process import beginthreadex
from win32api import GetCurrentThreadId

def Demo( prog_id ):
    # First create the object
    object = Dispatch(prog_id)
    print "Thread", GetCurrentThreadId(), "creating object"
    created_id = object.GetCreatedThreadId()
    print "Object reports it was created on thread", created_id
    # Now create the threads, remembering the handles.
    handles = []
    for i in range(3):
        # As we are not allowed to pass the object directly between
        # apartments, we need to marshal it.
        object_stream = CoMarshalInterThreadInterfaceInStream(
                          IID_IDispatch, object )
        # Build an argument tuple for the thread.
        args = (object_stream,)
        handle, id = beginthreadex(None, 0, WorkerThread, args, 0)
        handles.append(handle)
    # Now we have all the threads running, wait for them to terminate.
    # also remember how many times we are asked to pump messages.
    num_pumps = 0
    while handles:
        # A quirk in MsgWaitForMultipleObjects means we must wait
        # for each event one at at time
        rc = MsgWaitForMultipleObjects(handles, 0, 5000, QS_ALLINPUT)
        if rc >= WAIT_OBJECT_0 and rc < WAIT_OBJECT_0+len(handles):
            # A thread finished - remove its handle.
            del handles[rc-WAIT_OBJECT_0]
        elif rc==WAIT_OBJECT_0 + len(handles):
            # Waiting message
            num_pumps = num_pumps + 1
            PumpWaitingMessages()
        else:
            print "Nothing seems to be happening",
            print "but I will keep waiting anyway..."
    print "Pumped messages", num_pumps, "times"
    print "Demo of", prog_id, "finished."

def WorkerThread(object_stream):
    # First step - initialize COM
    CoInitialize() # Single-threaded.
    # Unmarshal the IDispatch object.
    object = CoGetInterfaceAndReleaseStream(
        object_stream, IID_IDispatch)
    # The object we get back is a PyIDispatch, rather
    # than a friendly Dispatch instance, so we convert
    # to a usable object.
    object = Dispatch(object)
    this_id = GetCurrentThreadId()
    that_id = object.GetCurrentThreadId()
    message = "Thread is %d, and object is on thread %d" % \
                                     (this_id, that_id)
    print message
    # Be a good citizen and finalize COM, but
    # first remove our object references.
    object = None
    CoUninitialize()

if __name__=='__main__':
    print "Running with Apartment Threaded object"
    Demo("PythonThreadDemo.Apartment")
    print
    print "Running with Free Threaded object"
    Demo("PythonThreadDemo.Free")
# end script ---------------------------------------------------------------



Michael Robin wrote:

> Thanks for trying - i'll
> send out any solutions I find...
>
> m
>
> -----Original Message-----
> From: Jim Vickroy [mailto:Jim.Vickroy@noaa.gov]
> Sent: Tuesday, February 19, 2002 8:40 AM
> To: Michael Robin
> Subject: Re: [python-win32] MsgWaitForMultipleObjects timeout
>
> Hello Mike,
>
> I have just run your script with Python 2.2 on a Win 2k machine with the
> same
> result you reported.  Setting timeout=5000 seemed to have no effect
either.
> I
> have never used this type of code so I do not understand the behavior
> either.
>
> Michael Robin wrote:
>
> > I'm having the problem of getting a timeout every
> > 200 ms or so, no matter what I use as the timeout
> > argument for MsgWaitForMultipleObjects. Anyone see
> > a problem here? Can someone
> > else run this and see if they get the same results?
> >
> > thanks,
> > mike
> >
> > ---------------------------------
> >
> > import win32event
> > import pythoncom
> > import time
> >
> > def messagePump():
> >         timeout = win32event.INFINITE
> >         event = win32event.CreateEvent(None, 0, 0, None)
> >
> >         while 1:
> >                 start = time.time()
> >
> >                 rc = win32event.MsgWaitForMultipleObjects(
> >                         (event,),
> >                         0, # wait all
> >                         win32event.QS_ALLEVENTS,
> >                         timeout)
> >
> >                 if rc == win32event.WAIT_TIMEOUT:
> >                         print "messageloop: Timeout %d" % int(1000 *
> > (time.time() - start))
> >
> > if __name__ == '__main__':
> >         messagePump()
> >
>
  ------------------------------------------------------------------------
> >                   Name: winmail.dat
> >    winmail.dat    Type: application/ms-tnef
> >               Encoding: base64




From brianb1185@yahoo.co.uk  Sun Feb 24 17:12:45 2002
From: brianb1185@yahoo.co.uk (=?iso-8859-1?q?Brian=20B?=)
Date: Sun, 24 Feb 2002 17:12:45 +0000 (GMT)
Subject: [python-win32] Win32 Com extensions, universal gateways
Message-ID: <20020224171245.875.qmail@web21303.mail.yahoo.com>

Hi,

how do I run test_PyCOMTest?

I get an error when running the server to register it:

============================
D:\Python22\lib\site-packages\win32com\universal.py:15:
UserWarning: win32com.un
iversal is a very new module - it probably has bugs,
and the interface may chang
e in the future.  Use at your own risk!
  warnings.warn(msg)
Traceback (most recent call last):
  File
"D:\Python22\Lib\site-packages\win32com\servers\test_pycomtest.py",
line
13, in ?
   
universal.RegisterInterfaces('{6BCDCB60-5605-11D0-AE5F-CADD4C000000}',
0, 1,
 1, ["IPyCOMTest"])
  File
"D:\Python22\lib\site-packages\win32com\universal.py",
line 29, in Regist
erInterfaces
    tlb = pythoncom.LoadRegTypeLib(typelibGUID, major,
minor, lcid)
pywintypes.com_error: (-2147319779, 'Library not
registered.', None, None)
============================


Then when running the test program, I get an error,
but perhaps not what I would expect, ie:


The PyCOMTest module can not be located or generated.
**** PyCOMTest is not installed ***
  PyCOMTest is a Python test specific COM client and
server.
  It is likely this server is not installed on this
machine
  To install the server, you must get the win32com
sources
  and build it using MS Visual C++
Traceback (most recent call last):
  File
"D:\Python22\Lib\site-packages\win32com\test\testPyComTest.py",
line 23,
in ?
    raise RuntimeError, importMsg
RuntimeError: **** PyCOMTest is not installed ***
  PyCOMTest is a Python test specific COM client and
server.
  It is likely this server is not installed on this
machine
  To install the server, you must get the win32com
sources
  and build it using MS Visual C++


Do I have to run makepy on something to register the
test server typelib, if so what?


best regards,

Brian.



__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


From mhammond@skippinet.com.au  Mon Feb 25 02:09:37 2002
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Mon, 25 Feb 2002 13:09:37 +1100
Subject: [python-win32] Win32 Com extensions, universal gateways
In-Reply-To: <20020224171245.875.qmail@web21303.mail.yahoo.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPKECIFDAA.mhammond@skippinet.com.au>

test_pycomtest requires a VB built test DLL.  You will need to clone it, and
change it according to the type library and interface you wish to implement.

Mark.

> -----Original Message-----
> From: python-win32-admin@python.org
> [mailto:python-win32-admin@python.org]On Behalf Of Brian B
> Sent: Monday, 25 February 2002 4:13 AM
> To: python-win32@python.org
> Subject: [python-win32] Win32 Com extensions, universal gateways
>
>
>
> Hi,
>
> how do I run test_PyCOMTest?
>
> I get an error when running the server to register it:
>
> ============================
> D:\Python22\lib\site-packages\win32com\universal.py:15:
> UserWarning: win32com.un
> iversal is a very new module - it probably has bugs,
> and the interface may chang
> e in the future.  Use at your own risk!
>   warnings.warn(msg)
> Traceback (most recent call last):
>   File
> "D:\Python22\Lib\site-packages\win32com\servers\test_pycomtest.py",
> line
> 13, in ?
>
> universal.RegisterInterfaces('{6BCDCB60-5605-11D0-AE5F-CADD4C000000}',
> 0, 1,
>  1, ["IPyCOMTest"])
>   File
> "D:\Python22\lib\site-packages\win32com\universal.py",
> line 29, in Regist
> erInterfaces
>     tlb = pythoncom.LoadRegTypeLib(typelibGUID, major,
> minor, lcid)
> pywintypes.com_error: (-2147319779, 'Library not
> registered.', None, None)
> ============================
>
>
> Then when running the test program, I get an error,
> but perhaps not what I would expect, ie:
>
>
> The PyCOMTest module can not be located or generated.
> **** PyCOMTest is not installed ***
>   PyCOMTest is a Python test specific COM client and
> server.
>   It is likely this server is not installed on this
> machine
>   To install the server, you must get the win32com
> sources
>   and build it using MS Visual C++
> Traceback (most recent call last):
>   File
> "D:\Python22\Lib\site-packages\win32com\test\testPyComTest.py",
> line 23,
> in ?
>     raise RuntimeError, importMsg
> RuntimeError: **** PyCOMTest is not installed ***
>   PyCOMTest is a Python test specific COM client and
> server.
>   It is likely this server is not installed on this
> machine
>   To install the server, you must get the win32com
> sources
>   and build it using MS Visual C++
>
>
> Do I have to run makepy on something to register the
> test server typelib, if so what?
>
>
> best regards,
>
> Brian.
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
> _______________________________________________
> Python-win32 mailing list
> Python-win32@python.org
> http://mail.python.org/mailman/listinfo/python-win32



From noah@sfbags.com  Wed Feb 27 21:21:13 2002
From: noah@sfbags.com (Noah Spurrier)
Date: Wed, 27 Feb 2002 13:21:13 -0800
Subject: [python-win32] COM Server won't go away!
Message-ID: <CDEMJIJCPELOLONMFIKGEENGCEAA.noah@sfbags.com>

I created a server and registered it OK. I called it from a VisualBasic client. OK. It worked.
Then I unregistered it. Tested VB client again and it failed to find the server. OK. That was expected.

Next I modified the source of the Python server and saved it and registered it.
When I tested it from VB again it was running the OLD version. 

I thought maybe it was running from an old .pyc file, but I could not find any .pyc files around.
So then I changed the GUID (_reg_clsid_). I test again and it still runs the old copy.
So then I changed the GUID and I changed ProgramID and I have the VB client create the object with the new name.
It STILL runs the old copy!

Finally, I rename the Python source filename for the server source.
This time the VB Client FINALLY runs the new version.

So the question is, where was VB finding this crusty old copy of the server?
Was it cached in memory somehow? And why would it be tied to the Python source file name?

Is this a common problem? I couldn't find any references to this in a FAQ in the mailing list archives.

Yours,
Noah



From sakoosh@uark.edu  Wed Feb 27 19:41:38 2002
From: sakoosh@uark.edu (Sayed A. Kooshesh)
Date: Wed, 27 Feb 2002 13:41:38 -0600
Subject: [python-win32] RE: python excel
In-Reply-To: <F666B26E8EF5B84C88E3DF34E5A1E49CF07FD5@venus.exolink.com>
Message-ID: <KAELKMKOKGCCOFGFCNHBOEOBCBAA.sakoosh@uark.edu>

yeah,
no problem
but you should really submit this to the list next time, I'm a newbie at
this

###start code
xl=win32com.client.Dispatch("Excel.Application")  #call the Excel object
wb=xl.Workbooks.Open(file,0) #replace file with the excel file
sh=wb.Worksheets(1) #open the appropriate worksheet
sh.Shapes.AddPicture(imagefile,0,1,541.5,92.25,192.75,180)  #replace image
file with the image

#the arguments go like this:
#imagefile - the location of the image file
#I'm not totally sure, but I believe in some versions of excel, the image
file has to be in bitmap
#format...
#linktofile - 0 for no, 1 for yes
#savewithdocument - 0 for no, 1 for yes
#left - how far from the left of the window
#top - how far from the top of the window
#width - image width
#height - image height




### end code
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What's the difference between fate and destiny?

Your destiny is determined by your actions.
Your fate is determined by your destiny.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-----Original Message-----
From: James Strater [mailto:James.Strater@exolink.com]
Sent: Wednesday, February 27, 2002 1:39 PM
To: 'sakoosh@uark.edu'
Subject: python excel


I saw a message from you on a python newsgroup.

I am trying to take a jpg file and insert it into an excel spreadsheet as a
picture object using python.  Do you have some code you might share?

Thanks so much,

James



From mhammond@skippinet.com.au  Thu Feb 28 00:40:51 2002
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Thu, 28 Feb 2002 11:40:51 +1100
Subject: [python-win32] COM Server won't go away!
In-Reply-To: <CDEMJIJCPELOLONMFIKGEENGCEAA.noah@sfbags.com>
Message-ID: <LCEPIIGDJPKCOIHOBJEPMEHGFDAA.mhammond@skippinet.com.au>

Python itself has been loaded into the VB designer process.  When you start
your test program, it is still running inside the VB environment.

If you were really keen, you could have your program use the
Python.Interpreter COM object, and attempt to import then reload your module
by name.  The reload should then force any subsequent creations of your
object to use the new module.

Mark.

> -----Original Message-----
> From: python-win32-admin@python.org
> [mailto:python-win32-admin@python.org]On Behalf Of Noah Spurrier
> Sent: Thursday, 28 February 2002 8:21 AM
> To: python-win32@python.org
> Subject: [python-win32] COM Server won't go away!
>
>
>
> I created a server and registered it OK. I called it from a
> VisualBasic client. OK. It worked.
> Then I unregistered it. Tested VB client again and it failed to
> find the server. OK. That was expected.
>
> Next I modified the source of the Python server and saved it and
> registered it.
> When I tested it from VB again it was running the OLD version.
>
> I thought maybe it was running from an old .pyc file, but I could
> not find any .pyc files around.
> So then I changed the GUID (_reg_clsid_). I test again and it
> still runs the old copy.
> So then I changed the GUID and I changed ProgramID and I have the
> VB client create the object with the new name.
> It STILL runs the old copy!
>
> Finally, I rename the Python source filename for the server source.
> This time the VB Client FINALLY runs the new version.
>
> So the question is, where was VB finding this crusty old copy of
> the server?
> Was it cached in memory somehow? And why would it be tied to the
> Python source file name?
>
> Is this a common problem? I couldn't find any references to this
> in a FAQ in the mailing list archives.
>
> Yours,
> Noah
>
>
> _______________________________________________
> Python-win32 mailing list
> Python-win32@python.org
> http://mail.python.org/mailman/listinfo/python-win32
>



From noah@sfbags.com  Thu Feb 28 01:48:06 2002
From: noah@sfbags.com (Noah Spurrier)
Date: Wed, 27 Feb 2002 17:48:06 -0800
Subject: [python-win32] COM Server won't go away!
In-Reply-To: <LCEPIIGDJPKCOIHOBJEPMEHGFDAA.mhammond@skippinet.com.au>
Message-ID: <CDEMJIJCPELOLONMFIKGAENJCEAA.noah@sfbags.com>

Ah, yes, this is evident because the problem goes away if 
I shut down VB and restart it again. Kind of a crappy, but at
least it's easy to do and it makes sense.

I thought that setting my Python COM object reference to "Nothing"
(VB Equivalent of None) that it would unload the object, but no such luck...

Yours,
Noah

> -----Original Message-----
> From: python-win32-admin@python.org
> [mailto:python-win32-admin@python.org]On Behalf Of Mark Hammond
> Sent: Wednesday, February 27, 2002 4:41 PM
> To: noah@sfbags.com
> Cc: python-win32@python.org
> Subject: RE: [python-win32] COM Server won't go away!
> 
> 
> Python itself has been loaded into the VB designer process.  When you start
> your test program, it is still running inside the VB environment.
> 
> If you were really keen, you could have your program use the
> Python.Interpreter COM object, and attempt to import then reload your module
> by name.  The reload should then force any subsequent creations of your
> object to use the new module.
> 
> Mark.
> 
> > -----Original Message-----
> > From: python-win32-admin@python.org
> > [mailto:python-win32-admin@python.org]On Behalf Of Noah Spurrier
> > Sent: Thursday, 28 February 2002 8:21 AM
> > To: python-win32@python.org
> > Subject: [python-win32] COM Server won't go away!
> >
> >
> >
> > I created a server and registered it OK. I called it from a
> > VisualBasic client. OK. It worked.
> > Then I unregistered it. Tested VB client again and it failed to
> > find the server. OK. That was expected.
> >
> > Next I modified the source of the Python server and saved it and
> > registered it.
> > When I tested it from VB again it was running the OLD version.
> >
> > I thought maybe it was running from an old .pyc file, but I could
> > not find any .pyc files around.
> > So then I changed the GUID (_reg_clsid_). I test again and it
> > still runs the old copy.
> > So then I changed the GUID and I changed ProgramID and I have the
> > VB client create the object with the new name.
> > It STILL runs the old copy!
> >
> > Finally, I rename the Python source filename for the server source.
> > This time the VB Client FINALLY runs the new version.
> >
> > So the question is, where was VB finding this crusty old copy of
> > the server?
> > Was it cached in memory somehow? And why would it be tied to the
> > Python source file name?
> >
> > Is this a common problem? I couldn't find any references to this
> > in a FAQ in the mailing list archives.
> >
> > Yours,
> > Noah
> >
> >
> > _______________________________________________
> > Python-win32 mailing list
> > Python-win32@python.org
> > http://mail.python.org/mailman/listinfo/python-win32
> >
> 
> 
> _______________________________________________
> Python-win32 mailing list
> Python-win32@python.org
> http://mail.python.org/mailman/listinfo/python-win32
>