Re: [Mono-dev] [patch] coreclr fix for internal calls
LGTM On Tue, Sep 8, 2009 at 11:23 AM, Sebastien Pouliot < sebastien.poul...@gmail.com> wrote: > Hello, > > Here's a patch to throw SecurityException (unlike p/invokes > MethodAccessException) for internal calls defined outside platform code. The > patch also tries to reduce some code duplication for other coreclr > exceptions thrown inside mini/method-to-ir.c > > Sebastien > > p.s. the test cases (moonlight unit tests) also show a difference between > [s]mcs and csc - not sure what the specs are (if any) for this case but I do > prefer smcs behavior :) > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libtool blowing up
Hello, I just upgraded to ToT of svn, and now libtool is blowing up on Debian/MIPS. Any pointers anyone? Thanks, Mark CC mono-stdlib.lo CC mono-property-hash.lo CC mono-value-hash.lo LD libmonoutils.la /home/mason/mono-svn/mono/mono/utils/../../libtool: line 759: X--tag=CC: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 792: libtool: ignoring unknown tag : command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 759: X--mode=link: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 909: *** Warning: inferring the mode of operation is deprecated.: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 910: *** Future versions of Libtool will require --mode=MODE be specified.: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 2107: X-g: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 2107: X-O2: command not found ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] BinaryReader does not reset decoder
Hi, While looking at the source code of System.IO.BinaryReader [1] I noticed it reuses char decoder and I'm just wondering whether it is ok that the BinaryReader does not reset its internal state before the loop in ReadString method. What if the code fails e.g. on line 498 (sb.Append...) while the decoder contains fallback data. Next time ReadString is called, it will fail because decoder will try to use fallback data from previous call to ReadString. Or am I missing something here? Thanks, Martin [1] http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/corlib/System.IO/BinaryReader.cs?revision=115560&view=markup ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libtool blowing up
Hi, Try reverting this: http://lists.ximian.com/pipermail/mono-patches/2009-September/156282.html Zoltan On Wed, Sep 9, 2009 at 4:23 PM, Mark Mason wrote: > Hello, > > I just upgraded to ToT of svn, and now libtool is blowing up on > Debian/MIPS. Any pointers anyone? > > Thanks, > Mark > > CC mono-stdlib.lo > CC mono-property-hash.lo > CC mono-value-hash.lo > LD libmonoutils.la > /home/mason/mono-svn/mono/mono/utils/../../libtool: line 759: X--tag=CC: > command not found > /home/mason/mono-svn/mono/mono/utils/../../libtool: line 792: libtool: > ignoring unknown tag : command not found > /home/mason/mono-svn/mono/mono/utils/../../libtool: line 759: > X--mode=link: command not found > /home/mason/mono-svn/mono/mono/utils/../../libtool: line 909: *** > Warning: inferring the mode of operation is deprecated.: command not > found > /home/mason/mono-svn/mono/mono/utils/../../libtool: line 910: *** Future > versions of Libtool will require --mode=MODE be specified.: command not > found > /home/mason/mono-svn/mono/mono/utils/../../libtool: line 2107: X-g: > command not found > /home/mason/mono-svn/mono/mono/utils/../../libtool: line 2107: X-O2: > command not found > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gtk depends on Winforms ¿?
Hi folks,
as you may have noticed, old Gtk# versions (< 2.12.8) did not use XP's
visual styles. Later versions have a workaround: they call
System.WIndows.Forms.Application.DoEvents which seems to enable XP's
theming. This workaround is far from optimal as it created a Winforms
dependency.
That's why I tried to integrate the code of Application.DoEvents into
Gtk# directly. As I do not have a Windows XP machine to test, I cannot
verify if it works.
I have attached an assembly and it's source code (change extension to
.exe; GMail does not allow executables as attachments) that can be run
with any Gtk# 2.12 version on XP. It uses a tweaked Gtk.Application
class with a new mechanism to enable theming.
I would really appreciate some feedback from the community as to whether
the new approach works (that is, if the attached application appears
with visual styles enabled). Just reply with a screenshot of the running
app on XP if you're not sure what I mean :-) .
Christian
Mike Kestner wrote:
On Sat, 2009-09-05 at 09:15 +0200, Christian Hoff wrote:
In Windows I use 'mkbundle' [1]
We should probably put that code in a try-block. What do you think, Mike?
My question would be, what do you do in the catch block?
The winforms reflection thing is a huge hack, we know that, and the
poster is tripping over it because of using mkbundle instead of
depending on mono or .Net.
We could also take the stance that if somebody wants to do this sort of
minimal packaging, they are required to add an artificial ref to swf to
ensure it gets bundled. But they won't have any clue that's required if
we just silently fallback to unthemed windows when we can't find swf.
According to Robert Jordan on this thread, it's a PeekMessage/GetMessage
loop that's required to happen before the first handle is created. We
should try a pinvoke solution like that and see if it works so we can
remove the hack altogether instead of figuring out ways to make the hack
more palatable.
Mike
// ButtonApp.cs - Gtk.Button class Test implementation
//
// Author: Mike Kestner
//
// (c) 2001-2002 Mike Kestner
namespace GtkSamples {
using Gtk;
using System;
public class ButtonApp {
public static int Main (string[] args)
{
GtkTuned.Application.Init (); // Our own implementation of Gtk.Application.Init
Window win = new Window ("Button Tester");
win.DefaultWidth = 200;
win.DefaultHeight = 150;
win.DeleteEvent += new DeleteEventHandler (Window_Delete);
Button btn = new Button ("Click Me");
btn.Clicked += new EventHandler (btn_click);
win.Add (btn);
win.ShowAll ();
GtkTuned.Application.Run ();
return 0;
}
static void btn_click (object obj, EventArgs args)
{
Console.WriteLine ("Button Clicked");
}
static void Window_Delete (object obj, DeleteEventArgs args)
{
GtkTuned.Application.Quit ();
args.RetVal = true;
}
}
}
// GTK.Application.cs - GTK Main Event Loop class implementation
//
// Author: Mike Kestner
//
// Copyright (c) 2001 Mike Kestner
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of version 2 of the Lesser GNU General
// Public License as published by the Free Software Foundation.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License along with this program; if not, write to the
// Free Software Foundation, Inc., 59 Temple Place - Suite 330,
// Boston, MA 02111-1307, USA.
namespace GtkTuned {
using System;
using System.Reflection;
using System.Runtime.InteropServices;
using Gdk;
public class Application {
//
// Disables creation of instances.
//
private Application ()
{
}
static Application ()
{
if (!GLib.Thread.Supported)
GLib.Thread.Init ();
switch (Environment.OSVersion.Platform) {
case PlatformID.Win32NT:
case PlatformID.Win32S:
case PlatformID.Win32Windows:
case PlatformID.WinCE:
// Comment the WinDoEvents call to disable the visual styles hack
Console.WriteLine ("Running visual styles hack");
WinDoEvents ();
break;
default:
break;
}
}
[StructLayout(LayoutKind.Sequential)]
internal struct POINT {
int x;
int y;
}
[StructLayout(LayoutKind.Sequential)]
internal struct MSG {
IntPtr hwnd;
int message;
IntPtr wParam;
IntPtr lParam;
uint time;
POINT pt;
object refobject;
}
const uint PM_REMOVE = 1;
[DllImport ("user32.dll", EntryPoint="PeekMessageW", CharSet=CharSet.Unicode, CallingConvention=CallingConvention.StdCall)]
extern static bool Win32PeekMessage(IntPtr msg, IntPtr hWnd, int wFilterMin, int wFilterMax, uint flags);
[DllImport ("user32.dll", EntryPoint="TranslateMessag
Re: [Mono-dev] Gtk depends on Winforms ¿?
Unfortunately, the button does not appear to use native themes on my WinXP machine (SP3, GTK# installed with Mono 2.4.2.3). On Wed, Sep 9, 2009 at 5:05 PM, Christian Hoff wrote: > Hi folks, > > as you may have noticed, old Gtk# versions (< 2.12.8) did not use XP's > visual styles. Later versions have a workaround: they call > System.WIndows.Forms.Application.DoEvents which seems to enable XP's > theming. This workaround is far from optimal as it created a Winforms > dependency. > > That's why I tried to integrate the code of Application.DoEvents into Gtk# > directly. As I do not have a Windows XP machine to test, I cannot verify if > it works. > I have attached an assembly and it's source code (change extension to .exe; > GMail does not allow executables as attachments) that can be run with any > Gtk# 2.12 version on XP. It uses a tweaked Gtk.Application class with a new > mechanism to enable theming. > > I would really appreciate some feedback from the community as to whether the > new approach works (that is, if the attached application appears with visual > styles enabled). Just reply with a screenshot of the running app on XP if > you're not sure what I mean :-) . > > > Christian > > Mike Kestner wrote: >> >> On Sat, 2009-09-05 at 09:15 +0200, Christian Hoff wrote: >> >> In Windows I use 'mkbundle' [1] >>> >>> We should probably put that code in a try-block. What do you think, Mike? >>> >> >> My question would be, what do you do in the catch block? >> The winforms reflection thing is a huge hack, we know that, and the >> poster is tripping over it because of using mkbundle instead of >> depending on mono or .Net. >> >> We could also take the stance that if somebody wants to do this sort of >> minimal packaging, they are required to add an artificial ref to swf to >> ensure it gets bundled. But they won't have any clue that's required if >> we just silently fallback to unthemed windows when we can't find swf. >> >> According to Robert Jordan on this thread, it's a PeekMessage/GetMessage >> loop that's required to happen before the first handle is created. We >> should try a pinvoke solution like that and see if it works so we can >> remove the hack altogether instead of figuring out ways to make the hack >> more palatable. >> >> Mike >> >> > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Gtk-sharp-list] Gtk depends on Winform s ¿?
Την Wed, 09 Sep 2009 18:05:42 +0300,ο(η) Christian Hoff έγραψε: > I would really appreciate some feedback from the community as to whether > the new approach works (that is, if the attached application appears > with visual styles enabled). Just reply with a screenshot of the running > app on XP if you're not sure what I mean :-) . Didn't render with visual styles here (Vista x86 Business w/ SP2). What magic sauce is Application.DoEvents using? I wonder if it is performing any static initialization (static constructors and/or fields). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Gtk-sharp-list] Gtk depends on Win forms ¿?
Hi Stefanos, 2009/9/9 Stefanos A. : > What magic sauce is Application.DoEvents using? I wonder if it is > performing any static initialization (static constructors and/or fields). That is what I thought, so I went on a hunt... but couldn't find anything conclusive. I paid particular attention to the static constructor of the Application class - maybe I overlooked something elsewhere! -- Tom Spink Mike Ditka - "If God had wanted man to play soccer, he wouldn't have given us arms." ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Gtk-sharp-list] Gtk depends on Winform s ¿?
Stefanos A. wrote: > Την Wed, 09 Sep 2009 18:05:42 +0300,ο(η) Christian Hoff > έγραψε: > >> I would really appreciate some feedback from the community as to whether >> the new approach works (that is, if the attached application appears >> with visual styles enabled). Just reply with a screenshot of the running >> app on XP if you're not sure what I mean :-) . > > Didn't render with visual styles here (Vista x86 Business w/ SP2). > > What magic sauce is Application.DoEvents using? I wonder if it is > performing any static initialization (static constructors and/or fields). You may need to look at the static constructor for XplatUIWin32.cs. It does some stuff you may need like creating a foster window. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Gtk-sharp-list] Gtk depends on Winform s ¿?
Stefanos A. wrote:
> Την Wed, 09 Sep 2009 18:05:42 +0300,ο(η) Christian Hoff
> έγραψε:
>
>> I would really appreciate some feedback from the community as to whether
>> the new approach works (that is, if the attached application appears
>> with visual styles enabled). Just reply with a screenshot of the running
>> app on XP if you're not sure what I mean :-) .
>
> Didn't render with visual styles here (Vista x86 Business w/ SP2).
>
> What magic sauce is Application.DoEvents using? I wonder if it is
> performing any static initialization (static constructors and/or fields).
>
By now I tried:
MSG msg = new MSG ();
while (Win32PeekMessage (ref msg, IntPtr.Zero, 0, 0, PM_REMOVE)) {
Console.WriteLine ("Got a message");
Win32TranslateMessage (ref msg);
Win32DispatchMessage (ref msg);
}
On my Windows 7 machine, PeekMessage returns false.
Now that emulating DoEvents does not seem to fix it, I'm looking at the
static constructor of XplatUIWin32, the class that also contains the
"real" code for DoEvents. Besides initialization stuff, it creates a
"foster window":
wnd_proc = new WndProc(InternalWndProc);
FosterParent=Win32CreateWindow(WindowExStyles.WS_EX_TOOLWINDOW,
"static", "Foster Parent Window", WindowStyles.WS_OVERLAPPEDWINDOW, 0,
0, 0, 0, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero);
Prepending that code to the workaround should make it work. I will
create a test app ASAP.
Thanks,
Christian
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compacting GC
Hello, > Is is possible to try the upcoming compacting GC? Is it in a status > close to be usable? You can try it, but it is not finished. Compile Mono with: ./configure --with-gc=sgen Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono SVN doesn't build on Mac OSX Snow Leopard
Hello, > The primary reason seems to be that the default version of gcc on Snow > Leopard, 4.2.1, no longer defines __i386__. gcc 4.2.1 defines __x86_64__. In general, and moving forward, we should stop using the GCC __platform__ macros, and instead use TARGET_ defines. This is becoming more important as Mono is used more and more as a cross compiler.When Mono is used as a cross compiler the __platform__ merely indicates the host system, but does not cope with the target system, which ends up breaking a lot of things. For instance, consider Mono running on Intel, generating code for ARM (the iPhone case) or Mono running on Intel, generating code for PowerPC (gaming consoles). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libtool blowing up
Hello, I tried reverting that change -- no luck. It's still blowing up. /Mark On Sep 9, 2009, at 7:45 AM, Zoltan Varga wrote: Hi, Try reverting this: http://lists.ximian.com/pipermail/mono-patches/2009-September/156282.html Zoltan On Wed, Sep 9, 2009 at 4:23 PM, Mark Mason wrote: Hello, I just upgraded to ToT of svn, and now libtool is blowing up on Debian/MIPS. Any pointers anyone? Thanks, Mark CC mono-stdlib.lo CC mono-property-hash.lo CC mono-value-hash.lo LD libmonoutils.la /home/mason/mono-svn/mono/mono/utils/../../libtool: line 759: X-- tag=CC: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 792: libtool: ignoring unknown tag : command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 759: X--mode=link: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 909: *** Warning: inferring the mode of operation is deprecated.: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 910: *** Future versions of Libtool will require --mode=MODE be specified.: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 2107: X-g: command not found /home/mason/mono-svn/mono/mono/utils/../../libtool: line 2107: X-O2: command not found ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compacting GC
Miguel, This build option hasn't been working for a while when compiling from trunk. Did anyone fix it recently? Diego Frata diego.fr...@gmail.com On Wed, Sep 9, 2009 at 1:30 PM, Miguel de Icaza wrote: > Hello, > > > Is is possible to try the upcoming compacting GC? Is it in a status > > close to be usable? > > You can try it, but it is not finished. > > Compile Mono with: > >./configure --with-gc=sgen > > Miguel > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Gtk-sharp-list] Gtk depends on Winform s ¿?
Christian Hoff wrote:
Stefanos A. wrote:
Την Wed, 09 Sep 2009 18:05:42 +0300,ο(η) Christian Hoff
έγραψε:
I would really appreciate some feedback from the community as to whether
the new approach works (that is, if the attached application appears
with visual styles enabled). Just reply with a screenshot of the running
app on XP if you're not sure what I mean :-) .
What magic sauce is Application.DoEvents using? I wonder if it is
performing any static initialization (static constructors and/or fields).
Now that emulating DoEvents does not seem to fix it, I'm looking at the
static constructor of XplatUIWin32, the class that also contains the
"real" code for DoEvents. Besides initialization stuff, it creates a
"foster window":
FosterParent=Win32CreateWindow(WindowExStyles.WS_EX_TOOLWINDOW,
"static", "Foster Parent Window", WindowStyles.WS_OVERLAPPEDWINDOW, 0,
0, 0, 0, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero);
Bingo! It's the foster window that enables theming. At least it worked
on a XP machine at school which I contaminated with Gtk# :-) . I
attached the new test application which should now work at least on XP
(the visual styles hack never worked on my Windows 7 machine). Again, it
would be great if you could give it a try on your machine to ensure it
works properly before we commit this.
Christian
theming-enabled.runme
Description: Binary data
// ButtonApp.cs - Gtk.Button class Test implementation
//
// Author: Mike Kestner
//
// (c) 2001-2002 Mike Kestner
namespace GtkSamples {
using Gtk;
using System;
public class ButtonApp {
public static int Main (string[] args)
{
GtkTuned.Application.Init (); // Our own implementation of Gtk.Application.Init
Window win = new Window ("Button Tester");
win.DefaultWidth = 200;
win.DefaultHeight = 150;
win.DeleteEvent += new DeleteEventHandler (Window_Delete);
Button btn = new Button ("Click Me");
btn.Clicked += new EventHandler (btn_click);
win.Add (btn);
win.ShowAll ();
GtkTuned.Application.Run ();
return 0;
}
static void btn_click (object obj, EventArgs args)
{
Console.WriteLine ("Button Clicked");
}
static void Window_Delete (object obj, DeleteEventArgs args)
{
GtkTuned.Application.Quit ();
args.RetVal = true;
}
}
}
// GTK.Application.cs - GTK Main Event Loop class implementation
//
// Author: Mike Kestner
//
// Copyright (c) 2001 Mike Kestner
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of version 2 of the Lesser GNU General
// Public License as published by the Free Software Foundation.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License along with this program; if not, write to the
// Free Software Foundation, Inc., 59 Temple Place - Suite 330,
// Boston, MA 02111-1307, USA.
namespace GtkTuned {
using System;
using System.Reflection;
using System.Runtime.InteropServices;
using Gdk;
public class Application {
//
// Disables creation of instances.
//
private Application ()
{
}
const int WS_EX_TOOLWINDOW = 0x0080;
const int WS_OVERLAPPEDWINDOW = 0x00CF;
[DllImport ("user32.dll", EntryPoint="CreateWindowExW", CharSet=CharSet.Unicode, CallingConvention=CallingConvention.StdCall)]
internal extern static IntPtr Win32CreateWindow(int dwExStyle, string lpClassName, string lpWindowName,int dwStyle, int x, int y, int nWidth, int nHeight, IntPtr hWndParent, IntPtr hMenu, IntPtr hInstance, IntPtr lParam);
static Application ()
{
if (!GLib.Thread.Supported)
GLib.Thread.Init ();
switch (Environment.OSVersion.Platform) {
case PlatformID.Win32NT:
case PlatformID.Win32S:
case PlatformID.Win32Windows:
case PlatformID.WinCE:
// No idea why we need to create that window, but it enables visual styles on the Windows platform
Win32CreateWindow (WS_EX_TOOLWINDOW, "static", "Foster Parent Window", WS_OVERLAPPEDWINDOW, 0, 0, 0, 0, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero);
break;
default:
break;
}
}
[DllImport ("libgtk-win32-2.0-0.dll", CallingConvention = CallingConvention.Cdecl)]
static extern void gtk_init (ref int argc, ref IntPtr argv);
[DllImport ("libgtk-win32-2.0-0.dll", CallingConvention = CallingConvention.Cdecl)]
static extern bool gtk_init_check (ref int argc, ref IntPtr argv);
static void SetPrgname ()
{
GLib.Global.ProgramName = System.IO.Path.GetFileNameWithoutExtension (Environment.GetCommandLineArgs () [0]);
}
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
}
static bool do_init (string progname, ref
[Mono-dev] [PATCH] Calling COM methods with delegates
Hi, The attached patch fixes a bug with calling a COM method using a delegate. I have also added a unit test for this bug. 2009-09-09 Bill Holmes * object.c (mono_object_get_virtual_method) : Call mono_cominterop_get_invoke if the object is a COM object. * mini-trampolines.c (mono_delegate_trampoline) : Call mono_cominterop_get_invoke if the delegate target object is a COM object. * cominterop.cs : Adding a test for invoking delegates that target COM methods. Code is contributed under MIT/X11 license. -bill invoke_com_delegate.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Calling COM methods with delegates
Looks ok. Zoltan On Wed, Sep 9, 2009 at 11:19 PM, Bill Holmes wrote: > Hi, > > The attached patch fixes a bug with calling a COM method using a > delegate. I have also added a unit test for this bug. > > 2009-09-09 Bill Holmes > >* object.c (mono_object_get_virtual_method) : Call > mono_cominterop_get_invoke if the object is a COM object. > >* mini-trampolines.c (mono_delegate_trampoline) : Call > mono_cominterop_get_invoke if the delegate target object > is a COM object. > >* cominterop.cs : Adding a test for invoking delegates that > target COM methods. > >Code is contributed under MIT/X11 license. > > -bill > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Gtk-sharp-list] Gtk depends on Winform s ¿?
Την Wed, 09 Sep 2009 23:14:07 +0300,ο(η) Christian Hoff
έγραψε:
> Bingo! It's the foster window that enables theming. At least it worked
> on a XP machine at school which I contaminated with Gtk# :-) . I
> attached the new test application which should now work at least on XP
> (the visual styles hack never worked on my Windows 7 machine). Again, it
> would be great if you could give it a try on your machine to ensure it
> works properly before we commit this.
>
Confirming success on Vista x86!
Additionally, there is no need to keep the window lying around. Calling
DestroyWindow immediately doesn't seem to be causing any problems.
[DllImport ("user32.dll", EntryPoint="DestroyWindow",
CharSet=CharSet.Unicode, CallingConvention=CallingConvention.StdCall)]
internal extern static bool Win32DestroyWindow(IntPtr window);
[...]
// No idea why we need to create that window, but it enables visual styles
on the Windows platform
IntPtr window = Win32CreateWindow (WS_EX_TOOLWINDOW, "static", "Foster
Parent Window", WS_OVERLAPPEDWINDOW, 0, 0, 0, 0, IntPtr.Zero, IntPtr.Zero,
IntPtr.Zero, IntPtr.Zero);
Win32DestroyWindow(window);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
