From bruce_dodson at hotmail.com Thu Apr 1 10:37:17 2004 From: bruce_dodson at hotmail.com (Bruce Dodson) Date: Thu Apr 1 10:37:22 2004 Subject: [Python.NET] Fixes for interface inheritance and abstract properties. References:

Message-ID: Problem 1 can also be seen on ADODB.Connection. It is not specific to COM, though: Interface ICollection inherits from IEnumerable. In C#, if I declare a variable as ICollection, I'll see GetEnumerator. In Python, if I cast to ICollection, I do not see GetEnumerator. I think this is because interface inheritence is a different animal than class inheritance. It seems to be more contractual than structural. I sent a workaround to Brian. The fix is probably not the best way of doing it, and is probably not complete, but it does seem to help. - I noticed as well that properties on interfaces don't work, e.g. I have to call get_Count() rather than just accessing the Count property. from CLR.System.Collections import Hashtable, ICollection ht = Hashtable() c = ICollection(ht) print c.Count #fails A fix for this is also sent to Brian. Bruce From pythonista at sbcglobal.net Fri Apr 9 22:33:43 2004 From: pythonista at sbcglobal.net (Brian Almond) Date: Fri Apr 9 22:33:47 2004 Subject: [Python.NET] CLR + wxPython + OLE initialization Message-ID: <20040410023343.15757.qmail@web80009.mail.yahoo.com> Today I found that in my wxPython apps, adding a CLR import at the top of the files causes wxPython's mainloop to generate a warning message box which reads "Could not initialize OLE". Otherwise, the application seemed functional. I experimented with it, and it seems that delaying CLR-related imports until after the wx Mainloop has started does the trick. Here's a tiny wxPython app that demonstrates the error: import wx #import CLR class MyApp(wx.App): def OnInit(self): # global CLR # import CLR self.frame = wx.Frame(None, -1, 'Test Window') self.frame.Show(True) return True app = MyApp(0) app.MainLoop() If you uncomment the first comment, the application window will open, and an OleInitialize failure message will pop up. If you instead uncomment the second two comments, the application window will open without error. (Note: this was with the latest wxPython build, 2.5.1.5 - I assume similar failures occur with older builds.) It's not a big deal to move the imports, but it's a little unnatural to me. Is this something that's broken in Python for .NET, or .NET, or... Here's a possibly related message I found on wx-users: http://lists.wxwidgets.org/archive/wx-users/msg30069.html From brian at zope.com Sat Apr 10 23:31:59 2004 From: brian at zope.com (Brian Lloyd) Date: Sat Apr 10 23:32:41 2004 Subject: [Python.NET] CLR + wxPython + OLE initialization In-Reply-To: <20040410023343.15757.qmail@web80009.mail.yahoo.com> Message-ID: > Today I found that in my wxPython apps, adding a CLR > import at the top of the files causes wxPython's > mainloop to generate a warning message box which reads > "Could not initialize OLE". Otherwise, the > application seemed functional. I experimented with > it, and it seems that delaying CLR-related imports > until after the wx Mainloop has started does the > trick. > > It's late, so forgive any errors in the details, but... This has to do with Deep Voodoo (tm) regarding the CLR and COM compartment initialization. Essentially, whenever you use interop (marshalling to/from native code, etc.), the CLR will have made sure that the process has been initialized to some COM apartment state. Because Python for .NET uses interop extensively (to join the managed world with unmanaged CPython), by the time 'import CLR' finishes, you will be in whatever kind of apartment the CLR deems the default. By your report (and my hazy memory), if you import CLR first you are probably getting the thread initialized as MTA, and OleInitialize probably wants the thread to either be uninitialized or initialized to STA. Your workaround is probably as good as any - there is no real way to change the apartment state from Python once its been intialized (without creating a new thread and doing a lot of things by hand, etc.), since either the CLR itself or some specific unmanaged call (like your OleInitialize) will have made the choice already by the time the CLR/Python layer is bootstrapped. Hope this helps! Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From pythonista at sbcglobal.net Fri Apr 16 21:22:14 2004 From: pythonista at sbcglobal.net (Brian Almond) Date: Fri Apr 16 21:22:19 2004 Subject: [Python.NET] Network install Message-ID: <20040417012214.42569.qmail@web80003.mail.yahoo.com> A new puzzle: Today I tried a Python.NET app on a machine that was accessing a Python installed on a network share. I had moved the CLR.dll & Python.Runtime.dll into the same place that I have them on my workstation's Python install. I ended up getting an error every time I tried to import the CLR module. For kicks, I copied all of the Python.NET files to a network folder and tried using it (in this case, simply trying to run python.exe), and I receive: Unhandled Exception: System.Security.Policy.PolicyException: Required permissions cannot be acquired. at PythonConsole.Main(String[] args) Any idea on why Python for .NET would get frisky on a Novell share? Help me out here, I suspect I'm overlooking something super obvious...it's been a long week! -BA From pythonista at sbcglobal.net Sun Apr 18 21:03:20 2004 From: pythonista at sbcglobal.net (Brian Almond) Date: Sun Apr 18 21:03:24 2004 Subject: [Python.NET] Network Install - Update Message-ID: <20040419010320.11279.qmail@web80008.mail.yahoo.com> More data: If I'm running Python from a Novell network share volume (that is, no local Python install) and try running a Python.NET script, I receive: Unhandled Exception: System.Security.Policy.PolicyException: Required permissions cannot be acquired. at CLRModule.initCLR() The script I'm running is simply a single line, "import CLR". Any tips from the .NET savvy programmers on the list? (Aside from: "Don't do that." ;) Additionally, I'm having trouble getting McMillan's installer to behave with the CLR imports. Is this something that may get resolved in the next beta? I've seen mention of switching to using the official import hooks in the TODO file in CVS. This sounds like something promising. TIA - It's really remarkable how well Python.NET works, and how simple it is to take C# code and convert it. From brian at zope.com Sun Apr 18 22:36:48 2004 From: brian at zope.com (Brian Lloyd) Date: Sun Apr 18 22:37:29 2004 Subject: [Python.NET] Network Install - Update In-Reply-To: <20040419010320.11279.qmail@web80008.mail.yahoo.com> Message-ID: > If I'm running Python from a Novell network share > volume (that is, no local Python install) and try > running a Python.NET script, I receive: > > Unhandled Exception: > System.Security.Policy.PolicyException: Required > permissions cannot be acquired. > at CLRModule.initCLR() > > The script I'm running is simply a single line, > "import CLR". > > Any tips from the .NET savvy programmers on the list? > (Aside from: "Don't do that." ;) I'm guessing that the Python for .NET runtime dll isn't asserting some permission that is required to run off of the share - I'd appreciate any help from those more clueful than me as to what that permission is... > Additionally, I'm having trouble getting McMillan's > installer to behave with the CLR imports. Is this > something that may get resolved in the next beta? > I've seen mention of switching to using the official > import hooks in the TODO file in CVS. This sounds > like something promising. I've tried everything I can think of (including the new import hooks), but unfortunately there is no good way to take control during the actual import that bootstraps the CLR module. Any subsequent imports are not a problem. I __really__ wanted to make sure that imports would work in a consistent way whether you were running the managed python.exe or importing the CLR module into a stock Python, but that turns out to be a really tough problem, at least for that initial import. I'm not sure if that's related at all to the McMillan installer issue (I'm not familiar with it), just me ranting ;) Can you give me a little more detail on the issue you're seeing? > > TIA - It's really remarkable how well Python.NET > works, and how simple it is to take C# code and > convert it. Thanks! Its good to hear that its useful to people! Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From pythonista at sbcglobal.net Mon Apr 19 00:11:06 2004 From: pythonista at sbcglobal.net (Brian Almond) Date: Mon Apr 19 00:11:09 2004 Subject: [Python.NET] Network Install - Update In-Reply-To: Message-ID: <20040419041106.3863.qmail@web80012.mail.yahoo.com> --- Brian Lloyd wrote: > I'm guessing that the Python for .NET runtime dll > isn't asserting > some permission that is required to run off of the > share - I'd > appreciate any help from those more clueful than me > as to what > that permission is... Turns out the Novell fileshare is, to .NET, part of the "Local Intranet" ... Going to the .NET framework wizards in the control panel and adjusting security of "Local Intranet" to full trust has solved the problem. Woohoo! I solved that after finding a related message on microsoft.public.dotnet.general that clued me in. This means I have to do this on every machine I want to run my app from. Of course, I was going to have to install the .NET framework on all those machines anyway, so no biggie :) I hope this message saves someone else some grief. > > Additionally, I'm having trouble getting > McMillan's > > installer to behave with the CLR imports. Is this > > something that may get resolved in the next beta? [snip] > Can you give > me a little more detail on the issue you're seeing? You mean telling you, "it goes boom!" isn't enough? Actually I need to re-install McMillan's installer and give it another go. IIRC, McMillan's installer does lot of inspection of the source file you give it, and processes imports itself. In my recollection, it tried to import the CLR module and then add attributes to it, choking followed... I'll take another look at it and get back to you as well as its author. Basically, I'm just testing all the deployment options I have if I want to deploy a PythonNet app to a bunch of people. I'll test the network-homed deploy further tomorrow and see if it continues to work OK. From andy at msistone.com Mon Apr 19 02:48:14 2004 From: andy at msistone.com (Andy Shah) Date: Mon Apr 19 02:48:27 2004 Subject: [Python.NET] How do you use PythonNET in a Zope Environment? Message-ID: <20040419064814.38C6A3944@sitemail.everyone.net> How does one use PythonNET in a Zope Environment to access .NET libraries... Can we also use pre-created .NET libraries, which inturn access database servers, the results of which can be shown via ZPT? Kind Regards, Anand. From brian at zope.com Mon Apr 19 13:43:06 2004 From: brian at zope.com (Brian Lloyd) Date: Mon Apr 19 13:43:17 2004 Subject: [Python.NET] How do you use PythonNET in a Zope Environment? In-Reply-To: <20040419064814.38C6A3944@sitemail.everyone.net> Message-ID: > How does one use PythonNET in a Zope Environment to access .NET > libraries... It is mostly an issue of making sure that the CLR modules are on the python path. I'm assuming you're using a windows build of Zope - if so, you should be able to put CLR.dll in the bin/DLLs directory of the Zope install. Python.Runtime.dll will need to either be in the GAC or in the 'application directory' (working directory of the process, which should either be the root of the Zope install or root/bin - sorry I don't recall which one exactly). > Can we also use pre-created .NET libraries, which inturn access > database servers, the results of which can be shown via ZPT? > > Kind Regards, > Anand. Should be no problem. Note that you *will* have a problem if you try to access any STA threaded COM components (directly or indirectly), as they won't play nice with the Zope threads. That's not to say that it can't be done, but you'd need to manage threading issues explicitly, which is different than the normal Zope rythym of not having to worry about threads and just writing code as if its single-threaded. HTH, Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From dart at pobox.com Sun Apr 25 16:24:03 2004 From: dart at pobox.com (Andre Van Der Merwe) Date: Sun Apr 25 16:25:11 2004 Subject: [Python.NET] AxHost & IDispatch Message-ID: Hi all, I've got a python script that I want to create a C# GUI for. I'd like to have a web browser control on the form that I can control from python. This is not too difficult - just drop a WebBrowser control on the form and create a public property to expose the control. The problem is that .net is wrapping the control (AxHost etc) and not all the methods are exposed (e.g. Document.all.tags does not work...) Can I get the control's IDispatch and use late-binding? If so how???? If I cant can I create the activex control from python and 'place' it on a specific form (given a HWND)? Any examples of manually creating and placing a activeX control? Thanks for any advice. Andre From brian at zope.com Sun Apr 25 22:53:37 2004 From: brian at zope.com (Brian Lloyd) Date: Sun Apr 25 22:54:12 2004 Subject: [Python.NET] AxHost & IDispatch In-Reply-To: Message-ID: > I've got a python script that I want to create a C# GUI for. I'd like to > have a web browser control on the form that I can control from > python. This > is not too difficult - just drop a WebBrowser control on the form > and create > a public property to expose the control. > > The problem is that .net is wrapping the control (AxHost etc) and not all > the methods are exposed (e.g. Document.all.tags does not work...) > > Can I get the control's IDispatch and use late-binding? If so how???? > > If I cant can I create the activex control from python and 'place' it on a > specific form (given a HWND)? Any examples of manually creating > and placing > a activeX control? Hi Andre - I'm not a real expert on interop stuff, but I'd suggest running aximp.exe or tlbimp.exe to generate a wrapper assembly from the dll that implements the WebBrowser control. The wrapper assembly should expose everything in a way that Python will be able to use it. Then you should be able to instantiate the control via the wrapper assembly from Python (or from C# for that matter), set it as your control property and drive it from Python. I'm guessing that VStudio.NET is using some kind of shortcut involving a RCW or something when you drop a control onto a form in the gui. Hope this helps! Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From dart at pobox.com Mon Apr 26 09:39:33 2004 From: dart at pobox.com (Andre Van Der Merwe) Date: Mon Apr 26 09:40:38 2004 Subject: [Python.NET] RE: AxHost & IDispatch In-Reply-To: Message-ID: > but I'd suggest running aximp.exe or tlbimp.exe Thanks. This is done automatically by VStudio when importing an ActiveX control. I got around the problem by using the getElementByTag method, which is more w3c compliant anyway... I'm still having a problem though... When I create the form from python using reflection then the first time I access the web browser activeX control there is a long delay (approx 5 seconds). The exact same form does not have any delay when started from the EXE directly. The delay only occurs if I cast the 'browser.Document' object to a HTMLDocument *but* the delay occurs as soon as I call the method, i.e. before the cast. Yet if I take the cast out there is no delay. Very strange! I have included a sample app that demonstrated the problem. Clicking the button when the form is loaded from python will result in a delay before the first messagebox. Any ideas? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: egCode.zip Type: application/octet-stream Size: 6526 bytes Desc: not available Url : http://mail.python.org/pipermail/pythondotnet/attachments/20040426/054c11cd/egCode.obj From bruce_dodson at hotmail.com Thu Apr 29 13:51:20 2004 From: bruce_dodson at hotmail.com (Bruce Dodson) Date: Thu Apr 29 13:51:28 2004 Subject: [Python.NET] Fixes for interface inheritance and abstract properties. References:

Message-ID: I haven't seen anything further on this. If there's anything more that you need from me before these enhancements can be committed, don't hesitate to email me. Bruce From brian at zope.com Thu Apr 29 14:14:06 2004 From: brian at zope.com (Brian Lloyd) Date: Thu Apr 29 14:14:19 2004 Subject: [Python.NET] Fixes for interface inheritance and abstractproperties. In-Reply-To: Message-ID: > I haven't seen anything further on this. If there's anything > more that you > need from me before these enhancements can be committed, don't > hesitate to > email me. > > Bruce Hi Bruce - the only thing I need is time to do it ;) I'm hoping I will get some time this weekend to at least checkin and make unit tests for the various things in the queue. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com