Hi,
IDropTarget should be in System.Windows.Forms namespace but it is in global
namespace currently.
Kornél
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
fixed.
On Tue, 2006-09-12 at 23:42 +0200, Kornél Pál wrote:
Hi,
IDropTarget should be in System.Windows.Forms namespace but it is in global
namespace currently.
Kornél
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
FYI,
Microsoft.VisualBasic 1.1 at 'mono-basic\vbruntime' now runs on Java.
I have added VB.J2EE.build.bat which compiles VB 1.1 (using the define
TARGET_JVM) and then, converts it into jar, using Mainsoft Grasshopper.
Next steps regard Java:
* Port and Run Microsoft.VisualBasic test suites on
Hello Zoltan,
Here is another set of patches for mono on Linux/Alpha.
What is changed:
- Reworked passing of arguments on stack - now it is more close to ABI
(and same as gcc) and safe from stack allocation leaks
- New argument passing schema would allow to start pass valuetypes in
registers
Hi,
/novbruntimeref treats AscW specially as it is compiled as if it were CInt
(no AscW method is called).
Now vbnc has support for this as well and a dedicated test case ensures this
behavior.
Please review and approve the patch.
Kornél
vbruntime_AscW.diff
Description: Binary data
Kornél,
I have tested and I agree with your patch.
Sorry for the extra iteration.
Please commit,
Rafael
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael Mizrahi
Sent: Tuesday, September 12, 2006 12:38
To: mono-devel-list@lists.ximian.com
Subject:
El dom, 10-09-2006 a las 20:43 -0700, Lucius Meredith escribió:
All,
The attached valid schema causes xsd.exe to fail with the following
stack trace. i'm working to minimize the example, but any help would
be greatly appreciated.
The NUllReferenceException error is a bug in mono that has
El mar, 12-09-2006 a las 05:38 -0700, L.G. Meredith escribió:
Lluis,
Thanks for the response. The schema validates against the W3C schema
schema using Oxygen. i haven't had the chance, yet to validate it
using any other validation tool. Does xsd.exe on mono not support all
valid schema?
Running WinCE or Linux? And for which CPU?
Pocket PCs vary greatly in the chosen CPU, and although Mono currently
has a ARM port (running on Linux), many Pocket PCs use completely
unsupported CPUs.
And many recent Pocket PCs (and Smartphones) come with WinCE.NET, that
sport a diet .NET, what
Hey, next step could be having the same on Windows? Do you imagine it? File
system kernel modules written in C#
ok, let's stop dreaming... :-P
- Original Message -
From: Jonathan Pryor [EMAIL PROTECTED]
To: Mono List mono-list@ximian.com; mono-devel-list
[EMAIL PROTECTED]
Sent:
On Tue, 2006-09-12 at 21:31 +0200, pablosantosluac wrote:
Hey, next step could be having the same on Windows? Do you imagine it? File
system kernel modules written in C#
You're more than welcome to try. :-)
The problem is that FUSE is a kernal module + library pair. To do the
same on
anybody working on an Irix port? I've been trying to compile for awhile
now but, I think I've answered my own question of how long it would take
to get going. Tooo long!
Mathew
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Hi,
The problem is that FUSE is a kernal module + library pair. To do the
same on Windows, you'd need a Windows kernel driver, and you'd need the
Windows kernel driver interface to support the FUSE operations.
This means you'd have to have the Windows DDK, which IIRC costs money
(as
On 9/13/06, Rolf Bjarne Kvinge [EMAIL PROTECTED] wrote:
As far as I can see you can download it (for free) here:
http://www.microsoft.com/whdc/devtools/ddk/default.mspx
So if you (a) have money, and (b) have lots of time to learn the
intricacies of Win32 device driver development, you're
On 9/11/06, Jonathan Pryor [EMAIL PROTECTED] wrote:
On Sun, 2006-09-10 at 21:07 -0700, Valient Gough wrote:
I think this is why they changed `struct fuse_operations' to deprecate
the getdir() method and replaced it with a readdir() method which
provides a `struct stat' to the filler function
I have 4 windows systems, one of which is the development machine.
Each is running the same deployed exe and set of libraries. The
problem is that two of the four machines fail with the following
message when executing code in Mono.Unix.Catalog for gettext. The
worst part is that
Hi,
Is there somone who could tell me what this is.
I'm writing a nhibernate application and testing it under windows with
mono 1.1.9.2.
The application runs with mono 1.1.16.1 or higher but I was recommended
to use the
1.1.9.2 release because of it´s stability.
I haven't done any attribute
Mats Nilsson wrote:
Is there somone who could tell me what this is. I'm writing a
nhibernate application and testing it under windows with mono
1.1.9.2. The application runs with mono 1.1.16.1 or higher but I was
recommended to use the 1.1.9.2 release because of it´s stability.
Thats a weird
Michael Schurter wrote:
Mats Nilsson wrote:
Is there somone who could tell me what this is. I'm writing a
nhibernate application and testing it under windows with mono
1.1.9.2. The application runs with mono 1.1.16.1 or higher but I was
recommended to use the 1.1.9.2 release
Mats Nilsson wrote:
Thats a problem for me because of the 77075 bug. Mono GC fails almost
everytime I'm testing my application because of the suspend thread
fault described in the above mentioned bug report. I was recommened
to try out the 1.1.9.2 release by Bill Seddon, the author of the bug
Yes, if you are running your app on Windows, then in my experience there
is no more stable version - and we've checked out *every* one. We have
an application that challenges many areas of System.Windows.Forms and it
does not work under any version of Mono since 1.1.9.2. XSP has had
problems
Hi,
So Rolf's new VB compiler can bootstrap itself on Windows, and is
able to build its own runtime on Windows as well (I mean, with .NET),
but on Linux we are running into a few bugs in Mono.
But it's unable to bootstrap itself on MS.NET using our VB runtime so the VB
runtime should be
Hey!
But it's unable to bootstrap itself on MS.NET using our VB runtime so the VB
runtime should be fixed as well before trying to fix vbnc on Mono.
Do you have some details for me?
This is a good observation, before we launch ourselves into a quest to
fix bugs on the Mono side (although we
Hi,
Use VB.replace.bat 2 then try to bootstrap vbnc on MS.NET.
For an example have a look at the attached vbrun.diff.
The bug I found when trying to compile vbnc was:
Case TypeCode.Decimal
Return CDec(Value)
This results in a recursiong with
Hi,
I didn't have a look at the docs, but when a type has no namespace or is in
the global namespace (I don't know the which is the right term:)
Type.Namespace returns null on Mono and MS.NET as well. It's quite easy to
create a such type. An example is Consts.cs that is used in almost all
On Tue, 2006-09-12 at 08:07 -0500, [EMAIL PROTECTED] wrote:
I have 4 windows systems, one of which is the development machine.
Each is running the same deployed exe and set of libraries. The
problem is that two of the four machines fail with the following
message when executing code in
On Tue, 2006-09-12 at 21:31 +0200, pablosantosluac wrote:
Hey, next step could be having the same on Windows? Do you imagine it? File
system kernel modules written in C#
You're more than welcome to try. :-)
The problem is that FUSE is a kernal module + library pair. To do the
same on
Hi,
The problem is that FUSE is a kernal module + library pair. To do the
same on Windows, you'd need a Windows kernel driver, and you'd need the
Windows kernel driver interface to support the FUSE operations.
This means you'd have to have the Windows DDK, which IIRC costs money
(as
Can you elaborate on the tests you've used?
On Tue, 2006-09-12 at 00:08 -0700, Valient Gough wrote:
There is a program fsx-linux which you might find useful. I've
found bugs in FUSE itself with this program in the past while trying
to debug my own filesystems.
I managed to find this; it
Hello,
This results in a recursiong with Conversions.ToDecimal because CDec (and
all the other CType conversions are done at runtime unless the type is known
to the compiler as well. And anyway there is no use to do reinterpretation
when the exact type is know. A simple unbox is enough.
30 matches
Mail list logo