Re: [Mono-list] Mono for an older Linux RHEL4r5?

[Maser, Dan]

   I use mono on RHEL4 with fine results.  I build mine from source.

-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of jmalcolm
Sent: Wednesday, December 15, 2010 8:16 PM
To: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Mono for an older Linux RHEL4r5?



CodeSlinger wrote:
 
 We have an older version of Linux - Red Hat EL4r5 - also known as Update
 5, 2007-05-01.
 
 Do I have much of a chance running a decent version of Mono on this older
 system?
 

You will have to wait for a more authoritative answer, but as a user of Mono
on RHEL5 I can say that I see no reason why you would not be able to build
and run Mono on RHEL4.  I would not be surprised if there are no packages
kicking around for that though.  You will probably have to build from
source.  This could be a bit of a pain.

I would expect the biggest problem to be compiling libgdiplus as it relies
on quite a few graphics libraries (including Cairo).  Mono almost certainly
needs newer versions than you have in RHEL4.  So, you will have to update
these which will likely also require building from source.  It may also
require newer versions of automake, autoconf, or the like.

libgdiplus is an implementation of GDI+ for Linux which is used to support
System.Drawing.

After you get libgdiplus in place, Mono should build fine I expect.  If you
are building Mono 2.8+ you will not have to worry about what version of
glib2 you have installed as Mono now uses the built-in eglib instead.  I
think maybe the only other thing you might need is bison.

If you want to run asp.net stuff you may run into an issue with the age of
your Apache install as well but I am not sure about that either.

Note, I have not tried to build Mono on RHEL4 myself.  Mono works very well
with RHEL5 if you are looking for an excuse to upgrade.


CodeSlinger wrote:
 
 
 I'm a Windows .NET developer and know some but not a lot about Linux.
 Would the installation of Mono on our system impact any kernel stuff or
 does it install in such a manner [perhaps just accessing a separate
 directory] that the production guys won't freak out about adding Mono to
 their system?
 
 Thanks, Dave
 

Mono does not impact the kernel at all.  It runs 100% in user space.  What
your production guys will or will not freak out about is hard to know of
course.

If you specify --prefix=/usr when you build Mono almost everything will
end up in /usr/lib/mono.  I think the default is /usr/local/lib/mono if
you do not specify anything.



-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/Mono-for-an-older-Linux-RHEL4r5-tp3089477p3090218.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Pure wrapper calling native code

[Maser, Dan]

   It's possible if you own the source to the unmanaged DLL can make ports to 
the desired operating systems.  My project makes heave use of both managed C# 
and unmanaged C++ dlls, and the C++ dlls I compile for both windows and linux.

-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Stifu
Sent: Thursday, August 05, 2010 12:40 PM
To: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Pure wrapper calling native code


Aren't native / unmanaged DLLs Windows only? If that's the case, then it's
not possible.


Brendon Chung wrote:
 
 I currently have a program written in C# and running via Mono on my Mac.
 
 I need this program to access an unmanaged C++ dll.
 
 My first attempt at this was using the DllImport call, but the call always
 fails out for me. I'm now trying to write a managed C++ wrapper dll to
 bridge between my C# program and the unmanaged C++ dll.
 
 My question is: is this even possible?  In order to be Mac-compatible, I
 need to compile my C++ wrapper with /clr:pure and /nodefaultlib. But after
 some research, it seems that /clr:pure precludes the possibility of
 importing/using any unmanaged code.
 
 So, is a wrapper feasible, or is DllImport the only way to go?
 --
 Brendon Chung
 www.blendogames.com
 

-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/Pure-wrapper-calling-native-code-tp2315133p2315364.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Can cross Windows and Linux platform mono application include Windows .NET C# dll ?

[Maser, Dan]

   Yeah, I do this with mono and it works very well for me.   Meaning that I 
have managed C# code that uses an unmanaged DLL via p/invoke.  I compile the C# 
code with .NET on Windows and mono on linux, and I compile the unmanaged (c++) 
code with vc++ on Windows and gcc on linux; using the same C# code and C++ 
code.   But of course I had to plan ahead to do this... primarily by not using 
Win32 APIs directly in code, I use portable libraries like ACE, BOOST, STLPort, 
ICU, and occasionally have a #ifdef section for platform specific code.


Dan Maser | Lead Software Developer
phone  fax +1.317.872.3000 | mobile +1.317.872.3000 | dan.ma...@inin.com

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com


-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of chuchieh...@micron.com
Sent: Thursday, October 01, 2009 9:06 AM
To: cdho...@gmail.com
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Can cross Windows and Linux platform mono application 
include Windows .NET C# dll ?

Chris,

My understanding that the DLL will be an unmanaged one.  This is a great help 
for me.

Thanks,
Jerry

-Original Message-
From: Chris Howie [mailto:cdho...@gmail.com] 
Sent: Wednesday, September 30, 2009 10:47 PM
To: chuchiehliu
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Can cross Windows and Linux platform mono application 
include Windows .NET C# dll ?

On Wed, Sep 30, 2009 at 6:19 PM,  chuchieh...@micron.com wrote:
 I am looking for cross platform (Windows and RedHat Linux) application
 (WindowForm with dll) solution.

 (1) Mono with X-develop is what I have tried first.  After I quickly
 created a Window.Form application using Windows mono 2.4 and X-develop, I
 can run it from RedHat Linux using “mono myapps.exe” command with mono
 version 1.9.1 that I got from website for my RedHat Linux.  It looks ok.
 After reading Mono-list, I am not sure whether my application which will
 need to include Windows dll (written in VC++ in dll and wrapped by .NET C#
 as dll) will work by using Mono together with X-develop environment?

If the DLL is unmanaged (it sounds like it is) then including a
Windows build of it will do no good.  You will have to compile this as
a native Linux library for Mono on Linux to be able to use it.

If the library uses non-portable calls (such as win32 functions) then
you will have to do the standard C/C++ thing and #if your way to
portability, or find a portable function that does the same thing.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Can cross Windows and Linux platform monoapplication include Windows .NET C# dll ?

[Maser, Dan]

  No, you can't do this.  If you have a C DLL compiled with MSVC++ that means 
it is essentially a stream of machine code instructions that are identifiable 
to the Windows OS.  A linux OS can't make any use of it (there is a Windows 
emulator... but it doesn't work in this way so it's not applicable).   What you 
need to do is that the same C++ source code and compile it as a linux shared 
library using gcc, which will then essentially be a stream of machine code that 
is known to the linux OS.

Dan Maser | Lead Software Developer
phone  fax +1.317.872.3000 | mobile +1.317.872.3000 | dan.ma...@inin.com

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com


-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of chuchieh...@micron.com
Sent: Thursday, October 01, 2009 9:17 AM
To: cdho...@gmail.com
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Can cross Windows and Linux platform monoapplication 
include Windows .NET C# dll ?

Chris,

Sorry, more thought about the DLL.  The DLL is implemented (by someone else) 
using MSVC++ (non-managed) as a C API library DLL.  What if I wrapped (platform 
invoke) it using .NET C# and to become a DLL also (managed to some degree).  
Can I include the .NET C# DLL and will work for Mono+Xdevelop for both Windows 
and Linux environment?

Regards,
Jerry



-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of chuchiehliu
Sent: Thursday, October 01, 2009 8:06 AM
To: cdho...@gmail.com
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Can cross Windows and Linux platform monoapplication 
include Windows .NET C# dll ?

Chris,

My understanding that the DLL will be an unmanaged one.  This is a great help 
for me.

Thanks,
Jerry

-Original Message-
From: Chris Howie [mailto:cdho...@gmail.com] 
Sent: Wednesday, September 30, 2009 10:47 PM
To: chuchiehliu
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Can cross Windows and Linux platform mono application 
include Windows .NET C# dll ?

On Wed, Sep 30, 2009 at 6:19 PM,  chuchieh...@micron.com wrote:
 I am looking for cross platform (Windows and RedHat Linux) application
 (WindowForm with dll) solution.

 (1) Mono with X-develop is what I have tried first.  After I quickly
 created a Window.Form application using Windows mono 2.4 and X-develop, I
 can run it from RedHat Linux using “mono myapps.exe” command with mono
 version 1.9.1 that I got from website for my RedHat Linux.  It looks ok.
 After reading Mono-list, I am not sure whether my application which will
 need to include Windows dll (written in VC++ in dll and wrapped by .NET C#
 as dll) will work by using Mono together with X-develop environment?

If the DLL is unmanaged (it sounds like it is) then including a
Windows build of it will do no good.  You will have to compile this as
a native Linux library for Mono on Linux to be able to use it.

If the library uses non-portable calls (such as win32 functions) then
you will have to do the standard C/C++ thing and #if your way to
portability, or find a portable function that does the same thing.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Charset issue

[Maser, Dan]

I've found that there two main categories of reasons for this.  The one 
that most people don't consider is that the font doesn't have entries for the 
characters.   Are you sure that the font being used has character entries for 
these characters?   The best thing to do is to put some test code in your app 
that converts the string to binary and dumps out the bytes (to the Console for 
example).  If the bytes are correct, then my hunch would be that your font 
doesn't support the characters in the string.   If the bytes are not correct 
then naturally you have to back track until you find out when in your process 
the bytes become corrupted.


Dan Maser | Lead Software Developer
phone  fax +1.317.872.3000 | mobile +1.317.872.3000 | dan.ma...@inin.com

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com


-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of mtrekker
Sent: Thursday, September 03, 2009 12:47 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Charset issue


Can somebody explain me what it needs to be set up to get rid of funny chars? 

See my previous post: http://www.nabble.com/Charset-issue-to25220398.html
-- 
View this message in context: 
http://www.nabble.com/Charset-issue-tp25280886p25280886.html
Sent from the Mono - General mailing list archive at Nabble.com.

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] C#: Compiling Classes Independently - How?

[Maser, Dan]

  I wouldn't be too surprised if your rude behavior fails to inspire anyone to 
help you get your question answered.  

  Charlie Poole, thanks for taking the time you ovbiously took with your reply.

-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of G_Morgan
Sent: Monday, June 29, 2009 4:03 PM
To: mono-list@lists.ximian.com
Subject: Re: [Mono-list] C#: Compiling Classes Independently - How?


So the official advice is to shut up and deal with it ;). I think I can
understand why MS decided to do things this way. Something along the line of
'OMG look at all those class files everywhere' wrt Java. Why don't they both
understand that C got it right in times immemorial? That you should copy
exactly and never question the one true way!

Out of interest are there any build tools that manage Mono projects in a
sane manner or do they all face the same problem I've bumped into trying to
use make?


Charlie Poole wrote:
 
 Hi,
 
 I remember being equally surprised when I moved from C++
 to C#. What you describe is how C++ works, but not how C# works.
 
 In the long run, I think you'll be much more satisfied with 
 the results if you learn to adapt to this new environment.
 
 There are, of course, ways to simulate your C++ experience
 using modules, but you will be creating a terribly complicated
 structure and anyone who follows you on the job will not
 be thankful. :-)
 
 If you have real performance problems with your compiles, it
 may mean that you are putting too much into a single assembly.
 It's pretty normal for an application developed in C# to have
 multiple assemblies, which are all delivered in the same
 directory.
 
 I suggest you try to go with the flow for a few weeks and
 then decide whether you really need to simulate your old
 environment.
 
 Charlie
 
 
 -Original Message-
 From: mono-list-boun...@lists.ximian.com 
 [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of G_Morgan
 Sent: Monday, June 29, 2009 11:51 AM
 To: mono-list@lists.ximian.com
 Subject: [Mono-list] C#: Compiling Classes Independently - How?
 
 
 Simply put I always develop my code in C++ by compiling each 
 file into a separate object code file and then linking them 
 together. In C# I'm struggling to see how to do this or 
 anything similar. I've tried using assemblies and modules but 
 both require me to actually deliver the assembly or module 
 with the executable. Does a mechanism exist by which a module 
 can be copied directly into the executable image and thus let 
 me delete the .netmodule files and still run? If not is there 
 a sensible CLI mechanism to allow C# programs to be developed 
 in such a way that I'm not doing a complete rebuild with 
 every minor change?
 
 I've tried using the incremental flag but smcs seems to throw 
 a fit complaining about missing .netmodule files. The 
 description of the option in the MSDN documents doesn't 
 suggest that these files are needed.
 --
 View this message in context: 
 http://www.nabble.com/C-%3A-Compiling-Classes-Independently---
 How--tp24259351p24259351.html
 Sent from the Mono - General mailing list archive at Nabble.com.
 
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com 
 http://lists.ximian.com/mailman/listinfo/mono-list
 
 
 
 
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list
 
 

-- 
View this message in context: 
http://www.nabble.com/C-%3A-Compiling-Classes-Independently---How--tp24259351p24261591.html
Sent from the Mono - General mailing list archive at Nabble.com.

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] What is Correct way to marshal wchar_t ?

[Maser, Dan]

I've found that you have two choices:

1. If you have source to the library you're interop'ing to, you can make the C 
interface take a unsigned short* instead of wchar_t* and it will work using 
the managed CharSet.Unicode for both systems.  Of course your C code will have 
cast the paramter to a wchar_t* on windows but use a conversion function 
between UTF-16 and UCS-4 or UTF-8 on the non-windows library.

2. You can use C#'s custom marshal code to marshal as 2 bytes wide on windows 
and 4 bytes wide elsewhere and leave your C code using wchar_t everywhere.  See 
the interfaces of System.Runtime.InteropServices.ICustomMarshaler and the 
attribute [MarshalAs(UnmanagedType.CustomMarshaler, 
MarshalTypeRef=typeof(YourClassDerivedFromICustomMarshaler))].   If you need 
an example of this let me know but the MSDN documentation using these classes 
should be enough for you to follow.




-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of ptr2009
Sent: Wednesday, June 03, 2009 11:54 AM
To: mono-list@lists.ximian.com
Subject: [Mono-list] What is Correct way to marshal wchar_t ?


hey all

 I am trying to marshal strings from managed code to native code using
DllImport. Marshalling both wchar_t* and char* works under mono on a windows
box. 

But on mac os x wchart_t marshalling does not seem to work. The wchar_t* is
all junk. I have tried to search this forum and people have talked about it
and it seems to have been fixed.

Am I missing something ? I have experimented with CharSet.Unicode on
DllImport and it still doesnt work ?

What is the recommended way ?

Thanks
Raj



My cs files is something like this

[DllImport(Test.dll, EntryPoint = Global_PrintStringW)]
 public static extern void Global_PrintStringW(
[MarshalAs(UnmanagedType.LPWStr)]string arg1);

[DllImport(Test.dll, EntryPoint = Global_PrintStringA)]
 public static extern void Global_PrintStringA(string arg1);


private static void StringMarshallingTest()
{
   
string newString = This is a cool string;

Console.WriteLine(Global_PrintStringA Test );
Global_PrintStringA(newString);

Console.WriteLine(Global_PrintStringW Test );
Global_PrintStringW(newString);
 
}

My cpp file is something like this


extern C
{
EXPORT_API void Global_PrintStringW(const wchar_t * str)
{
std::wcout  Global_PrintStringW called with   str  
std::endl;
}

EXPORT_API void Global_PrintStringA(const char* str)
{
std::wcout  Global_PrintStringA called with   str  
std::endl;
}
}



-- 
View this message in context: 
http://www.nabble.com/What-is-Correct-way-to-marshal-wchar_t---tp23855173p23855173.html
Sent from the Mono - General mailing list archive at Nabble.com.

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] What is Correct way to marshal wchar_t ?

[Maser, Dan]

  Yes, I use SWIG also and I am successfully using both methods I described 
below.   If you're using SWIG than I find that option #1 is easier provided 
that you have the source to the library you're interopping to, but if you don't 
then option #2 should work (ie, if the library interface is stuck taking a 
wchat_t* and you can't change that, option #2 will work for you).


Dan Maser | Lead Software Developer
phone  fax +1.317.872.3000 | mobile +1.317.872.3000 | dan.ma...@inin.com

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com

From: ptr [mailto:ptrajku...@gmail.com]
Sent: Wednesday, June 03, 2009 12:36 PM
To: Maser, Dan
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] What is Correct way to marshal wchar_t ?

I am using swig to generate all my interop stuff as recommended by 
http://www.mono-project.com/Interop_with_Native_Libraries as I have lot of C++ 
code that needs to be wrapper.  Can swig handle this ?

Thanks
Raj
On Wed, Jun 3, 2009 at 1:31 PM, Maser, Dan 
dan.ma...@inin.commailto:dan.ma...@inin.com wrote:
   I've found that you have two choices:

1. If you have source to the library you're interop'ing to, you can make the C 
interface take a unsigned short* instead of wchar_t* and it will work using 
the managed CharSet.Unicode for both systems.  Of course your C code will have 
cast the paramter to a wchar_t* on windows but use a conversion function 
between UTF-16 and UCS-4 or UTF-8 on the non-windows library.

2. You can use C#'s custom marshal code to marshal as 2 bytes wide on windows 
and 4 bytes wide elsewhere and leave your C code using wchar_t everywhere.  See 
the interfaces of System.Runtime.InteropServices.ICustomMarshaler and the 
attribute [MarshalAs(UnmanagedType.CustomMarshaler, 
MarshalTypeRef=typeof(YourClassDerivedFromICustomMarshaler))].   If you need 
an example of this let me know but the MSDN documentation using these classes 
should be enough for you to follow.




-Original Message-
From: 
mono-list-boun...@lists.ximian.commailto:mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.commailto:mono-list-boun...@lists.ximian.com]
 On Behalf Of ptr2009
Sent: Wednesday, June 03, 2009 11:54 AM
To: mono-list@lists.ximian.commailto:mono-list@lists.ximian.com
Subject: [Mono-list] What is Correct way to marshal wchar_t ?


hey all

 I am trying to marshal strings from managed code to native code using
DllImport. Marshalling both wchar_t* and char* works under mono on a windows
box.

But on mac os x wchart_t marshalling does not seem to work. The wchar_t* is
all junk. I have tried to search this forum and people have talked about it
and it seems to have been fixed.

Am I missing something ? I have experimented with CharSet.Unicode on
DllImport and it still doesnt work ?

What is the recommended way ?

Thanks
Raj



My cs files is something like this

[DllImport(Test.dll, EntryPoint = Global_PrintStringW)]
 public static extern void Global_PrintStringW(
[MarshalAs(UnmanagedType.LPWStr)]string arg1);

[DllImport(Test.dll, EntryPoint = Global_PrintStringA)]
 public static extern void Global_PrintStringA(string arg1);


   private static void StringMarshallingTest()
   {

   string newString = This is a cool string;

   Console.WriteLine(Global_PrintStringA Test );
   Global_PrintStringA(newString);

   Console.WriteLine(Global_PrintStringW Test );
   Global_PrintStringW(newString);

   }

My cpp file is something like this


extern C
{
   EXPORT_API void Global_PrintStringW(const wchar_t * str)
   {
   std::wcout  Global_PrintStringW called with   str  
std::endl;
   }

   EXPORT_API void Global_PrintStringA(const char* str)
   {
   std::wcout  Global_PrintStringA called with   str  
std::endl;
   }
}



--
View this message in context: 
http://www.nabble.com/What-is-Correct-way-to-marshal-wchar_t---tp23855173p23855173.html
Sent from the Mono - General mailing list archive at Nabble.com.

___
Mono-list maillist  -  
Mono-list@lists.ximian.commailto:Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Newbie - How to invoke compiler after installing?

[Maser, Dan]

It looks like you just have to quote the c:\Mono Test\Simple.cs on your 
command line since your directory has a space in it.


Dan Maser | Lead Software Developer
phone  fax +1.317.872.3000 | mobile +1.317.872.3000 | dan.ma...@inin.com

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com


-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of lionel keene
Sent: Monday, March 02, 2009 2:25 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Newbie - How to invoke compiler after installing?

Hello all, Mono newbie here. How do I compile the following example
(which I've entered via Microsoft Norepad and saved as c:\Mono
Test\Simple.cs:

using System.Windows.Forms;
using System.Drawing;

public class Simple : Form
{
public Simple()
{
   Text = Simple;
   Size = new Size(250, 200);
   CenterToScreen();
}

static public void Main()
{
   Application.Run(new Simple());
}
}

I've installed Mono 2.2 using the default installation parameters on
my Wndows XP box. Then, at the command prompt, I tried changing to the
compiler directory (the directory containing gmcs.exe) via:

cd c:\Program files\Mono-2.2\lib\mono\2.0

Then I invoke the compiler and specify the file to compile using the following:

gmcs -r:System.Windows.Forms.dll -r:System.Drawing.dll c:\Mono Test\simple.cs

I get errors at compile time claimg 'Mono' could not be found 
Test\Simple.cs could not be found.

After hunting aroud online I changed appended the following to my PATH
system variable:

;C:\Program Files\Mono-2.2\bin

Then I changed directories to the one containing my csharp source:

cd C:\Mono Test

I then try to compile via:

gmcs -r:System.Windows.Forms.dll -r:System.Drawing.dll c:\Mono Test\simple.cs

I get an error claiming gmcs is not recognized as an internal or
external command


 What is the proper procedure for doing this? Thanks so much in advance!

-L
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] kerne32 CreateSemaphore

[Maser, Dan]

  You can't p/invoke to windows DLLs when you're running on linux.  I doubt 
you'll get around making a conditionally compiled section for each OS, unless 
you can do everything you need with on managed calls.  You can choose where 
to put the OS-specific abstraction stuff, but not if. 

-Original Message-
From: mono-list-boun...@lists.ximian.com 
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of rg1
Sent: Tuesday, January 13, 2009 1:01 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] kerne32 CreateSemaphore



On Linux, I am getting an EntryPointNotFoundException trying to call the
CreateSemaphore function that is part of kernel32.dll. (On Windows,
naturally all works fine)


Does anyone know of a way around this on Linux without a tremendous amount
of re-writing a bunch of my code.

Thank you
-- 
View this message in context: 
http://www.nabble.com/kerne32-CreateSemaphore-tp21442221p21442221.html
Sent from the Mono - General mailing list archive at Nabble.com.

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-winforms-list] Porting application that calls windows andother DLLs

[Maser, Dan]

  Correct.  Once in a while I see some emails about Wine and such but I don't 
recall anyone ever saying that they've gotten it to work; mostly it's once in a 
while that someone asks if it *can* work and pretty much the situation is if 
you have to ask - then you don't know near enough to ever get it working.


-Original Message-
From: Matthew Donaldson [mailto:matt...@datadeliverance.com] 
Sent: Thursday, December 18, 2008 4:20 PM
To: mono-winforms-list@lists.ximian.com; Maser, Dan
Subject: RE: [Mono-winforms-list] Porting application that calls windows 
andother DLLs

Thanks, that's encouraging news.  But you definitely have to compile the DLLs 
for Linux don't you - I'm right in assuming that pinvoke on Mono won't call 
into native Windows DLLs?

+--+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd.Email: matt...@datadeliverance.com |
| 30 Musgrave Ave.  Phone: +61 8 8265 7976_|
| Banksia Park  Fax:   +61 8 8265 0032 John  / \/  |
| South Australia 5091 3:16  \_/\  |
+--+



 On Fri 19/12/08  1:07 AM , Maser, Dan dan.ma...@inin.com sent:
 In my mono application I have PInvokes that run on both Windows and Linux
 and in my experience it works and you don't even have to change the source
 code from .dll to .so.  If you put the module name
 only in the source code then the right thing happens.  The MS.NET knowns to
 append .dll when looking for the file and Mono knows to try
 both .dll and .so when running on Linux.
 Additionally, I think there's something about an xml file you can put in
 the same directory as your assembly that acts as a mapping where you can
 tell mono when looking for foo.dll you should try bar.so that
 you can use if you don't want the Windows and Linux libraries to have the
 same name.
 Of course you have to pay close attention to using the correct decorations
 for calling conventions on both libraries.
 
 -Original Message-
 From: mono-winforms-list-boun...@lists.ximian.com 
 [mono-winforms-list-boun...@lists.ximian.com] On Behalf
 Of mcgdSent: Thursday, December 18, 2008 5:42 AM
 To: mono-winforms-l...@lists.ximian.comsubject: [Mono-winforms-list] Porting 
 application that calls windows and
 other DLLs
 
 Hi,
 
 I've been asked to try and get a .NET 1.1 application working under Mono.
 It makes quite a few Windows API calls, but also calls several other
 DLLsusing PInvoke.  Most of these DLLs can probably be recompiled under
 Linux,but probably not all.
 
 From looking around, it seems that it's not
 possible to call Windows DLLsvia PInvoke using Mono, but I wanted to make 
 sure this is the case. 
 Someonementioned something called ctypes as a way of doing this, but
 this seemsto be a Python thing.
 
 I'd appreciate input on what my options might be available here, and
 whetherit's worth trying to go further.  A few other specific questions -
 answersor URLs appreciated:
 
 - Is there any way at all to get the equivalent of calls into User32.dll? 
 Most of these are in User32.dll.  The application is very
 GUI-intensive.
 - Is it possible to use Wine to run the DLLs?  I've seen references to
 thisidea, but I don't think I've found anything concrete.
 
 - If the other DLLs could be recompiled into .so files under Linux, can
 Iuse PInvoke without changing anything except .dll into
 .so, or doparameter names and types need to be changed too?  (i.e. would 
 this
 possiblybe a significant porting effort in its own right?)
 -- 
 View this message in context: 
 http://www.nabble.com/Porting-application-that-calls-windows-an
 d-other-DLLs-tp21071161p21071161.htmlSent from the Mono - WinForms mailing 
 list archive at Nabble.com.
 
 ___
 Mono-winforms-list maillist  -  
 mono-winforms-l...@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-winforms-list
 
 
 
 
 Message sent via Adam Internet WebMail  - http://www.adam.com.au/

___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-list] Is this a common error that someone has a hint about?

[Maser, Dan]

   No, I'm completely unable to create a test case...nothing else I seem to do 
reproduces the problem tho in my full app it happens every time.  For more info 
- this error happens not when the offending line is excuted but instead the 
exception is thrown before the entire function is even run.  Like mono is 
trying to compile the whole function at run time in order to execute it and 
bombs out before it starts running the whole function.

   If I send you the whole IL of that function would that do anything?  I'd 
gladly give you the whole app but it's HUGE and requires dozens of supporting 
libs special environment stuff to run.

  Thanks for your time!

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paolo Molaro
Sent: Thursday, October 09, 2008 11:56 AM
To: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Is this a common error that someone has a hint about?

On 10/08/08 Maser, Dan wrote:
   I'm using RHEL4 and I rebuilt my mono from the svn head today.  When I run 
 my app (which was working a month ago) I get this fatal exception I've not 
 seen before.  Does it look familiar to anyone?  If there are some ideas I'd 
 try them before trying to make a test app to reproduce the problem and 
 posting a bug.

 ** ERROR **: Opcode 'strlen' missing from machine description file.
 aborting...
 Stacktrace:

Do you have a complete test case? I can't reproduce.
Please file it in bugzilla.
Thanks!

lupus

--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Is this a common error that someone has a hint about?

[Maser, Dan]

::ToString()
L_0118: call string [mscorlib]System.String::Concat(string, string)
L_011d: stloc.s str2
L_011f: ldloc.s str2
L_0121: ldloc.s str2
L_0123: callvirt instance int32 [mscorlib]System.String::get_Length()
L_0128: ldc.i4.s 9
L_012a: sub
L_012b: callvirt instance string [mscorlib]System.String::Substring(int32)
L_0130: stloc.s str2
L_0132: ldloc.s str2
L_0134: ldstr 00
L_0139: callvirt instance bool [mscorlib]System.String::EndsWith(string)
L_013e: ldc.i4.0
L_013f: ceq
L_0141: stloc.s flag
L_0143: ldloc.s flag
L_0145: brtrue.s L_0152
L_0147: ldloc.s str2
L_0149: ldc.i4.0
L_014a: ldc.i4.7
L_014b: callvirt instance string [mscorlib]System.String::Substring(int32, 
int32)
L_0150: stloc.s str2
L_0152: ldstr Elapsed Time {0}:{1}:{2}.{3} ({4} messages)
L_0157: ldc.i4.5
L_0158: newarr object
L_015d: stloc.s objArray
L_015f: ldloc.s objArray
L_0161: ldc.i4.0
L_0162: ldloca.s num4
L_0164: ldstr D2
L_0169: call instance string [mscorlib]System.Int32::ToString(string)
L_016e: stelem.ref
L_016f: ldloc.s objArray
L_0171: ldc.i4.1
L_0172: ldloca.s num5
L_0174: ldstr D2
L_0179: call instance string [mscorlib]System.Int32::ToString(string)
L_017e: stelem.ref
L_017f: ldloc.s objArray
L_0181: ldc.i4.2
L_0182: ldloca.s num6
L_0184: ldstr D2
L_0189: call instance string [mscorlib]System.Int32::ToString(string)
L_018e: stelem.ref
L_018f: ldloc.s objArray
L_0191: ldc.i4.3
L_0192: ldloc.s str2
L_0194: stelem.ref
L_0195: ldloc.s objArray
L_0197: ldc.i4.4
L_0198: ldarg.0
L_0199: ldfld class ININ.LogViewer.SelectionTracker 
ININ.LogViewer.LogWindow::m_SelectedItems
L_019e: callvirt instance int32 ININ.LogViewer.SelectionTracker::get_Count()
L_01a3: box int32
L_01a8: stelem.ref
L_01a9: ldloc.s objArray
L_01ab: call string [mscorlib]System.String::Format(string, object[])
L_01b0: stloc.0
L_01b1: nop
L_01b2: ldloc.0
L_01b3: stloc.s str3
L_01b5: leave.s L_01c9
L_01b7: pop
L_01b8: nop
L_01b9: ldc.i4.0
L_01ba: call void [System]System.Diagnostics.Debug::Assert(bool)
L_01bf: nop
L_01c0: nop
L_01c1: leave.s L_01c3
L_01c3: nop
L_01c4: ldnull
L_01c5: stloc.s str3
L_01c7: br.s L_01c9
L_01c9: nop
L_01ca: ldloc.s str3
L_01cc: ret
.try L_0001 to L_01b7 catch [mscorlib]System.Exception handler L_01b7 to 
L_01c3
}





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paolo Molaro
Sent: Friday, October 10, 2008 3:31 PM
To: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Is this a common error that someone has a hint about?

On 10/10/08 Maser, Dan wrote:
If I send you the whole IL of that function would that do anything?
 I'd gladly give you the whole app but it's HUGE and requires dozens of
 supporting libs special environment stuff to run.

Yes, the IL of the function may be enough (tell us also what kind of
class/struct it's included in and if it's generic what arguments it was
instantiated with).

Thanks!

lupus

--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Is this a common error that someone has a hint about?

[Maser, Dan]

   I've got some more info now.  This happens only when I compile with Visual 
Studio on Windows and then run that binary under mono on my linux machine.  
Thru trial and error I narrowed it down to this simple code:



  String nsecString = 0 + someOtherStringVariable;

  nsecString = nsecString.Substring(nsecString.Length - 9);



and taking a guess at the exception talking about strlen I replaced the use 
of the nsecString.Length with a literal 11 and it worked.  Then I replaced 
the 11 with the nsecString.Length and the exception is back.



  However, when I make a simple test project that accesses the String.Length 
property it's fine.



  Then I looked at the IL and there's no mention of any strlen, so I assume 
this OpCode in the exception message is not talking about the IL instructions.



  Does this make any sense?




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maser, Dan
Sent: Wednesday, October 08, 2008 1:37 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Is this a common error that someone has a hint about?

  I'm using RHEL4 and I rebuilt my mono from the svn head today.  When I run my 
app (which was working a month ago) I get this fatal exception I've not seen 
before.  Does it look familiar to anyone?  If there are some ideas I'd try them 
before trying to make a test app to reproduce the problem and posting a bug.

** ERROR **: Opcode 'strlen' missing from machine description file.
aborting...
Stacktrace:

  at ININ.LogViewer.LogWindow.LogWindow_Activated (object,System.EventArgs) 
0x
  at ININ.LogViewer.LogWindow.LogWindow_Activated (object,System.EventArgs) 
0x01ce8
  at System.Windows.Forms.Form.OnActivated (System.EventArgs) 0x00044
  at System.Windows.Forms.Form.OnActivatedInternal () 0x00015
  at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Form.OnActivatedInternal () 0x
  at System.Windows.Forms.MdiWindowManager.RaiseActivated () 0x00029
  at System.Windows.Forms.Form.CreateHandle () 0x00437
  at System.Windows.Forms.Control.CreateControl () 0x0007a
  at System.Windows.Forms.Control.SetVisibleCore (bool) 0x0006f
  at System.Windows.Forms.Form.SetVisibleCore (bool) 0x00210
  at System.Windows.Forms.Control.set_Visible (bool) 0x00026
  at System.Windows.Forms.Control.Show () 0xc
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control.Show () 
0x
  at ININ.LogViewer.MDIMainForm.OpenFile (object,System.EventArgs) 0x001c7
  at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs) 0x00044
  at System.Windows.Forms.ToolStripButton.OnClick (System.EventArgs) 0x00034
  at System.Windows.Forms.ToolStripItem.HandleClick (System.EventArgs) 0x00029
  at System.Windows.Forms.ToolStripItem.FireEvent 
(System.EventArgs,System.Windows.Forms.ToolStripItemEventType) 0x0008e
  at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.ToolStripItem.FireEvent 
(System.EventArgs,System.Windows.Forms.ToolStripItemEventType) 0x
  at System.Windows.Forms.ToolStrip.OnMouseUp 
(System.Windows.Forms.MouseEventArgs) 0x0010b
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message) 
0x000fe
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message) 
0x001a2
  at System.Windows.Forms.ScrollableControl.WndProc 
(System.Windows.Forms.Message) 0xd
  at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message) 
0xd
  at System.Windows.Forms.Control/ControlWindowTarget.OnMessage 
(System.Windows.Forms.Message) 0x00014
  at System.Windows.Forms.Control/ControlNativeWindow.WndProc 
(System.Windows.Forms.Message) 0x0001f
  at System.Windows.Forms.NativeWindow.WndProc 
(intptr,System.Windows.Forms.Msg,intptr,intptr) 0x001be
  at System.Windows.Forms.XplatUIX11.DispatchMessage 
(System.Windows.Forms.MSG) 0x00023
  at System.Windows.Forms.XplatUI.DispatchMessage (System.Windows.Forms.MSG) 
0x00014
  at System.Windows.Forms.Application.RunLoop 
(bool,System.Windows.Forms.ApplicationContext) 0x0091f
  at System.Windows.Forms.Application.Run 
(System.Windows.Forms.ApplicationContext) 0x0005e
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) 0x00028
  at ININ.LogViewer.Program.Main (string[]) 0x001d4
  at (wrapper runtime-invoke) 
ININ.LogViewer.Program.runtime_invoke_void_string[] 
(object,intptr,intptr,intptr) 0x

Native stacktrace:

mono [0x806de3b]
/lib/tls/libpthread.so.0 [0x8bca90]
/lib/tls/libc.so.6(abort+0xe9) [0x67b289]
/usr/lib/libglib-2.0.so.0(g_log+0) [0x982ebe]
/usr/lib/libglib-2.0.so.0(g_log+0x32) [0x982ef0]
mono [0x81f2d17]
mono [0x8193e51]
mono [0x819574d]
mono [0x8196d81]
mono [0x806e47a]
[0x53a066]
[0xd4217d]
[0x595a436]
[0x595a3ef]
[0x595a37a]
[0xd306c0]
[0xcb6cc3]
[0xf1b4c8]
[0xd2ff61]
[0xf1b427]
[0x3b0a93d]
[0x3b0a8ff

[Mono-list] Is this a common error that someone has a hint about?

[Maser, Dan]

  I'm using RHEL4 and I rebuilt my mono from the svn head today.  When I run my 
app (which was working a month ago) I get this fatal exception I've not seen 
before.  Does it look familiar to anyone?  If there are some ideas I'd try them 
before trying to make a test app to reproduce the problem and posting a bug.

** ERROR **: Opcode 'strlen' missing from machine description file.
aborting...
Stacktrace:

  at ININ.LogViewer.LogWindow.LogWindow_Activated (object,System.EventArgs) 
0x
  at ININ.LogViewer.LogWindow.LogWindow_Activated (object,System.EventArgs) 
0x01ce8
  at System.Windows.Forms.Form.OnActivated (System.EventArgs) 0x00044
  at System.Windows.Forms.Form.OnActivatedInternal () 0x00015
  at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Form.OnActivatedInternal () 0x
  at System.Windows.Forms.MdiWindowManager.RaiseActivated () 0x00029
  at System.Windows.Forms.Form.CreateHandle () 0x00437
  at System.Windows.Forms.Control.CreateControl () 0x0007a
  at System.Windows.Forms.Control.SetVisibleCore (bool) 0x0006f
  at System.Windows.Forms.Form.SetVisibleCore (bool) 0x00210
  at System.Windows.Forms.Control.set_Visible (bool) 0x00026
  at System.Windows.Forms.Control.Show () 0xc
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control.Show () 
0x
  at ININ.LogViewer.MDIMainForm.OpenFile (object,System.EventArgs) 0x001c7
  at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs) 0x00044
  at System.Windows.Forms.ToolStripButton.OnClick (System.EventArgs) 0x00034
  at System.Windows.Forms.ToolStripItem.HandleClick (System.EventArgs) 0x00029
  at System.Windows.Forms.ToolStripItem.FireEvent 
(System.EventArgs,System.Windows.Forms.ToolStripItemEventType) 0x0008e
  at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.ToolStripItem.FireEvent 
(System.EventArgs,System.Windows.Forms.ToolStripItemEventType) 0x
  at System.Windows.Forms.ToolStrip.OnMouseUp 
(System.Windows.Forms.MouseEventArgs) 0x0010b
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message) 
0x000fe
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message) 
0x001a2
  at System.Windows.Forms.ScrollableControl.WndProc 
(System.Windows.Forms.Message) 0xd
  at System.Windows.Forms.ToolStrip.WndProc (System.Windows.Forms.Message) 
0xd
  at System.Windows.Forms.Control/ControlWindowTarget.OnMessage 
(System.Windows.Forms.Message) 0x00014
  at System.Windows.Forms.Control/ControlNativeWindow.WndProc 
(System.Windows.Forms.Message) 0x0001f
  at System.Windows.Forms.NativeWindow.WndProc 
(intptr,System.Windows.Forms.Msg,intptr,intptr) 0x001be
  at System.Windows.Forms.XplatUIX11.DispatchMessage 
(System.Windows.Forms.MSG) 0x00023
  at System.Windows.Forms.XplatUI.DispatchMessage (System.Windows.Forms.MSG) 
0x00014
  at System.Windows.Forms.Application.RunLoop 
(bool,System.Windows.Forms.ApplicationContext) 0x0091f
  at System.Windows.Forms.Application.Run 
(System.Windows.Forms.ApplicationContext) 0x0005e
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) 0x00028
  at ININ.LogViewer.Program.Main (string[]) 0x001d4
  at (wrapper runtime-invoke) 
ININ.LogViewer.Program.runtime_invoke_void_string[] 
(object,intptr,intptr,intptr) 0x

Native stacktrace:

mono [0x806de3b]
/lib/tls/libpthread.so.0 [0x8bca90]
/lib/tls/libc.so.6(abort+0xe9) [0x67b289]
/usr/lib/libglib-2.0.so.0(g_log+0) [0x982ebe]
/usr/lib/libglib-2.0.so.0(g_log+0x32) [0x982ef0]
mono [0x81f2d17]
mono [0x8193e51]
mono [0x819574d]
mono [0x8196d81]
mono [0x806e47a]
[0x53a066]
[0xd4217d]
[0x595a436]
[0x595a3ef]
[0x595a37a]
[0xd306c0]
[0xcb6cc3]
[0xf1b4c8]
[0xd2ff61]
[0xf1b427]
[0x3b0a93d]
[0x3b0a8ff]
[0xd820e0]
[0xd81efd]
[0xd81e7d]
[0xd81b22]
[0xd4da3f]
[0xd4d981]
[0xd8144c]
[0xd8119f]
[0xf14213]
[0xd31cce]
[0xd35936]
[0xf14065]
[0xf14048]
[0xf13567]
[0xd41e24]
[0xd41df5]
[0xd2f7d8]
[0xd2ee67]
[0xd2eb49]
[0xeb5465]
[0xeb51e5]
mono(mono_runtime_exec_main+0xcd) [0x80f5f65]
mono(mono_runtime_run_main+0x1df) [0x80f62c3]
mono(mono_main+0x1401) [0x805ad09]
mono [0x805946b]
/lib/tls/libc.so.6(__libc_start_main+0xd3) [0x666df3]
mono(dl_iterate_phdr+0x171) [0x80593cd]


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-list] Question about the lifetime of libraries loaded by a p/invoke

[Maser, Dan]

  The simple question is this:  When a .dll or .so is loaded by the
framework as the result of a p/invoke is that library guarenteed to stay
loaded for the duration of the hosting process?  Or can the framework
unload the dll if it wants to?  Is there anything in a spec that
indicates a standard behavior?  I've been trying to get this from the
microsoft documentation but I can't seem to find anything.

  Thanks in advance for any thoughts
Dan Maser
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-winforms-list] A font that has unicode characters?

[Maser, Dan]

   I'm using the standard System.Drawing methods to draw some text and I
notice that unicode characters are not drawn with any of the fonts that
I have available.  Can I add fonts? (How?)  Since it works properly on
windows .NET when I have an appropriate font I'm assuming for now that
it's nothing more complex than getting a suitable font.

  Thanks! 
   Dan
___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

[Mono-list] How best to detect if running in mono from an unmanaged library?

[Maser, Dan]

  I've got a situation where my managed app p/invokes to my unmanaged
library.  The unmanaged library also gets used in regular unmanaged
processes.

  The library has some logic that uses the name of the executable.
Which doesn't what I want when it's used via the interop.  For example
when the library is used from my_regular_program.exe it generates an
output file of my_regular_program.output.  When I interop to that same
library and run under mono using the command line mono my_assembly.exe
the library generates mono.output when naturally I'd prefer
my_assembly.output.

  Is there a preferred way to determine whether the process is running
under mono?  I could string-match the executable name but that won't
catch places where people compile mono with a more descriptive name such
as /usr/local/bin/mono-v1.9 or something like that.

  Thanks in advance for any ideas!
Dan

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] install libgdiplus?

[Maser, Dan]

 (mostly)
   be ok.
   
   On Wed, 2007-09-19 at 16:33 -0500, B R wrote:
 checking for BASE_DEPENDENCIES... Package glib-2.0 was not 
 found in
 the
 pkg-config search path.
 Perhaps you should add the directory containing `glib-2.0.pc'
 to the PKG_CONFIG_PATH environment variable No package 
 'glib-2.0' found
 configure: error: Package requirements (glib-2.0 = 2.2.3) 
 were not
 met:

 Consider adjusting the PKG_CONFIG_PATH environment variable if

 you installed software in a non-standard prefix.

 Alternatively, you may set the environment variables 
 BASE_DEPENDENCIES_CFLAGS and BASE_DEPENDENCIES_LIBS to avoid 
 the need to call pkg-config.
 See the pkg-config man page for more details.


 Couldn't find a glib package, but did notice that libgdiplus 
 is
 already
 listed as installed in Synaptic. Maybe I'm chasing after a red
 herring?
 Getting a System.DLLNotFoundException:gdiplus.dll when I run a
 simple
 WinForms app.




 From: Maser, Dan [EMAIL PROTECTED]
 To: B R 
 [EMAIL PROTECTED],mono-list@lists.ximian.com
 Subject: RE: [Mono-list] install libgdiplus?
 Date: Wed, 19 Sep 2007 17:14:12 -0400
 MIME-Version: 1.0
 Received: from inin.com ([209.43.1.24]) by
   bay0-mc4-f11.bay0.hotmail.com
 with Microsoft SMTPSVC(6.0.3790.2668); Wed, 19 Sep 2007 
 14:14:14
 -0700
 Received: from Unknown [172.16.1.161] by i3smtp.inin.com -
 SurfControl
 E-mail Filter (5.2.1); Wed, 19 Sep 2007 17:14:13 -0400
 X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
 X-Message-Info:


  JGTYoYF78jH49xRJghVcfmEYh8iR4pL0GdOB8KU6ep1sZuZ9BreAz7lZ5AawPuW2pJB
  UnW4JfXhFcUoymh6oFw==
 X-SEF-Processed: 5_0_0_910__2007_09_19_17_14_13
 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1
 X-MimeOLE: Produced By Microsoft Exchange V6.5
 Content-class: urn:content-classes:message
 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 
 [Mono-list]
   install
 libgdiplus?
 Thread-Index: Acf7AbwyyvR9qXDkTNCrcjTXB+xYKAAAB3lQ
 References:
 
  [EMAIL PROTECTED]
  
 [EMAIL PROTECTED]
 Return-Path: [EMAIL PROTECTED]
 X-OriginalArrivalTime: 19 Sep 2007 21:14:14.0318 (UTC) 
 FILETIME=[07D3DCE0:01C7FB02]
 
 
Maybe send the end of the text from the ./configure 
  then?  Is
   there
 a Makefile in your directory which appears after running 
 ./configure?  I assume not, the output below looks as tho 
 the ./configure process did not output a Makefile.
 
 -Original Message-
 From: B R [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, September 19, 2007 4:12 PM
 To: Maser, Dan; mono-list@lists.ximian.com
 Subject: RE: [Mono-list] install libgdiplus?
 
 [EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$ make
 make: *** No targets specified and no makefile found.  Stop.
 
 [EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$ make install
 make: *** No rule to make target `install'.  Stop.
 
 [EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$
 make check
 make: *** No rule to make target `check'.  Stop.
 
 
 
  From: Maser, Dan [EMAIL PROTECTED]
  To: B R 
  [EMAIL PROTECTED],mono-list@lists.ximian.com
  Subject: RE: [Mono-list] install libgdiplus?
  Date: Wed, 19 Sep 2007 17:06:50 -0400
  MIME-Version: 1.0
  Received: from inin.com ([209.43.1.24]) by
 bay0-mc9-f23.bay0.hotmail.com
  with Microsoft SMTPSVC(6.0.3790.2668); Wed, 19 Sep 2007 
  14:06:52
   -0700
  Received: from Unknown [172.16.1.161] by i3smtp.inin.com -
   SurfControl
  E-mail Filter (5.2.1); Wed, 19 Sep 2007 17:06:52 -0400
  X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
  X-Message-Info:
 

  JGTYoYF78jF4KkBuPcVLyNgG8JmcWdspwdQTTu3pdOzE+yAAnkcj+T4Jab14Tv7W02e
  JGTYoYF78jF4KkBuPcVLyNgG8JmcWdspwdQTTu3pdOzE+yAAnkcj+If98
 /dDPvLwxT14oxeA==
  X-SEF-Processed: 5_0_0_910__2007_09_19_17_06_52
  X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1
  X-MimeOLE: Produced By Microsoft Exchange V6.5
  Content-class: urn:content-classes:message
  X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 
  [Mono-list]
 install
  libgdiplus?
  Thread-Index: Acf7AM4qXMuQCG85SQKLGcJMLKQUgAAACfnQ
  References: [EMAIL PROTECTED]
  Return-Path: [EMAIL PROTECTED]
  X-OriginalArrivalTime: 19 Sep 2007 21:06:52.0711 (UTC) 
  FILETIME=[009BFB70:01C7FB01]
  
  
It should help if you send the output of the command.
  
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of B 
  R
  Sent: Wednesday, September 19, 2007 4:05 PM
  To: mono-list@lists.ximian.com
  Subject: [Mono-list] install libgdiplus?
  
  I'm having difficulties installing libgdiplus on my Ubuntu 
  test
   system.
  Per the install

Re: [Mono-list] install libgdiplus?

[Maser, Dan]

  Nice progress.  It sounds like you're very close to give up now!   Can
you run mono with the --debug flag?  It should show in the text where
it's trying to load from.


-Original Message-
From: B R [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 20, 2007 2:47 PM
To: Maser, Dan; [EMAIL PROTECTED]
Cc: mono-list@lists.ximian.com
Subject: RE: [Mono-list] install libgdiplus?

finally got ./configure to complete. Had to install ALL of these
packages:

libglib2-dev
libfontconfig1-dev
libfreetype6-dev
libxrender-dev
libtiff-dev
libjpeg-dev
libgif-dev
libpng-dev (still get some errors about this one though) libexif-dev

Was able to do a make, then make install. Didn't seem to help. So,
tried installing the new mono (1.2.5.1). Didn't help. Followed the
instructions on this page:

http://www.mono-project.com/DllNotFoundException

ldconfig can now find libgdiplus.so, but my app STILL produces that same
error.  Think I've had enough with Mono and WinForms.  Gonna try my luck
with a GTK app.




From: Maser, Dan [EMAIL PROTECTED]
To: [EMAIL PROTECTED],B R [EMAIL PROTECTED]
CC: mono-list@lists.ximian.com
Subject: RE: [Mono-list] install libgdiplus?
Date: Thu, 20 Sep 2007 09:02:49 -0400
MIME-Version: 1.0
Received: from inin.com ([209.43.1.24]) by 
bay0-mc11-f13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); 
Thu, 20 Sep 2007 06:02:53 -0700
Received: from Unknown [172.16.1.161] by i3smtp.inin.com - SurfControl 
E-mail Filter (5.2.1); Thu, 20 Sep 2007 09:02:53 -0400
X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
X-Message-Info: 
JGTYoYF78jG6J/yEQ6b3ERhANwh9zzF0+XdmW/FGtjqopPeMSNGiHyJHvWyclsXUg2+44Oa
j1+R+xTC7bVY1Tw==
X-SEF-Processed: 5_0_0_910__2007_09_20_09_02_53
X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mono-list] 
install libgdiplus?
Thread-Index: Acf7fxazeQ0swLtNT9yebW8sqzrMdQABx1qg
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 20 Sep 2007 13:02:55.0253 (UTC) 
FILETIME=[8F594450:01C7FB86]


   For clarification many things have *two* separate install packages, 
in this case glib and glib-devel.  There should be dozens of 
packages that follow the foo and foo-devel format.  So it's likely 
that you have the glib package installed (which includes the runtime 
for executing programs) but don't have the glib-devel installed (which 
includes additional information which allows programs to compile 
against the glib).

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sebastien 
Pouliot
Sent: Thursday, September 20, 2007 7:06 AM
To: B R
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] install libgdiplus?

On Wed, 2007-09-19 at 22:10 -0500, B R wrote:
  yes, libgdiplus is present on the system. But its been mentioned 
  that any other libgdiplus other than what comes with Mono, doesn't 
  work. So

  that's why I'm trying to compile it.

Not quite.

I said that you need to have a libgdiplus version that *match* your 
Mono version, otherwise you can have *runtime* issues (that no one can 
replicate).

Now AFAIK the Mono installer includes both a Mono and a libgdiplus 
version that match this condition. If your original install was correct

then it should be working.

  glib may have already been installed, but I was just going with the 
  what the error message said.

You're misinterpreting the messages. The missing .pc was for 
development packages, not to download and install a newer glib.

  so what are the ./configure requirements?

The exact requirements depends on your actual configuration, i.e. 
what's installed or not.

Short story:

As long as ./configure fails {
   read the error message
   fix it
}

  How about what the error message said about the path? Not sure if 
  resolving that would change anything.

Probably not as you said you didn't have any file named glib-2.0.pc 
installed on your system. If you had then yes you could adjust the path

to make sure it's found.

 
  From: Sebastien Pouliot [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
  To: B R [EMAIL PROTECTED]
  CC: mono-list@lists.ximian.com
  Subject: Re: [Mono-list] install libgdiplus?
  Date: Wed, 19 Sep 2007 20:05:33 -0400
  MIME-Version: 1.0
  Received: from relais.videotron.ca ([24.201.245.36]) by 
  bay0-mc1-f2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444);

  Wed, 19 Sep 2007 17:04:59 -0700
  Received: from poupou.home ([24.203.181.222]) by 
  VL-MH-MR001.ip.videotron.ca (Sun Java System Messaging Server
  6.2-2.05 (built Apr 28 2005)) with ESMTP id 
  [EMAIL PROTECTED] for 
  [EMAIL PROTECTED]; Wed, 19 Sep 2007 20:04:53 -0400 (EDT)
  X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
  X-Message-Info:
  JGTYoYF78jGuESsWr17bNBMPySJCrKWs3QL2adMSPTsursO07KTloEvf8aIknO6psFF
  hY
  fGElgnwYSd9AIeolw==
  X-Mailer: Evolution 2.6.0
  References: [EMAIL

Re: [Mono-list] MeasureString

[Maser, Dan]

 
  It might be a real issue, but my app has the need to measure strings
too and I've found that MeasureString is often quite wrong.  The MSDN
docs indicate that it often is too, and recommends using
Graphics.MeasureCharacterRanges instead.   You might consider trying
that approach as a work-around.   I know that I've removed all
references to MeasureString in my app in favor of MeasureCharacterRanges
which is far more reliable for me.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jansen Bart
Sent: Thursday, September 20, 2007 3:28 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] MeasureString



Hi all,

 

I'm trying to ensure that a string fits in a rectangle shown on screen,
so whenever the string is too long, some characters are stripped.  I'm
using MeasureString to accomplish this.  With mono under windows this is
working fine, under linux the resulting string is always way too long.
Is this a known issue? Is there a workaround?

 

Thanks a lot for your help,

 

B.

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] install libgdiplus?

[Maser, Dan]

  Maybe send the end of the text from the ./configure then?  Is there
a Makefile in your directory which appears after running
./configure?  I assume not, the output below looks as tho the
./configure process did not output a Makefile. 

-Original Message-
From: B R [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 19, 2007 4:12 PM
To: Maser, Dan; mono-list@lists.ximian.com
Subject: RE: [Mono-list] install libgdiplus?

[EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$ make
make: *** No targets specified and no makefile found.  Stop.

[EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$ make install
make: *** No rule to make target `install'.  Stop.

[EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$
make check
make: *** No rule to make target `check'.  Stop.



From: Maser, Dan [EMAIL PROTECTED]
To: B R [EMAIL PROTECTED],mono-list@lists.ximian.com
Subject: RE: [Mono-list] install libgdiplus?
Date: Wed, 19 Sep 2007 17:06:50 -0400
MIME-Version: 1.0
Received: from inin.com ([209.43.1.24]) by
bay0-mc9-f23.bay0.hotmail.com 
with Microsoft SMTPSVC(6.0.3790.2668); Wed, 19 Sep 2007 14:06:52 -0700
Received: from Unknown [172.16.1.161] by i3smtp.inin.com - SurfControl 
E-mail Filter (5.2.1); Wed, 19 Sep 2007 17:06:52 -0400
X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
X-Message-Info: 
JGTYoYF78jF4KkBuPcVLyNgG8JmcWdspwdQTTu3pdOzE+yAAnkcj+T4Jab14Tv7W02eIf98
/dDPvLwxT14oxeA==
X-SEF-Processed: 5_0_0_910__2007_09_19_17_06_52
X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mono-list]
install 
libgdiplus?
Thread-Index: Acf7AM4qXMuQCG85SQKLGcJMLKQUgAAACfnQ
References: [EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 19 Sep 2007 21:06:52.0711 (UTC) 
FILETIME=[009BFB70:01C7FB01]


  It should help if you send the output of the command.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of B R
Sent: Wednesday, September 19, 2007 4:05 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] install libgdiplus?

I'm having difficulties installing libgdiplus on my Ubuntu test system.
Per the install instructions, I first run ./configure which seems to
run fine.
But it won't take any of the make commands. Make is installed on the
system and updated to the latest version. Anyone got any ideas? Thanks


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list






___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] install libgdiplus?

[Maser, Dan]

 It should help if you send the output of the command. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of B R
Sent: Wednesday, September 19, 2007 4:05 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] install libgdiplus?

I'm having difficulties installing libgdiplus on my Ubuntu test system.
Per the install instructions, I first run ./configure which seems to
run fine. 
But it won't take any of the make commands. Make is installed on the
system and updated to the latest version. Anyone got any ideas? Thanks


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] install libgdiplus?

[Maser, Dan]

  I think I saw something a while back about Mono needing its own
libgdiplus and won't work correctly with a public one from somewhere
else.

  But your second point could be correct too.  The default build process
puts binaries in /usr/local/lib and I had to add that to my
/etc/ld.so.conf file (or to my LD_LIBRARY_PATH variable) to allow things
to work properly.  Where on your machine is the gdiplus.dll? When you
find it, see if your system library path needs updating. 

-Original Message-
From: B R [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 19, 2007 4:34 PM
To: Maser, Dan; mono-list@lists.ximian.com
Subject: RE: [Mono-list] install libgdiplus?

checking for BASE_DEPENDENCIES... Package glib-2.0 was not found in the 
pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found
configure: error: Package requirements (glib-2.0 = 2.2.3) were not met:

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables 
BASE_DEPENDENCIES_CFLAGS
and BASE_DEPENDENCIES_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


Couldn't find a glib package, but did notice that libgdiplus is already 
listed as installed in Synaptic. Maybe I'm chasing after a red herring? 
Getting a System.DLLNotFoundException:gdiplus.dll when I run a simple 
WinForms app.




From: Maser, Dan [EMAIL PROTECTED]
To: B R [EMAIL PROTECTED],mono-list@lists.ximian.com
Subject: RE: [Mono-list] install libgdiplus?
Date: Wed, 19 Sep 2007 17:14:12 -0400
MIME-Version: 1.0
Received: from inin.com ([209.43.1.24]) by
bay0-mc4-f11.bay0.hotmail.com 
with Microsoft SMTPSVC(6.0.3790.2668); Wed, 19 Sep 2007 14:14:14 -0700
Received: from Unknown [172.16.1.161] by i3smtp.inin.com - SurfControl 
E-mail Filter (5.2.1); Wed, 19 Sep 2007 17:14:13 -0400
X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
X-Message-Info: 
JGTYoYF78jH49xRJghVcfmEYh8iR4pL0GdOB8KU6ep1sZuZ9BreAz7lZ5AawPuW2pJBUnW4
JfXhFcUoymh6oFw==
X-SEF-Processed: 5_0_0_910__2007_09_19_17_14_13
X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mono-list]
install 
libgdiplus?
Thread-Index: Acf7AbwyyvR9qXDkTNCrcjTXB+xYKAAAB3lQ
References: 
[EMAIL PROTECTED] 
[EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 19 Sep 2007 21:14:14.0318 (UTC) 
FILETIME=[07D3DCE0:01C7FB02]


   Maybe send the end of the text from the ./configure then?  Is
there
a Makefile in your directory which appears after running
./configure?  I assume not, the output below looks as tho the
./configure process did not output a Makefile.

-Original Message-
From: B R [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 19, 2007 4:12 PM
To: Maser, Dan; mono-list@lists.ximian.com
Subject: RE: [Mono-list] install libgdiplus?

[EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$ make
make: *** No targets specified and no makefile found.  Stop.

[EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$ make install
make: *** No rule to make target `install'.  Stop.

[EMAIL PROTECTED]:~/Desktop/libgdiplus-1.2.5$
make check
make: *** No rule to make target `check'.  Stop.



 From: Maser, Dan [EMAIL PROTECTED]
 To: B R [EMAIL PROTECTED],mono-list@lists.ximian.com
 Subject: RE: [Mono-list] install libgdiplus?
 Date: Wed, 19 Sep 2007 17:06:50 -0400
 MIME-Version: 1.0
 Received: from inin.com ([209.43.1.24]) by
bay0-mc9-f23.bay0.hotmail.com
 with Microsoft SMTPSVC(6.0.3790.2668); Wed, 19 Sep 2007 14:06:52
-0700
 Received: from Unknown [172.16.1.161] by i3smtp.inin.com -
SurfControl
 E-mail Filter (5.2.1); Wed, 19 Sep 2007 17:06:52 -0400
 X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
 X-Message-Info:

JGTYoYF78jF4KkBuPcVLyNgG8JmcWdspwdQTTu3pdOzE+yAAnkcj+T4Jab14Tv7W02eIf98
/dDPvLwxT14oxeA==
 X-SEF-Processed: 5_0_0_910__2007_09_19_17_06_52
 X-SEF-439E6655-7365-4FE1-A53E-B05742EF2C96: 1
 X-MimeOLE: Produced By Microsoft Exchange V6.5
 Content-class: urn:content-classes:message
 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mono-list]
install
 libgdiplus?
 Thread-Index: Acf7AM4qXMuQCG85SQKLGcJMLKQUgAAACfnQ
 References: [EMAIL PROTECTED]
 Return-Path: [EMAIL PROTECTED]
 X-OriginalArrivalTime: 19 Sep 2007 21:06:52.0711 (UTC)
 FILETIME=[009BFB70:01C7FB01]
 
 
   It should help if you send the output of the command.
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of B R
 Sent: Wednesday, September 19, 2007 4:05 PM
 To: mono-list@lists.ximian.com
 Subject: [Mono-list] install libgdiplus?
 
 I'm having difficulties installing libgdiplus on my Ubuntu test
system.
 Per the install instructions, I first run ./configure which seems
to
 run fine.
 But it won't take any of the make commands. Make

Re: [Mono-winforms-list] Dynamic drawing of Images on the form

[Maser, Dan]

 You must be very tired, otherwise why all the sleeping?  You don't need
any sleeps to be able to accomplish what you're doing. 
 
  Overall this is far better than what you had last time.   Here's the
idea of what you need to do:
 
 
private void t1Elapsed(object source, ElapsedEventArgs e)

{

 intCtr++;

 if (intCtr == Cntr - 1)

 {

intCtr = 0;

 }

 

 this.Invalidate();  // Or, just invalidate the rect where
the picture is if you can

}

 

protected override void OnPaint(PaintEventArgs e)

{

base.OnPaint(e);

try

{ 

   PaintFinalRect(enS.EnCodeString((string)a2[intCtr]),
e.Graphics);

}

catch (System.Exception)

{

}

}

 


___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-winforms-list] Dynamic drawing of Images on the form

[Maser, Dan]

   I would expect this code to do strange things.  I would highly
recommend getting your logic out of the paint routine.  Specifically:
 
1. Your OnPaint should be simple, and should paint the window and
return.  No sleeps should be here, ever.
2. I would only calls the base.OnPaint once.
3. My hunch is that it's not ok to call the static Graphics.FromHwnd
from inside the OnPaint handler.  Use the Graphics object that was
passed to you, don't create another one.
4. Don't Dispose the object that gr points to - it was passed to you and
you don't own it.
 
 
I think you ahve two main choices (after fixing the above things);
 
A. you can code up the OnPaint function to paint the correct ONE of your
images.  Then you can make a Timer object on your form.  When the timer
fires, update a member variable that indicates which images is 'current'
and call Invalidate so the system will invoke your OnPaint again and
you'll paint the newer image.
 
B. you can code up the OnPaint function to paint the correct ONE of your
images.  Then you can make a Timer object on your form.  When the timer
fires, you can call the static Graphics.FromHwnd to get a graphics
object and directly paint the newer image.  Also update a member
variable with the current image so that if your window is covered and
uncovered it will paint the correct thing.
 
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Abir
Bhattacharya
Sent: Wednesday, September 12, 2007 6:16 AM
To: mono-winforms-list@lists.ximian.com
Subject: [Mono-winforms-list] Dynamic drawing of Images on the form



HI, 

 

I need to display some dynamic images on a windows form at regular
intervals based on some logic. The code runs perfectly fine with .NET
and as well as the Win MONO(1.2.4) platforms , but when I port the
identical code to the Mono develop running on the Linux (2.6.22-Fedora)
the images are displayed in sporadic bursts . 

 

The code snippet:

protected override void OnPaint(PaintEventArgs e)

{

//base.OnPaint(e);

Graphics gr ,gf;

gr = e.Graphics;

gf = Graphics.FromHwnd(this.Handle);

 

for (; intCtr  Cntr; intCtr += 1)

{

 



// call the final rect

//passEncStr = enS.EnCodeString((string)a2[intCtr]);

PaintFinalRect(enS.EnCodeString((string)a2[intCtr]),gr);

Thread.Sleep(100);

base.OnPaint(e);

gf.FillRectangle(new SolidBrush(this.BackColor),
this.ClientRectangle);

gr.Dispose();

 

if (intCtr == Cntr - 1)

{

intCtr = 0;

}

 



}

 





return;



   

 

}

 

I s there a problem with the primary thread Sleep methods ?




-- Visit us at http://www.2pirad.com/ --

___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-list] DockPanel or something like thtat for mono?

[Maser, Dan]

  I looked at DockPanel Suite a while back.  I saw how the Win32
interops were being used and figured it was reasonable to remove them.
In fact, Weifen Luo agrees... See this thread:

http://sourceforge.net/forum/forum.php?thread_id=1786012forum_id=402316

  The thread does mention that the MonoDevelop app has docking, and uses
Gtk#.  I've not checked, but if the interfaces are similar it might be
reasonable to make a wrapper class such that Win32 apps use the
DockPanel Suite and Linux apps use Gtk#? 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of DW
Sent: Thursday, September 06, 2007 6:37 AM
To: Mono-list@lists.ximian.com
Subject: [Mono-list] DockPanel or something like thtat for mono?

Hello,
is it possible to build mono apps with a GUI like VS or Eclipse?
a really great lib for that is Weifen Luo's DockPanel Suite. [1]

is there something equal for the mono world? the way monodevelop
implemented this isnt complete. they can minimize panels, but can't
autopopup and drag them around. or am i missing something at this point?

thx for any informations

regards

Daniel

[1] http://sourceforge.net/projects/dockpanelsuite

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-winforms-list] Mono winforms running on different linuxDISPLAY?

[Maser, Dan]

  Thanks for the info.  I doubt this looks like bug #74013 since
everything here is an Intel x86 machine and should have the same
endian-ness.  I did some bugzilla queries and don't see anything
directly relevant so I'll create a new bug with my call stacks and OS
info for tracking.

  Thanks 
Dan Maser

-Original Message-
From: Sebastien Pouliot [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 20, 2007 1:13 PM
To: Maser, Dan
Cc: mono-winforms-list@lists.ximian.com
Subject: Re: [Mono-winforms-list] Mono winforms running on different
linuxDISPLAY?

Hello Dan,

On Mon, 2007-08-20 at 13:31 -0400, Maser, Dan wrote:
 
   I'm using the latest SVN code and I'm still not able to run mono 
 apps on a different X display using the DISPLAY env variable like I 
 can with other apps.  I can only run mono apps directly on the linux 
 console.

Does it looks like bug #74013 ? either the first part (endian bugs
introducing bad colors) or the later part (crash) ?

If so add yourself to the bug c.c. (if not then fill a new bug report).
That way you'll get automatically notified if anything change wrt to the
issue.

I raised this issue about a year or so ago and at the time someone 
 mentioned something about this being a known problem in gdiplus/cairo 
 and would be fixed in a later version.

Sadly there's too many cases where someone said something about a year
ago about known issue in gdiplus/cairo. Some were fixed, others still
exists. In any case bugzilla knows best.

 Since it's been about a year I wanted to check to see if this issue is

 on any schedule and if so, what it's estimated target might be.
 
Thanks in advance,

Sorry I can't tell you much more right now, but this lacks too many
details.

  Dan Maser
 
 ___
 Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
Sebastien Pouliot  [EMAIL PROTECTED]
Blog: http://pages.infinit.net/ctech/



___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-winforms-list] Handle being created when I don't expect

[Maser, Dan]

Excellent ideas, thanks.  I'll go add those right now. 

-Original Message-
From: Rolf Bjarne Kvinge [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 10, 2007 11:23 AM
To: Maser, Dan; mono-winforms-list@lists.ximian.com
Subject: RE: [Mono-winforms-list] Handle being created when I don't expect



 -Original Message-
 From: Maser, Dan [mailto:[EMAIL PROTECTED]
 Sent: viernes, 10 de agosto de 2007 14:34
 To: Rolf Bjarne Kvinge; mono-winforms-list@lists.ximian.com
 Subject: RE: [Mono-winforms-list] Handle being created when I don't 
 expect
 
 
That's the first time the HandleCreated event is fired, I have a 
 MessageBox.Show in the first line of the HandleCreated handler and 
 this is the first time I see it.  As such, how can I show you a call 
 stack for the first time the handle is created if this is the first 
 time the HandleCreated event is fired?
 

I never rely on events for debugging :)
Try overriding CreateHandle and print a stack trace from there (remember to 
call the base class as well).
You can also override WndProc and watch out for WM_CREATE (0x1) and WM_DESTROY 
(0x2).

And just before doing:
form.MdiParent = theParent;

Do this:
Console.WriteLine (form.IsHandleCreated) Which will tell you if the handle has 
already been created or not.

Rolf

I wonder if I should hack in some Console.WriteLine statements into 
 the mono source and recompile to see?
 
Dan
 
 -Original Message-
 From: Rolf Bjarne Kvinge [mailto:[EMAIL PROTECTED]
 Sent: Friday, August 10, 2007 6:23 AM
 To: Maser, Dan; mono-winforms-list@lists.ximian.com
 Subject: RE: [Mono-winforms-list] Handle being created when I don't 
 expect
 
 
 
  -Original Message-
  From: Maser, Dan [mailto:[EMAIL PROTECTED]
  Sent: jueves, 09 de agosto de 2007 15:15
  To: Rolf Bjarne Kvinge; mono-winforms-list@lists.ximian.com
  Subject: RE: [Mono-winforms-list] Handle being created when I don't 
  expect
 
 
Sure. I'm using the latest mono I built from the SVN source on 
  08/07/2007.  The call stack with file/line info is really wide, so 
  I've attached it as a text file to this message.
 
 
 When setting MdiParent the handle is being *re*created, not created, 
 and this is matching MS' behavior.
 
 To know when the handle was created in the first place I'd need 
 another stack trace :)
 
 Rolf
 
Thanks!
 
  -Original Message-
  From: Rolf Bjarne Kvinge [mailto:[EMAIL PROTECTED]
  Sent: Thursday, August 09, 2007 2:15 AM
  To: Maser, Dan; mono-winforms-list@lists.ximian.com
  Subject: RE: [Mono-winforms-list] Handle being created when I don't 
  expect
 
 
 
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  Maser, Dan
  Sent: miércoles, 08 de agosto de 2007 23:49
  To: Maser, Dan; mono-winforms-list@lists.ximian.com
  Subject: Re: [Mono-winforms-list] Handle being created when I don't 
  expect
  
    Sorry, that got sent too early.  Here's more of the call stack
 this
  time.
 
 
  Could you execute with mono --debug app.exe so that you get line 
  numbers as well? And knowing which version of Winforms you're using 
  would also help
  :)
 
  Rolf
 
  _
  From:   Maser, Dan
  Sent:   Wednesday, August 08, 2007 4:39 PM
  To: 'mono-winforms-list@lists.ximian.com'
  Subject:    Handle being created when I don't expect
 
    I've got a situation with MDI forms where the behavior is
 different
  on MS
  vs mono, but it's proving difficult to get a simple test project 
  that
  reproduces it.  The problem is that in my app setting the 
  Form.MdiParent is
  causing that Form's handle to be created in mono when it doesn't on
  MS.NET.   And it doesn't happen for simple test programs on mono 
  either;
  with simple test programs setting the MdiParent property doesn't
 cause
  the
  handle to be created.  I think it must be something about my real 
  project
  that causes this, but the program is so large it's difficult to tell 
  what that might be.  Here's a partial call stack from the 
  Form.HandleCreated event.  Does this info give enough info to 
  someone to make some guesses about what could cause the MdiParent 
  property
 to
  trigger the HandleCreated in some projects but not in others?
    Thanks in advance for any ideas!
   Partial call stack:
  at MyChildForm.on_HandleCreated(System.Object sender, 
  System.EventArgs
  e) at System.Windows.Forms.Control.OnHandleCreated(System.EventArgs
  e) at System.Windows.Forms.Form.OnHandleCreated(System.EventArgs e) 
  at System.Windows.Forms.Control.WmCreate(Message ByRef m) at 
  System.Windows.Forms.Control.WndProc(Message ByRef m) at 
  System.Windows.Forms.ScrollableControl.WndProc(Message ByRef m) at 
  System.Windows.Forms.ContainerControl.WndProc(Message ByRef m) at 
  System.Windows.Forms.Form.WndProc(Message ByRef m) at 
  System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message
  ByRef
  m)
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc

Re: [Mono-winforms-list] Handle being created when I don't expect

[Maser, Dan]

  Sure. I'm using the latest mono I built from the SVN source on 08/07/2007.  
The call stack with file/line info is really wide, so I've attached it as a 
text file to this message.

  Thanks!

-Original Message-
From: Rolf Bjarne Kvinge [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 09, 2007 2:15 AM
To: Maser, Dan; mono-winforms-list@lists.ximian.com
Subject: RE: [Mono-winforms-list] Handle being created when I don't expect



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maser, Dan
Sent: miércoles, 08 de agosto de 2007 23:49
To: Maser, Dan; mono-winforms-list@lists.ximian.com
Subject: Re: [Mono-winforms-list] Handle being created when I don't 
expect

  Sorry, that got sent too early.  Here's more of the call stack this time.


Could you execute with mono --debug app.exe so that you get line numbers as 
well? And knowing which version of Winforms you're using would also help
:)

Rolf

_
From:   Maser, Dan
Sent:   Wednesday, August 08, 2007 4:39 PM
To: 'mono-winforms-list@lists.ximian.com' 
Subject:    Handle being created when I don't expect

  I've got a situation with MDI forms where the behavior is different 
on MS
vs mono, but it's proving difficult to get a simple test project that
reproduces it.  The problem is that in my app setting the 
Form.MdiParent is
causing that Form's handle to be created in mono when it doesn't on
MS.NET.   And it doesn't happen for simple test programs on mono 
either;
with simple test programs setting the MdiParent property doesn't cause the
handle to be created.  I think it must be something about my real 
project
that causes this, but the program is so large it's difficult to tell what that 
might be.  Here's a partial call stack from the Form.HandleCreated event.  
Does this info give enough info to someone to make some guesses about what 
could cause the MdiParent property to trigger the HandleCreated in some 
projects but not in others?
  Thanks in advance for any ideas! 
 Partial call stack: 
at MyChildForm.on_HandleCreated(System.Object sender, System.EventArgs 
e) at System.Windows.Forms.Control.OnHandleCreated(System.EventArgs e) 
at System.Windows.Forms.Form.OnHandleCreated(System.EventArgs e) at 
System.Windows.Forms.Control.WmCreate(Message ByRef m) at 
System.Windows.Forms.Control.WndProc(Message ByRef m) at 
System.Windows.Forms.ScrollableControl.WndProc(Message ByRef m) at 
System.Windows.Forms.ContainerControl.WndProc(Message ByRef m) at 
System.Windows.Forms.Form.WndProc(Message ByRef m) at 
System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message 
ByRef
m) 
at System.Windows.Forms.Control+ControlNativeWindow.WndProc(Message 
ByRef
m) 
at System.Windows.Forms.NativeWindow.WndProc(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at System.Windows.Forms.XplatUIX11.SendMessage(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at
System.Windows.Forms.XplatUIX11.CreateWindow(System.Windows.Forms.CreatePara
ms cp) 
at
System.Windows.Forms.XplatUI.CreateWindow(System.Windows.Forms.CreateParams
cp) 
at
System.Windows.Forms.NativeWindow.CreateHandle(System.Windows.Forms.CreatePa
rams create_params) 
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Form.CreateHandle()
at System.Windows.Forms.Control.WmDestroy(Message ByRef m) at 
System.Windows.Forms.Control.WndProc(Message ByRef m) at 
System.Windows.Forms.ScrollableControl.WndProc(Message ByRef m) at 
System.Windows.Forms.ContainerControl.WndProc(Message ByRef m) at 
System.Windows.Forms.Form.WmDestroy(Message ByRef m) at 
System.Windows.Forms.Form.WndProc(Message ByRef m) at 
System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message 
ByRef
m) 
at System.Windows.Forms.Control+ControlNativeWindow.WndProc(Message 
ByRef
m) 
at System.Windows.Forms.NativeWindow.WndProc(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at System.Windows.Forms.XplatUIX11.SendMessage(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at System.Windows.Forms.XplatUIX11.DestroyWindow(IntPtr handle) at 
System.Windows.Forms.XplatUI.DestroyWindow(IntPtr handle) at 
System.Windows.Forms.NativeWindow.DestroyWindow()
at System.Windows.Forms.Control.DestroyHandle()
at System.Windows.Forms.Control.RecreateHandle()
at System.Windows.Forms.Form.set_MdiParent(System.Windows.Forms.Form 
value)

 
There's more, but this seems like the relevant part. 












at MyChildForm.on_HandleCreated(System.Object sender, System.EventArgs e) in 
/home/danm/builds/test1/child_window.cs:line 123
at System.Windows.Forms.Control.OnHandleCreated(System.EventArgs e) in 
/home/danm/mono_src/anon_svn/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:line
 5767
at System.Windows.Forms.Form.OnHandleCreated(System.EventArgs e) in 
/home/danm/mono_src/anon_svn/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Forms.cs:line
 1979
at System.Windows.Forms.Control.WmCreate(Message ByRef m) in 
/home/danm/mono_src

Re: [Mono-winforms-list] Handle being created when I don't expect

[Maser, Dan]

Also, if it helps I hacked my code to not crash when the HandleCreated is 
called early and I notice the these additional problems right away:

* When opening the first MDI child, that window does not get an Activated event 
like it used to.  If I open a second MDI child and toggle between them then the 
Activate gets called, but with one MDI child the Actived event is skipped.

* There seems to be a focus/current problem because if I have MDI Child #1 
active I can click around in it and see the mouse clicks have the normal effect 
but when I press Ctrl+F2 that keystroke appears to get sent to MDI Child #2 
instead.

   I update my mono installation from SVN source every couple of days and all 
of these items were working as of a few weeks ago.


-Original Message-
From: Rolf Bjarne Kvinge [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 09, 2007 2:15 AM
To: Maser, Dan; mono-winforms-list@lists.ximian.com
Subject: RE: [Mono-winforms-list] Handle being created when I don't expect



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maser, Dan
Sent: miércoles, 08 de agosto de 2007 23:49
To: Maser, Dan; mono-winforms-list@lists.ximian.com
Subject: Re: [Mono-winforms-list] Handle being created when I don't 
expect

  Sorry, that got sent too early.  Here's more of the call stack this time.


Could you execute with mono --debug app.exe so that you get line numbers as 
well? And knowing which version of Winforms you're using would also help
:)

Rolf

_
From:   Maser, Dan
Sent:   Wednesday, August 08, 2007 4:39 PM
To: 'mono-winforms-list@lists.ximian.com' 
Subject:    Handle being created when I don't expect

  I've got a situation with MDI forms where the behavior is different 
on MS
vs mono, but it's proving difficult to get a simple test project that
reproduces it.  The problem is that in my app setting the 
Form.MdiParent is
causing that Form's handle to be created in mono when it doesn't on
MS.NET.   And it doesn't happen for simple test programs on mono 
either;
with simple test programs setting the MdiParent property doesn't cause the
handle to be created.  I think it must be something about my real 
project
that causes this, but the program is so large it's difficult to tell what that 
might be.  Here's a partial call stack from the Form.HandleCreated event.  
Does this info give enough info to someone to make some guesses about what 
could cause the MdiParent property to trigger the HandleCreated in some 
projects but not in others?
  Thanks in advance for any ideas! 
 Partial call stack: 
at MyChildForm.on_HandleCreated(System.Object sender, System.EventArgs 
e) at System.Windows.Forms.Control.OnHandleCreated(System.EventArgs e) 
at System.Windows.Forms.Form.OnHandleCreated(System.EventArgs e) at 
System.Windows.Forms.Control.WmCreate(Message ByRef m) at 
System.Windows.Forms.Control.WndProc(Message ByRef m) at 
System.Windows.Forms.ScrollableControl.WndProc(Message ByRef m) at 
System.Windows.Forms.ContainerControl.WndProc(Message ByRef m) at 
System.Windows.Forms.Form.WndProc(Message ByRef m) at 
System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message 
ByRef
m) 
at System.Windows.Forms.Control+ControlNativeWindow.WndProc(Message 
ByRef
m) 
at System.Windows.Forms.NativeWindow.WndProc(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at System.Windows.Forms.XplatUIX11.SendMessage(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at
System.Windows.Forms.XplatUIX11.CreateWindow(System.Windows.Forms.CreatePara
ms cp) 
at
System.Windows.Forms.XplatUI.CreateWindow(System.Windows.Forms.CreateParams
cp) 
at
System.Windows.Forms.NativeWindow.CreateHandle(System.Windows.Forms.CreatePa
rams create_params) 
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.Form.CreateHandle()
at System.Windows.Forms.Control.WmDestroy(Message ByRef m) at 
System.Windows.Forms.Control.WndProc(Message ByRef m) at 
System.Windows.Forms.ScrollableControl.WndProc(Message ByRef m) at 
System.Windows.Forms.ContainerControl.WndProc(Message ByRef m) at 
System.Windows.Forms.Form.WmDestroy(Message ByRef m) at 
System.Windows.Forms.Form.WndProc(Message ByRef m) at 
System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message 
ByRef
m) 
at System.Windows.Forms.Control+ControlNativeWindow.WndProc(Message 
ByRef
m) 
at System.Windows.Forms.NativeWindow.WndProc(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at System.Windows.Forms.XplatUIX11.SendMessage(IntPtr hWnd, Msg msg, 
IntPtr
wParam, IntPtr lParam) 
at System.Windows.Forms.XplatUIX11.DestroyWindow(IntPtr handle) at 
System.Windows.Forms.XplatUI.DestroyWindow(IntPtr handle) at 
System.Windows.Forms.NativeWindow.DestroyWindow()
at System.Windows.Forms.Control.DestroyHandle()
at System.Windows.Forms.Control.RecreateHandle()
at System.Windows.Forms.Form.set_MdiParent(System.Windows.Forms.Form 
value)

 
There's more, but this seems like the relevant part

[Mono-winforms-list] Handle being created when I don't expect

[Maser, Dan]

  I've got a situation with MDI forms where the behavior is different on
MS vs mono, but it's proving difficult to get a simple test project that
reproduces it.  The problem is that in my app setting the Form.MdiParent
is causing that Form's handle to be created in mono when it doesn't on
MS.NET.   And it doesn't happen for simple test programs on mono either;
with simple test programs setting the MdiParent property doesn't cause
the handle to be created.  I think it must be something about my real
project that causes this, but the program is so large it's difficult to
tell what that might be.  Here's a partial call stack from the
Form.HandleCreated event.  Does this info give enough info to someone to
make some guesses about what could cause the MdiParent property to
trigger the HandleCreated in some projects but not in others?

  Thanks in advance for any ideas!

 Partial call stack:

at MyChildForm.on_HandleCreated(System.Object sender, System.EventArgs
e)
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
at System.Windows.Forms.
___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-list] Windows.Forms not found

[Maser, Dan]

  You need to add the reference to System.Windows.Forms just like you
did System.Drawing.  Such as mcs -r:System.Drawing
-r:System.Windows.Forms sample.cs 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mladen Bestvina
Sent: Monday, July 02, 2007 4:51 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Windows.Forms not found

Hello!

The compilation of the code below fails, apparently because 
Windows.Forms cannot be found on the system. I do have 
Windows.Forms.dll. I am using Ubuntu Feisty Fawn and I installed mono 
from ubuntu packages.

Any advice is appreciated.

Mladen

=

[EMAIL PROTECTED]:~/mono$ mcs -r:System.Drawing sample.cs
sample.cs(3,7): error CS0234: The type or namespace name `Windows' does 
not exist in the namespace `System'. Are you missing an assembly
reference?
sample.cs(3,1): error CS0246: The type or namespace name `Windows.Forms'

could not be found. Are you missing a using directive or an assembly 
reference?
Compilation failed: 2 error(s), 0 warnings



===

using System;
using System.Drawing;
using System.Windows.Forms;

public class HelloWorld : Form
{
static public void Main ()
{
Application.Run (new HelloWorld ());
}

public HelloWorld ()
{
Button b = new Button ();
b.Text = Click Me!;
b.Click += new EventHandler (Button_Click);
Controls.Add (b);
}

private void Button_Click (object sender, EventArgs e)
{
MessageBox.Show (Button Clicked!);
}
}
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Windows.Forms not found

[Maser, Dan]

  I checked my machine and I have the .dll extension in my command
line 

  -r:System.Window.Forms.dll 

  If adding the .dll to your example doesn't work then I'm out of
ideas :)

-Original Message-
From: Mladen Bestvina [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 06, 2007 11:16 AM
To: Maser, Dan
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Windows.Forms not found

Thanks Dan. I tried this, but I get:

[EMAIL PROTECTED]:~/mono$ mcs -r:System.Drawing -r:System.Windows.Forms 
sample.cs
error CS0006: cannot find metadata file `System.Windows.Forms'
Compilation failed: 1 error(s), 0 warnings

Maser, Dan wrote:
   You need to add the reference to System.Windows.Forms just like you
 did System.Drawing.  Such as mcs -r:System.Drawing
 -r:System.Windows.Forms sample.cs 

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Mladen
Bestvina
 Sent: Monday, July 02, 2007 4:51 PM
 To: mono-list@lists.ximian.com
 Subject: [Mono-list] Windows.Forms not found

 Hello!

 The compilation of the code below fails, apparently because 
 Windows.Forms cannot be found on the system. I do have 
 Windows.Forms.dll. I am using Ubuntu Feisty Fawn and I installed mono 
 from ubuntu packages.

 Any advice is appreciated.

 Mladen

 =

 [EMAIL PROTECTED]:~/mono$ mcs -r:System.Drawing sample.cs
 sample.cs(3,7): error CS0234: The type or namespace name `Windows'
does 
 not exist in the namespace `System'. Are you missing an assembly
 reference?
 sample.cs(3,1): error CS0246: The type or namespace name
`Windows.Forms'

 could not be found. Are you missing a using directive or an assembly 
 reference?
 Compilation failed: 2 error(s), 0 warnings



 ===

 using System;
 using System.Drawing;
 using System.Windows.Forms;

 public class HelloWorld : Form
 {
 static public void Main ()
 {
 Application.Run (new HelloWorld ());
 }

 public HelloWorld ()
 {
 Button b = new Button ();
 b.Text = Click Me!;
 b.Click += new EventHandler (Button_Click);
 Controls.Add (b);
 }

 private void Button_Click (object sender, EventArgs e)
 {
 MessageBox.Show (Button Clicked!);
 }
 }
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list


   


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Windows.Forms not found

[Maser, Dan]

  My guess is that there's a problem with your mono installation.  Here
are things to check:

1. My mono is installed in /usr/local/lib/mono.  Is the path
/usr/local/lib in your /etc/ld.so.conf file or your user
$LD_LIBRARY_PATH variable?

2. I have the System.Windows.Forms.dll in a few places under the
/usr/local/lib, do you?
mono/1.0/System.Windows.Forms.dll
mono/2.0/System.Windows.Forms.dll

mono/gac/System.Windows.Forms/1.0.5000/System.Windows.Forms.dll

mono/gac/System.Windows.Forms/2.0.0.0_/System.Windows.Forms.dll


  If you have those files my next guess is that your lib path doesn't
include the place where your mono dlls are.


-Original Message-
From: Mladen Bestvina [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 06, 2007 12:08 PM
To: Maser, Dan
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Windows.Forms not found

Thanks. It doesn't seem to make any difference if you add .dll. Let me 
know if you think of something.
Mladen

Maser, Dan wrote:
   I checked my machine and I have the .dll extension in my command
 line 

   -r:System.Window.Forms.dll 

   If adding the .dll to your example doesn't work then I'm out of
 ideas :)

 -Original Message-
 From: Mladen Bestvina [mailto:[EMAIL PROTECTED] 
 Sent: Friday, July 06, 2007 11:16 AM
 To: Maser, Dan
 Cc: mono-list@lists.ximian.com
 Subject: Re: [Mono-list] Windows.Forms not found

 Thanks Dan. I tried this, but I get:

 [EMAIL PROTECTED]:~/mono$ mcs -r:System.Drawing -r:System.Windows.Forms
sample.cs
 error CS0006: cannot find metadata file `System.Windows.Forms'
 Compilation failed: 1 error(s), 0 warnings

 Maser, Dan wrote:
   
   You need to add the reference to System.Windows.Forms just like you
 did System.Drawing.  Such as mcs -r:System.Drawing
 -r:System.Windows.Forms sample.cs 

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Mladen
 
 Bestvina
   
 Sent: Monday, July 02, 2007 4:51 PM
 To: mono-list@lists.ximian.com
 Subject: [Mono-list] Windows.Forms not found

 Hello!

 The compilation of the code below fails, apparently because 
 Windows.Forms cannot be found on the system. I do have 
 Windows.Forms.dll. I am using Ubuntu Feisty Fawn and I installed mono

 from ubuntu packages.

 Any advice is appreciated.

 Mladen

 =

 [EMAIL PROTECTED]:~/mono$ mcs -r:System.Drawing sample.cs
 sample.cs(3,7): error CS0234: The type or namespace name `Windows'
 
 does 
   
 not exist in the namespace `System'. Are you missing an assembly
 reference?
 sample.cs(3,1): error CS0246: The type or namespace name
 
 `Windows.Forms'
   
 could not be found. Are you missing a using directive or an assembly 
 reference?
 Compilation failed: 2 error(s), 0 warnings



 ===

 using System;
 using System.Drawing;
 using System.Windows.Forms;

 public class HelloWorld : Form
 {
 static public void Main ()
 {
 Application.Run (new HelloWorld ());
 }

 public HelloWorld ()
 {
 Button b = new Button ();
 b.Text = Click Me!;
 b.Click += new EventHandler (Button_Click);
 Controls.Add (b);
 }

 private void Button_Click (object sender, EventArgs e)
 {
 MessageBox.Show (Button Clicked!);
 }
 }
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list


   
 


   


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-list] Can there be a problem with System.Math.Max?

[Maser, Dan]

  I updated to the latest SVN code this morning and noticed that the
following code   
   

int a = 100;
int b = -2147483647;
System.Console.WriteLine(String.Format(Math.Max(a, b) is {0},
Math.Max(a, b)));


Prints -2147483647 when I'd expect it to print 100.  Looking at the
source code to Math.Max in class/corelib/System/Math.cs I don't see any
problem, though.  Can someone else verify this?
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Can there be a problem with System.Math.Max?

[Maser, Dan]

  Thanks, I created

http://bugzilla.ximian.com/show_bug.cgi?id=82001
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Jordan
Sent: Tuesday, July 03, 2007 11:46 AM
To: Mono-list@lists.ximian.com
Subject: Re: [Mono-list] Can there be a problem with System.Math.Max?

Maser, Dan wrote:
   I updated to the latest SVN code this morning and noticed that the
 following code   

 
 int a = 100;
 int b = -2147483647;
 System.Console.WriteLine(String.Format(Math.Max(a, b) is {0},
 Math.Max(a, b)));
 
 
 Prints -2147483647 when I'd expect it to print 100.  Looking at the
 source code to Math.Max in class/corelib/System/Math.cs I don't see
any
 problem, though.  Can someone else verify this?

Please file a bug and mention that it doesn't occur with
`mono --optimize=-all'.

My mono version is: Mono JIT compiler version 1.2.4 (/trunk/ r80002),
so it's probably not a fresh bug.

Robert

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Trouble with utf-16 marshaling

[Maser, Dan]

  Thanks to the ideas suggested by those who responded, I have a little
more info on this.  I was trying to make a smaller test project that
reproduced this so I could submit a bug and found out that the real
problem is slightly different than I originally reported.  The real
problem isn't with simple marshaling of UTF-16 data using the
UnmanagedType.LPWStr, but rather the problem is with some SWIG code that
uses some function pointer tricks to allow C library functions to return
pointers-to-buffers without leaking memory.

   The trick I refer to is where the C Library has a pointer-to-function
that allocates string data for C# strings.  And the C# stub sends a
delegate function implementation to the C library to use for this - and
thus the string return values are managed by the C# world and not
leaked.

   I've got a very small test project that reproduces this.  I'll create
a bug and attach it shortly.  Two bugs, really.  Because as I created
this small test project I notice that if I compile the project with MS
visual studio it's ok but if I compile with mono the test project
crashes well before the spot I'm trying to test at.

   I'll create two bugs for this and send the links in case any brave
souls would like to take a look.
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Jordan
Sent: Friday, June 29, 2007 9:02 PM
To: Mono-list@lists.ximian.com
Subject: Re: [Mono-list] Trouble with utf-16 marshaling

Hi Dan,

Maser, Dan wrote:

Here are you speaking about out marshaling:

It works properly in windows with MS .NET, but doesn't work for me
in
 linux with mono.   I've verified in gdb that the C library is
returning
 the correct string, but immediately after the C dll returns and mono
 does the LPWStr marshaling the string is total garbage characters.   I
 am under the impression from previous posts that 2-byte UTF-16 should
 marshal properly to mono with the LPWStr attribute.  In fact it looks
 like some of the gdiplus calls use that same thing and work... any
ideas
 what I can check on because mine doesn't?

But your sample is about in marshaling:

 
For more clarification my C library has a function signature like
 this:
 
 void my_function(unsigned short* myArg);
 
 And my C# code looks like this:
 
 
 [DllImport(myCLib)]
 public static extern void
my_function([MarshalAs(UnmanagedType.LPWStr)]
 string myArg);

Please post, or better: file a bug with a self-contained and
compilable sample.

Robert

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Trouble with utf-16 marshaling

[Maser, Dan]

  I created bug:
http://bugzilla.ximian.com/show_bug.cgi?id=81990
 
  which contains the description and the two source files that will
reproduce this problem.  The way I compiled them both is written in a
comment block on the top of the source files.

  Thanks in advance to anyone who can give it a try.
 Dan Maser

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maser, Dan
Sent: Monday, July 02, 2007 11:16 AM
To: Mono-list@lists.ximian.com
Subject: Re: [Mono-list] Trouble with utf-16 marshaling


  Thanks to the ideas suggested by those who responded, I have a little
more info on this.  I was trying to make a smaller test project that
reproduced this so I could submit a bug and found out that the real
problem is slightly different than I originally reported.  The real
problem isn't with simple marshaling of UTF-16 data using the
UnmanagedType.LPWStr, but rather the problem is with some SWIG code that
uses some function pointer tricks to allow C library functions to return
pointers-to-buffers without leaking memory.

   The trick I refer to is where the C Library has a pointer-to-function
that allocates string data for C# strings.  And the C# stub sends a
delegate function implementation to the C library to use for this - and
thus the string return values are managed by the C# world and not
leaked.

   I've got a very small test project that reproduces this.  I'll create
a bug and attach it shortly.  Two bugs, really.  Because as I created
this small test project I notice that if I compile the project with MS
visual studio it's ok but if I compile with mono the test project
crashes well before the spot I'm trying to test at.

   I'll create two bugs for this and send the links in case any brave
souls would like to take a look.
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Jordan
Sent: Friday, June 29, 2007 9:02 PM
To: Mono-list@lists.ximian.com
Subject: Re: [Mono-list] Trouble with utf-16 marshaling

Hi Dan,

Maser, Dan wrote:

Here are you speaking about out marshaling:

It works properly in windows with MS .NET, but doesn't work for me
in
 linux with mono.   I've verified in gdb that the C library is
returning
 the correct string, but immediately after the C dll returns and mono
 does the LPWStr marshaling the string is total garbage characters.   I
 am under the impression from previous posts that 2-byte UTF-16 should
 marshal properly to mono with the LPWStr attribute.  In fact it looks
 like some of the gdiplus calls use that same thing and work... any
ideas
 what I can check on because mine doesn't?

But your sample is about in marshaling:

 
For more clarification my C library has a function signature like
 this:
 
 void my_function(unsigned short* myArg);
 
 And my C# code looks like this:
 
 
 [DllImport(myCLib)]
 public static extern void
my_function([MarshalAs(UnmanagedType.LPWStr)]
 string myArg);

Please post, or better: file a bug with a self-contained and
compilable sample.

Robert

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-list] Trouble with utf-16 marshaling

[Maser, Dan]

   My situation is this:  I've got a C library that has a lot of UTF-16
inputs and outputs.  The C type is always unsigned short* or const
unsigned short* (because clearly wchar_t* isn't portable because it's 4
bytes on linux).   All of my C# code has the
[MarshalAs(UnsignedType.LPWStr)] attribute specified.

   It works properly in windows with MS .NET, but doesn't work for me in
linux with mono.   I've verified in gdb that the C library is returning
the correct string, but immediately after the C dll returns and mono
does the LPWStr marshaling the string is total garbage characters.   I
am under the impression from previous posts that 2-byte UTF-16 should
marshal properly to mono with the LPWStr attribute.  In fact it looks
like some of the gdiplus calls use that same thing and work... any ideas
what I can check on because mine doesn't?

   For more clarification my C library has a function signature like
this:

void my_function(unsigned short* myArg);

And my C# code looks like this:


[DllImport(myCLib)]
public static extern void my_function([MarshalAs(UnmanagedType.LPWStr)]
string myArg);

   Thanks in advance for any ideas on what to check!
  Dan Maser
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Trouble with utf-16 marshaling

[Maser, Dan]

   I have debugged this some more, and found this.  (I'm not yet sure
how to convert this information into something actionable).
 
I was browsing some of the mono source code and found this function (and
its sisters):
  MonoString* mono_string_new_utf16 (MonoDomain *domain, const
guint16 *text, gint32 len);
 
which seem to be the function(s) that initialize internal C# strings
from C data.  This one in particular appears to be invoked when internal
C# strings are created from UTF-16 C data.   I hacked in a simple loop
that printf'd the hex values of the UTF-16 data (the 'text' parameter).
 
  What I see in my console window is interesting.  (After a bunch of
unrelated stuff) I see my C library returning a UTF-16 string that gets
correctly interpreted as MonoString:
 
DBG: invocation of mono_string_new_utf16 with data:
   002f  0068  006f  006d  0065  002f  0064  0061  006e
006d  002f  0069  006e  0074 ...
 
which is the correct string.  The next thing I see in the console window
is this:
 
DBG: invocation of mono_string_new_utf16 with data:
   682f  6d6f  2f65  6164  6d6e  692f  746e''
 
Notice that this second data is similiar to the first where each 2-bytes
in the second string is the corresponding *4* bytes of the first string
and re-ordered as if there were some endian issue.  Clearly this second
string is supposed to be the same as the first string but it's been
damaged by some translation process.
 
   Does that information mean anything to anyone?   As always, thanks
for any help.
Dan Maser.




From: Maser, Dan 
Sent: Friday, June 29, 2007 1:10 PM
To: Maser, Dan; 'mono-list@lists.ximian.com'
Subject: RE: [Mono-list] Trouble with utf-16 marshaling


   Furthermore, I see in the mono source code that there is a test
function in the mono/mono/tests/libtest.c
 
STDCALL unsigned short*
test_lpwstr_marshal (unsigned short* chars, long length)
{
...
}
 
   Which is basically the same thing I'm doing; further indicating that
this should work.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maser, Dan
Sent: Friday, June 29, 2007 9:13 AM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Trouble with utf-16 marshaling




   My situation is this:  I've got a C library that has a lot of UTF-16
inputs and outputs.  The C type is always unsigned short* or const
unsigned short* (because clearly wchar_t* isn't portable because it's 4
bytes on linux).   All of my C# code has the
[MarshalAs(UnsignedType.LPWStr)] attribute specified.

   It works properly in windows with MS .NET, but doesn't work for me in
linux with mono.   I've verified in gdb that the C library is returning
the correct string, but immediately after the C dll returns and mono
does the LPWStr marshaling the string is total garbage characters.   I
am under the impression from previous posts that 2-byte UTF-16 should
marshal properly to mono with the LPWStr attribute.  In fact it looks
like some of the gdiplus calls use that same thing and work... any ideas
what I can check on because mine doesn't?

   For more clarification my C library has a function signature like
this: 

void my_function(unsigned short* myArg); 

And my C# code looks like this: 


[DllImport(myCLib)] 
public static extern void my_function([MarshalAs(UnmanagedType.LPWStr)]
string myArg); 

   Thanks in advance for any ideas on what to check! 
  Dan Maser 

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Trouble with utf-16 marshaling

[Maser, Dan]

I don't think that's the issue.   They're aren't any mutable strings
in my C library; I probably introduced that confusion accidentally.  My
C library has input UTF-16 parameters that are const, and has return
values that are UTF-16 as well.   Despite how the function signature
below looks, that myArg is really a const input.   My C code actually
does have const unsigned short * for the arguments and I just mistyped
it when I wrote the original message.
 
  I think I could have done the CharSet=CharSet.Unicode but (unless
I'm mistaken) that's an equivalent shortcut to putting the MarshalAs for
all the parameters.  In my case, I'm using SWIG so it's far easier to
make SWIG output the MarshalAs than the CharSet=CharSet.Unicode.
 
  But most importantly I am not trying to invoke a C function with a
mutable string buffer.  
 


From: Andy Hume [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 29, 2007 6:13 PM
To: Maser, Dan; mono-list@lists.ximian.com
Subject: RE: [Mono-list] Trouble with utf-16 marshaling


If the string argument is mutable then I believe one should use a
StringBuilder -- with its capacity set, and that length passed to the
native function too.  And if the native method writes more chars than
allocated then the heap will be corrupted. :-(
 
So with native method:
void my_function(unsigned short* myArg, int maxLen); 
 
Do 
[DllImport(myCLib, CharSet=CharSet.Unicode)]
// I think CharSet on that attr is enough, no need for MarshalAs
on the param...
public static extern void my_function(StringBuilder myArg, int
maxLength); 
...
StringBuilder bldr = new StringBuilder(256);
NativeMethods.my_function(bldr, bldr.Capacity);

See a similar sample at
http://msdn2.microsoft.com/en-us/library/x3txb6xc(vs.80).aspx
http://msdn2.microsoft.com/en-us/library/x3txb6xc(vs.80).aspx , and
reference material at
http://msdn2.microsoft.com/en-us/library/s9ts558h(VS.80).aspx
http://msdn2.microsoft.com/en-us/library/s9ts558h(VS.80).aspx  etc.

Unless I'm much confused it shouldn't work (at least isn't guaranteed
to) on MSFT either: Platform invoke copies string arguments, converting
from the .NET Framework format (Unicode) to the platform unmanaged
format. Strings are immutable and are not copied back from unmanaged
memory to managed memory when the call returns.

I suppose since it is Unicode on both sides the MSFT CLR skips the copy
and just passed the address of the String's content.  Whereas Mono
doesn't have that optimisation perhaps.

Does that solve it, or is something else the problem?

Andy




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maser, Dan
Sent: 29 June 2007 23:23
To: Maser, Dan; mono-list@lists.ximian.com
Subject: Re: [Mono-list] Trouble with utf-16 marshaling


   I have debugged this some more, and found this.  (I'm not yet
sure how to convert this information into something actionable).
 
I was browsing some of the mono source code and found this
function (and its sisters):
  MonoString* mono_string_new_utf16 (MonoDomain *domain,
const guint16 *text, gint32 len);
 
which seem to be the function(s) that initialize internal C#
strings from C data.  This one in particular appears to be invoked when
internal C# strings are created from UTF-16 C data.   I hacked in a
simple loop that printf'd the hex values of the UTF-16 data (the 'text'
parameter).
 
  What I see in my console window is interesting.  (After a
bunch of unrelated stuff) I see my C library returning a UTF-16 string
that gets correctly interpreted as MonoString:
 
DBG: invocation of mono_string_new_utf16 with data:
   002f  0068  006f  006d  0065  002f  0064
0061  006e  006d  002f  0069  006e  0074 ...
 
which is the correct string.  The next thing I see in the
console window is this:
 

DBG: invocation of mono_string_new_utf16 with data:
   682f  6d6f  2f65  6164  6d6e  692f  746e''
 
Notice that this second data is similiar to the first where each
2-bytes in the second string is the corresponding *4* bytes of the first
string and re-ordered as if there were some endian issue.  Clearly this
second string is supposed to be the same as the first string but it's
been damaged by some translation process.
 
   Does that information mean anything to anyone?   As always,
thanks for any help.
Dan Maser.




From: Maser, Dan 
Sent: Friday, June 29, 2007 1:10 PM
To: Maser, Dan; 'mono-list@lists.ximian.com'
Subject: RE: [Mono-list] Trouble with utf-16 marshaling


   Furthermore, I see in the mono source code that there is a
test function in the mono/mono/tests

Re: [Mono-winforms-list] Different Behaviour

[Maser, Dan]

 
For item 1 (If I recall properly) you can set a ContextMenuStrip to a
Textbox if you manually set the ContextMenu to null first.  I just
thought I'd mention it in case it might help to debug these differences.
 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
AutoLyrix AutoLyrix
Sent: Saturday, June 16, 2007 12:22 PM
To: Mono-winforms-list@lists.ximian.com
Subject: [Mono-winforms-list] Different Behaviour


Hello,

First, I would like to thank you all for the great work.

Well, I will list a few things that maybe could be fixed in the next
versions. They are not related to performance. The things listed here
have a different behavior if you compare with the Microsoft .NET
framework. 

1 - You can set a ContextMenuStrip in a TextBox
2 - Even if you set the ShowImageMargin = false in a ContextMenuStrip
the Image Column still shows.
3 - When you add a ToolStripLabel to a ContextMenuStrip it aligns the
text to the center by default. When it should be left ? 
4 - There is no way to bring a form to the front. I tried .Activate(),
.Show() and .BringToFront(). For example: The form is in the screen
(visible) but it is behind another application and I want to bring it to
the front when I click the NotifyIcon... In the Microsoft .NET Framework
.Activate() or .BringToFront() do that. 
5 - When I change the .Text property in a TextBox it always select the
new text (highlight), even when I set the .SelectionStart = 0 and
.SelectionLenght = 0

Ok, I still run my app anyway and I can bypass some of these different
behaviors. 
So, they don't have to be done/fixed for the next version, but I would
appreciate if you guys keep this in the To Do list for the future.

Thank you,
Alex A. dos Santos


___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

[Mono-winforms-list] What is best to use to identify the mono runtime installation?

[Maser, Dan]

  In my 'about' dialog on my app I display some useful information for
diagnostics.  Meaning useful when someone reports a problem.  Currently
it display things like the base OS, service packs/patches, and other
various information that end uses can copy/paste into a bug report.
I'm wondering what the best information to show about the mono runtime
is?   If someone reports a problem it would be really useful to be able
to say that problem is already fixed in a later mono build.   On the
mailing lists and such people often talk about r77343 which is the svn
revision.  Is that revision compiled into the runtime in some way that
can be extracted at run time programatically?   Is there something
better?  (Other ideas would include perhaps taking the build date of one
of the core mono dlls or something).

  Thanks in advance for any ideas!

___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

[Mono-winforms-list] Probably bug in SetSystemColors

[Maser, Dan]

  I was investigation my colors problem and I noticed this printed to my
console window:
   Gtk colorscheme read failure, using built-in colorscheme

  I investigated that code and found a probably bug.  In the file
mcs/class/Managed.Windows.Forms/System.Windows.Forms/Theme.cs there is
this function, starting near line 207:

private void SetSystemColors(KnownColor kc, Color value)
{
if (update == null)
{
   Type known_colors = Type.GetType(System.Drawing.KnownColors, +
Consts.AssemblySystem_Drawing);
   if (known_colors != null)
   {
   update = known_colors.GetMethod(Update, BindingFlags.Static
| BindingFlags.Public);
   }
}
if (update != null)
{
update.Invoke (null, new object[2] { (int)kc, value.ToArgb() });
}
}


Which uses reflection to invoke the KnownColors.Update method.   In the
last line the Color.ToArgb() function returns an int.  However, the
function signature of Update is:

public static void Update (int knownColor, uint color)
{
ArgbValues[knownColor] = color;
}

Which expects a uint as the second parameter, not an int.  This throws a
System.ArgumentException.   I verified that if the last line of
SetSystemColors is changed to

if (update != null)
{
update.Invoke (null, new object[2] { (int)kc,
(uint)value.ToArgb() });
}

Then the exception no longer happens, and the warning is no longer
printed to my console window when launching mono apps.

___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-winforms-list] WinForms On Linux

[Maser, Dan]

  With this amount of information I think the answer is inconclusive;
and depends heavily on your time frame.  Just as one example, if your
app uses only (or mostly) WinForms features from the v1.1 release of
.NET you'll have a much easier time in the short term.  My app uses a
number of v2.0 features such as ToolStrips, MenuStrips, MDI forms, etc,
and I have to hack things a bit (today) to get the app to work properly.
More and more of these newer features are completed every day; but it
will still be weeks before my app has 100% support and I don't have to
hack anything.  And you'll have to be more specific about your app
having heavy reliance on GDI+.  Does that mean you're making many GDI+
function calls directly using p/invoke?  If so, that's going to
significantly complicate things for you.  Obviously if your app has
platform-specific stuff in it then porting it is a chore :)

  My hunch is that based on your experience level you'll be more
successful developing and building with Visual Studio.  You can run the
VS binaries on mono directly.  There's no need to build with mono if
you're also building in Visual Studio.

  If you're using the latest stable release and you had no errors during
the installation you'll have to be more specific about what's not
working.  If you take a binary compiled using Visual Studio that doesn't
use platform-specific p/invoke function calls and copy it to your linux
machine you should be able to run it with the command line mono
my-app.exe.  If that fails I'd recommend first checking your
$LD_LIBRARY_PATH variable and-or the /etc/ld.so.conf paths.  If that
fails you can get some more help by changing your command line to
MONO_LOG_LEVEL=Debug mono my-app.exe.  However, this isn't as simple
as installing a shareware app on Windows and running it.  If it doesn't
work you'll have to send information about any error messages you're
getting and your setup.  Simply saying that you tried it and it doesn't
work, and asking for a set of steps, is never going to produce a good
result.  The steps *are* available on the web site and they *do* work,
however the level of expertise they assume is open to some debate.   So
if something isn't working instead of saying the steps are not working,
where should I get better instructions? you should consider saying
everything seems to be working up until I do (fill in the blank) at
which point I get error message (fill in the blank) which is unexpected.
I did these steps (fill in the blank) which should have satisfied the
error I'm getting, but the error is still there.  Any ideas on what the
error means? and you'll get much father.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Denis
B
Sent: Thursday, May 03, 2007 10:44 PM
To: mono-winforms-list@lists.ximian.com
Subject: Re: [Mono-winforms-list] WinForms On Linux


Hi Dan,

To introduce myself quickly, I am lead of a small development team of
engineering software. The application is client/server written in VB.Net
and
MSSQL. I am looking at the feasibility of supporting linux and thought I
would take a look at how useable Mono is. I am a relative linux newb. I
am
not really fussed about missing VB specific features in Mono because
they
can be recoded easily however I have a heavy reliance on WinForms and
GDI+.

I have recently installed Feisty Ubuntu and installed Mono/MonoDevelop
from
the package manager on my home machine to have a play and havent got
very
far.

Windows.Forms is part of a standard Mono installation. I cant see how to
reference and/or use it. 

I have been occasionally checking http://www.mono-project.com/ over
quite a
long time. 
http://www.mono-project.com/WinForms provides some background info,
nothing
of any use really. The development weblog it references was last updated
Feb
06.
I am happy using the latest stable release so I hope I dont have to
compile
my own version.

Is there a simple way of getting up and running with WinForms? Is there
a
decent way to develop WinForms in Linux or would I be better off staying
in
Windows and using Visual Studio (and then trying to compile under Mono
and
run results on Linux)? If there are any other website with information
please point me in the right direction, I have tried the mono website,
mailing list, various blogs, Wikipedia and whatever Google has thrown up
to
try and find my way.

Thanks,
Denis




Maser, Dan wrote:
 
Yes, it does work.  Naturally if you do something (just as an
 example) that calls into the Win32 api directly you'll have to make
some
 changes to your code to let it do the equiv on linux.   All the steps
 are on the mono web site.  If you have a more specific question about
an
 error your getting then perhaps this mailing list might be a good
place
 to start.   But for general steps on how to start:
  
 1. Read as much of the http://www.mono-project.com/ web site as you
can.
 2. Pay close attention to http://www.mono-project.com/Compiling_Mono
and
 http

Re: [Mono-winforms-list] WinForms On Linux

[Maser, Dan]

   Yes, it does work.  Naturally if you do something (just as an
example) that calls into the Win32 api directly you'll have to make some
changes to your code to let it do the equiv on linux.   All the steps
are on the mono web site.  If you have a more specific question about an
error your getting then perhaps this mailing list might be a good place
to start.   But for general steps on how to start:
 
1. Read as much of the http://www.mono-project.com/ web site as you can.
2. Pay close attention to http://www.mono-project.com/Compiling_Mono and
http://www.mono-project.com/FAQ:_Winforms
 
 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Project Development
Sent: Monday, April 30, 2007 5:06 AM
To: [EMAIL PROTECTED]
Subject: [Mono-winforms-list] WinForms On Linux


Hi,
 
I am Rajesh. I am had been trying to run Windows Forms using Mono but
couldn't get much success.  I have installed the Mono release 1.2 on
Redhat 9.0. I was able to run console applications but Windows Forms
fails to run. Is it really possible to run Windows Application
(Windows.Forms applications) on linux. Pls let me knw the steps of how
to go about this from the start. ( Installation, Configuration etc )
 
Thanks and Regards
Rajesh
___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-list] Continuous integration

[Maser, Dan]

  My company uses 
http://www.viewtier.com/products/parabuild/index.htm

  The product itself seems very good.  It's sometimes difficult for me
to say for sure, though, since I'm not yet convinced that I'm a fan of
continuous integration in the first place.  I'm sure this is at least
worth investigating.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scasquiov
Sent: Friday, April 27, 2007 1:43 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Continuous integration

Hi,

I'm looking for a continuous integration system that works well with
mono (having a good integration with Trac is a very strong plus too).

I'm wondering if someone working with mono and with a well behaved CI
system can please advise me.

Thanks in advance
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-winforms-list] Concerns about system colors?

[Maser, Dan]

 
 I wonder if I should raise concerns about the System colors in mono?
What I'm seeing is a little strange.  My app code uses System colors
for everything and looks as expected in Win32 but on linux mono it
doesn't look natural.  But it's not as clear what it *should* look
like either.  

 The colors for most apps are set in the /usr/lib/X11/app-defaults
directory per application I suppose.  So for example I see gnome
terminal windows that are black-on-white and highlight text
white-on-black.  I have standard xterms that are black-on-grey and
highlight white-on-black. Both of these seem normal because the two
colors have a high contrast.  However, my mono app has black-on-grey
(which is ok) but highlights white-on-gray.  The white-on-grey
highlight looks pretty bad for two reasons: the white-on-grey isn't a
high enough contrast plus the highlight background and non-highlight
background are both grey which doesn't clearly indicate what's
highlighted.
 
 Sorry for the long-winded explanation.  I guess what I'm wondering
foremost is if there's an some /usr/lib/X11/app-defaults resources
file I can specify that will set the system colors I like?  If not,
can someone explain where the system colors come from?
 
 In case it helps my app draws its window as 
  not highlighted: SystemColors.WindowText on SystemColors.Window 
  highlighted: SystemColors.HighlightText on SystemColors.Highlight
 

 I see that there's some colors hard coded into
mcs/class/System.Drawing/System.Drawing/KnownColors.cs.  The relevant
colors for my case are:
 
WindowFF FF FF   (this is black-on-white)
WindowText00 00 00
 
Highlight 31 6A C5   (this is white-on-bluish)
HighlightText FF FF FF
 
   Which seems reasonable to me. However it seems as though my current
active theme is apparently overriding these.  It's not obvious to me
where I need to change things.  And most importantly I don't see any
other apps looking strange... And this theme is the default them for the
REHL OS and I haven't updated it.

  
   Thanks in advance for any ideas!
 Dan Maser
 

___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

[Mono-list] Concerns about system colors?

[Maser, Dan]

 I wonder if I should raise concerns about the System colors in mono?
What I'm seeing is a little strange.  My app code uses System colors for
everything and looks as expected in Win32 but on linux mono it doesn't
look natural.  But it's not as clear what it *should* look like either.


 The colors for most apps are set in the /usr/lib/X11/app-defaults
directory per application I suppose.  So for example I see gnome
terminal windows that are black-on-white and highlight text
white-on-black.  I have standard xterms that are black-on-grey and
highlight white-on-black. Both of these seem normal because the two
colors have a high contrast.  However, my mono app has black-on-grey
(which is ok) but highlights white-on-gray.  The white-on-grey highlight
looks pretty bad for two reasons: the white-on-grey isn't a high enough
contrast plus the highlight background and non-highlight background are
both grey which doesn't clearly indicate what's highlighted.

  Sorry for the long-winded explanation.  I guess what I'm wondering
foremost is if there's an some /usr/lib/X11/app-defaults resources file
I can specify that will set the system colors I like?  If not, can
someone explain where the system colors come from?

 In case it helps my app draws its window as
   not highlighted: SystemColors.WindowText on SystemColors.Window
   highlighted: SystemColors.HighlightText on SystemColors.Highlight

  Thanks in advance for your time.
Dan Maser
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Concerns about system colors?

[Maser, Dan]

   For some more data I see that there's some colors hard coded into
mcs/class/System.Drawing/System.Drawing/KnownColors.cs
 
The relevant colors for my case are:
 
WindowFF FF FF   (this is black-on-white)
WindowText00 00 00
 
Highlight 31 6A C5   (this is white-on-bluish)
HighlightText FF FF FF
 
 
  Which seems reasonable to me.   However my app shows up in
black-on-gray and white-on-gray.  It's not obvious to me why.
  



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maser, Dan
Sent: Friday, April 20, 2007 2:51 PM
To: mono-list@lists.ximian.com
Subject: [Mono-list] Concerns about system colors?





 I wonder if I should raise concerns about the System colors in mono?
What I'm seeing is a little strange.  My app code uses System colors for
everything and looks as expected in Win32 but on linux mono it doesn't
look natural.  But it's not as clear what it *should* look like either.


 The colors for most apps are set in the /usr/lib/X11/app-defaults
directory per application I suppose.  So for example I see gnome
terminal windows that are black-on-white and highlight text
white-on-black.  I have standard xterms that are black-on-grey and
highlight white-on-black. Both of these seem normal because the two
colors have a high contrast.  However, my mono app has black-on-grey
(which is ok) but highlights white-on-gray.  The white-on-grey highlight
looks pretty bad for two reasons: the white-on-grey isn't a high enough
contrast plus the highlight background and non-highlight background are
both grey which doesn't clearly indicate what's highlighted.

  Sorry for the long-winded explanation.  I guess what I'm wondering
foremost is if there's an some /usr/lib/X11/app-defaults resources file
I can specify that will set the system colors I like?  If not, can
someone explain where the system colors come from?

 In case it helps my app draws its window as 
   not highlighted: SystemColors.WindowText on SystemColors.Window 
   highlighted: SystemColors.HighlightText on SystemColors.Highlight


  Thanks in advance for your time. 
Dan Maser 

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Concerns about system colors?

[Maser, Dan]

  Thanks, I'll move my question to the winforms list!

-Original Message-
From: Sebastien Pouliot [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 20, 2007 3:21 PM
To: Maser, Dan
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Concerns about system colors?

Hello Dan,

System colors depends on a lot of things. 

If you're talking about a SWF application then the active theme
updates System.Drawing color tables with it's own color information.
However I'm not quite sure where the default theme gets it's colors. You
should ask this on the mono-winforms-list.

Otherwise (non SWF apps) System.Drawing use some default hard-coded
values that looks like a default windows system.

Sebastien

On Fri, 2007-04-20 at 15:50 -0400, Maser, Dan wrote:
 
 
  I wonder if I should raise concerns about the System colors in mono?
 What I'm seeing is a little strange.  My app code uses System colors
 for everything and looks as expected in Win32 but on linux mono it
 doesn't look natural.  But it's not as clear what it *should* look
 like either.  
 
  The colors for most apps are set in the /usr/lib/X11/app-defaults
 directory per application I suppose.  So for example I see gnome
 terminal windows that are black-on-white and highlight text
 white-on-black.  I have standard xterms that are black-on-grey and
 highlight white-on-black. Both of these seem normal because the two
 colors have a high contrast.  However, my mono app has black-on-grey
 (which is ok) but highlights white-on-gray.  The white-on-grey
 highlight looks pretty bad for two reasons: the white-on-grey isn't a
 high enough contrast plus the highlight background and non-highlight
 background are both grey which doesn't clearly indicate what's
 highlighted.
 
   Sorry for the long-winded explanation.  I guess what I'm wondering
 foremost is if there's an some /usr/lib/X11/app-defaults resources
 file I can specify that will set the system colors I like?  If not,
 can someone explain where the system colors come from?
 
  In case it helps my app draws its window as 
not highlighted: SystemColors.WindowText on SystemColors.Window 
highlighted: SystemColors.HighlightText on
 SystemColors.Highlight
 
   Thanks in advance for your time. 
 Dan Maser
 
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list



___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-winforms-list] Getting the latest winforms code to run onlinux

[Maser, Dan]

   Yes, indeed you're correct. I updated my libgdiplus from 1.2.2 to
1.2.3 yesterday and the problem went away immediately.

-Original Message-
From: Sebastien Pouliot [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 27, 2007 9:48 AM
To: Maser, Dan
Cc: mono-winforms-list@lists.ximian.com
Subject: Re: [Mono-winforms-list] Getting the latest winforms code to
run onlinux

Hello Dan,

It is a message from libgdiplus (*)

As a general rule you cannot update SWF without updating System.Drawing,
and you cannot update System.Drawing without updating libgdiplus. 

While you can break this rule 90% of the time, you'll end up (10%) in
hard to diagnose bugs (or cosmetic issues) that no one else can
duplicate. Once there it's easy to lose much more time finding the
(non-)bugs than to update everything, every time.

(*) In this case the message means it could not decode an image. From
the stacktrace I'm pretty sure this is due to an old libgdiplus that
didn't implement the ICO codec with a newer System.Drawing.dll (that no
longer use managed code for this task).

On Mon, 2007-03-26 at 16:13 -0500, Jonathan Pobst wrote:
 Hey Dan,
 
 I think this is reported by libgdiplus.  It means that one of the
image 
 libraries is missing.  When I got this error, I installed libpng, 
 libgif, and libtiff libraries, then reran the autogen/make steps for 
 libgdiplus.  (Those may not be the exact libraries from memory,
whatever 
 ones the autogen step of libgdiplus tells you that you are missing at 
 the end.)
 
 Jonathan
 
 
 Maser, Dan wrote:
 
I downloaded the 03/25/2007 daily tarball and updated my system
with 
  it.   In the past I've also had to hack in a handful of methods that

  weren't implemented yet with stub implementations (which I did
rather 
  than change the source to omit them).   However, with the latest
build 
  I'm getting a not impl error that isn't clear what change is
needed, 
  nor clear what code of mine I can comment out.  Any ideas with
locating 
  this error are appreciated!I think this used to work with the 
  previous mono build I had since it doesn't look like a familiar
error to me.
  
  
  type: 10 Not implemented
  
  Unhandled Exception: System.NotImplementedException: Feature not 
  implemented.
at System.Drawing.GDIPlus.CheckStatus (Status status) [0x0]
at System.Drawing.Image.InitFromStream (System.IO.Stream stream) 
  [0x0]
at System.Drawing.Image.LoadFromStream (System.IO.Stream stream, 
  Boolean keepAlive) [0x0]
at System.Drawing.Icon.GetInternalBitmap () [0x0]
at System.Drawing.Icon.ToBitmap () [0x0]
at (wrapper remoting-invoke-with-check)
System.Drawing.Icon:ToBitmap ()
at System.Windows.Forms.XplatUIX11.SetIcon
(System.Windows.Forms.Hwnd 
  hwnd, System.Drawing.Icon icon) [0x0]
at System.Windows.Forms.XplatUIX11.SetIcon (IntPtr handle, 
  System.Drawing.Icon icon) [0x0]
at System.Windows.Forms.XplatUI.SetIcon (IntPtr handle, 
  System.Drawing.Icon icon) [0x0]
at System.Windows.Forms.Form.CreateHandle () [0x0]
at System.Windows.Forms.Control.CreateControl () [0x0]
at System.Windows.Forms.Control.SetVisibleCore (Boolean value)
[0x0]
at System.Windows.Forms.Form.SetVisibleCore (Boolean value)
[0x0]
at System.Windows.Forms.Control.set_Visible (Boolean value)
[0x0]
at (wrapper remoting-invoke-with-check) 
  System.Windows.Forms.Control:set_Visible (bool)
at System.Windows.Forms.Application.RunLoop (Boolean Modal, 
  System.Windows.Forms.ApplicationContext context) [0x0]
  
at System.Windows.Forms.Application.Run (System.Windows.Forms.Form

  mainForm) [0x0]
at ININ.LogViewer.Program.Main (System.String[] Args) [0x0]
  
  
 

  
  ___
  Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-winforms-list
 
 ___
 Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-winforms-list
-- 
Sebastien Pouliot  [EMAIL PROTECTED]
Blog: http://pages.infinit.net/ctech/



___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

[Mono-winforms-list] Getting the latest winforms code to run on linux

[Maser, Dan]

  I downloaded the 03/25/2007 daily tarball and updated my system with
it.   In the past I've also had to hack in a handful of methods that
weren't implemented yet with stub implementations (which I did rather
than change the source to omit them).   However, with the latest build
I'm getting a not impl error that isn't clear what change is needed,
nor clear what code of mine I can comment out.  Any ideas with locating
this error are appreciated!I think this used to work with the
previous mono build I had since it doesn't look like a familiar error to
me.


type: 10 Not implemented

Unhandled Exception: System.NotImplementedException: Feature not
implemented.
  at System.Drawing.GDIPlus.CheckStatus (Status status) [0x0]
  at System.Drawing.Image.InitFromStream (System.IO.Stream stream)
[0x0]
  at System.Drawing.Image.LoadFromStream (System.IO.Stream stream,
Boolean keepAlive) [0x0]
  at System.Drawing.Icon.GetInternalBitmap () [0x0]
  at System.Drawing.Icon.ToBitmap () [0x0]
  at (wrapper remoting-invoke-with-check) System.Drawing.Icon:ToBitmap
()
  at System.Windows.Forms.XplatUIX11.SetIcon (System.Windows.Forms.Hwnd
hwnd, System.Drawing.Icon icon) [0x0]
  at System.Windows.Forms.XplatUIX11.SetIcon (IntPtr handle,
System.Drawing.Icon icon) [0x0]
  at System.Windows.Forms.XplatUI.SetIcon (IntPtr handle,
System.Drawing.Icon icon) [0x0]
  at System.Windows.Forms.Form.CreateHandle () [0x0]
  at System.Windows.Forms.Control.CreateControl () [0x0]
  at System.Windows.Forms.Control.SetVisibleCore (Boolean value)
[0x0]
  at System.Windows.Forms.Form.SetVisibleCore (Boolean value) [0x0]
  at System.Windows.Forms.Control.set_Visible (Boolean value) [0x0]
  at (wrapper remoting-invoke-with-check)
System.Windows.Forms.Control:set_Visible (bool)
  at System.Windows.Forms.Application.RunLoop (Boolean Modal,
System.Windows.Forms.ApplicationContext context) [0x0]
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form
mainForm) [0x0]
  at ININ.LogViewer.Program.Main (System.String[] Args) [0x0]

___
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

[Mono-list] Is the Form.MouseClick event not implemented?

[Maser, Dan]

   I'm using a very recent snapshot tarball of mono (the Jan 5th, 2007
one to be specific) and when I add a MouseClick handler to a Form it
doesn't appear to get triggered.   I noted that I was compiling with
gmcs, and I tried using mcs so I could see if that made a difference.
My simple test app wouldn't even build with mcs, it said
System.Windows.Forms.Form doesn't contain a MouseClick property.
This doesn't strike me as something that would be unimplemented, but is
it?

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Am I missing something with ContextMenuStrips andToolStrips?

[Maser, Dan]

  Thanks for the reply.  My issue is a run time issue, not a compile
issue though.  In fact, the executable I'm running in this case was
compiled with another .NET compiler.  Is there something about the
runtime environment that would affect this?

  And as to your second point - is there a posted list (like there is
for the 1.1 Windows.Forms) about what's working and what isn't?  I can
only find the 1.1 information and not the 2.0 info.

   Thanks! 

-Original Message-
From: Miguel de Icaza [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 26, 2006 1:35 PM
To: Maser, Dan
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Am I missing something with ContextMenuStrips
andToolStrips?

Hello,

 
I've seen a few posts here and there about mono and MenuStrips,
 ToolStrips and ToolStripMenuItems but when I compile the latest mono I
 get runtime errors about missing methods like
 System.Windows.Forms.Form.set_MainMenuStrip().   Is it the case that
 MenuStrips are implemented but the methods that hook them up to Forms
 is not?  Or am I missing something about how to run my application to
 use the newest libs?  The debug output does indicate to me that the
 SWF 2.0 dll is the one reporting the error, not the 1.x version.  Any
 ideas?

You must compile with gmcs instead of mcs to get access to 2.0 APIs.

But the whole Windows.Forms 2.0 stack is under heavy development, we
make no promises that anything will work.


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Am I missing something with ContextMenuStrips and ToolStrips?

[Maser, Dan]

  Thanks for the info!  The mono I'm using is something that I compiled
from the tarballs, it's version mono-1.2.20061217 which appears to be
using a different numbering scheme than you mention.  Is version
1.2.20061217 better than 1.2.2.1, or less than it?

-Original Message-
From: Jonathan Pobst [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 26, 2006 1:51 PM
To: Maser, Dan
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Am I missing something with ContextMenuStrips
and ToolStrips?

ToolStrip/MenuStrip is under heavy development.  Although they work for 
many cases, there are plenty that are not yet implemented.  For a list 
of which methods are missing, you can check here:

http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/class-status-Syste
m.Windows.Forms.html

Also, using the MoMA reports, many of the most commonly used methods 
have been implemented since 1.2.2.1, including the Form.MainMenuStrip 
mentioned.  These changes are available in SVN, and will be available in

the next release of Mono.

A demo of what is working is available here:
http://svn.myrealbox.com/viewcvs/trunk/winforms/toolstrip20/

Jonathan


Maser, Dan wrote:
 
I've seen a few posts here and there about mono and MenuStrips, 
 ToolStrips and ToolStripMenuItems but when I compile the latest mono I

 get runtime errors about missing methods like 
 System.Windows.Forms.Form.set_MainMenuStrip().   Is it the case that

 MenuStrips are implemented but the methods that hook them up to Forms
is 
 not?  Or am I missing something about how to run my application to use

 the newest libs?  The debug output does indicate to me that the SWF
2.0 
 dll is the one reporting the error, not the 1.x version.  Any ideas?
 
Many thanks in advance for any hints!
  Dan
 
 


 
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list



___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list