problem with inheritance? ironpython ok, python.net - different
To run this script you need to get Weifen Luo's Dock Panel Suite from Source forge - just get the pre-compiled dll at http://sourceforge.net/project/showfiles.php?group_id=110642 and stick it in the same directory as the script. -----------------------------------------beginning of script import clr clr.AddReference('System.Windows.Forms') clr.AddReference('System.Drawing') clr.AddReference('WeifenLuo.WinFormsUI.Docking') import System.Windows.Forms as Winforms import WeifenLuo.WinFormsUI as DockSuite from System.Drawing import (Font, Point, FontStyle, GraphicsUnit) class EditForm(DockSuite.Docking.DockContent): def __init__(self): self.Text = "EditForm" self.console = Winforms.TextBox() self.console.Location = Point(0,0) self.console.Enabled = True self.console.Name = "EditForm console" self.console.Multiline = True self.console.WordWrap = True self.console.ScrollBars = Winforms.ScrollBars.Both self.console.Font = Font("Courier New", 10, FontStyle.Bold, GraphicsUnit.Point, 0) self.console.Dock = Winforms.DockStyle.Fill self.Controls.Add(self.console) def OnClosing(self, ev): pass class ExecuteForm(Winforms.Form): def __init__(self): self.IsMdiContainer = True self.DockMain = DockSuite.Docking.DockPanel() self.DockMain.Dock = Winforms.DockStyle.Fill self.Controls.Add(self.DockMain) self.eform = EditForm() self.eform.ShowHint = DockSuite.Docking.DockState.DockBottomAutoHide self.eform.Show(self.DockMain, DockSuite.Docking.DockState.Document) # Create the menu mainMenu1 = Winforms.MainMenu() editMenu = Winforms.MenuItem() editMenu.Text = "Edit" menuItemTest = Winforms.MenuItem() menuItemTest.Text = "Test" menuItemTest.Click += self.TestMenuHandler editMenu.MenuItems.Add(menuItemTest) mainMenu1.MenuItems.Add(editMenu) self.Menu = mainMenu1 def TestMenuHandler(self, source, ev): print type(self.DockMain.ActiveContent) form = ExecuteForm() Winforms.Application.Run(form) -------------------------------------------- end of script The script runs under both IronPython and Python.net which is very cool - but there is a different result when you select Edit - Test from the menu. For IronPython it prints: <class '__main__.EditForm'> for python.net you get: <class 'WeifenLuo.WinFormsUI.Docking.DockContent'> It seems that python.net is printing the base class rather than the class defined in the script. Is this a bug or am I being stupid? Regards, David
david lawler wrote:
To run this script you need to get Weifen Luo's Dock Panel Suite from Source forge - just get the pre-compiled dll at http://sourceforge.net/project/showfiles.php?group_id=110642 and stick it in the same directory as the script.
I'm unable to run DockSample.exe and your Python example: With mono 1.2.5.2 from svn Unhandled Exception: System.EntryPointNotFoundException: GetCurrentThreadId at (wrapper managed-to-native) WeifenLuo.WinFormsUI.Docking.NativeMethods:GetCurrentThreadId () at WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl+LocalWindowsHook.Install () [0x00000] at WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl..ctor (WeifenLuo.WinFormsUI.Docking.DockPanel dockPanel) [0x00000] at (wrapper remoting-invoke-with-check) FocusManagerImpl:.ctor (WeifenLuo.WinFormsUI.Docking.DockPanel) at WeifenLuo.WinFormsUI.Docking.DockPanel..ctor () [0x00000] at (wrapper remoting-invoke-with-check) WeifenLuo.WinFormsUI.Docking.DockPanel:.ctor () at DockSample.MainForm.InitializeComponent () [0x00000] at DockSample.MainForm..ctor () [0x00000] at (wrapper remoting-invoke-with-check) DockSample.MainForm:.ctor () at DockSample.Program.Main () [0x00000] With mono 1.2.4 (Ubuntu 7.04) ** (DockSample.exe:16336): WARNING **: Missing method System.Windows.Forms.Form::set_RightToLeftLayout(bool) in assembly /usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll, referenced in assembly /home/heimes/dev/mono/dockpanel/Release/DockSample.exe Unhandled Exception: System.MissingMethodException: Method not found: 'System.Windows.Forms.Form.set_RightToLeftLayout'. at <0x00000> <unknown method> at (wrapper remoting-invoke-with-check) DockSample.MainForm:.ctor () at DockSample.Program.Main () [0x00000] Christian
Christian Heimes <lists@...> writes:
david lawler wrote:
To run this script you need to get Weifen Luo's Dock Panel Suite from Source forge - just get the pre-compiled dll at http://sourceforge.net/project/showfiles.php?group_id=110642 and stick it in the same directory as the script.
I'm unable to run DockSample.exe and your Python example: .... Christian _________________________________________________ Python.NET mailing list - PythonDotNet@... http://mail.python.org/mailman/listinfo/pythondotnet
Ah yes - sorry - this is running on a Windows box. DockSuite has issues on Mono - it makes p/invoke calls into user32 in some places, see this post: http://osdir.com/ml/gnome.winforms/2006-11/msg00019.html Do you (or any other developer) have a way to look at this on windows? Regards, David
david lawler wrote:
Ah yes - sorry - this is running on a Windows box. DockSuite has issues on Mono - it makes p/invoke calls into user32 in some places, see this post: http://osdir.com/ml/gnome.winforms/2006-11/msg00019.html Do you (or any other developer) have a way to look at this on windows?
I really don't know when I can access a working Windows box with .NET and VS 2005. My Windows box has a hardware problem and I don't have time and money to fix the box until next month. Brian seems to be very busy, too. I haven't heard from him for quite a while. Christian
I really don't know when I can access a working Windows box with .NET and VS 2005. My Windows box has a hardware problem and I don't have time and money to fix the box until next month.
Brian seems to be very busy, too. I haven't heard from him for quite a while.
...but I'm still alive ;) On the original question here - David, you've basically run into the edge of the integration between python and .net here. The object that gets passed to your event handler by the CLR will always be the of actual .net class, not the python subclass. This is because the python subclass is not a real CLR class (it is only visible in Python), which is not the case in IronPython (python classes are bona fide CLR classes). Technically it would be possible to have the integration machinery track 'wrapped' instances so that a transition from Python -> CLR -> Python would lookup and pass the wrapped instance, but that's not there today (and I'm not sure what effect that would have on perf and memory usage). If there's no way around it, you could implement a poor man's version of this in your app using GCHandle to map back and forth between managed objects and the wrapped Python instances -- but its usually easier to find some other way around the problem ;) hope this helps, -------------------------- Brian Lloyd brian.lloyd@revolutionhealth.com
Brian Lloyd <brian.lloyd@...> writes:
...but I'm still alive ;)
On the original question here - David, you've basically run into the edge of the integration between python and .net here.
The object that gets passed to your event handler by the CLR will always be the of actual .net class, not the python subclass. This is because the python subclass is not a real CLR class (it is only visible in Python), which is not the case in IronPython (python classes are bona fide CLR classes)......
That does indeed help. Strangely I think I even follow your points :). I will see if there is another way that will work with both python.net and IronPython. The other issue I have started to look at is getting to the GUI thread (and the controls in the main form), from other threads. In IronPython there is some odd 'CallTarget0' stuff to allow you to Invoke/access data across threads. Is there something like that in Python.net? This is not of vital importance - just curiosity. I was working on a half *ssed IronPython 'IDE' written in IronPython and was shocked to see that the application actually ran under Python.net but then ran into the issue I described in the previous post as well as this other issue. It will not be a big deal if it does not work. Thanks for the quick and understandable reply! David
That does indeed help. Strangely I think I even follow your points :). I will see if there is another way that will work with both python.net and IronPython. The other issue I have started to look at is getting to the GUI thread (and the controls in the main form), from other threads. In IronPython there is some odd 'CallTarget0' stuff to allow you to Invoke/access data across threads. Is there something like that in Python.net? This is not of vital importance - just curiosity. I was working on a half *ssed IronPython 'IDE' written in IronPython and was shocked to see that the application actually ran under Python.net but then ran into the issue I described in the previous post as well as this other issue. It will not be a big deal if it does not work.
Thanks for the quick and understandable reply!
David
IP and python.net use pretty different models for this, since python.net has to cooperate with the std python global interpreter lock (IronPython does not replicate the GIL in its implementation). The GIL, in addition to the various restrictions .NET makes on interaction with the GUI thread will probably make for some fun times and late nights if you try to do anything too fancy ;) -------------------------- Brian Lloyd brian.lloyd@revolutionhealth.com
Brian Lloyd wrote:
IP and python.net use pretty different models for this, since python.net has to cooperate with the std python global interpreter lock (IronPython does not replicate the GIL in its implementation).
The GIL, in addition to the various restrictions .NET makes on interaction with the GUI thread will probably make for some fun times and late nights if you try to do anything too fancy ;)
It's no fun to debug a problem when .NET, the C python library and python code meet each other. It's a constant task switch between a C# debugger, gdb and Python. You don't want to debug it when threads join the battle. It may take hours before you even grasp which part of your code is causing trouble. I wish I could exercise more patience and spare more time on the debug support. Unfortunately Python's Py_DEBUG / Py_TRACE_REFS changes the memory layout and API calls a lot. It would be much easier to debug reference leaks and other problems with a debug build of Python. I think the use case of PythonDotNet is different from IronPython's use case. PythonDotNet doesn't aim to be another Python implementation or a replacement for IronPython. I usually explain it as a bridge between managed code/.NET/C# on the one side and CPython and C extensions on the other side. You should use IronPython if you want to do Python development under .NET. PythonDotNet is for people who need to embed Python C extensions in managed code or embed managed code in applications with a CPython interface. For example I'm experimenting with using and script a C# assembly with Python inside Blender. So far I haven't done much but the initial experiments are doing well. Christian
participants (3)
-
Brian Lloyd -
Christian Heimes -
david lawler