Re: [Mono-winforms-list] ListView vs DataGridView - which is more stable?
Hi,
Please file a bug with the problem and with a test case and I will
look into it - http://mono-project.com/Bugs
Kind Regards,
Ivan N. Zlatev
http://ivan-zlatev.com
On Sun, Jun 7, 2009 at 1:22 AM, jmausterevan.arn...@gmail.com wrote:
Thanks for the help.:-)
But, it turns out that I need to have rows of varying height, which I
believe is impossible in a list view, therefore I have gone with a
DataGridView.
However, this row sizing is behaving a little strangely. When I use the
code before, my text does not wrap and it does not autosize the rows,
although that seems like it is what should happen.
public DataGridViewForm()
{
DataGridView dgv = new DataGridView();
dgv.Parent = this;
DataGridViewTextBoxColumn colDisplayDate = new
DataGridViewTextBoxColumn();
DataGridViewTextBoxColumn colDisplayText = new
DataGridViewTextBoxColumn();
colDisplayDate.Name = Display Date;
colDisplayDate.Width = 100;
colDisplayText.Name = Note Text;
colDisplayText.Width = 150;
dgv.Columns.Add(colDisplayDate);
dgv.Columns.Add(colDisplayText);
dgv.Rows.Add(Display Date 1, Display Note);
dgv.Rows.Add(Second Date, Lorem ipsum dolor ... [a
long string]
...);
dgv.Dock = DockStyle.Fill;
dgv.DefaultCellStyle.WrapMode =
DataGridViewTriState.True;
dgv.AutoSizeRowsMode =
DataGridViewAutoSizeRowsMode.AllCells;
}
Any other thoughts?
Thanks again,
Carlos Alberto wrote:
ListView should do enough for that you need - also, take into account that
*some* features of DataGridView hadn't been implemented yet.
Carlos.
2009/6/5 jmauster evan.arn...@gmail.com
Hi,
I am new to Mono and I am building a simple application that will display
a
two-column table with no more than 100 rows at a time. I believe I can do
this equally well with ListView and DataGridView, however - I was
wondering
which of these is more stable.
Any thoughts?
Thanks,
--
View this message in context:
http://www.nabble.com/ListView-vs-DataGridView---which-is-more-stable--tp23891679p23891679.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
___
Mono-winforms-list maillist - mono-winforms-l...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
___
Mono-winforms-list maillist - mono-winforms-l...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
View this message in context:
http://www.nabble.com/ListView-vs-DataGridView---which-is-more-stable--tp23891679p23906831.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
___
Mono-winforms-list maillist - mono-winforms-l...@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
Re: [Mono-list] 2.4 issues: assertion failure in mini-codegen.c, NRE in DataGridView
Hi. Please open a bug for the second issue (DataGridView) using our bug tracker - http://mono-project.com/Bugs so I can take a look. Please zip me up all binaries needed to run RLDViewer and provide a sample file if that's needed for the interaction + steps to reproduce (I haven't ever used RLDViewer). On Sun, Jun 7, 2009 at 5:20 PM, Andrus Moor kobrule...@hot.ee wrote: I installed Mono 2.4 distribution package on Vista. 1. Tested fyireporting.com RDLViewer. Trying to preview any report causes exception ERROR:mini-codegen.c:1032:mono_local_regalloc: assertion failed: (reginfo [ins-sreg1].born_in 0) 2. Moving to new row in end of DataGridiew and back to previous row causes exception System.ArgumentNullException: Argument cannot be null. Parameter name: value at System.ComponentModel.BaseNumberConverter.ConvertTo (ITypeDescriptorContext context, System.Globalization.CultureInfo culture, System.Object value, System.Type destinationType) [0x0] at System.ComponentModel.TypeConverter.ConvertTo (System.Object value, System.Type destinationType) [0x0] at System.Windows.Forms.DataGridViewCell.GetFormattedValue (System.Object value, Int32 rowIndex, System.Windows.Forms.DataGridViewCellStyle cellStyle, System.ComponentModel.TypeConverter valueTypeConverter, System.ComponentModel.TypeConverter formattedValueTypeConverter, DataGridViewDataErrorContexts context) [0x0] at System.Windows.Forms.DataGridViewCell.get_FormattedValue () [0x0] at System.Windows.Forms.DataGridViewRow.PaintCells (System.Drawing.Graphics graphics, Rectangle clipBounds, Rectangle rowBounds, Int32 rowIndex, DataGridViewElementStates rowState, Boolean isFirstDisplayedRow, Boolean isLastVisibleRow, DataGridViewPaintParts paintParts) [0x0] at System.Windows.Forms.DataGridViewRow.Paint (System.Drawing.Graphics graphics, Rectangle clipBounds, Rectangle rowBounds, Int32 rowIndex, DataGridViewElementStates rowState, Boolean isFirstDisplayedRow, Boolean isLastVisibleRow) [0x0] at System.Windows.Forms.DataGridView.OnPaint (System.Windows.Forms.PaintEventArgs e) [0x0] at System.Windows.Forms.Control.WmPaint (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.DataGridView.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x0] In previous release there was no such errors. How to fix ? Andrus. ___ Mono-list maillist - mono-l...@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] 2.4 issues: assertion failure in mini-codegen.c, NRE in DataGridView
On Mon, Jun 8, 2009 at 11:44 AM, Andrus Moorkobrule...@hot.ee wrote: Can you download fyireporting from http://fyireporting.com/download.html , please ? It comes in an .msi Windows Installer. I am running Linux so that's why I am asking you to zip up the binaries for me. It contains demo reports which you can preview and open in designer. If you still require, I can try to create step-by step testcases. I was referring to instructions like open this, click there Other issues with fyireporting in Mono 2.4 which also occured in earlier versions: 1. RDLDesigner: Report item properties panel appears in wrong place in screen, must apper in right side. 2. RDLViewer Report preview: Dates are displayed in invariant culture format, it does not recognize thread culture setting. 3. Report status window causes application to stop responding. It creates separate thread which seems to crash mono. Workaround is to modify source code to comment out thread creation. You should probably file bug reports for each of those issues in Bugzilla. . FYIReporting.com is free and powerful reporting system. I think it is worth to make it work under mono. Andrus. - Original Message - From: Ivan N. Zlatev cont...@i-nz.net To: Andrus Moor kobrule...@hot.ee Cc: Mono-list@lists.ximian.com Sent: Monday, June 08, 2009 1:03 PM Subject: Re: [Mono-list] 2.4 issues: assertion failure in mini-codegen.c, NRE in DataGridView Hi. Please open a bug for the second issue (DataGridView) using our bug tracker - http://mono-project.com/Bugs so I can take a look. Please zip me up all binaries needed to run RLDViewer and provide a sample file if that's needed for the interaction + steps to reproduce (I haven't ever used RLDViewer). On Sun, Jun 7, 2009 at 5:20 PM, Andrus Moor kobrule...@hot.ee wrote: I installed Mono 2.4 distribution package on Vista. 1. Tested fyireporting.com RDLViewer. Trying to preview any report causes exception ERROR:mini-codegen.c:1032:mono_local_regalloc: assertion failed: (reginfo [ins-sreg1].born_in 0) 2. Moving to new row in end of DataGridiew and back to previous row causes exception System.ArgumentNullException: Argument cannot be null. Parameter name: value at System.ComponentModel.BaseNumberConverter.ConvertTo (ITypeDescriptorContext context, System.Globalization.CultureInfo culture, System.Object value, System.Type destinationType) [0x0] at System.ComponentModel.TypeConverter.ConvertTo (System.Object value, System.Type destinationType) [0x0] at System.Windows.Forms.DataGridViewCell.GetFormattedValue (System.Object value, Int32 rowIndex, System.Windows.Forms.DataGridViewCellStyle cellStyle, System.ComponentModel.TypeConverter valueTypeConverter, System.ComponentModel.TypeConverter formattedValueTypeConverter, DataGridViewDataErrorContexts context) [0x0] at System.Windows.Forms.DataGridViewCell.get_FormattedValue () [0x0] at System.Windows.Forms.DataGridViewRow.PaintCells (System.Drawing.Graphics graphics, Rectangle clipBounds, Rectangle rowBounds, Int32 rowIndex, DataGridViewElementStates rowState, Boolean isFirstDisplayedRow, Boolean isLastVisibleRow, DataGridViewPaintParts paintParts) [0x0] at System.Windows.Forms.DataGridViewRow.Paint (System.Drawing.Graphics graphics, Rectangle clipBounds, Rectangle rowBounds, Int32 rowIndex, DataGridViewElementStates rowState, Boolean isFirstDisplayedRow, Boolean isLastVisibleRow) [0x0] at System.Windows.Forms.DataGridView.OnPaint (System.Windows.Forms.PaintEventArgs e) [0x0] at System.Windows.Forms.Control.WmPaint (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.DataGridView.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x0] In previous release there was no such errors. How to fix ? Andrus. ___ 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] Panel.Handle
In X11 we have 2 X windows for each control - one for the client (ClientWindow) and one for the non-client areas (WholeWindow). Control.Handle is the handle for the Client window returned by XCreateWindow. You can see more details in CreateWindow () in http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs and http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Hwnd.cs for details. On Wed, May 27, 2009 at 5:36 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: Hello Is Panel.Handle by any chance X Window identifier which is returned by XCreateWindow? Can anyone point me to location in mono svn where I could study these specifics? thanks, Tommi ___ Mono-winforms-list maillist - mono-winforms-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Kind Regards, Ivan N. Zlatev ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Clipboard.SetDataObject() doing nothing
Hey,
There is already a bug for this:
https://bugzilla.novell.com/show_bug.cgi?id=357642
Basically we don't support IDataObject and custom data (clipboard)
formats and just hand-check for text and handle that in a magical way.
The best way (imho) to fix this is to have a IDataObject centric
clipboard implementation. I have some notes if someone is interested.
On Sun, May 24, 2009 at 4:33 PM, Carlos Alberto Cortez
calberto.cor...@gmail.com wrote:
This issue has nothing to see with that Changelog entry.
Basically we have never supported copying/pasting other than text/rtf text.
So feel free to open a bug report for it :-)
Thanks!
Carlos.
2009/5/24 Christoph Teuber christoph.teu...@gmx.li
Hello,
thanks for your fast answer.
You were right, there were several changes, but nothing seems to be
connected with my SetDataObject() problem. But I found this statement:
2007-03-18 Jackson Harper jack...@ximian.com
* TextBoxBase.cs: Remove image pasting code for now. There is no
way to get an image on the clipboard right now anyways.
This ist from 2007, so it may be out of date, but does it mean, that
copying images to the clipboard doesn't work at all? I wonder, because
Clipboard.SetImage( im );
or
Clipboard.SetObjectData( im );
doesn't do anything either. (im is an image loaded as posted before). In
contrary,
Clipboard.SetObjectData(this is a test);
does work.
Greetings
cht
Stifu wrote:
I know there've been clipboard fixes after 2.4, so you could check out
SVN
(or bugzilla).
cht wrote:
Hello,
I'm trying to do some clipboard stuff under Mono right now, and I have
the
problem, that Windows.Forms.Clipboard.SetDataObject() doesn't seem to
do
anything if a DataObject will be passed.
I do have the following two pieces of code, which both run under .NET
2.0,
but running under mono (2.0.1, Ubuntu 9.04) leaves the clipboard
completely unchanged.
private void testButton_Click(object sender, EventArgs e)
{
Image im = (Image)Bitmap.FromFile(test.jpg);
DataObject dataObj = new DataObject();
dataObj.SetData(im.GetType().ToString(), im);
Clipboard.SetDataObject(dataObj, true);
}
private void testTextButton_Click(object sender, EventArgs e)
{
DataObject dataObj = new DataObject();
string format = System.String;
dataObj.SetData(format, this is a test);
Clipboard.SetDataObject(dataObj, false);
}
I compile using VS 2008.
As Clipboard.cs seems to bee unchanged since 2.0.1, I didn't try
installing Mono 2.4. But I would like to stay compatible to 2.0.1
anyway,
so I hope I'm doing something wrong.
Anybody any idea, why this is the case?
Thanks in advance
cht
___
Mono-winforms-list maillist - mono-winforms-l...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
___
Mono-winforms-list maillist - mono-winforms-l...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
Kind Regards,
Ivan N. Zlatev
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Bug 479405 has not patched in Mono 2.4RC3.2 one month's ago
On Fri, Mar 27, 2009 at 3:42 AM, tsai t...@pinnacle.com.tw wrote:
After I upgrade to mono 2.4 RC3.5, this bug also exists. My program crashed.
r130179 Modified: trunk/mcs/class/System.Data/System.Data/DataView.cs
Can you tell me where I can find DataView.cs. Thanks in advance.
The fix is not going to be in the 2.4 because it's already too late in
the release cycle. You will have to compile Mono from SVN as described
here - http://mono-project.com/Compiling_Mono .
- Original Message -
From: Ivan N. Zlatev cont...@i-nz.net
To: peter tsai t...@pinnacle.com.tw
Cc: mono-winforms-list@lists.ximian.com
Sent: Wednesday, March 25, 2009 11:38 AM
Subject: Re: [Mono-winforms-list] Bug 479405 has not patched in Mono 2.4RC3.2
one month's ago
On Tue, Mar 24, 2009 at 1:31 AM, peter tsai t...@pinnacle.com.tw wrote:
I'm using Mono 2.2 on openSuSE 11.1. Unfortunately, I compile Mono 2.4RC3.2
has problem,too.
who can help me? thanks in advance.
Fixed in r130179.
The problem was in the DataView class not firing ListChanged when the
RowFilter changes.
dataGridView1.DataSource = MakeDataTable(); // generate DataTable with 10
records
DataView view = ((DataTable)dataGridView1.DataSource).DefaultView;
view.RowFilter = Qty=3 and Qty=8; // filter 4 records
DataGridView display ok (records is 7) in .net,
but mono (2.0.1, 2.2 and 2.4RC3.2) on SUSE 11.1 abnormal (RowFilter not
active, so records is still 10).
mono 2.4RC3.2 crashed my application
namespace MonoBug
{
public partial class MonoBug : Form
{
bool inFilter = false;
private void button2_Click(object sender, EventArgs e) // bug
{
DataView view =
((DataTable)dataGridView1.DataSource).DefaultView;
if (inFilter)
view.RowFilter = ;
else
view.RowFilter = Qty=3 and Qty=8;
// run in .net ok, but mono (2.0.1 and 2.2) on SUSE 11.1
abnormal
// visual studio 2005 complier on windows XP
// dataGridView1.Invalidate();
inFilter = !inFilter;
}
public MonoBug()
{
InitializeComponent();
dataGridView1.ReadOnly = true;
dataGridView1.AllowUserToAddRows = false;
dataGridView1.DataSource = MakeDataTable(); ;
}
private DataTable MakeDataTable()
{
DataTable table = new DataTable();
DataColumn column = new DataColumn();
column.DataType = System.Type.GetType(System.String);
column.Caption = Item;
column.ColumnName = Item;
table.Columns.Add(column);
column = new DataColumn();
column.DataType = System.Type.GetType(System.Decimal);
column.Caption = Qty;
column.ColumnName = Qty;
table.Columns.Add(column);
DataRow row;
for (int i = 1; i = 10; i++)
{
row = table.NewRow();
row[Item] = Item + i.ToString();
row[Qty] = i;
table.Rows.Add(row);
}
return table;
}
}
}
--
View this message in context:
http://www.nabble.com/Bug-479405-has-not-patched-in-Mono-2.4RC3.2-one-month%27s-ago-tp22672789p22672789.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
Kind Regards,
Ivan N. Zlatev
__ NOD32 3953 (20090321) Information __
This message was checked by NOD32 antivirus system.
http://www.nod32cn.com
--
Kind Regards,
Ivan N. Zlatev
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] test-Windows_Forms-2.0 failures on mono-trunk
On Wed, Mar 25, 2009 at 11:05 PM, Marc Christensen mchristen...@novell.com wrote: Hi Ivan, It looks like one or more of your changes to DataGridView* may have caused a breakage in the test-Windows_Forms-2.0 test suite on mono trunk. The breakage started occurring between -r129798:129815. Here's the error: Test Case Failures: 1) MonoTests.System.Windows.Forms.DataGridViewBindingTest.DataSetBindingTest.TestAutoGenerateColumns : A4 Expected: 4 But was: 3 at MonoTests.System.Windows.Forms.DataGridViewBindingTest.DataSetBindingTest.TestAutoGenerateColumns () [0x00137] in /tmp/monobuild/build/BUILD/mono-130215/mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/DataGridViewDataBindingTest.cs:252 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x000ca] in /tmp/monobuild/build/BUILD/mono-130215/mcs/class/corlib/System.Reflection/MonoMethod.cs:169 It looks like you modified DataGridView* stuff in at least the following revisions: r129803, r129804, r129805, r129806, r129815. A full report of the changes in those revisions can be found here: http://monoport.com/40062 Thanks! -- Marc Christensen http://www.novell.com Hey, Thanks, fixed in r130267. -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-winforms-list] Bug 479405 has not patched in Mono 2.4RC3.2 one month's ago
On Tue, Mar 24, 2009 at 1:31 AM, peter tsai t...@pinnacle.com.tw wrote:
I'm using Mono 2.2 on openSuSE 11.1. Unfortunately, I compile Mono 2.4RC3.2
has problem,too.
who can help me? thanks in advance.
Fixed in r130179.
The problem was in the DataView class not firing ListChanged when the
RowFilter changes.
dataGridView1.DataSource = MakeDataTable(); // generate DataTable with 10
records
DataView view = ((DataTable)dataGridView1.DataSource).DefaultView;
view.RowFilter = Qty=3 and Qty=8; // filter 4 records
DataGridView display ok (records is 7) in .net,
but mono (2.0.1, 2.2 and 2.4RC3.2) on SUSE 11.1 abnormal (RowFilter not
active, so records is still 10).
mono 2.4RC3.2 crashed my application
namespace MonoBug
{
public partial class MonoBug : Form
{
bool inFilter = false;
private void button2_Click(object sender, EventArgs e) // bug
{
DataView view =
((DataTable)dataGridView1.DataSource).DefaultView;
if (inFilter)
view.RowFilter = ;
else
view.RowFilter = Qty=3 and Qty=8;
// run in .net ok, but mono (2.0.1 and 2.2) on SUSE 11.1
abnormal
// visual studio 2005 complier on windows XP
// dataGridView1.Invalidate();
inFilter = !inFilter;
}
public MonoBug()
{
InitializeComponent();
dataGridView1.ReadOnly = true;
dataGridView1.AllowUserToAddRows = false;
dataGridView1.DataSource = MakeDataTable(); ;
}
private DataTable MakeDataTable()
{
DataTable table = new DataTable();
DataColumn column = new DataColumn();
column.DataType = System.Type.GetType(System.String);
column.Caption = Item;
column.ColumnName = Item;
table.Columns.Add(column);
column = new DataColumn();
column.DataType = System.Type.GetType(System.Decimal);
column.Caption = Qty;
column.ColumnName = Qty;
table.Columns.Add(column);
DataRow row;
for (int i = 1; i = 10; i++)
{
row = table.NewRow();
row[Item] = Item + i.ToString();
row[Qty] = i;
table.Rows.Add(row);
}
return table;
}
}
}
--
View this message in context:
http://www.nabble.com/Bug-479405-has-not-patched-in-Mono-2.4RC3.2-one-month%27s-ago-tp22672789p22672789.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
___
Mono-winforms-list maillist - mono-winforms-l...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
Kind Regards,
Ivan N. Zlatev
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] problem with Binding
On Mon, Mar 9, 2009 at 6:11 PM, Martin Matusiak numero...@gmail.com wrote: Greetings, I'm trying to do a hello world data binding to widgets. I've tried a couple of tutorials and none of the example code worked. Here's what I did: http://www.matusiak.eu/numerodix/blog/index.php/2009/03/09/data-binding-made-of-fail/ The databinding in that sample works just fine with SVN HEAD and probably also with Mono 2.4. On the other side there seems to be a bug with the TableLayoutPanel because the layout is broken on Mono. A bug has to be filed with that - http://mono-project.com/Bugs. On MS.NET you seem to be running the assembly with limited trust zone and that won't work because DataBinding requires reflection which is not allowed by the security zone. -- Kind Regards, Ivan N. Zlatev ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] how do i get mouse position on the screen?
On Tue, Feb 24, 2009 at 6:46 PM, jkarpago jkarp...@gmail.com wrote: Hi: I want to know where is the mouse in the screen, not the app window but the whole screen. I have tried width cursor, mouse, pointer and did not find a solution. how can I do it? Hi, WinForms or GTK#? In WinForms try the static property Control.MousePosition and for GTK# the someWidgetInstance.RootWindow.GetPointer (...) method. -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-winforms-list] [Mono-list] Bug? DataGridView on Mono Crashes (or locks rather)... does not occur on Microsoft platforms
Please try using Mono 2.4 RC1 . There were *many* changes related to databinding and DGV that were done during the 2.4 development cycle. If you still experience problems then please file a bug (http://mono-project.com/Bugs) so I/we can look at it. On Thu, Feb 26, 2009 at 1:17 PM, W Allan Edwards silicon_pla...@hotmail.com wrote: I appear to have found a bug in the mono stack? Or was it a design implementation choice? Here is the scenario... I pull data from a database, then load up a Dataset then find it to a Datagridview. Then I substitute textual values inside of that grid based on the numeric values in the grid. I do this after I have already bound the DataSet table to the DataGridView. On the Microsoft side (Vista) this error does not occur... or no lock up. The DataTable object the datagridview is bound to simply updates to the underlying table data changed on the fly. When you run the commented lines of code the application on Mono will lock up and just stop execution. I get no exception thrown or any clue as to what is going on. The app just locks, I have to manually kill the process. I changed the code just to update the grid cell directly and it works fine on both platforms for display purposes. // Commented code that locks on linux //BoundDataSet.Tables[0].Rows[i][DataGridViewColumnIndexToConvert] = // DisplayValue; // Uncommented code below runs on both mono and the Microsoft stack no problems as expected oDataGridView.Rows[i].Cells[DataGridViewColumnIndexToConvert].Value = DisplayValue; Version information for reproduction OpenSuse 11.1 32-bit Linux, Mono 2.2 (freshly released and installed) Microsoft Windows Vista Home Premium edition 32-bit, .NET 2.0 framework compilation for all libs Algorithmic scenario 1 - Pull db data 2 - Bind to DataGridView 3 - Update numeric values in the underlying bound DataTable bound to the Grid (originally via the DataTable, now just the Grid Display Cell value) Thanks, -A- ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Kind Regards, Ivan N. Zlatev ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-list] Bug? DataGridView on Mono Crashes (or locks rather)... does not occur on Microsoft platforms
Please try using Mono 2.4 RC1 . There were *many* changes related to databinding and DGV that were done during the 2.4 development cycle. If you still experience problems then please file a bug (http://mono-project.com/Bugs) so I/we can look at it. On Thu, Feb 26, 2009 at 1:17 PM, W Allan Edwards silicon_pla...@hotmail.com wrote: I appear to have found a bug in the mono stack? Or was it a design implementation choice? Here is the scenario... I pull data from a database, then load up a Dataset then find it to a Datagridview. Then I substitute textual values inside of that grid based on the numeric values in the grid. I do this after I have already bound the DataSet table to the DataGridView. On the Microsoft side (Vista) this error does not occur... or no lock up. The DataTable object the datagridview is bound to simply updates to the underlying table data changed on the fly. When you run the commented lines of code the application on Mono will lock up and just stop execution. I get no exception thrown or any clue as to what is going on. The app just locks, I have to manually kill the process. I changed the code just to update the grid cell directly and it works fine on both platforms for display purposes. // Commented code that locks on linux //BoundDataSet.Tables[0].Rows[i][DataGridViewColumnIndexToConvert] = // DisplayValue; // Uncommented code below runs on both mono and the Microsoft stack no problems as expected oDataGridView.Rows[i].Cells[DataGridViewColumnIndexToConvert].Value = DisplayValue; Version information for reproduction OpenSuse 11.1 32-bit Linux, Mono 2.2 (freshly released and installed) Microsoft Windows Vista Home Premium edition 32-bit, .NET 2.0 framework compilation for all libs Algorithmic scenario 1 - Pull db data 2 - Bind to DataGridView 3 - Update numeric values in the underlying bound DataTable bound to the Grid (originally via the DataTable, now just the Grid Display Cell value) Thanks, -A- ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Bug? DataGridView on Mono Crashes (or locks rather)... does not occur on Microsoft platforms
On Thu, Feb 26, 2009 at 1:46 PM, W Allan Edwards silicon_pla...@hotmail.com wrote: Yes, the DataGridView works now on 2.4 BUT I had a bug back on the 1.9 version where when I clicked on a tree node it would not select properly. I then moved to 2.2 and that fixed that issue. Now on 2.4 the tree node click issue is back! : - ) Then this is a regression and you should most definitely file it as such right now (put Regression in the title of the bug) as there isn't much time left until the 2.4 release. -A- Date: Thu, 26 Feb 2009 13:21:10 + From: cont...@i-nz.net To: wallanedwa...@gmail.com CC: mono-list@lists.ximian.com; mono-winforms-l...@lists.ximian.com Subject: Re: [Mono-list] Bug? DataGridView on Mono Crashes (or locks rather)... does not occur on Microsoft platforms Please try using Mono 2.4 RC1 . There were *many* changes related to databinding and DGV that were done during the 2.4 development cycle. If you still experience problems then please file a bug (http://mono-project.com/Bugs) so I/we can look at it. On Thu, Feb 26, 2009 at 1:17 PM, W Allan Edwards silicon_pla...@hotmail.com wrote: I appear to have found a bug in the mono stack? Or was it a design implementation choice? Here is the scenario... I pull data from a database, then load up a Dataset then find it to a Datagridview. Then I substitute textual values inside of that grid based on the numeric values in the grid. I do this after I have already bound the DataSet table to the DataGridView. On the Microsoft side (Vista) this error does not occur... or no lock up. The DataTable object the datagridview is bound to simply updates to the underlying table data changed on the fly. When you run the commented lines of code the application on Mono will lock up and just stop execution. I get no exception thrown or any clue as to what is going on. The app just locks, I have to manually kill the process. I changed the code just to update the grid cell directly and it works fine on both platforms for display purposes. // Commented code that locks on linux //BoundDataSet.Tables[0].Rows[i][DataGridViewColumnIndexToConvert] = // DisplayValue; // Uncommented code below runs on both mono and the Microsoft stack no problems as expected oDataGridView.Rows[i].Cells[DataGridViewColumnIndexToConvert].Value = DisplayValue; Version information for reproduction OpenSuse 11.1 32-bit Linux, Mono 2.2 (freshly released and installed) Microsoft Windows Vista Home Premium edition 32-bit, .NET 2.0 framework compilation for all libs Algorithmic scenario 1 - Pull db data 2 - Bind to DataGridView 3 - Update numeric values in the underlying bound DataTable bound to the Grid (originally via the DataTable, now just the Grid Display Cell value) Thanks, -A- ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Bug in DataGridView.ScrollBars
2009/2/20 Marcelo Marques Inacio marceloina...@hotmail.com: Dear friends developers. The property ScrollBars.Vertical or ScrollBars.Horizontal in the DataGridView control is not working properly. The horizontal and vertical bar is always visible. Attached the following changes to correct operation. I have fixed this in r127716, thanks. Please next time directly file bugs for the WinForms component next time - http://mono-project.com/Bugs . -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] ListBox RemoveAt error.
On Mon, Jan 12, 2009 at 3:29 PM, Steve Harp st...@abelscreening.com wrote:
Hi All,
I'm using a ListBox in a WinForms application under Linux to provide
status/progress messages to the user. I'd like to limit the # of items in
the ListBox by deleting the first entry after some pre-defined limit has
been reached.
If (ListBox1.Items.Count myLimit)
{
ListBox1.Items.RemoveAt(0);
}
Whenever the application hits the RemoveAt line, it throws an exception.
System.ArgumentOutOfRangeException: Argument is out of range.
Parameter name: GetItemRectangle index out of range.
at System.Windows.Forms.ListBox.GetItemRectangle (Int32 index) [0x00167]
in
/usr/src/packages/BUILD/mono-2.0.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListBox.cs:847
at System.Windows.Forms.ListBox.GetItemDisplayRectangle (Int32 index,
Int32 first_displayble) [0x8] in
/usr/src/packages/BUILD/mono-2.0.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListBox.cs:1286
at System.Windows.Forms.ListBox.InvalidateItem (Int32 index) [0xc] in
/usr/src/packages/BUILD/mono-2.0.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListBox.cs:1687
at (wrapper remoting-invoke-with-check)
System.Windows.Forms.ListBox:InvalidateItem (int)
at System.Windows.Forms.ListBox+SelectedIndexCollection.ClearCore ()
[0x00030] in
/usr/src/packages/BUILD/mono-2.0.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListBox.cs:2699
at System.Windows.Forms.ListBox+SelectedIndexCollection.Clear ()
[0x0] in
/usr/src/packages/BUILD/mono-2.0.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListBox.cs:2687
at System.Windows.Forms.ListBox.ClearSelected () [0x0] in
/usr/src/packages/BUILD/mono-2.0.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListBox.cs:716
at (wrapper remoting-invoke-with-check)
System.Windows.Forms.ListBox:ClearSelected ()
I have similar code running on Windows boxes and it works fine with MS
.NET. What is the correct way to do this with Mono?
Thanks,
Steve
This most definitely seems like a bug in Mono, so please file a bug with a
small test case to reproduce the issue - http://mono-project.com/Bugs
--
Kind Regards,
Ivan N. Zlatev
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re gistry questions
On Tue, Jan 13, 2009 at 2:10 AM, rg1 rgrib...@yahoo.com wrote: I'm not completely following - Is there no way to continue to use Registry.LocalMachine.OpenSubKey() followed by a set of GetValue() calls? Even if I write a program to set the values -where are the values put? What file and what location is used? Because there is no Registry on Linux mono internally simulates a Registry by storing in and retrieving from XML the values (the xml files are stored in ~/.mono/registry/). This is an implementation detail as far as you are concerned and as Chris said you don't have to care about this and you should just go ahead and use the Registry API as usual. -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re gistry questions
On Tue, Jan 13, 2009 at 2:33 AM, Renee Griboff rgrib...@yahoo.com wrote: OK - but can you explain to me how to set up the XML file? I can't seem to find an example anywhere. Set up what? You can use the Registry API to set the initial values. You don't have to deal with the XML files. Please don't forget to CC the list (Reply to All). Thank you. --- On Mon, 1/12/09, Ivan N. Zlatev cont...@i-nz.net wrote: From: Ivan N. Zlatev cont...@i-nz.net Subject: Re: [Mono-list] Re gistry questions To: rg1 rgrib...@yahoo.com Cc: mono-list@lists.ximian.com Date: Monday, January 12, 2009, 9:30 PM On Tue, Jan 13, 2009 at 2:10 AM, rg1 rgrib...@yahoo.com wrote: I'm not completely following - Is there no way to continue to use Registry.LocalMachine.OpenSubKey() followed by a set of GetValue() calls? Even if I write a program to set the values -where are the values put? What file and what location is used? Because there is no Registry on Linux mono internally simulates a Registry by storing in and retrieving from XML the values (the xml files are stored in ~/.mono/registry/). This is an implementation detail as far as you are concerned and as Chris said you don't have to care about this and you should just go ahead and use the Registry API as usual. -- Kind Regards, Ivan N. Zlatev -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Cannot resize a winform
On Sun, Jan 4, 2009 at 6:25 AM, Olivier Duclos olivier.duc...@gmail.com wrote: Hi, I have a WinForm application developed under Visual Studio in .NET 2.0. The main window is an MDI. The application runs fine but is unusable because : - the main window starts at a too small fixed size (which was never set in VS) - I can't re-size or maximize the window despite these operations were allowed in VS Also, originally the main main window was supposed to start maximized, but mono didn't take account of this and kept starting at a (too small) fixed size. We tried everything we could in VS to make the main window re-sizable, but without success. Is this normal ? Any idea how to fix this ? Very strange. Please file a bug - http://mono-project.com/Bugs with a test case, mono version, etc. -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono-2.0.1 installation on Sparc (with commands)
On Fri, Jan 2, 2009 at 7:34 PM, Tynar rippe...@gmail.com wrote: Hi community I have successfully installed mono-2.0.1 on Solaris 10 sparc. I want to share the logs and settings I have applied. [snip] Hey, It might be helpful for other if you add this information to the Wiki at http://mono-project.com/Compiling_Mono -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-winforms-list] DataGridView Events are not supported Mono on Linux
On Sat, Jan 3, 2009 at 2:10 PM, Stifu st...@free.fr wrote: It seems like a known issue, it's just not implemented yet. Follow these bugs (but don't spam them): https://bugzilla.novell.com/show_bug.cgi?id=428870 Bug 428870 - DataGridView: Begin implementation https://bugzilla.novell.com/show_bug.cgi?id=428871 Bug 428871 - DataGridView: Implement IGridProvider and events https://bugzilla.novell.com/show_bug.cgi?id=428872 Bug 428872 - DataGridView: Implement ITableProvider and events https://bugzilla.novell.com/show_bug.cgi?id=428873 Bug 428873 - DataGridView: Implement ITableItemProvider and events Those bugs are not WinForms bugs, but UIA bugs (WinForms accessibility framework bugs). For some reason I don't have the initial e-mail that was posted to the list and only your reply, but I would suggest to the original poster to file a bug - http://mono-project.com/Bugs . There is very high chance that I have fixed the problems in SVN trunk already, but this can't be determined without a filed bug and a good test case. -- Kind Regards, Ivan N. Zlatev ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] [Mono-list] Announcing Mono 2.2 RC1...
On Tue, Dec 23, 2008 at 12:47 AM, Thomas Wiest twi...@novell.com wrote: Hey Everyone, We've just released Mono 2.2 RC1 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.2 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.2.xorder=bugs.bug_status The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed. Please help the Mono team to make 2.2 the best ever. Hi Thomas, Can you please add the fixed and backported bug https://bugzilla.novell.com/show_bug.cgi?id=381435 (Castle Project) to your tracking. Thanks. -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Announcing Mono 2.2 RC1...
On Tue, Dec 23, 2008 at 12:47 AM, Thomas Wiest twi...@novell.com wrote: Hey Everyone, We've just released Mono 2.2 RC1 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.2 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.2.xorder=bugs.bug_status The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed. Please help the Mono team to make 2.2 the best ever. Hi Thomas, Can you please add the fixed and backported bug https://bugzilla.novell.com/show_bug.cgi?id=381435 (Castle Project) to your tracking. Thanks. -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Object data source update fails on nullable field.
2008/12/16 Vladimir Krasnov vladim...@mainsoft.com Hi Marek, I've found some problems in updating row in GridView control that bound to ObjectDataSource. 1. ObjectDataSource fails to convert values to Nullable properties while creating data object. 2. BoundField should return null when no value entered by the user, it returns empty string and ObjectDataSource fails to convert it. Please review attached patch that fixes both these problems, also find attached test cases. Vladimir I don't know if the web databinding layer uses TypeConverters (the WinForms one does), but just in case I should note that I have implemented the NullableConverter two weeks ago in SVN HEAD. -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Object data source update fails on nullable field.
On Tue, Dec 16, 2008 at 8:40 PM, Marek Habersack mhabers...@novell.com wrote: On Tue, 2008-12-16 at 10:29 +, Ivan N. Zlatev wrote: 2008/12/16 Vladimir Krasnov vladim...@mainsoft.com Hi Marek, I've found some problems in updating row in GridView control that bound to ObjectDataSource. 1. ObjectDataSource fails to convert values to Nullable properties while creating data object. 2. BoundField should return null when no value entered by the user, it returns empty string and ObjectDataSource fails to convert it. Please review attached patch that fixes both these problems, also find attached test cases. Vladimir I don't know if the web databinding layer uses TypeConverters (the WinForms one does), but just in case I should note that I have implemented the NullableConverter two weeks ago in SVN HEAD. It does, when the type being converted is adorned with the TypeConverter attribute A type doesn't necessarily have to have a TypeConverterAttribute attached. There is a table of predefined converters in TypeDescriptor that it always falls back to. In addition TypeConverters can be fed via TypeDescriptionProvider-s added to the TypeDescriptor. -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Swf BUG(?) in Validating event
On Fri, Dec 12, 2008 at 4:40 AM, Charlie Poole char...@nunit.com wrote: I'm seeing my Validating events fire when I simply open and close a form under Mono 2.0.1. With Windows, they only fire if I give a control focus and then move away from it. If this is already addressed in 2.2, I can work around it. Does anyone know? Can't tell without a test case :-). Please file a bug. -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Swf BUG(?) in Validating event
On Fri, Dec 12, 2008 at 12:04 PM, Paul p...@all-the-johnsons.co.uk wrote: Hi, I'm seeing my Validating events fire when I simply open and close a form under Mono 2.0.1. With Windows, they only fire if I give a control focus and then move away from it. If this is already addressed in 2.2, I can work around it. Does anyone know? Can't tell without a test case :-). Please file a bug. Sounds like this one... https://bugzilla.novell.com/show_bug.cgi?id=450342 No, this bug is different -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-winforms-list] DataGridView binding not working
On Tue, Dec 2, 2008 at 11:53 AM, marcos b [EMAIL PROTECTED] wrote:
I have a datatable binded to a DataGridView.
When I add a record in the gridview a row is added to the datatable when
running in .net environment, but no row is added when running in mono.
I didn't try, but I supose that edit, and delete actions in the gridview do
not affect the datatable neither.
Is it a known bug? When is it going to be fixed?
Hey,
I have fixed this problem in SVN HEAD, which means it will be fixed in the
next mono 2.x release.
I paste the code of my form below. The form only has a DataGridView named
dataGridView1 and a button
public partial class DataGridViewTest : Form
{
DataTable dt = new DataTable();
public DataGridViewTest()
{
InitializeComponent();
}
private void btnNumberOfRows_Click(object sender, EventArgs e)
{
MessageBox.Show(dt.Rows.Count.ToString());
}
private void DataGridViewTest_Load(object sender, EventArgs e)
{
dt.Columns.Add(Key);
dt.Columns.Add(Value);
dt.Rows.Add(1, one);
dataGridView1.DataSource = dt;
}
}
--
View this message in context:
http://www.nabble.com/DataGridView-binding-not-working-tp20780541p20780541.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
Kind Regards,
Ivan N. Zlatev
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] System.Drawing.Graphics.MeasureCharacterRanges broken with empty layout rectangle
2008/11/27 Stefanos A. [EMAIL PROTECTED]: When MeasureCharacterRanges is passed an empty layout rectangle (RectangleF.Empty), it should not perform any word wrapping. Attached is a test case that demonstrates the issue (runs fine under .Net). The best way to get this properly tracked is to file a bug in Bugzilla - http://mono-project.com/Bugs. -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Inheriting from System.Windows.Forms.TextBox
On Thu, Nov 20, 2008 at 4:47 PM, Jb Evain [EMAIL PROTECTED] wrote:
Hey,
On 11/20/08, Jon Harrop [EMAIL PROTECTED] wrote:
Any ideas why?
It looks like a F# compiler bug to me.
Just for info the the method is defined in the TextBoxBase:
internal abstract Color ChangeBackColor (Color backColor);
and implemented in the TextBox class:
internal override Color ChangeBackColor (Color backColor) { ... }
So maybe the F# compiler/interpreter doesn't handle internal abstract ?
--
Kind Regards,
Ivan N. Zlatev
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SPAM-LOW: Re: Inheriting from System.Windows.Forms.TextBox
On Thu, Nov 20, 2008 at 7:08 PM, Charlie Poole [EMAIL PROTECTED] wrote:
Hi
On Thu, Nov 20, 2008 at 4:47 PM, Jb Evain [EMAIL PROTECTED] wrote:
Hey,
On 11/20/08, Jon Harrop [EMAIL PROTECTED] wrote:
Any ideas why?
It looks like a F# compiler bug to me.
Just for info the the method is defined in the TextBoxBase:
internal abstract Color ChangeBackColor (Color backColor);
and implemented in the TextBox class:
internal override Color ChangeBackColor (Color backColor) { ... }
It also seems to be a design bug. What's the point of having
a public abstract class if it's written in such a way that you
can only extend it internally?
Hi,
It's definitely not a design bug, but quite the opposite.
TextBox(Base) is part of the Windows Forms API, which is part of the
.NET Class Library, which we have to be API compatible with. However
the public API covers only so much functionality and there is so much
more that happens behind the scenes, which requires a lot of internal
code implemented, which is implemented in a nice OO manner.
--
Kind Regards,
Ivan N. Zlatev
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Linux Equivalent to Visual Studio?
--- Original message --- From: Jerry Houston [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: 29.10.'08, 22:33 Petit Eric wrote: http://www.mono-project.com/WinForms_Designer Yeah! Now, that's what I'm talking about. I'll check back later ... hopefully it will become available via something other than svn when it's closer to stable. Thanks! Hi, please do not have high expectations usability-wise. It's such a shame the designer's state, because the complex infrastructure work is already done and we only lack a decent drag and drop mechanism. In order to implement one like VS's snap lines we need to have a transparent control on top of the design surface. This is where we hit a wall, because while on Win32 transparency can be achieved easily by an extra flag in CreateParams, this has proven to be hell (for me at least) on X/Linux. Everaldo, I remember that you mentioned that you are poking at the transparency again some time ago. Did you get anywhere? Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] RichTextBox Scroll Position
On Mon, Oct 20, 2008 at 5:00 PM, Alisdair Little [EMAIL PROTECTED] wrote: Hi Guys, Any idea how to get the vertical scroll position for a RichTextBox? I have tried; [DllImport(user32)] public static extern bool GetScrollInfo(IntPtr hwnd, int fnBar, ref SCROLLINFO lpsi); [DllImport(user32)] public static extern int GetScrollPos(IntPtr hwnd, int nBar); [DllImport(user32)] public static extern int SendMessage(HWND hwnd, int wMsg, int wParam, IntPtr lParam); All these calls work under Visual Studio/windows but not under mono. My Environment: Windows XP, Visual Studio 2005 and Mono 2.0. What about richTextBox.GetPositionFromCharIndex (richTextBox.GetFirstCharIndexFromLine (0)).Y ? -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Fwd: RichTextBox Scroll Position
-- Forwarded message -- From: [EMAIL PROTECTED] Date: Tue, Oct 21, 2008 at 4:28 PM Subject: Re: RichTextBox Scroll Position To: [EMAIL PROTECTED] Hi Ivan, Thanks so much for the hint. It works like a charm! Kind Regards, Al Ivan N. Zlatev wrote: On Mon, Oct 20, 2008 at 5:00 PM, Alisdair Little [EMAIL PROTECTED] wrote: Hi Guys, Any idea how to get the vertical scroll position for a RichTextBox? I have tried; [DllImport(user32)] public static extern bool GetScrollInfo(IntPtr hwnd, int fnBar, ref SCROLLINFO lpsi); [DllImport(user32)] public static extern int GetScrollPos(IntPtr hwnd, int nBar); [DllImport(user32)] public static extern int SendMessage(HWND hwnd, int wMsg, int wParam, IntPtr lParam); All these calls work under Visual Studio/windows but not under mono. My Environment: Windows XP, Visual Studio 2005 and Mono 2.0. What about richTextBox.GetPositionFromCharIndex (richTextBox.GetFirstCharIndexFromLine (0)).Y ? -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Quoted from: http://www.nabble.com/RichTextBox-Scroll-Position-tp20073031p20092389.html -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-winforms-list] Oddball SWF problem.
On Tue, Sep 9, 2008 at 1:22 PM, Paul [EMAIL PROTECTED] wrote:
Hi,
I'm using a bog standard OpenFileDialog with Mono 2.0 RC 1 (code below).
When I run the app, everything is fine until I go to the directory which
contains .spec files (these are plain text files used for packaging
under Linux).. it then goes kabloom with the following throwback (from
MD 1.9)
It seems that on your setup there is no icon associated with the mime
type for the .spec and there is no fallback by the gnome/gtk
functions (weird) and we don't handle that nicely. I can't reproduce
here (.spec mime type is text/x-rpm-spec and icon is the text file
one). I suggest you file a bug so we can fix this. It's probably just
a missing null check somewhere.
Unhandled Exception: System.ArgumentNullException: Argument cannot be
null.
Parameter name: value
at System.Windows.Forms.ImageList+ImageCollection+ImageListItem..ctor
(System.Drawing.Image value) [0x0003b]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ImageList.cs:202
at System.Windows.Forms.ImageList+ImageCollection+ImageListItem..ctor
(System.Drawing.Image value, Color transparentColor) [0x0]
in /home/paul/rpmbuild/BUILD/mono-2.0/mcs/build/common/Consts.cs:1
at System.Windows.Forms.ImageList+ImageCollection.Add
(System.Drawing.Image value, Color transparentColor) [0x0]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ImageList.cs:716
at System.Windows.Forms.GnomeHandler.AddAndGetIconIndex (System.String
filename, System.String mime_type) [0xc]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/MimeIcon.cs:374
at System.Windows.Forms.MimeIconEngine.GetIconIndexForFile
(System.String full_filename) [0x0006b]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/MimeIcon.cs:159
at System.Windows.Forms.FileSystem.GetFileFSEntry (System.IO.FileInfo
fileinfo) [0x00043]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/FileDialog.cs:3597
at System.Windows.Forms.FileSystem.GetNormalFolderContent
(System.String from_folder,
System.Collections.Specialized.StringCollection filters,
System.Collections.ArrayList directories_out,
System.Collections.ArrayList files_out) [0x000ea]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/FileDialog.cs:3543
at System.Windows.Forms.FileSystem.GetFolderContent
(System.Collections.Specialized.StringCollection filters,
System.Collections.ArrayList directories_out,
System.Collections.ArrayList files_out) [0x0016f]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/FileDialog.cs:3465
at System.Windows.Forms.MWFVFS+WorkerThread.GetFolderContentThread ()
[0x0]
in
/home/paul/rpmbuild/BUILD/mono-2.0/mcs/class/Managed.Windows.Forms/System.Windows.Forms/FileDialog.cs:3240
The application was terminated by a signal: SIGHUP
Code which did the nasty
8--
private string createDialog()
{
OpenFileDialog filer = new OpenFileDialog();
filer.Filter = spec files (*.spec)|*.spec;
filer.Title = Select a spec file;
return ( filer.ShowDialog() == DialogResult.OK )
? filer.FileName : null;
}
private void button1Click(object sender, EventArgs e)
{
createDialog();
}
--8
Nothing nasty, it just doesn't behave!
Any ideas?
TTFN
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
Kind Regards,
Ivan N. Zlatev
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-list] About Mono installation in CentOS
On Wed, Sep 3, 2008 at 7:42 PM, javierfernandez108 [EMAIL PROTECTED] wrote: Roilan Cardoso Sánchez wrote: Hello everybody I'm trying to install Mono on my CentOS 5 but i coudn't Firstly i try using mono.repo for centos, but when it try to install libgdiplus it throw an dependency error, coudn't find libexif.so.9 and libungif.so.4 Then i try with the .bin istalator and the throw the same error but with libgailutil.so.17 and liblitz.so.1 I try too, with the CentOS Extras reporsitory and the same but with lifgif.so.4 Finally I reinstall my system and from 0 y try with the CentOS GUI installer in extras Mono, it works, but when i try to run an application (GUI app) mono thow error coudn't find gdiplus.dll I really don't know what to do, please can any budy help me regards Roilan ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list I'm having a similar problem on a RH4 x86_64 box. I went to the download page (http://ftp.novell.com/pub/mono/download-stable/rhel-4-i386/) and downloaded all the RPM's in a zip file, and first attempted to install the libgdiplus0-1.9-1.rhel4.novell.i386.rpm and it gave me error: Failed dependencies: libexif.so.9 is needed by libgdiplus0-1.9-1.rhel4.novell.i386 libglib-2.0.so.0 is needed by libgdiplus0-1.9-1.rhel4.novell.i386 libjpeg.so.62 is needed by libgdiplus0-1.9-1.rhel4.novell.i386 libpng12.so.0 is needed by libgdiplus0-1.9-1.rhel4.novell.i386 libtiff.so.3 is needed by libgdiplus0-1.9-1.rhel4.novell.i386 libungif.so.4 is needed by libgdiplus0-1.9-1.rhel4.novell.i386 I verified I had a libexif rpm installed and found libexif-0.5.12-5.1.0.2. The I searched and found /usr/lib64/libexif.so.9 installed. Is this an issue x86_64 issue where I cannot use the downloaded rpms with this architecture? It seems you are installing 32bit mono packages on a 64bit system and those packages require 32bit dependencies and not their 64bit equivalents. -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-winforms-list] Support for programatic scrolling via WM_VSCROLL and WM_HSCROLL messages
Jeff Richardson wrote:
This patch adds support for certain controls to respond to WM_HSCROLL
and WM_VSCROLL messages to allow them to be scrolled programatically.
I've implemented this for every control in which both contains an
instance of ImplicitVScrollBar and ImplicitHScrollBar and have the
corresponding .NET type respond to sending the WM_HSCROLL and WM_VSCROLL
messages, with the exception of MdiClient (I'm unsure exactly how to
test that).
* The patch breaks the compilation as you are not adding the ScrollType
file to the list of sources in System.Windows.Forms.dll.sources
* The ScrollType enum is redundant - we already have it as
ScrollBarCommands in XplatUIStructs
Index: System.Windows.Forms/ScrollType.cs
===
--- System.Windows.Forms/ScrollType.cs (revision 0)
+++ System.Windows.Forms/ScrollType.cs (revision 0)
@@ -0,0 +1,10 @@
+namespace System.Windows.Forms{
+internal enum ScrollType{
+SB_LINEUP =0,
+SB_LINEDOWN = 1,
+SB_PAGEUP =2,
+SB_PAGEDOWN = 3,
+SB_TOP = 6,
+SB_BOTTOM =7,
+}
+}
Commenting out the SendWMScroll method basically breaks scrolling
completely. I don't know if and how you've tested your patch. Unlike
WinForms on MSNET/Win32 our scrollbars are custom controls and they
don't automagically fire WM_?SCROLL messages somewhere down the native
code pipe, so by commenting out the method we won't ever send/receive
WM_?SCROLL.
--- System.Windows.Forms/ScrollBar.cs (revision 109230)
+++ System.Windows.Forms/ScrollBar.cs (working copy)
@@ -668,6 +668,12 @@
}
private void SendWMScroll(ScrollBarCommands cmd) {
+ // Since the WM_?SCROLL messages actually trigger
+ // scrolling a control at the same time as the
+ // control responds to the ScrollBar events,
+ // having the ScrollBar send the WM_?SCROLL event
+ // tends to cause a double scroll.
+ /*
if ((Parent != null) Parent.IsHandleCreated) {
if (vert) {
XplatUI.SendMessage(Parent.Handle,
Msg.WM_VSCROLL, (IntPtr)cmd,
implicit_control ? IntPtr.Zero : Handle);
@@ -675,6 +681,7 @@
XplatUI.SendMessage(Parent.Handle,
Msg.WM_HSCROLL, (IntPtr)cmd,
implicit_control ? IntPtr.Zero : Handle);
}
}
+ */
}
* A minor coding style issue is the lack of space prior to the opening (
in most of the method definition.
The rest of the patch seems alright. It's very unfortunate that we have
to do this for each control though.
Please send a revised patch, thanks.
--
Kind Regards,
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] When passing managed array of COM object references (Marshaled as UnmanagedType.LPArray) to native Code, expected native COM ptrs are invalid.
On Fri, Aug 15, 2008 at 2:43 AM, Tom Hindle [EMAIL PROTECTED] wrote: Hi, When passing managed array of COM object references (Marshaled as UnmanagedType.LPArray) to native Code, expected native COM ptrs are invalid. This same technique works when running on MS .Net. If it works on MS.NET and not on Mono then it's a bug and as such it should be filed with a small self-contained test case. For information on how to file bugs check: http://mono-project.com/Bugs . 1. I'm running on Linux (Hardy), using mono build from svn. 2. I have created 2 C++ COM objects using libCom. 3. I have created a c# Interop to call/create these COM objects. relevant line in Interop is: [MethodImpl(MethodImplOptions.InternalCall,MethodCodeType=MethodCodeType.Runtime)] public virtual extern void PassComArray( int length, [MarshalAs(UnmanagedType.LPArray, SizeParamIndex=0] INativeCreatedObject[] a); 4. I create an instance of the COM object in c# I use that to return a Naively created COM object to c#. I can use this COM object in c#. However passing this COM object ref as an array back to native doesn't work. IE: Test t = new Test(); // Create Com object Test INativeCreatedObject i; t.CreateNativeObject(out i); // return another Com object created naively. // prints address as 0x83cbd50 i.DoSomething(); // Works fine. // Create managed array INativeCreatedObject[] array = new INativeCreatedObject[10]; array[0] = i; t.PassComArray(1, array); // address of array element 0 is 0x60d80 not 0x83cbd50 which means using the COM object ptr will crash. 5. This Marshaling technique works in mono when passing int's. IE: MethodImpl(MethodImplOptions.InternalCall, MethodCodeType=MethodCodeType.Runtime)] public virtual extern void PassIntArray([MarshalAs(UnmanagedType.LPArray, SizeParamIndex=0)] int length, int[] a); 6. after gdb-ing mono I suspect the problem with the CIL that is generated for the marshaling (is it called the Runtime Callable Wrapper?) However I can't verify this as I can't program in any Assembler :( I have a work around using a custom marshaler, but I would rather use the same interops on both Windows and Linux. Thanks in advance for any advice. Tom ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kind Regards, Ivan N. Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] TypeConverter cannot convert from System.String in2.0 preview 1
On Mon, Aug 11, 2008 at 1:34 PM, Andrus [EMAIL PROTECTED] wrote: https://bugzilla.novell.com/show_bug.cgi?id=414445 To verify Ivan's fix I tried the following: 1. http://mono.ximian.com/snapshots/ is broken The actual link (as present in the Download section on mono-project.com) is http://mono.ximian.com/monobuild/snapshot/download-trunk/ 2. http://www.mono-project.com/Guide:_Debugging_With_MWF using those instructions VCSE 2008 reports missing links to WebBrowser control. I added WebBrowser project also to solution but VCSE still reports some missing references and refuces to compile. How to verify this fix in Windows ? I haven't ever build mono with Visual Studio, so I can't help there. However you could use this quick step by step guide to compile and install from source at http://i-nz.net/2006/03/14/compile-mono-svn-head-on-windows/ . I hope that helps. -- Kind Regards, Ivan N. Zlatev ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-winforms-list] [PATCH] Avoid sending MouseEnter messages when clicking
On Mon, Aug 11, 2008 at 3:14 PM, Carlos Alberto Cortez [EMAIL PROTECTED] wrote: Hey Ivanz, The attached patch reverts a check in XplatUIX11.GetMessage method, specifically handling the X11 EnterNotify message generated when clicking a control (rev 101225). Basically when a control is clicked, EnterNotify events are generated for the container form and the control being clicked. Usually when we get this event we generate a WM_MOUSE_ENTER message, but in this case we don't need it, since it's not real pointer motion. That's why, when the EnterNotify event tell us that it's a not a real motion event, we have to ignore it, no matter the value of the window/hwnd (right now, when clicking any control, MouseEnter/MouseMove events are generated for the containing form, which is obviously wrong). Hopefully that was clear ;-D I can't look into more detail into that this week and unfortunately I don't remember of the top of my head what the bug involved. However, have you verified that the patch doesn't regress Gert's test case (not the original reporter's one) in bug 323234 (which rev 101225 was supposed to fix)? -- Kind Regards, Ivan N. Zlatev ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-list] TypeConverter cannot convert from System.String in 2.0 preview 1
On Mon, Aug 4, 2008 at 5:08 PM, Andrus [EMAIL PROTECTED] wrote:
My WinForms application does not start with 2.0 preview 1. Exception is
below.
If it runs on MS.NET but doesn't run on mono then it's a bug of ours.
Can you please make a *small* self-contained test case out of your
application by extracting only the part that causes the exception and
then file a bug with it (attach it to the bug) -
http://mono-project.com/Bugs. Then post the bug number.
--
Kind Regards,
Ivan N. Zlatev
Maybe this is because I store Font object in user settings:
[global::System.Configuration.UserScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute(Arial,
15pt)]
public global::System.Drawing.Font TextBoxFont {
get {
return ((global::System.Drawing.Font)(this[TextBoxFont]));
}
set {
this[TextBoxFont] = value;
}
}
How to fix ?
Andrus.
Unhandled Exception: System.TypeInitializationException: An exception was
thrown by the type initializer for
MyApplication.Windows.Forms.Properties.Settings ---
System.NotSupportedException: TypeConverter cannot convert from
System.String.
at System.ComponentModel.TypeConverter.GetConvertFromException
(System.Object value) [0x0]
at System.ComponentModel.TypeConverter.ConvertFrom (ITypeDescriptorContext
context, System.Globalization.CultureInfo culture, System.Object value)
[0x0]
at System.ComponentModel.TypeConverter.ConvertFrom (System.Object o)
[0x0]
at System.ComponentModel.TypeConverter.ConvertFromString (System.String
text) [0x0]
at System.Configuration.ApplicationSettingsBase.CreateSettingsProperty
(System.Reflection.PropertyInfo prop,
System.Configuration.SettingsPropertyCollection properties,
System.Configuration.LocalFileSettingsProvider local_provider) [0x0]
at System.Configuration.ApplicationSettingsBase.get_Properties ()
[0x0]
at System.Configuration.ApplicationSettingsBase..ctor () [0x0]
at MyApplication.Windows.Forms.Properties.Settings..ctor () [0x0]
at MyApplication.Windows.Forms.Properties.Settings..cctor () [0x0]
--- End of inner exception stack trace ---
at MyApplication.Windows.Forms.UserLoginForm.InitializeComponent ()
[0x0]
at MyApplication.Windows.Forms.UserLoginForm..ctor () [0x0]
at (wrapper remoting-invoke-with-check)
MyApplication.Windows.Forms.UserLoginForm:.ctor ()
at MyApplication.Windows.Forms.AppMainEntry.Main () [0x0]
___
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] 1 pixel offset problem
[EMAIL PROTECTED] wrote: I see another potentially related bug with drawing. I am trying to draw some Bezier curves (with GraphicsPath); and the positioning and appearance is way off (at least with respect to MS .NET). Can someone comment on this? I have attached source code, makefile, and two screenshots (ms.net/windows vs. mono/linux). I see the bad rendering with SVN Head as well. Please file a bug[1] for the System.Drawing component with a good description of the problem, a self-contained test case and the screenshots attached. [1] http://mono-project.com/Bugs Kind Regards, -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Scrolling performance isues
Carlos Alberto Cortez wrote: Hey, The new code that detects not visibles areas of the window to scroll (obscured by other mwf windows or x11 top level ones), although working fine, is somewhat slow, as some people have noticed. After some research, I found that getting all the child windows for the root window (using XQueryTree on RootWindow, this is, top level windows) is the hot spot, and was causing the slow down. And after some more research in other graphics tool kits, found that: * Most of them make use of GraphicsExpose event, handling it by directly generating expose events or invalidating the area pointed by GraphicsExpose (Gtk+ as far as I know, and also Ivan told me other frameworks do that). Yes, this is because GraphicsExpose is designed exactly for that purpose. It is fired when a destination area can't be copied (XCopyArea) to because the source area is obscured. I still fail to see why we need special obscured-areas-checking logic when we can just handle that message. I do understand that if we do indeed handle the GraphicsExpose message we stand the problem that it might get delayed (X11 message roundtrip time) until after we perform the next ScrollWindow/XCopyArea, so because the destination area (for the previous ScrollWindow call) won't be repainted yet we will copy that garbage from it to the next offset. However we currently have an explicit AddExpose just after the XCopyArea, so we are working around this problem by forcing a repaint on the queue, so that we are guaranteed to be repainted prior to the next ScrollWindow. And this just-works (tm) :-) If we want to handle it properly we can either 1) Flush the paint queue prior to XCopyArea somehow ... or ... 2) Block the message queue until we get the last GraphicsExpose for the window, invalidate and then unblock the message queue. ... or ... 3) Something better And also, regarding our code: * When using composite (Xgl or similar) it's not necessary to do this detection, since the window manager (*it seems*) is doing something that somehow already knows which areas need to get an expose event (in other words: only mwf overlapping detection is needed, not for x top level windows). * The new code, at least in my laptop, without using composite, seems to work fine (no performance lost), and don't know if it's because XQueryTree on RootTree returns a minor number of windows (61 with no composite, instead of 89 with composite, using 5 terminals and a gtk+ application, for example). This I think is very implementation/environment/window manager/toolkit specific. E.g some toolkits/window managers might keep menu windows as hidden, but still mapped toplevels. I think this was referred to as one of the reason for the huge number of toplevels in some email I saw on a mailing list long time ago. Because of the variety of setups out there (window managers, toolkits, etc, etc) we can't really know with how many toplevels we are going to deal. To give you an example of the problem - on my GNOME + Metacity desktop with a standard set of programs running (Firefox, terminal, pidgin, nautilus, thunderbird, etc) XQueryTree returns 228 toplevels. So, it seems that we should actually handle GraphicsExpose (which all it involves) *or maybe* try to detect if we are using composite - if we are, simply don't use this new code, but just do simple calculations, and if we are not using it, do the detection, since it won't harm the performance. My personal position on the matter is that short-term (as in for Mono 2.0) we just handle GraphicsExpose instead of the new code and keep the AddExpose after XCopyArea to workaround the timing issue. Long-term we can look into adding a proper handling for the delays of GraphicsExpose if it's feasible. But I woould like people to tell me how this code (2.0 branch or trunk) behaves for them, in both cases (since I remember that Ivan was having performance problems with the new code even without using composite). As I mentioned above with my setup I have 228 toplevels and I get garbage everywhere when scrolling on a Core Duo 2 machine. Tell me what do you think, Cheers, -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] 1 pixel offset problem
Ernesto wrote: Hi, I noticed that System.Drawing primitives will sometimes render things with a one pixel offset. I noticed that this affects MWF too, and I understand this is a libgdi problem, probably related to the fact that cairo takes pixel coordinates in a different way than Windows' GDI+. The attached screenshot shows the problem in the Cancel button right border of a MessageBox. Seems like you are using an old libgdiplus with a newer MWF. What versions of Mono and libgdiplus have you got installed? I'm willing to try to fix this, but I wanted to ask first if this is a known issue or limitation of the current gdiplus implementation. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] Patch for mwf-designer
Petit Eric wrote: Hi Ivan, the last SVN version seem to always have the case naming problem, who fire exception no codebhind .designer.cs vs .Designer.cs, unlluke, i have errase the fix i did after the svn up, but from my memory it was a simple or, i think it should be better to use something like StringComparison.OrdinalIgnoreCase. or a function to check if the file is Designer.cs or .designer.cs .. This is now fixed in r108680. I made the search for codebehind file case insensitive. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for mwf-designer
Guillaume Simard wrote: Hello, Please find attached a suggested patch for mwf-designer, which corrects improper exception handling when empty fields are provided in the NewFileDialog dialog box (upon pressing Done). Thanks for the patch. I have applied it in SVN. However I had to edit it prior to that, because you haven't followed Mono's coding style guidelines. I assume you just weren't aware of them, so it's okay for this patch, but please keep in mind for the next. Now, to reply to the message you sent me privately through my blog, where you were showing general interest of the status of the mwf-designer and you were expressing interest in contributing. During the weekend I have updated the designer wiki page at http://www.mono-project.com/WinForms_Designer. Now you will find much better information and documentation resources. Please read it through. You will find a lot of goodies, including documentation resources, installation guide, but probably most important for you (as you have stated that you are a hardcore Visual Studio user) will be the fact that during the weekend I have made it possible to fully develop, debug, use, etc mono's design-time code (subset of the System.Design assembly) + the windows forms designer in Visual Studio and run it on MS.NET. This should give you a kick-start if you are interested in contributing. The wiki page has all of the details. The wiki page, the source code and the documentation resources section on the wiki page, which includes my dissertation from last year titled Building User Interface Design Tools could be of interest for someone looking into that area. Definitely poke me if you have any questions or you need help with getting around the code. Kind Regards, Ivan Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-winforms-list] Things for 2.0...
Andy Hume wrote: Hi chaps I've had no Internet access for the last fortnight or so, so still working my way through my emails... Anyway before its too late, can I suggest some bugs that should be looked at before the release. There's actually only one major one, bug 383462 where a crash occurs in DateTimePicker when one types in a year. Eeek! Other things that would be nice to have include that old chestnut, bug 324237 non-painting NotifyIcon. What's the trick to get tray icons to paint in X?! I have a fix for the NotifyIcon painting issues on X11, which I haven't committed because 1) I am having internet issues since 3 days (argh!) and 2) I am still debating on something about the fix. I will surely commit it by the end of the week and also backport it to the 2.0 branch. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. Another thing -- thought not entirely WinForms -- that was discussed on the bugs database but not fixed was BackgroundWorker, bug 328830 and bug 373153 . Or maybe too late now? HTH Andy ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Fwd: [PATCH] AutoSize fixes for bug 355408 - Please Review
On Wed, Jul 2, 2008 at 4:48 PM, Jonathan Pobst [EMAIL PROTECTED] wrote: Hey Ivan, Your patch leaves two blocks of unreachable code. Ops. I blame my editor's automagic unsurround feature :) Also, layout is extremely tricky and easily testable, so EVERY change to default/table/flow layout MUST have a test case. See TableLayoutTest.cs. Yeah I was going to write the tests, but thought I might get this looked at first. So yeah, I will write the tests and then commit. Thanks. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [PATCH] AutoSize fixes for bug 402849 - Please Review
Attached patch fixes bug #402849 and basically boils down to two main things
- We should check whether children are in AutoSize and only then ask
for PreferredSize, else use ExplicitBounds.
- Apply padding to the preferred size for Form.
If no objections, I will commit.
Thanks,
Ivan
Index: System.Windows.Forms/FlowLayoutPanel.cs
===
--- System.Windows.Forms/FlowLayoutPanel.cs (revision 107002)
+++ System.Windows.Forms/FlowLayoutPanel.cs (working copy)
@@ -120,7 +120,11 @@
bool horizontal = FlowDirection == FlowDirection.LeftToRight || FlowDirection == FlowDirection.RightToLeft;
if (!WrapContents || (horizontal proposedSize.Width == 0) || (!horizontal proposedSize.Height == 0)) {
foreach (Control control in Controls) {
- Size control_preferred_size = control.PreferredSize;
+ Size control_preferred_size;
+ if (control.AutoSize)
+ control_preferred_size = control.PreferredSize;
+ else
+ control_preferred_size = control.Size;
Padding control_margin = control.Margin;
if (horizontal) {
width += control_preferred_size.Width + control_margin.Horizontal;
@@ -135,7 +139,11 @@
int size_in_other_direction = 0;
int increase;
foreach (Control control in Controls) {
- Size control_preferred_size = control.PreferredSize;
+ Size control_preferred_size;
+ if (control.AutoSize)
+ control_preferred_size = control.PreferredSize;
+ else
+ control_preferred_size = control.ExplicitBounds.Size;
Padding control_margin = control.Margin;
if (horizontal) {
increase = control_preferred_size.Width + control_margin.Horizontal;
Index: System.Windows.Forms/ChangeLog
===
--- System.Windows.Forms/ChangeLog (revision 107010)
+++ System.Windows.Forms/ChangeLog (working copy)
@@ -1,3 +1,13 @@
+2008-07-01 Ivan N. Zlatev [EMAIL PROTECTED]
+
+ * Form.cs:
+ - (GetPreferredSizeCore): Use PreferredSize only if the
+ child is AutoSize, else you the ExplicitBounds.
+ - (GetPreferredSizeCore): Add up the Padding.
+ * FlowLayoutPanel.cs: (GetPreferredSizeCore): Use PreferredSize
+ only if the child is AutoSize, else you the ExplicitBounds.
+ [Fixes bug #402849]
+
2008-07-01 Carlos Alberto Cortez [EMAIL PROTECTED]
* ListViewItem.cs: Restore the initial value of bounds rect to
Index: System.Windows.Forms/Form.cs
===
--- System.Windows.Forms/Form.cs (revision 107002)
+++ System.Windows.Forms/Form.cs (working copy)
@@ -169,21 +169,36 @@
Size retsize = Size.Empty;
foreach (Control child in Controls) {
+Size child_preferred_size;
+if (child.AutoSize)
+ child_preferred_size = child.PreferredSize;
+else
+ child_preferred_size = child.ExplicitBounds.Size;
+int child_right = child.Bounds.X + child_preferred_size.Width;
+int child_bottom = child.Bounds.Y + child_preferred_size.Height;
+
if (child.Dock == DockStyle.Fill) {
- if (child.Bounds.Right retsize.Width)
- retsize.Width = child.Bounds.Right;
+ if (child_right retsize.Width)
+ retsize.Width = child_right;
}
-else if (child.Dock != DockStyle.Top child.Dock != DockStyle.Bottom (child.Bounds.Right + child.Margin.Right) retsize.Width)
- retsize.Width = child.Bounds.Right + child.Margin.Right;
+else if (child.Dock != DockStyle.Top child.Dock != DockStyle.Bottom child_right retsize.Width)
+ retsize.Width = child_right + child.Margin.Right;
if (child.Dock == DockStyle.Fill) {
- if (child.Bounds.Bottom retsize.Height)
- retsize.Height = child.Bounds.Bottom;
+ if (child_bottom retsize.Height)
+ retsize.Height = child_bottom;
}
-else if (child.Dock != DockStyle.Left child.Dock != DockStyle.Right (child.Bounds.Bottom + child.Margin.Bottom) retsize.Height)
- retsize.Height = child.Bounds.Bottom + child.Margin.Bottom;
+else if (child.Dock != DockStyle.Left child.Dock != DockStyle.Right child_bottom retsize.Height)
+ retsize.Height = child_bottom + child.Margin.Bottom;
}
+ if (retsize == Size.Empty) { // no child controls
+retsize.Height += this.Padding.Top;
+retsize.Width += this.Padding.Left;
+ }
+ retsize.Height += this.Padding.Bottom;
+ retsize.Width += this.Padding.Right;
+
return SizeFromClientSize (retsize);
}
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-list] Creating file name from string
On Sat, Jun 28, 2008 at 7:40 PM, Andrus [EMAIL PROTECTED] wrote:
I need to create legal file name form any string so that PDF and other
viewers show nice title.
This code should create legal file name in every platform supported by MONO
and .NET
I created method LegalFileName() for this which uses 2 helper methods.
It replaces \/:?*| characters in name.
Is this best solution ?
Will LegalFineName return legal file name for every OS ?
It will depend not on the OS, but on the file system.
If you are targeting .Net 2.0+ you should probably use
Path.GetInvalidFileNameChars () and/or GetInvalidPathChars () static
methods.
Cheers,
Ivan
/// summary
/// Creates valid file name for current OS
/// /summary
/// returnsLegal file name/returns
public static string LegalFileName(string proposedFileName)
{
return ChrTran(proposedFileName, \\/:?*\|, [] ).Trim();
}
/// summary
/// Replaces each character in a character expression that matches a
character
/// in a second character expression with the corresponding character in
a
/// third character expression
/// /summary
/// example
/// Console.WriteLine(ChrTran(ABCDEF, ACE, XYZ)); //Displays
XBYDZF
/// Console.WriteLine(ChrTran(ABCD, ABC, YZ)); //Displays YZD
/// Console.WriteLine(ChrTran(ABCDEF, ACE, XYZQRST)); //Displays
XBYDZF
/// /example
/// param name=cSearchIn /param
/// param name=cSearchFor /param
/// param name=cReplaceWith /param
public static string ChrTran(string cSearchIn, string cSearchFor, string
cReplaceWith)
{
string lcRetVal = cSearchIn;
string cReplaceChar;
for (int i = 0; i cSearchFor.Length; i++)
{
if (cReplaceWith.Length = i)
cReplaceChar = ;
else
cReplaceChar = cReplaceWith[i].ToString();
lcRetVal = StrTran(lcRetVal, cSearchFor[i].ToString(),
cReplaceChar);
}
return lcRetVal;
}
/// summary
/// Searches one string into another string and replaces all occurences
with
/// a third string.
/// pre
/// Example:
/// StrTran(Joe Doe, o, ak); //returns Jake Dake
/// /pre
/// /summary
/// param name=cSearchIn /param
/// param name=cSearchFor /param
/// param name=cReplaceWith /param
public static string StrTran(string cSearchIn, string cSearchFor, string
cReplaceWith)
{
//Create the StringBuilder
StringBuilder sb = new StringBuilder(cSearchIn);
//There is a bug in the replace method of the StringBuilder
sb.Replace(cSearchFor, cReplaceWith);
//Call the Replace() method of the StringBuilder and specify the
string to replace with
return sb.Replace(cSearchFor, cReplaceWith).ToString();
}
___
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] Simple bug in Cursor.Show()
Bob Frankston wrote:
Trivial bug (I'd post it via BUgzilla but I dont' seem to be getting the
confrim message but it's so simple that ...)
public static void Hide() {
XplatUI.ShowCursor(false);
}
public static void Show() {
XplatUI.ShowCursor(false);
}
Obviously should be true for Show() -- I tested by calling the base API
and it worked fine.
Fixed in r106371. Thanks.
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] X11 Scrolling Regressions
On Wed, Jun 4, 2008 at 6:01 PM, Ernesto [EMAIL PROTECTED] wrote: Ivan N. Zlatev escribió: We have two scrolling regressions on X11: 1) Carlos, your X11 changes cause the first. Check the attached test case grab: the scrollbar and scroll up/down fast. You will notice that we seem not to redraw properly. I can reproduce this with any scrollable control. 2) Scrolling with the scrollbar's scroll buttons makes it flicker like mad during scrolling. It doesn't happen if I scroll by dragging the bar. Cheers, Ivan Maybe this stack trace helps. I'm getting dozens of this when running a winforms app: X11 Error encountered: Error: BadWindow (invalid Window parameter) Request: 3 (0) Resource ID: 0x0 Serial: 399 Hwnd:null Control: null at System.Environment.get_StackTrace() in /home/usuario/mono/mcs/class/corlib/System/Environment.cs:line 203 at System.Windows.Forms.XplatUIX11.HandleError(IntPtr display, XErrorEvent ByRef error_event) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:line 1873 at System.Windows.Forms.XplatUIX11.XGetWindowAttributes(IntPtr , IntPtr , XWindowAttributes ByRef ) at System.Windows.Forms.XplatUIX11.GetVisibleRegion(System.Windows.Forms.Control c, Rectangle visible_area) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:line 5011 at System.Windows.Forms.XplatUIX11.GetTotalVisibleArea(IntPtr handle) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:line 4970 at System.Windows.Forms.XplatUIX11.ScrollWindow(IntPtr handle, Rectangle area, Int32 XAmount, Int32 YAmount, Boolean with_children) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:line 4900 at System.Windows.Forms.XplatUI.ScrollWindow(IntPtr handle, Rectangle rectangle, Int32 XAmount, Int32 YAmount, Boolean with_children) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUI.cs:line 902 at System.Windows.Forms.TextBoxBase.vscroll_ValueChanged(System.Object sender, System.EventArgs e) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs:line 2196 at System.Windows.Forms.ScrollBar.OnValueChanged(System.EventArgs e) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ScrollBar.cs:line 689 at System.Windows.Forms.ScrollBar.set_Value(Int32 value) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ScrollBar.cs:line 609 at System.Windows.Forms.TextBoxBase.CaretMoved(System.Object sender, System.EventArgs e) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs:line 2369 at System.Windows.Forms.TextBoxBase.ScrollToCaret() in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs:line 836 at System.Windows.Forms.TextBoxBase.CreateHandle() in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs:line 986 at System.Windows.Forms.Control.CreateControl() in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:line 3746 at System.Windows.Forms.Control.CreateControl() in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:line 3758 at System.Windows.Forms.Control.WmShowWindow(Message ByRef m) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:line 5738 at System.Windows.Forms.Control.WndProc(Message ByRef m) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:line 5327 at System.Windows.Forms.ScrollableControl.WndProc(Message ByRef m) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ScrollableControl.cs:line 807 at System.Windows.Forms.ContainerControl.WndProc(Message ByRef m) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ContainerControl.cs:line 631 at System.Windows.Forms.UserControl.WndProc(Message ByRef m) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/UserControl.cs:line 150 at System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message ByRef m) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:line 227 at System.Windows.Forms.Control+ControlNativeWindow.WndProc(Message ByRef m) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:line 208 at System.Windows.Forms.NativeWindow.WndProc(IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/NativeWindow.cs:line 240 at System.Windows.Forms.XplatUIX11.SendMessage(IntPtr hwnd, Msg message, IntPtr wParam, IntPtr lParam) in /home/usuario/mono/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:line 5100
Re: [Mono-winforms-list] X11 Scrolling Regressions
On Wed, Jun 4, 2008 at 7:04 PM, Ernesto [EMAIL PROTECTED] wrote: Ivan N. Zlatev escribió: On Wed, Jun 4, 2008 at 6:01 PM, Ernesto [EMAIL PROTECTED] wrote: Ivan N. Zlatev escribió: We have two scrolling regressions on X11: 1) Carlos, your X11 changes cause the first. Check the attached test case grab: the scrollbar and scroll up/down fast. You will notice that we seem not to redraw properly. I can reproduce this with any scrollable control. 2) Scrolling with the scrollbar's scroll buttons makes it flicker like mad during scrolling. It doesn't happen if I scroll by dragging the bar. Cheers, Ivan Maybe this stack trace helps. I'm getting dozens of this when running a winforms app: X11 Error encountered: Error: BadWindow (invalid Window parameter) Request: 3 (0) Resource ID: 0x0 Serial: 399 Hwnd:null Control: null at System.Environment.get_StackTrace() in ... I do not get such errors here. What's your system? 32bit opensuse 10.3 here. 64-bit Fedora 9. I started to see those errors after I pulled svn yesterday. They seem to be related to scroll, that's why I brought this up. The app runs anyway (just very slow, because of the dumps I guess). This is something 64bit specific then. File a bug clearly marked as 64bit one and with a test case and the stacktrace so that it can get looked into at some point. Cheers, Ivan ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [RFC] Multiple NativeWindows per Handle Patch for bug #374660
Hey Team,
To fix bug #374660
(https://bugzilla.novell.com/show_bug.cgi?id=374660) I had to
introduce support in NativeWindow for dealing with multiple
NativeWindows per Handle, where one (the first one) is organic (the
ControlNativeWindow) and the rest are synthetic. Messages pass through
both. This is allowed in MS's implementation and is what the test code
in the bug uses to loose couple the drawing code from the behavior
code. Ugly I know, but I guess seems natural to people coming from
hardcore Win32 coding background or something.
Anyway the attached patch, which I am asking you to check out just in case:
* All tests pass. woo! In theory no regressions.
* Handles single handle vs multiple handles in the following way,
where window_collection is a Hashtable with key-value pair, where the
key is the handle and the value is either a single NativeWindow or an
ArrayList of handles
object current = window_collection[handle];
if (current != null) {
NativeWindow currentWindow = current as
NativeWindow;
if (currentWindow != null) {
// only one handle - do stuff
} else { // list of windows
ArrayList windows = (ArrayList)
window_collection[handle];
// multiple handles (first one
is organic always) - do stuff
}
}
* Most notably doesn't increase our current memory consumption and
should not have any performance impact.
* Probably decreases the current memory consumption a bit. It came
to my attention that NativeWindow.FromHandle instantiates a new
NativeWindow instead of returning one from the internal table.
* NativeWindow.window_handle: internal - private - we don't use
this anywhere and we shouldn't provide access to this to future code
as it breaks encapuslation and allows avoiding
AssignHandle/CreateHandle, InvalidateHandle. Evil.
* NativeWindow.windows_collection: internal - private - now that
multiple handles are allowed and the way those are handled is an
implementation detail, code shouldn't have access to the collection
directly. I have replaced the few direct references to the field with
a method to return the organic handle.
Does anyone have any objections or should I go ahead and commit?
Thanks in advance,
Ivan
Index: System.Windows.Forms/LibSupport.cs
===
--- System.Windows.Forms/LibSupport.cs (revision 102517)
+++ System.Windows.Forms/LibSupport.cs (working copy)
@@ -40,7 +40,7 @@
static IntPtr FindWindow (IntPtr hWnd)
{
- NativeWindow nw = NativeWindow.FindWindow (hWnd);
+ NativeWindow nw = NativeWindow.FromHandle (hWnd);
if (nw == null)
return IntPtr.Zero;
Index: System.Windows.Forms/Control.cs
===
--- System.Windows.Forms/Control.cs (revision 102517)
+++ System.Windows.Forms/Control.cs (working copy)
@@ -181,7 +181,7 @@
static internal Control ControlFromHandle(IntPtr hWnd) {
ControlNativeWindow window;
-window = (ControlNativeWindow)window_collection[hWnd];
+window = (ControlNativeWindow)NativeWindow.FromHandle (hWnd);
if (window != null) {
return window.owner;
}
@@ -194,7 +194,7 @@
Hwnd hwnd = Hwnd.ObjectFromHandle (handle);
while (hwnd != null) {
- window = (ControlNativeWindow)window_collection[hwnd.Handle];
+ window = (ControlNativeWindow)NativeWindow.FromHandle (handle);
if (window != null) {
return window.owner;
}
Index: System.Windows.Forms/ChangeLog
===
--- System.Windows.Forms/ChangeLog (revision 102537)
+++ System.Windows.Forms/ChangeLog (working copy)
@@ -1,5 +1,12 @@
2008-05-05 Ivan N. Zlatev [EMAIL PROTECTED]
+ * NativeWindow.cs: Add support for multiple handles per window.
+ * NativeWindows.cs, LibSupport.cs, Control.cs, XplatUIX11GTK.cs,
+ XplatUIX11.cs, X11Display.cs: Do not access NativeWindow.windows_collection
+ directly - use FromHandle instead.
+
+2008-05-05 Ivan N. Zlatev [EMAIL PROTECTED]
+
* GridEntry.cs: Read-only properties with Editor with
UITypeEditorEditStyle.Modal shouldn't be read-only in the PropertyGrid.
[Fixes bug #384184]
Index: System.Windows.Forms/XplatUIX11GTK.cs
===
--- System.Windows.Forms/XplatUIX11GTK.cs (revision 102517)
+++ System.Windows.Forms/XplatUIX11GTK.cs (working copy)
@@ -1408,7 +1408,7 @@
// Modality handling, if we are modal and the new active window is one
// of ours but not the modal one, switch back to the modal window
Re: [Mono-dev] [PATCH] TypeDescriptor
On Wed, Apr 30, 2008 at 7:36 PM, James Fitzsimons [EMAIL PROTECTED] wrote: 2008/4/28 Ivan N. Zlatev [EMAIL PROTECTED]: On Mon, Apr 28, 2008 at 11:28 PM, James Fitzsimons [EMAIL PROTECTED] wrote: 2008/4/28 Ivan N. Zlatev [EMAIL PROTECTED]: 2008/4/28 James Fitzsimons [EMAIL PROTECTED]: Hi all, While debugging a problem with Spring.NET over the weekend I uncovered an inconsistency in behaviour between the Mono and Microsoft implementations of the GetProperties method of the TypeDescriptor class. Basically the Microsoft only returns properties that have a getter, however Mono returns write only properties as well. The attached patch contains a fix and a few more unit tests to check that it works and it doesn't break existing behaviour. Please fix the following things and resend: 1) Reformat your patch to match our coding guidelines - http://www.mono-project.com/Coding_Guidelines 2) Add ChangeLog entries. 3) Fix the mixed indentation in the code in the tests you've added. 4) Fix the indentation in this hunk: @@ -427,6 +447,9 @@ MyComponent sitedcom = new MyComponent (new MySite ()); MyComponent nfscom = new MyComponent (new NoFilterSite (new MyContainer ())); AnotherComponent anothercom = new AnotherComponent (); + TestObject testObject = new TestObject(); +PropertyDescriptorCollection properties = TypeDescriptor.GetProperties(testObject); + [Test] public void TestICustomTypeDescriptor () Cheers, Ivan Maybe this time? Two more things: 1) Refactor all your asserts into 1 test method, say TestGetProperties_WriteOnly and drop the fields - use local variables inside. No need for PropertyDescriptorExists, just check the propertydescriptorcollection[property] != null inside that test method like the other tests do. Number the asserts. 2) There is no need for a special TestObject - just add a single write-only property MyComponent and use that. You will also have to add it to the GetProperties_Order test Resend when those are fixed, thanks. Hi Ivan, I've done as you requested and checked all tests still pass. I have applied your patch with a further slight modification of the tests in r102535, thanks. Ivan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Linux Printers
On Mon, May 5, 2008 at 3:08 PM, Steve Harp [EMAIL PROTECTED] wrote: On 5/2/08, Steve Harp [EMAIL PROTECTED] wrote: Hi All, How do I get list of available printers on a Linux machine? I'm using C#/Mono and trying to populate a ComboBox with printers available on the computer. One way is to use System.Drawing.Printing.PrinterSettings.InstalledPrinters , which returns a string collection of all detected printers. andreia gaita Thanks for the reply Andreia. With this, I get an error libcups not found. To have printing support, you need cups installed. I do have cups installed along with several cups related libraries. I'm using openSuse 10.3 and there is no libcups available in Yast. libcups is part of the cups-devel package, which you should install. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] TypeDescriptor
2008/4/28 James Fitzsimons [EMAIL PROTECTED]: Hi all, While debugging a problem with Spring.NET over the weekend I uncovered an inconsistency in behaviour between the Mono and Microsoft implementations of the GetProperties method of the TypeDescriptor class. Basically the Microsoft only returns properties that have a getter, however Mono returns write only properties as well. The attached patch contains a fix and a few more unit tests to check that it works and it doesn't break existing behaviour. Please fix the following things and resend: 1) Reformat your patch to match our coding guidelines - http://www.mono-project.com/Coding_Guidelines 2) Add ChangeLog entries. 3) Fix the mixed indentation in the code in the tests you've added. 4) Fix the indentation in this hunk: @@ -427,6 +447,9 @@ MyComponent sitedcom = new MyComponent (new MySite ()); MyComponent nfscom = new MyComponent (new NoFilterSite (new MyContainer ())); AnotherComponent anothercom = new AnotherComponent (); + TestObject testObject = new TestObject(); +PropertyDescriptorCollection properties = TypeDescriptor.GetProperties(testObject); + [Test] public void TestICustomTypeDescriptor () Cheers, Ivan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] TypeDescriptor
On Mon, Apr 28, 2008 at 11:28 PM, James Fitzsimons [EMAIL PROTECTED] wrote: 2008/4/28 Ivan N. Zlatev [EMAIL PROTECTED]: 2008/4/28 James Fitzsimons [EMAIL PROTECTED]: Hi all, While debugging a problem with Spring.NET over the weekend I uncovered an inconsistency in behaviour between the Mono and Microsoft implementations of the GetProperties method of the TypeDescriptor class. Basically the Microsoft only returns properties that have a getter, however Mono returns write only properties as well. The attached patch contains a fix and a few more unit tests to check that it works and it doesn't break existing behaviour. Please fix the following things and resend: 1) Reformat your patch to match our coding guidelines - http://www.mono-project.com/Coding_Guidelines 2) Add ChangeLog entries. 3) Fix the mixed indentation in the code in the tests you've added. 4) Fix the indentation in this hunk: @@ -427,6 +447,9 @@ MyComponent sitedcom = new MyComponent (new MySite ()); MyComponent nfscom = new MyComponent (new NoFilterSite (new MyContainer ())); AnotherComponent anothercom = new AnotherComponent (); + TestObject testObject = new TestObject(); +PropertyDescriptorCollection properties = TypeDescriptor.GetProperties(testObject); + [Test] public void TestICustomTypeDescriptor () Cheers, Ivan Maybe this time? Two more things: 1) Refactor all your asserts into 1 test method, say TestGetProperties_WriteOnly and drop the fields - use local variables inside. No need for PropertyDescriptorExists, just check the propertydescriptorcollection[property] != null inside that test method like the other tests do. Number the asserts. 2) There is no need for a special TestObject - just add a single write-only property MyComponent and use that. You will also have to add it to the GetProperties_Order test Resend when those are fixed, thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Compiling Mono from source code
On Tue, Apr 22, 2008 at 1:35 PM, Paramesh Gunasekaran [EMAIL PROTECTED] wrote: Ohh.. The same issue remains my export suffs are the following PATH=.:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program Files/Mono-1.9/bin:$PATH #PKG_CONFIG_PATH=.:/lib/pkgconfig:/cygdrive/c/Program Files/Mono-1.9/lib/pkgconfig #LD_LIBRARY_PATH=.:/usr/local/lib:/usr/lib:/lib:/cygdrive/c/Program Files/Mono-1.9/lib #export PATH PKG_CONFIG_PATH LD_LIBRARY_PATH export PATH Do not install Mono in a path with spaces (Program Files), because it causes problems for the build for some reason. Install it e.g in C:\mono and it work. And, I'm using .bashrc file in C:\Cygwin\etc\skel instead of c:\cygwin\home\user since I don't get a home directory created... On Tue, Apr 22, 2008 at 9:02 AM, Robert Jordan [EMAIL PROTECTED] wrote: Paramesh Gunasekaran wrote: Yes. I've bison-i18n.m4 intltool.m4 libtool.m4 ltdl.m4 pkg.m4 at /usr/share/aclocal OK. Instead of following Shana's advice: PATH=.:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Mono-1.2.2.1/bin PKG_CONFIG_PATH=.:/lib/pkgconfig:/cygdrive/c/Mono-1.2.2.1/lib/pkgconfig export ... use only this: PATH=/cygdrive/c/Mono-adjust-me/bin:$PATH export PATH 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
Re: [Mono-winforms-list] libgdiplus MWF regression
On Sat, Apr 19, 2008 at 9:49 PM, Sebastien Pouliot [EMAIL PROTECTED] wrote: Hello Ivan, On Sat, 2008-04-19 at 20:45 +0100, Ivan N. Zlatev wrote: Hi Sebastien, Your libgdiplus commit in revision 100945 regresses rectangles drawing in MWF. They are drawn off by a pixel or so. Cairo 1.6 changed (at least) how their AA works. Reverting this would produce other regressions (SD has unit tests for old bugs similar to this). Please provide me with a test case so I can make sure to fix this one without breaking old ones. I have opened up a bug ( https://bugzilla.novell.com/show_bug.cgi?id=381737 ) assigned to you, so we can better track this. Also, do you have any clue why would I get the following failures[1], considering that I am running the tests on a machine with 3GB of ram? Thanks, Ivan [1] Test Failures 2) MonoTests.System.Windows.Forms.ButtonTest.ImageTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String filename, Boolean useEmbeddedColorManagement) [0x0002f] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:116 at System.Drawing.Image.FromFile (System.String filename) [0x0] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:101 at MonoTests.System.Windows.Forms.ButtonTest.ImageTest () [0xd] in /home/ivanz/src/svn/mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/ButtonTest.cs:227 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00057] in /home/ivanz/src/svn/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 3) MonoTests.System.Windows.Forms.ButtonTest.ImageListTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String filename, Boolean useEmbeddedColorManagement) [0x0002f] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:116 at System.Drawing.Image.FromFile (System.String filename) [0x0] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:101 at MonoTests.System.Windows.Forms.ButtonTest.ImageListTest () [0x6] in /home/ivanz/src/svn/mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/ButtonTest.cs:235 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00057] in /home/ivanz/src/svn/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 4) MonoTests.System.Windows.Forms.EventClass.BgrndImageChangedTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String filename, Boolean useEmbeddedColorManagement) [0x0002f] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:116 at System.Drawing.Image.FromFile (System.String filename) [0x0] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:101 at MonoTests.System.Windows.Forms.EventClass.BgrndImageChangedTest () [0x00024] in /home/ivanz/src/svn/mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/ControlEventTest.cs:38 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00057] in /home/ivanz/src/svn/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 5) MonoTests.System.Windows.Forms.ImageListTest.ImageListPropertyTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String filename, Boolean useEmbeddedColorManagement) [0x0002f] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:116 at System.Drawing.Image.FromFile
Re: [Mono-winforms-list] libgdiplus MWF regression
On Sun, Apr 20, 2008 at 9:03 PM, Sebastien Pouliot [EMAIL PROTECTED] wrote: On Sun, 2008-04-20 at 19:17 +0100, Ivan N. Zlatev wrote: ... Also, do you have any clue why would I get the following failures[1], considering that I am running the tests on a machine with 3GB of ram? yep, compatibility :( MS GDI+ return OutOfMemory *way* too often (looks like whenever they see a NULL pointer, whatever the real cause) and this is translated into a OutOfMemoryException by SD (both Mono and MS). I did not see any bots with those errors. Are you sure you built libgdiplus with all the codecs ? Good call! I was missing the giflib headers. No failures now, thanks. If so then on which arch/distro are your getting those results ? Thanks, Ivan [1] Test Failures 2) MonoTests.System.Windows.Forms.ButtonTest.ImageTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String filename, Boolean useEmbeddedColorManagement) [0x0002f] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:116 at System.Drawing.Image.FromFile (System.String filename) [0x0] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:101 at MonoTests.System.Windows.Forms.ButtonTest.ImageTest () [0xd] in /home/ivanz/src/svn/mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/ButtonTest.cs:227 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00057] in /home/ivanz/src/svn/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 3) MonoTests.System.Windows.Forms.ButtonTest.ImageListTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String filename, Boolean useEmbeddedColorManagement) [0x0002f] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:116 at System.Drawing.Image.FromFile (System.String filename) [0x0] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:101 at MonoTests.System.Windows.Forms.ButtonTest.ImageListTest () [0x6] in /home/ivanz/src/svn/mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/ButtonTest.cs:235 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00057] in /home/ivanz/src/svn/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 4) MonoTests.System.Windows.Forms.EventClass.BgrndImageChangedTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String filename, Boolean useEmbeddedColorManagement) [0x0002f] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:116 at System.Drawing.Image.FromFile (System.String filename) [0x0] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/Image.cs:101 at MonoTests.System.Windows.Forms.EventClass.BgrndImageChangedTest () [0x00024] in /home/ivanz/src/svn/mcs/class/Managed.Windows.Forms/Test/System.Windows.Forms/ControlEventTest.cs:38 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00057] in /home/ivanz/src/svn/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 5) MonoTests.System.Windows.Forms.ImageListTest.ImageListPropertyTest : System.OutOfMemoryException : Not enough memory to complete operation [GDI+ status: OutOfMemory] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x000be] in /home/ivanz/src/svn/mcs/class/System.Drawing/System.Drawing/gdipFunctions.cs:222 at System.Drawing.Image.FromFile (System.String
[Mono-winforms-list] libgdiplus MWF regression
Hi Sebastien, Your libgdiplus commit in revision 100945 regresses rectangles drawing in MWF. They are drawn off by a pixel or so. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] Regression in r99253 trunk/mcs/class/System.Design/System.ComponentModel.Design?
On Sat, Mar 29, 2008 at 12:36 AM, Andreas Nahr [EMAIL PROTECTED] wrote: If I understand the changes correctly with the patch the list will now repopulate with any change. This makes the class unusable in a lot of situations (every situation where population is slow in the first place). Moreover this is not the case in .Net. The code will only repopulate the list if: 1) The value of the property edited *in the PropertyGrid* is changed *and* the collectioneditor form is opened at that moment (itemDisplay_PropertyValueChanged) 2) If OnEditValueChanged is called, which in our code is done only once when EditValue is initialized This commit does not change the logic above. Or am I missing something? Is there any special goal why the existing code is changed? (changelog is unspecific) Changelog is unspecific because I forgot to link to the bugs that the code fixes - #365940 and #365942. Also there were a couple of other small issues. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Possible bug in r97246 - trunk/mcs/class/System.Drawing/System.Drawing
On Tue, Mar 4, 2008 at 9:40 AM, Andreas Nahr [EMAIL PROTECTED] wrote: The change in r97246 is likely buggy, because the comparison is now done on the current locale but should likely be ordinalIgnoreCase or InvariantIgnoreCase. You were right. This is fixed in r97619. Thanks. Ivan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Possible bug in r97246 - trunk/mcs/class/System.Drawing/System.Drawing
I will look into this tomorrow, cheers. On Tue, Mar 4, 2008 at 9:40 AM, Andreas Nahr [EMAIL PROTECTED] wrote: The change in r97246 is likely buggy, because the comparison is now done on the current locale but should likely be ordinalIgnoreCase or InvariantIgnoreCase. Happy Hacking Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] corlib GetCustomAttributes for overriden properties bug
On Tue, Feb 26, 2008 at 5:47 AM, Raja R Harinath [EMAIL PROTECTED] wrote: Hi, Ivan N. Zlatev [EMAIL PROTECTED] writes: On Mon, Feb 25, 2008 at 9:43 PM, Ivan N. Zlatev [EMAIL PROTECTED] wrote: Please review the attached patch that fixes our behavior to match MS's in terms of GetCustomAttributes for overridden attributes on properties. That is: * PropertyInfo.GetCustomAttributes - Inherit parameter is ignored and behavior defaults to false * Attributes.GetCustomAttributes - Inherit parameter is not ignored * Attributes.IsDefined - Inherit parameter is not ignored on the 2.0 profile. This patch fixes bugs #324472 and #322464. Also now all our Attribute tests pass on 1.1 and 2.0 profiles(woho!). Please say whether it's okay to commit and if the fixes should be backported. The previous patch did not handle indexed properties. Attached is an updated patch. I did a clean rebuild with the patch applied - no breakages. All Attributes tests pass. Zoltan, what do you think? Since this affects reflection, one good testcase is that it doesn't break the compiler. Can you check that this doesn't break make compiler-tests (you need to run this from the mono/ tree). Done that and there are no breakages. I talked with Zoltan on IRC last night and he said the patch looks okay. I am going to commit it. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] corlib GetCustomAttributes for overriden properties bug
On Tue, Feb 26, 2008 at 1:05 PM, Ivan N. Zlatev [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 5:47 AM, Raja R Harinath [EMAIL PROTECTED] wrote: Hi, Ivan N. Zlatev [EMAIL PROTECTED] writes: On Mon, Feb 25, 2008 at 9:43 PM, Ivan N. Zlatev [EMAIL PROTECTED] wrote: Please review the attached patch that fixes our behavior to match MS's in terms of GetCustomAttributes for overridden attributes on properties. That is: * PropertyInfo.GetCustomAttributes - Inherit parameter is ignored and behavior defaults to false * Attributes.GetCustomAttributes - Inherit parameter is not ignored * Attributes.IsDefined - Inherit parameter is not ignored on the 2.0 profile. This patch fixes bugs #324472 and #322464. Also now all our Attribute tests pass on 1.1 and 2.0 profiles(woho!). Please say whether it's okay to commit and if the fixes should be backported. The previous patch did not handle indexed properties. Attached is an updated patch. I did a clean rebuild with the patch applied - no breakages. All Attributes tests pass. Zoltan, what do you think? Since this affects reflection, one good testcase is that it doesn't break the compiler. Can you check that this doesn't break make compiler-tests (you need to run this from the mono/ tree). Done that and there are no breakages. I talked with Zoltan on IRC last night and he said the patch looks okay. I am going to commit it. For the record - committed as revision 96632. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] corlib GetCustomAttributes for overriden properties bug
Please review the attached patch that fixes our behavior to match MS's
in terms of GetCustomAttributes for overridden attributes on
properties. That is:
* PropertyInfo.GetCustomAttributes - Inherit parameter is ignored and
behavior defaults to false
* Attributes.GetCustomAttributes - Inherit parameter is not ignored
* Attributes.IsDefined - Inherit parameter is not ignored on the 2.0 profile.
This patch fixes bugs #324472 and #322464. Also now all our Attribute
tests pass on 1.1 and 2.0 profiles(woho!). Please say whether it's
okay to commit and if the fixes should be backported.
Cheers!
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
Index: System/MonoCustomAttrs.cs
===
--- System/MonoCustomAttrs.cs (revision 96538)
+++ System/MonoCustomAttrs.cs (working copy)
@@ -320,18 +320,12 @@
if (obj is MonoProperty)
{
MonoProperty prop = (MonoProperty) obj;
-method = prop.GetGetMethod (true);
-if (method == null)
- method = prop.GetSetMethod (true);
-/*
-MonoProperty prop = (MonoProperty) obj;
if (prop.DeclaringType.BaseType != null) {
PropertyInfo baseProp = prop.DeclaringType.BaseType.GetProperty (prop.Name);
if (baseProp != prop)
return baseProp;
}
return null;
-*/
}
else if (obj is MonoMethod)
{
Index: System/ChangeLog
===
--- System/ChangeLog (revision 96538)
+++ System/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2008-02-25 Ivan N. Zlatev [EMAIL PROTECTED]
+
+ * Attribute.cs, MonoCustomAttrs: MS ignores the inherit param in
+ PropertyInfo's ICustomAttributeProvider implementation, but not
+ in the Attributes, so directly get the attributes from
+ MonoCustomAttrs instead of going throught the PropertyInfo's
+ ICustomAttributeProvider.
+ [Fixes bugs #324472 and #322464]
+
2008-02-25 Atsushi Enomoto [EMAIL PROTECTED]
* DateTime.cs, DateTimeUtils.cs : make Kind value from parse result
Index: System/Attribute.cs
===
--- System/Attribute.cs (revision 96538)
+++ System/Attribute.cs (working copy)
@@ -224,6 +224,13 @@
// element parameter is not allowed to be null
CheckParameters (element, type);
+ // MS ignores the inherit param in PropertyInfo's ICustomAttributeProvider
+ // implementation, but not in the Attributes, so directly get the attributes
+ // from MonoCustomAttrs instead of going throught the PropertyInfo's
+ // ICustomAttributeProvider
+ MemberTypes mtype = element.MemberType;
+ if (mtype == MemberTypes.Property)
+return (Attribute []) MonoCustomAttrs.GetCustomAttributes (element, type, inherit);
return (Attribute []) element.GetCustomAttributes (type, inherit);
}
@@ -248,6 +255,13 @@
// element parameter is not allowed to be null
CheckParameters (element, typeof (Attribute));
+ // MS ignores the inherit param in PropertyInfo's ICustomAttributeProvider
+ // implementation, but not in the Attributes, so directly get the attributes
+ // from MonoCustomAttrs instead of going throught the PropertyInfo's
+ // ICustomAttributeProvider
+ MemberTypes mtype = element.MemberType;
+ if (mtype == MemberTypes.Property)
+return (Attribute []) MonoCustomAttrs.GetCustomAttributes (element, inherit);
return (Attribute []) element.GetCustomAttributes (inherit);
}
@@ -301,7 +315,14 @@
mtype != MemberTypes.NestedType)
throw new NotSupportedException (Locale.GetText (
Element is not a constructor, method, property, event, type or field.));
-
+#if NET_2_0
+ // MS ignores the inherit param in PropertyInfo's ICustomAttributeProvider
+ // implementation, but not in the Attributes, so directly get the attributes
+ // from MonoCustomAttrs instead of going throught the PropertyInfo's
+ // ICustomAttributeProvider
+ if (mtype == MemberTypes.Property)
+return MonoCustomAttrs.IsDefined (element, attributeType, inherit);
+#endif
return ((MemberInfo) element).IsDefined (attributeType, inherit);
}
Index: Test/System/AttributeTest.cs
===
--- Test/System/AttributeTest.cs (revision 96538)
+++ Test/System/AttributeTest.cs (working copy)
@@ -129,9 +129,6 @@
}
[Test]
-#if NET_2_0
- [Category (NotWorking)] // bug #81797
-#endif
public void IsDefined_PropertyInfo_Override ()
{
PropertyInfo pi = typeof (TestSub).GetProperty (PropBase3);
@@ -218,7 +215,6 @@
}
[Test]
- [Category (NotWorking)] // bug #81797
public void GetCustomAttribute_PropertyInfo_Override ()
{
PropertyInfo pi = typeof (TestSub).GetProperty (PropBase3);
@@ -607,7 +603,6 @@
}
[Test]
- [Category (NotWorking)] // bug #81797
public void GetCustomAttributes_PropertyInfo_Override ()
{
object [] attrs;
Index: Test/System/ChangeLog
Re: [Mono-dev] [PATCH] corlib GetCustomAttributes for overriden properties bug
On Mon, Feb 25, 2008 at 9:43 PM, Ivan N. Zlatev [EMAIL PROTECTED] wrote:
Please review the attached patch that fixes our behavior to match MS's
in terms of GetCustomAttributes for overridden attributes on
properties. That is:
* PropertyInfo.GetCustomAttributes - Inherit parameter is ignored and
behavior defaults to false
* Attributes.GetCustomAttributes - Inherit parameter is not ignored
* Attributes.IsDefined - Inherit parameter is not ignored on the 2.0
profile.
This patch fixes bugs #324472 and #322464. Also now all our Attribute
tests pass on 1.1 and 2.0 profiles(woho!). Please say whether it's
okay to commit and if the fixes should be backported.
The previous patch did not handle indexed properties. Attached is an
updated patch. I did a clean rebuild with the patch applied - no
breakages. All Attributes tests pass.
Zoltan, what do you think?
Cheers.
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
Index: System/MonoCustomAttrs.cs
===
--- System/MonoCustomAttrs.cs (revision 96538)
+++ System/MonoCustomAttrs.cs (working copy)
@@ -305,6 +305,31 @@
[MethodImplAttribute (MethodImplOptions.InternalCall)]
internal static extern bool IsDefinedInternal (ICustomAttributeProvider obj, Type AttributeType);
+ static PropertyInfo GetBasePropertyDefinition (PropertyInfo property)
+ {
+ MethodInfo method = property.GetGetMethod (true);
+ if (method == null || !method.IsVirtual)
+method = property.GetSetMethod (true);
+ if (method == null || !method.IsVirtual)
+return null;
+
+ MethodInfo baseMethod = method.GetBaseDefinition ();
+ if (baseMethod != null baseMethod != method) {
+ParameterInfo[] parameters = property.GetIndexParameters ();
+if (parameters != null parameters.Length 0) {
+ Type[] paramTypes = new Type[parameters.Length];
+ for (int i=0; i paramTypes.Length; i++)
+ paramTypes[i] = parameters[i].ParameterType;
+ return baseMethod.DeclaringType.GetProperty (property.Name, property.PropertyType,
+ paramTypes);
+} else {
+ return baseMethod.DeclaringType.GetProperty (property.Name, property.PropertyType);
+}
+ }
+ return null;
+
+ }
+
// Handles Type, MonoProperty and MonoMethod.
// The runtime has also cases for MonoEvent, MonoField, Assembly and ParameterInfo,
// but for those we return null here.
@@ -318,25 +343,9 @@
MethodInfo method = null;
if (obj is MonoProperty)
- {
-MonoProperty prop = (MonoProperty) obj;
-method = prop.GetGetMethod (true);
-if (method == null)
- method = prop.GetSetMethod (true);
-/*
-MonoProperty prop = (MonoProperty) obj;
-if (prop.DeclaringType.BaseType != null) {
- PropertyInfo baseProp = prop.DeclaringType.BaseType.GetProperty (prop.Name);
- if (baseProp != prop)
- return baseProp;
-}
-return null;
-*/
- }
+return GetBasePropertyDefinition ((MonoProperty) obj);
else if (obj is MonoMethod)
- {
method = (MethodInfo) obj;
- }
/**
* ParameterInfo - null
Index: System/ChangeLog
===
--- System/ChangeLog (revision 96538)
+++ System/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2008-02-25 Ivan N. Zlatev [EMAIL PROTECTED]
+
+ * Attribute.cs, MonoCustomAttrs: MS ignores the inherit param in
+ PropertyInfo's ICustomAttributeProvider implementation, but not
+ in the Attributes, so directly get the attributes from
+ MonoCustomAttrs instead of going throught the PropertyInfo's
+ ICustomAttributeProvider.
+ [Fixes bugs #324472 and #322464]
+
2008-02-25 Atsushi Enomoto [EMAIL PROTECTED]
* DateTime.cs, DateTimeUtils.cs : make Kind value from parse result
Index: System/Attribute.cs
===
--- System/Attribute.cs (revision 96538)
+++ System/Attribute.cs (working copy)
@@ -224,6 +224,13 @@
// element parameter is not allowed to be null
CheckParameters (element, type);
+ // MS ignores the inherit param in PropertyInfo's ICustomAttributeProvider
+ // implementation, but not in the Attributes, so directly get the attributes
+ // from MonoCustomAttrs instead of going throught the PropertyInfo's
+ // ICustomAttributeProvider
+ MemberTypes mtype = element.MemberType;
+ if (mtype == MemberTypes.Property)
+return (Attribute []) MonoCustomAttrs.GetCustomAttributes (element, type, inherit);
return (Attribute []) element.GetCustomAttributes (type, inherit);
}
@@ -248,6 +255,13 @@
// element parameter is not allowed to be null
CheckParameters (element, typeof (Attribute));
+ // MS ignores the inherit param in PropertyInfo's ICustomAttributeProvider
+ // implementation, but not in the Attributes, so directly get the attributes
+ // from MonoCustomAttrs instead of going throught the PropertyInfo's
Re: [Mono-winforms-list] PropertyGrid bugs
On Feb 18, 2008 11:07 AM, Andy Hume [EMAIL PROTECTED] wrote: Hi Ivan I'm just rebuilding so that I can re-check the CultureInfo selection issue, I had r95958 on both platforms but saw the problem. However after a rebuild on Linux it is fixed, so something must have gone wonky in my build. I'm rebuilding on Win32, so I'll be able to retest there after cygwin's managed to do its work... I've added some unit-tests to bugzilla of the PropertyDescriptor.Converter property. That seems to work with attributes applied to properties, but PG itself doesn't seem to respect such attributes. Does it do its own lookups? No it doesn't, but you might be hitting a bug related to #324472 - Attribute.GetCustomAttributes doesn't get inherited attributes for properties (https://bugzilla.novell.com/show_bug.cgi?id=324472) I also did some unit-tests of CharConverter but Gert beat me to it, and uncovered and fixed the only issue I found (NRE when null passed in). Kudos to Gert and my bad I didn't review my changes better. On the property tab support. I haven't managed to get MSFT to display an events tab. I presume one has to do stuff with System.Windows.Forms.Design.EventsTab to get it to appear. You would need to have the PropertyGrid Sited (.Site = ...) to an ISite that provides an IEventBindingService, because that would be how the EventsTab will use to feed the propertygrid with events as properties. What did you mean by * Implement TypeDescriptor Associations and Providers. This will be a biggie. Basically Associations are where you associate a component with others, so that the associated components are used instead of the original component or something along the lines. Providers are a way to modify the metadata provided by a component because instead of asking the component directly of its e.g properties the provider is being asked. This indirectly related to the ability of the PG to handle extended metadata (PG uses TypeDescriptor). get_Property is called twice for each item when opening a drop-down, etc) but I'll re-check against the new build before I log them. Things are improving greatly! The get_Property one is not a bug. It's an implementation detail, which doesn't make a difference behavior-wise and one shouldn't rely on the number of time get_Property gets called. I do not think MS can guarantee you that either. Conclusion: not a bug, could be regarded as a future optimization though. Optimizing the GridEntry class with some caching is on the todo list. BTW, you might want to consider subscribing to the mono-winforms list at http://lists.ximian.com/mailman/listinfo/mono-winforms-list . :) -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] PropertyGrid bugs
Also Andy, Can you please explicitly sign off all your test code under the MIT license so I commit it to SVN. If you add the following line as a reply to the bugs where you have code and also as a reply to this e-mail and the list it should be sufficient: Signed off under the MIT/X11 license by Your Name [EMAIL PROTECTED] On Feb 18, 2008 11:09 PM, Ivan N. Zlatev [EMAIL PROTECTED] wrote: On Feb 18, 2008 11:07 AM, Andy Hume [EMAIL PROTECTED] wrote: Hi Ivan I'm just rebuilding so that I can re-check the CultureInfo selection issue, I had r95958 on both platforms but saw the problem. However after a rebuild on Linux it is fixed, so something must have gone wonky in my build. I'm rebuilding on Win32, so I'll be able to retest there after cygwin's managed to do its work... I've added some unit-tests to bugzilla of the PropertyDescriptor.Converter property. That seems to work with attributes applied to properties, but PG itself doesn't seem to respect such attributes. Does it do its own lookups? No it doesn't, but you might be hitting a bug related to #324472 - Attribute.GetCustomAttributes doesn't get inherited attributes for properties (https://bugzilla.novell.com/show_bug.cgi?id=324472) I also did some unit-tests of CharConverter but Gert beat me to it, and uncovered and fixed the only issue I found (NRE when null passed in). Kudos to Gert and my bad I didn't review my changes better. On the property tab support. I haven't managed to get MSFT to display an events tab. I presume one has to do stuff with System.Windows.Forms.Design.EventsTab to get it to appear. You would need to have the PropertyGrid Sited (.Site = ...) to an ISite that provides an IEventBindingService, because that would be how the EventsTab will use to feed the propertygrid with events as properties. What did you mean by * Implement TypeDescriptor Associations and Providers. This will be a biggie. Basically Associations are where you associate a component with others, so that the associated components are used instead of the original component or something along the lines. Providers are a way to modify the metadata provided by a component because instead of asking the component directly of its e.g properties the provider is being asked. This indirectly related to the ability of the PG to handle extended metadata (PG uses TypeDescriptor). get_Property is called twice for each item when opening a drop-down, etc) but I'll re-check against the new build before I log them. Things are improving greatly! The get_Property one is not a bug. It's an implementation detail, which doesn't make a difference behavior-wise and one shouldn't rely on the number of time get_Property gets called. I do not think MS can guarantee you that either. Conclusion: not a bug, could be regarded as a future optimization though. Optimizing the GridEntry class with some caching is on the todo list. BTW, you might want to consider subscribing to the mono-winforms list at http://lists.ximian.com/mailman/listinfo/mono-winforms-list . :) -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] PropertyGrid testing aims?
Andy Hume wrote: Ivan N. Zlatev wrote: Andy Hume wrote: Just thought I'd drop you a note to see what your aims are for the PropertyGrid in the short and longer term. I'm guite willing to bang away on it in my spare time and log bugs if that's useful to you. Or maybe you're working away on it yourself and will find the bugs anyway, and other bugs would just get in the way. :-) Let me know. For the past two weeks I rewrote most of PropertyGrid and its components, so we have support for a lot of things now and better improved support for others. I hope you have noticed that during your testing. (We will ship the PropertyGrid with major improvements in 1.9 hurray!) Yup, I've seen a great improvement! I particularly like that it doesn't throw when a bad value is input. :-,) Huge thanks for your bug reports and please keep them coming! I really appreciate your time and effort. Short-term goals are: * Fix layout issues related to the scrollbar. They cause your bug #359199 and a couple of others with recursive collapse/expand. * Fix TypeDescriptor's Editors table and GetEditor to fix #358332 and a few others non-filed ones. * Fix the rest of the reported bugs. Long-term goals are: * Implement PropertyTab support, so I can implement EventsTab. * Implement TypeDescriptor Associations and Providers. * Bugfix and implement Editors and Converters -- BTW, if you feel like coding those might be a quick and easy start. * Fix bugs, implement missing features, etc. P.S: I CCed the mono-winforms list, so the information will be available for others as well. I hope you won't mind. Well I'll continue to testing the TypeConverters first off. I would appreciate if you also make unit tests for the bugs you find (in case you have the time for that of course). It should be very straightforward for all Converters. For an example on how this is done take a look at mcs/class/System.Drawing/Test/System.Drawing/ColorConverter.cs And then check the Editors thereafter. Assuming that's OK. I'll stay at just QA-ing at least for now, you seems to be able to fix the problems quickly so I'll not get in the way. :-) You won't get in my way at all if you start bugfixing Converters and Editors, mainly because this is not something I am directly focusing at at the moment. BTW how do you debug the faults, are you using the Mono debugger or printf-debugging, or someother system? For those that I have to track down I use CWL (Console.WriteLine) or mbox (MessageBox.Show) :). Luckily for now I know why and where most happen. It'd be nice to see why a value isn't accepted, a typeconverter attrbute ignored, etc. I'd normally put breakpoints on the error-handling statements... You can add CWLs inside all try-catch blocks in mcs/class/Managed.Windows.Forms/System.Windows.Forms/GridEntry.cs to print the exception and StackTrace. We swallow most exceptions on purpose, but essentially they are the main indicators whether something has failed. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] PropertyGrid testing aims?
Andy Hume wrote: Hi Ivan Andy Hume, logger of Mono bug reports here. :-,) Just thought I'd drop you a note to see what your aims are for the PropertyGrid in the short and longer term. I'm guite willing to bang away on it in my spare time and log bugs if that's useful to you. Or maybe you're working away on it yourself and will find the bugs anyway, and other bugs would just get in the way. :-) Let me know. Andy Hey Andy, For the past two weeks I rewrote most of PropertyGrid and its components, so we have support for a lot of things now and better improved support for others. I hope you have noticed that during your testing. (We will ship the PropertyGrid with major improvements in 1.9 hurray!) Huge thanks for your bug reports and please keep them coming! I really appreciate your time and effort. Short-term goals are: * Fix layout issues related to the scrollbar. They cause your bug #359199 and a couple of others with recursive collapse/expand. * Fix TypeDescriptor's Editors table and GetEditor to fix #358332 and a few others non-filed ones. * Fix the rest of the reported bugs. Long-term goals are: * Implement PropertyTab support, so I can implement EventsTab. * Implement TypeDescriptor Associations and Providers. * Bugfix and implement Editors and Converters -- BTW, if you feel like coding those might be a quick and easy start. * Fix bugs, implement missing features, etc. P.S: I CCed the mono-winforms list, so the information will be available for others as well. I hope you won't mind. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor
On Thu, 2008-01-03 at 03:32 -0800, Vladimir Krasnov wrote:
Hi Ivan,
You are right, I've reverted the Hashtable patch and everything works
fine. TestGetProperties in TypeDescriptorTests is ok also.
Look at attached patch.
Looks good, please commit, thanks.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ivan N.
Zlatev
Sent: Thursday, January 03, 2008 2:24 AM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor
Vladimir Krasnov wrote:
Hello,
Please review and approve attached patch for
TypeDescriptor.GetProperties() method. This fixes the order of
properties in the returning collection which is important for
System.Web data bound controls.
You can get rid off the Hashtable used in TypeInfo.GetProperties. I
introduced it because at some point Type.GetProperties used to return
two AnotherProperty PropertyInfos for typeof(B) in the following case:
class A
{
public string AnotherProperty {
}
}
class B : A
{
public new string AnotherProperty {
}
}
It seems to no longer be the case (back then I did not test the
Type.GetProperties behavior on msnet and assumed bug in TypeDescriptor),
but you should test to make sure. You can check test #G2 in
TestGetProperties in TypeDescriptorTests.
Regards,
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor
Vladimir Krasnov wrote:
Hello,
Please review and approve attached patch for
TypeDescriptor.GetProperties() method. This fixes the order of
properties in the returning collection which is important for System.Web
data bound controls.
You can get rid off the Hashtable used in TypeInfo.GetProperties. I
introduced it because at some point Type.GetProperties used to return
two AnotherProperty PropertyInfos for typeof(B) in the following case:
class A
{
public string AnotherProperty {
}
}
class B : A
{
public new string AnotherProperty {
}
}
It seems to no longer be the case (back then I did not test the
Type.GetProperties behavior on msnet and assumed bug in TypeDescriptor),
but you should test to make sure. You can check test #G2 in
TestGetProperties in TypeDescriptorTests.
Regards,
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-winforms-list] mwf-designer dead?
On 12/23/07, hellboy195 [EMAIL PROTECTED] wrote: Hi, Is the mwf-designer project from Ivan N. Zlatev dead? No commit since 2007-10-24. This would be very sad :( Hey, the designer is just a thin layer on top of what's in the System.Design assembly, which is where the work is taking place (slowly but getting there). http://mono-project.com/WinForms_Designer has some information on the status and todos. Regards, -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] Patch for System.ComponentModel.PropertyDescriptionCollection
Vladimir Krasnov wrote: Hello, Please review and approve attached patch for System.ComponentModel.PropertyDescriptionCollection. It fixed Find method that should not use culture sensitive string compare. Please commit, thanks. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] System.ComponentModel.Design.CheckoutException
Arina Itkes wrote: Hello, Please review the patch. It includes small change for ctors of CheckoutException: CheckoutException should not be initialized with ErrorCode = 0 by default. Please commit, thanks. Regards, Ivan Zlatev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono CodeDom problem
[EMAIL PROTECTED] wrote:
Hi Guys:
I have this code from a example of a simple code generator with CodeDom
(from here http://www.15seconds.com/issue/020917.htm , I list the code
at end of the message), but with mono I only get the using and namespace
declarations...I see in the status page of mono that the codedom is
allmost complete, do you have some examples?
I didn't bother to go through the article, but the code sample is wrong
and broken in many aspects. But to answer your question - there is
nothing wrong with Mono's CodeDom C# code generator. It won't generate
anything more than the namespace essentially because the author never
adds the class to the namespace (e.g via: cnsCodeDom.Types.Add (ctd); ).
Based on the code sample I wouldn't recommend this article. A good
starting point is
http://msdn2.microsoft.com/en-us/library/aa720100(VS.71).aspx
Regard,
Ivan Zlatev
thanks
Mauricio
using System;
using System.CodeDom;
using System.CodeDom.Compiler;
using System.Reflection;
using System.IO;
using Microsoft.CSharp;
using Microsoft.VisualBasic;
namespace CodeDomPartOne
{
///
/// Summary description for Briefcase.
///
public class Briefcase
{
//Member Variables private string m_strFileName;
private string m_Suffix = .cs;
public Briefcase(string strFileName)
{
m_strFileName = strFileName; }public void
CreateCodeDomBriefcase()
{
//Initialize CodeDom Variables
//para windows
//Stream s = File.Open(c:\\ + m_strFileName + m_Suffix,
FileMode.Create);
//para linux
Stream s = File.Open( + m_strFileName + m_Suffix, FileMode.Create);
StreamWriter sw = new StreamWriter(s);
CSharpCodeProvider cscProvider = new CSharpCodeProvider();
ICodeGenerator cscg = cscProvider.CreateGenerator(sw);
CodeGeneratorOptions cop = new CodeGeneratorOptions();
//Create Class Using Statements
CodeSnippetCompileUnit csu1 = new CodeSnippetCompileUnit(using
System);
CodeSnippetCompileUnit csu2 = new CodeSnippetCompileUnit(using
System.IO); cscg.GenerateCodeFromCompileUnit(csu1, sw, cop);
cscg.GenerateCodeFromCompileUnit(csu2, sw, cop);
sw.WriteLine();
//Create Class Namespaces
CodeNamespace cnsCodeDom = new CodeNamespace(CodeDom);
//Create Class Declaration
CodeTypeDeclaration ctd = new CodeTypeDeclaration();
ctd.IsClass = true; ctd.Name = Briefcase;
ctd.TypeAttributes = TypeAttributes.Public;
//Create Class Member Fields
sw.WriteLine(); CodeMemberField cmfBriefcaseName = new
CodeMemberField(string,m_BriefcaseName);
cmfBriefcaseName.Attributes =
MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseName);
CodeMemberField cmfBriefcaseTitle = new CodeMemberField(string,
m_BriefcaseTitle);
cmfBriefcaseTitle.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseTitle);
CodeMemberField cmfBriefcaseID = new CodeMemberField(int,
m_cmfBriefcaseID);
cmfBriefcaseID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseID);
CodeMemberField cmfBriefcaseSectionID = new CodeMemberField(int,
m_BriefcaseSectionID);
cmfBriefcaseSectionID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseSectionID);
CodeMemberField cmfBriefcaseFolderID = new CodeMemberField(int,
m_BriefcaseFolderID);
cmfBriefcaseFolderID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseFolderID);
CodeMemberField cmfBriefcaseItemID = new CodeMemberField(int,
m_BriefcaseItemID);
cmfBriefcaseItemID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseItemID);
//Create Class Constructor CodeConstructor ccon =
new CodeConstructor();
ccon.Attributes = MemberAttributes.Public;
ccon.Statements.Add(new CodeSnippetStatement(//));
ccon.Statements.Add(new CodeSnippetStatement(// TODO: Add
constructor logic here));
ccon.Statements.Add(new CodeSnippetStatement(//));
ctd.Members.Add(ccon);
//Create Class BriefcaseName Property
CodeMemberProperty mpBriefcaseName = new CodeMemberProperty();
mpBriefcaseName.Attributes = MemberAttributes.Private;
mpBriefcaseName.Type = new CodeTypeReference(string);
mpBriefcaseName.Name = BriefcaseName;
mpBriefcaseName.HasGet = true;
mpBriefcaseName.GetStatements.Add(new CodeSnippetExpression(return
m_BriefcaseName));
mpBriefcaseName.HasSet = true;
mpBriefcaseName.SetStatements.Add(new
CodeSnippetExpression(m_BriefcaseName = value));
Re: [Mono-dev] mono CodeDom problem
[EMAIL PROTECTED] wrote:
thanks Ivan, bad source info then, the link that you send me is broken,
but of course I'm going to search for better info on the net..
The link opens fine here. Try this one -
http://msdn2.microsoft.com/en-us/library/650ax5cx.aspx
thanks again.
Mauricio
Ivan N. Zlatev wrote:
[EMAIL PROTECTED] wrote:
Hi Guys:
I have this code from a example of a simple code generator with CodeDom
(from here http://www.15seconds.com/issue/020917.htm , I list the code
at end of the message), but with mono I only get the using and namespace
declarations...I see in the status page of mono that the codedom is
allmost complete, do you have some examples?
I didn't bother to go through the article, but the code sample is wrong
and broken in many aspects. But to answer your question - there is
nothing wrong with Mono's CodeDom C# code generator. It won't generate
anything more than the namespace essentially because the author never
adds the class to the namespace (e.g via: cnsCodeDom.Types.Add (ctd); ).
Based on the code sample I wouldn't recommend this article. A good
starting point is
http://msdn2.microsoft.com/en-us/library/aa720100(VS.71).aspx
Regard,
Ivan Zlatev
thanks
Mauricio
using System;
using System.CodeDom;
using System.CodeDom.Compiler;
using System.Reflection;
using System.IO;
using Microsoft.CSharp;
using Microsoft.VisualBasic;
namespace CodeDomPartOne
{
///
/// Summary description for Briefcase.
///
public class Briefcase
{
//Member Variables private string m_strFileName;
private string m_Suffix = .cs;
public Briefcase(string strFileName)
{
m_strFileName = strFileName; }public void
CreateCodeDomBriefcase()
{
//Initialize CodeDom Variables
//para windows
//Stream s = File.Open(c:\\ + m_strFileName + m_Suffix,
FileMode.Create);
//para linux
Stream s = File.Open( + m_strFileName + m_Suffix, FileMode.Create);
StreamWriter sw = new StreamWriter(s);
CSharpCodeProvider cscProvider = new CSharpCodeProvider();
ICodeGenerator cscg = cscProvider.CreateGenerator(sw);
CodeGeneratorOptions cop = new CodeGeneratorOptions();
//Create Class Using Statements
CodeSnippetCompileUnit csu1 = new CodeSnippetCompileUnit(using
System);
CodeSnippetCompileUnit csu2 = new CodeSnippetCompileUnit(using
System.IO); cscg.GenerateCodeFromCompileUnit(csu1, sw, cop);
cscg.GenerateCodeFromCompileUnit(csu2, sw, cop);
sw.WriteLine();
//Create Class Namespaces
CodeNamespace cnsCodeDom = new CodeNamespace(CodeDom);
//Create Class Declaration
CodeTypeDeclaration ctd = new CodeTypeDeclaration();
ctd.IsClass = true; ctd.Name = Briefcase;
ctd.TypeAttributes = TypeAttributes.Public;
//Create Class Member Fields
sw.WriteLine(); CodeMemberField cmfBriefcaseName = new
CodeMemberField(string,m_BriefcaseName);
cmfBriefcaseName.Attributes =
MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseName);
CodeMemberField cmfBriefcaseTitle = new CodeMemberField(string,
m_BriefcaseTitle);
cmfBriefcaseTitle.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseTitle);
CodeMemberField cmfBriefcaseID = new CodeMemberField(int,
m_cmfBriefcaseID);
cmfBriefcaseID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseID);
CodeMemberField cmfBriefcaseSectionID = new CodeMemberField(int,
m_BriefcaseSectionID);
cmfBriefcaseSectionID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseSectionID);
CodeMemberField cmfBriefcaseFolderID = new CodeMemberField(int,
m_BriefcaseFolderID);
cmfBriefcaseFolderID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseFolderID);
CodeMemberField cmfBriefcaseItemID = new CodeMemberField(int,
m_BriefcaseItemID);
cmfBriefcaseItemID.Attributes = MemberAttributes.Private;
ctd.Members.Add(cmfBriefcaseItemID);
//Create Class Constructor CodeConstructor ccon =
new CodeConstructor();
ccon.Attributes = MemberAttributes.Public;
ccon.Statements.Add(new CodeSnippetStatement(//));
ccon.Statements.Add(new CodeSnippetStatement(// TODO: Add
constructor logic here));
ccon.Statements.Add(new CodeSnippetStatement(//));
ctd.Members.Add(ccon);
//Create Class BriefcaseName Property
CodeMemberProperty mpBriefcaseName = new CodeMemberProperty();
mpBriefcaseName.Attributes = MemberAttributes.Private;
mpBriefcaseName.Type = new CodeTypeReference(string
[Mono-dev] Mono Summit 2007 Photos
Dear Monkeys, I would like firstly to thank everyone for the great time I had during this Mono Summit. It was a pleasure for me to meet and spend this week with you guys. I suggest everyone replies to this e-mail with a link of his/her zip-ed/tar-ed/whatever photos of the event. Also if you don't feel like sharing your photos with The Others (you know, the ones that live on the other side of the island) I propose you archive them with a password same as the WiFi one from the summit. I could file a bug in bugzilla so we can track this easier. ;) Unfortunately I do not have any photos to share as I did not have a camera on me. Cheers! P.S: And no, I did not fix the transparency in WinForms... -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HEAD build broken?
I am failing to compile HEAD r90040 because of the following: make[7]: Entering directory `/svn/mono/mcs/tools/tuner' make all-local make[8]: Entering directory `/svn/mono/mcs/tools/tuner' MONO_PATH=.:../../class/lib/default:$MONO_PATH /svn/mono/mono/runtime/mono-wrapper --debug ../linker/monolinker.exe -d ../../class/lib/net_2_1 -o ../../class/lib/net_2_1_tuned -l none -c link -a smcs -b true -m display_internalized false -x Descriptors/mscorlib.xml -x Descriptors/smcs.xml -x Descriptors/System.xml -s Mono.Tuner.InjectAttributes,Mono.Tuner:OutputStep -s Mono.Tuner.AdjustVisibility,Mono.Tuner:OutputStep -s Mono.Tuner.PrintStatus,Mono.Tuner:OutputStep -s Mono.Tuner.RemoveSerialization,Mono.Tuner:OutputStep -s Mono.Tuner.CheckVisibility,Mono.Tuner -i masterinfos/silverlight/mscorlib.info -i masterinfos/silverlight/System.info -i masterinfos/silverlight/System.Core.info -i masterinfos/silverlight/System.Xml.Core.info Fatal error in Mono CIL Linker System.TypeLoadException: Could not load type 'Mono.Tuner.InjectAttributes,Mono.Tuner'. at (wrapper managed-to-native) System.Type:internal_from_name (string,bool,bool) at System.Type.GetType (System.String typeName, Boolean throwOnError) [0x00011] in /svn/mono/mcs/class/corlib/System/Type.cs:457 at Mono.Linker.Driver.ResolveStep (System.String type) [0x0] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:197 at Mono.Linker.Driver.AddCustomStep (Mono.Linker.Pipeline pipeline, System.String arg) [0x00053] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:177 at Mono.Linker.Driver.Run () [0x001a6] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:124 at Mono.Linker.Driver.Main (System.String[] args) [0x00014] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:51 make[8]: *** [tune] Error 1 -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HEAD build broken?
On 11/21/07, Atsushi Eno [EMAIL PROTECTED] wrote: Sometimes you need to do make PROFILE=net_2_1 clean under mcs, or make clean under mono when you aren't lucky enough, or sometimes even make maintainer-clean or distclean. Yeap, that helped. The buildbot is your friend if you are in doubt on build sanity ;-) http://mono.ximian.com/monobuild/python/monobuild.py Will check against that in the future Atsushi Eno Ivan N. Zlatev wrote: I am failing to compile HEAD r90040 because of the following: make[7]: Entering directory `/svn/mono/mcs/tools/tuner' make all-local make[8]: Entering directory `/svn/mono/mcs/tools/tuner' MONO_PATH=.:../../class/lib/default:$MONO_PATH /svn/mono/mono/runtime/mono-wrapper --debug ../linker/monolinker.exe -d ../../class/lib/net_2_1 -o ../../class/lib/net_2_1_tuned -l none -c link -a smcs -b true -m display_internalized false -x Descriptors/mscorlib.xml -x Descriptors/smcs.xml -x Descriptors/System.xml -s Mono.Tuner.InjectAttributes,Mono.Tuner:OutputStep -s Mono.Tuner.AdjustVisibility,Mono.Tuner:OutputStep -s Mono.Tuner.PrintStatus,Mono.Tuner:OutputStep -s Mono.Tuner.RemoveSerialization,Mono.Tuner:OutputStep -s Mono.Tuner.CheckVisibility,Mono.Tuner -i masterinfos/silverlight/mscorlib.info -i masterinfos/silverlight/System.info -i masterinfos/silverlight/System.Core.info -i masterinfos/silverlight/System.Xml.Core.info Fatal error in Mono CIL Linker System.TypeLoadException: Could not load type 'Mono.Tuner.InjectAttributes,Mono.Tuner'. at (wrapper managed-to-native) System.Type:internal_from_name (string,bool,bool) at System.Type.GetType (System.String typeName, Boolean throwOnError) [0x00011] in /svn/mono/mcs/class/corlib/System/Type.cs:457 at Mono.Linker.Driver.ResolveStep (System.String type) [0x0] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:197 at Mono.Linker.Driver.AddCustomStep (Mono.Linker.Pipeline pipeline, System.String arg) [0x00053] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:177 at Mono.Linker.Driver.Run () [0x001a6] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:124 at Mono.Linker.Driver.Main (System.String[] args) [0x00014] in /svn/mono/mcs/tools/linker/Mono.Linker/Driver.cs:51 make[8]: *** [tune] Error 1 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Counts 11-16-07...
Those bug counts do not mean much. They do not show how many new bugs were opened during the period nor how many were closed. It might be also good to show how many bugs with needinfo are there and the resolve status of the closed bugs during the period (e.g how many resolved, wontfix, invalid, etc) Regards -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 1.2.6 Release Notes
My notes as follows. System.Windows.Forms * SplitContainer now supports FixedPanel layouting. System.Design Initial implementation of the .Net 1.1 and .Net 2.0 Design-Time framework. Includes: * Hosting: DesignSurface, DesignSurfaceManager, etc. * CodeDom Serialization/Deserialization: CodeDomSerializer, CodeDomSerializerBase, DesignerSerializationManager, etc * Core WinForms Designers Stack: ComponentDesigner, ControlDesigner, ScrollableControlDesigner, ParentControlDesigner, DocumentDesigner, etc. P.S: I am starting a new thread because the original got polluted. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] [Mono-dev] MonoSummit: Planning the Sessions
On 10/26/07, Miguel de Icaza [EMAIL PROTECTED] wrote: Hey folks, Am looking for ideas for topics that developers would be interested in hearing about at the Mono Summit. I personally would be interested to hear a brief introduction to Silverlight and Moonlight with some examples etc. Last year, we chose in advance that the developers in the team will each present what they are working on. This does not necessarily map to what people wanted to learn or discuss. Please send us feedback about the topics that we should discuss. I have created a module monosummit07 on SVN where am going to be tracking the suggestions for sessions that we should have at the Mono summit. This is our current list Ideas for some sessions for the open days at the the Mono Summit in Madrid * Embedding Mono Scripting applications through the Mono Virtual Machine Discuss C#, Boo, IronPython and how they can be embedded * Mono on Windows * Mono on Mac Discuss Winforms on OSX Possible directions (Native Gtk/OSX) CocoaSharp * Existing Use Cases Users of the Mono Platform: existing users talk about what they are using Mono for. Show existing success case stories. ___ Mono-devel-list mailing list [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-winforms-list] MWF-Designer doesn't build
On 9/9/07, Jonathan Pobst [EMAIL PROTECTED] wrote: Add src/UI/ToolBoxList/*.cs to the list of sources it is building from. Fixed in head. Jonathan Valentin Sawadski wrote: Hello everybody, just a quick question: Is it just me or is the MWF-Designer currently broken? I have an updated version of mono but trying to compile the MWF-Designer fails with the following message: mkdir -p build cp deps/ICSharpCode.NRefactory.dll build gmcs -debug -r:System.Design,System.Windows.Forms,System.Drawing,System.Data,build/ICSharpCode.NRefactory.dll -out:build/mwf-designer.exe src/*.cs src/*/*.cs src/UI/MainView.Designer.cs(349,21): error CS0246: The type or namespace name `ToolBoxList' could not be found. Are you missing a using directive or an assembly reference? src/UI/MainView.cs(114,47): error CS0246: The type or namespace name `ToolBoxList' could not be found. Are you missing a using directive or an assembly reference? Compilation failed: 2 error(s), 0 warnings Kind Regards, Valentin S. ___ 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 -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] MWF status report
Nope :( On 8/30/07, Everaldo Canuto [EMAIL PROTECTED] wrote: Hey, Is this patch working? Everaldo. On 8/29/07, Ivan N. Zlatev [EMAIL PROTECTED] wrote: On 8/29/07, Everaldo Canuto [EMAIL PROTECTED] wrote: Hi all, Attached is an spreadsheet (openOfice Calc required) with details about current Mono WinForms bugs. We have an total of 140 bugs. Grids, text boxes, lists and trees is the area where we have most number of bugs, 53,57% of bugs. The spreadsheet is from 27th august but I have plans to publish one every week. Because the report mentioned Transparency - http://bugzilla.ximian.com/show_bug.cgi?id=81135 -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] WinForms Designer after-GSoC Status Report
If someone is interested in the current status of the Design-Time code and what work is left, etc my after-Google Summer of Code summary report can be read here: http://files.i-nz.net/projects/gsoc2007/reports/Mono.Design%20Report.html -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Helping Ivan.
On 8/12/07, Miguel de Icaza [EMAIL PROTECTED] wrote: Hey folks, If you have some cycles, would you mind helping Ivan with one of the issues that he is having with XEMBED to get his Winforms designed working? It should be noted that I have moved my work to a standalone MWF hosted designer, so this is not a top priority for me any more, but it is still cruicial for the MonoDevelop integration. I do need help with other 2 issues related to MWF though: http://bugzilla.ximian.com/show_bug.cgi?id=82453 http://bugzilla.ximian.com/show_bug.cgi?id=82187 Regards, Ivan. -- Forwarded message -- From: Ivan N. Zlatev [EMAIL PROTECTED] To: Miguel de Icaza [EMAIL PROTECTED] Date: Wed, 8 Aug 2007 19:44:53 +0100 Subject: GSoC WinForms Addin for MonoDevelop Hey Miguel, I am on my vacation right now woho ;) It was my intention to send this email before the beginning of it, but there we go. I was hacking on the monodevelop addin to the last minute and the good news is that something that initially seemed to work came out of that. Unfortunately there are 2 major problems I have stumbled upon both related to the mfw-gtk interop as described below. They are both blockers and I won't be able to continue my work on the addin unless those are resolved. A possibility is to spend the last week of the gsoc program hacking on a standalone mwf hosted designer. 1.) As I have described here - http://lists.ximian.com/pipermail/mono-winforms-list/2007-August/002979.html Drag and Drop doesn't work because there are some differences in how that is handled when one of the parents is a Plug parented to a Socket (that is - XEMBED is used). I have to use a socket/plug as the designing is done on a separate process than the main MD one via remoting. This is the way to go in MD. 2.) The second issue can be observed only sometimes (well quite often actually) and looks like this - http://www.i-nz.net/files/gallery/software/mwf-addin-borked.png. To me this looks like that one of the gtk/mwf thread is blocking the other. I do not know why and how. The mwf parented in gtk code also known as the Designer Remote Editor Process is this http://monodt.i-nz.net/browser/trunk/WinFormsAddin/src/EditorProcess.cs. The MD main gtk thread creates a socket and attaches the DesignerWidget offered by the EditorProcess (RemoveDesignerProcess from the DesignerSupport addin) to a plug. In this designer widget I parent the MWF control. * To get, install and test the addin from the attached tarball: make install make run (make uninstall is also present) Load the test solution from the tarball - open Form1.cs - click on Design * To get and install the addin from source code (requires MonoDevelop 0.15): svn co http://svn.i-nz.net/monodt/trunk/Mono.Design svn co http://svn.i-nz.net/monodt/trunk/WinFormsAddin cd Mono.Design; make; cd .. cd WinFormsAddin; make; make install; cd .. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ 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
[Mono-winforms-list] X11Dnd + XEMBED = NRE
] at Mono.Design.ControlDesigner.WndProc (System.Windows.Forms.Message m) [0x0] at Mono.Design.ControlDesigner.Mono.Design.IMessageReceiver.WndProc (System.Windows.Forms.Message m) [0x0] at Mono.Design.WndProcRouter.System.Windows.Forms.IWindowTarget.OnMessage (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message m) [0x0] at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x0] at System.Windows.Forms.XplatUIX11.DispatchMessage (System.Windows.Forms.MSG msg) [0x0] at System.Windows.Forms.XplatUI.DispatchMessage (System.Windows.Forms.MSG msg) [0x0] at System.Windows.Forms.Application.RunLoop (Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x0] at System.Windows.Forms.Application.Run () [0x0] at WinFormsAddin.EditorProcess.InitializeMWF () [0x0] -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Request for help: MWF Control in a GTK Container
On 7/28/07, Valentin Sawadski [EMAIL PROTECTED] wrote:
Hi,
On Sat, 2007-07-28 at 00:38 +0300, Ivan N. Zlatev wrote:
I have been trying to parent a MWF control in a GTK Container
unsuccessfully. I have attached the result of my hackings, which
doesn't crash, but doesn't seem to show the MWF control properly.
Anyone care to help me out figure what's wrong and how to make this
work? I really need this working in order to integrate the GSoC
WinForms designer in MonoDevelop. :(
I haven't got much experience with this kind of stuff, but at first
glance it looks like your control is being created at a different thread
than the one on which System.Windows.Forms.Application.Run is being
invoked on.
Doesn't it needed to be created in the same thread because
System.Windows.Forms.Application.Run creates the message pumps only on
its current thread?
Absolutely true. I have overlooked that and infact it seems to work
very well now! Thanks!
I have attached the updated code in case someone ever finds it useful
for something.
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
using System;
using Gtk;
using Gdk;
using System.Windows.Forms;
using System.Drawing;
using System.Threading;
namespace mwfingtk
{
class MainClass
{
private static Container _gtkContainer;
private static Control _mwfContainer;
public static void Main (string[] args)
{
RunGTK ();
while (_gtkContainer == null) {}
while (_gtkContainer.Handle == IntPtr.Zero) { } // wait for the gtk handle
Console.WriteLine (GTK up and running.\n);
RunMWF ();
while (_mwfContainer == null) {}
while (!_mwfContainer.IsHandleCreated) { } // wait for the mwf handle
Console.WriteLine (MWF up and running.\n);
Gtk.Application.Invoke ( delegate {
Gdk.Window window = Gdk.Window.ForeignNew ((uint) _mwfContainer.Handle);
window.Reparent (_gtkContainer.GdkWindow, 0, 0);
window.Show ();
Console.WriteLine (Parenting complete.\n);
} );
}
private static void RunMWF ()
{
Thread t = new Thread (InitializeMWF);
t.Start ();
while (!t.IsAlive) {};
}
private static void RunGTK ()
{
Thread t = new Thread (InitializeGTK);
t.Start ();
while (!t.IsAlive) {};
}
private static void InitializeGTK ()
{
Gtk.Application.Init ();
Gtk.Window gtkWindow = new Gtk.Window (Title);
gtkWindow.ShowAll ();
_gtkContainer = gtkWindow;
Gtk.Application.Run ();
}
private static void InitializeMWF ()
{
Control mwfContainer = new Panel ();
mwfContainer.Click += delegate {
System.Windows.Forms.Button b = new System.Windows.Forms.Button ();
b.BackColor = System.Drawing.Color.Black;
b.Top = 50;
b.Left = 50;
b.Click += delegate {
b.Parent.Controls.Add (new System.Windows.Forms.ComboBox ());
};
_mwfContainer.Controls.Add (b);
};
mwfContainer.Controls.Add (new System.Windows.Forms.Button ());
mwfContainer.BackColor = System.Drawing.Color.Yellow;
mwfContainer.Size = new System.Drawing.Size (200, 200);
mwfContainer.CreateControl ();
_mwfContainer = mwfContainer;
System.Windows.Forms.Application.Run ();
}
}
}
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] Request for help: MWF Control in a GTK Container
I have been trying to parent a MWF control in a GTK Container
unsuccessfully. I have attached the result of my hackings, which
doesn't crash, but doesn't seem to show the MWF control properly.
Anyone care to help me out figure what's wrong and how to make this
work? I really need this working in order to integrate the GSoC
WinForms designer in MonoDevelop. :(
Regards.
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
using System;
using Gtk;
using Gdk;
using System.Windows.Forms;
using System.Drawing;
using System.Threading;
namespace mwfingtk
{
class MainClass
{
private static Container _gtkContainer;
private static Control _mwfContainer;
public static void Main (string[] args)
{
Gtk.Application.Init ();
_gtkContainer = InitializeGTK ();
RunGTK ();
while (_gtkContainer.Handle == IntPtr.Zero) { } // wait for the gtk handle
Console.WriteLine (GTK up and running.\n);
_mwfContainer = InitializeMWF ();
RunMWF ();
while (!_mwfContainer.IsHandleCreated) { } // wait for the mwf handle
Console.WriteLine (MWF up and running.\n);
Gtk.Application.Invoke ( delegate {
Gdk.Window window = Gdk.Window.ForeignNew ((uint) _mwfContainer.Handle);
window.Reparent (_gtkContainer.GdkWindow, 0, 0);
window.Show ();
Console.WriteLine (Parenting complete.\n);
} );
}
private static void RunMWF ()
{
Thread t = new Thread (System.Windows.Forms.Application.Run);
t.Start ();
while (!t.IsAlive) {};
}
private static void RunGTK ()
{
Thread t = new Thread (Gtk.Application.Run);
t.Start ();
while (!t.IsAlive) {};
}
private static Container InitializeGTK ()
{
Gtk.Window gtkWindow = new Gtk.Window (Title);
gtkWindow.ShowAll ();
return gtkWindow;
}
private static Control InitializeMWF ()
{
Control mwfContainer = new Panel ();
mwfContainer.Click += delegate { MessageBox.Show (Panel clicked); };
mwfContainer.Controls.Add (new System.Windows.Forms.Button ());
mwfContainer.BackColor = System.Drawing.Color.Yellow;
mwfContainer.Size = new System.Drawing.Size (200, 200);
mwfContainer.CreateControl ();
return mwfContainer;
}
}
}
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] WS_EX_TRANSPARENT implementation for the X11 backend
Attached is a version 3 of the patch, which still causes a BadWindow X
error. May be someone can take a look?
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs (working copy)
@@ -1659,4 +1659,19 @@
public int nimage; /* number of images */
public IntPtr images; /* array of XcursorImage pointers */
}
+
+ [StructLayout(LayoutKind.Sequential)]
+ internal struct XVisualInfo
+ {
+ internal IntPtr visual;
+ internal int visualid;
+ internal int screen;
+ internal uint depth;
+ internal int klass;
+ internal uint red_mask;
+ internal uint green_mask;
+ internal uint blue_mask;
+ internal int colormap_size;
+ internal int bits_per_rgb;
+ }
}
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs (working copy)
@@ -2617,15 +2617,23 @@
Rectangle XClientRect = TranslateClientRectangleToXClientRectangle (hwnd, cp.control);
lock (XlibLock) {
-WholeWindow = XCreateWindow(DisplayHandle, ParentHandle, X, Y, XWindowSize.Width, XWindowSize.Height, 0, (int)CreateWindowArgs.CopyFromParent, (int)CreateWindowArgs.InputOutput, IntPtr.Zero, new UIntPtr ((uint)ValueMask), ref Attributes);
+
+int depth = (int)CreateWindowArgs.CopyFromParent;
+IntPtr colormap = CustomColormap;
+IntPtr visual = CustomVisual;
+
+if (ExStyleSet (cp.ExStyle, WindowExStyles.WS_EX_TRANSPARENT))
+ GetRGBAInfo (Display, RootWindowHandle, Screen, out colormap, out visual, out depth);
+
+if (colormap != IntPtr.Zero) {
+ ValueMask |= SetWindowValuemask.ColorMap;
+ Attributes.colormap = colormap;
+}
+
+WholeWindow = XCreateWindow(DisplayHandle, ParentHandle, X, Y, XWindowSize.Width, XWindowSize.Height, 0, depth, (int)CreateWindowArgs.InputOutput, visual, new UIntPtr ((uint)ValueMask), ref Attributes);
if (WholeWindow != IntPtr.Zero) {
ValueMask = ~(SetWindowValuemask.OverrideRedirect | SetWindowValuemask.SaveUnder);
-
- if (CustomVisual != IntPtr.Zero CustomColormap != IntPtr.Zero) {
- ValueMask = SetWindowValuemask.ColorMap;
- Attributes.colormap = CustomColormap;
- }
- ClientWindow = XCreateWindow(DisplayHandle, WholeWindow, XClientRect.X, XClientRect.Y, XClientRect.Width, XClientRect.Height, 0, (int)CreateWindowArgs.CopyFromParent, (int)CreateWindowArgs.InputOutput, CustomVisual, new UIntPtr ((uint)ValueMask), ref Attributes);
+ ClientWindow = XCreateWindow(DisplayHandle, WholeWindow, XClientRect.X, XClientRect.Y, XClientRect.Width, XClientRect.Height, 0, depth, (int)CreateWindowArgs.InputOutput, visual, new UIntPtr ((uint)ValueMask), ref Attributes);
}
}
@@ -2711,6 +2719,33 @@
return hwnd.Handle;
}
+ private void GetRGBAInfo (IntPtr display, IntPtr rootWindow, int screenNo, out IntPtr colormap,
+ out IntPtr visual, out int depth)
+ {
+ visual = colormap = IntPtr.Zero;
+ depth = (int)CreateWindowArgs.CopyFromParent; /* 0 */
+
+ XVisualInfo visualInfo = new XVisualInfo ();
+ visualInfo.screen = screenNo;
+ visualInfo.depth = 32;
+ visualInfo.red_mask = 0xff;
+ visualInfo.green_mask = 0x00ff00;
+ visualInfo.blue_mask = 0xff;
+ visualInfo.klass = 4; /* TrueColor */
+ int mask = 0x2 /* VisualScreenMask */ | 0x04 /* VisualDepthMask */ | 0x10 /* VisualRedMaskMask */ |
+0x20 /* VisualGreenMaskMask */ | 0x40 /* VisualBlueMaskMask */ | 0x8 /* VisualClassMask */;
+
+ int nitems = 0;
+ IntPtr vPtr = XGetVisualInfo (display, mask, ref visualInfo, ref nitems);
+ if (vPtr != IntPtr.Zero nitems 0) {
+visualInfo = (XVisualInfo) Marshal.PtrToStructure (vPtr, typeof (XVisualInfo));
+visual = visualInfo.visual;
+depth = (int) visualInfo.depth;
+colormap = XCreateColormap (display, rootWindow, visual, 0x0 /* AllocNone */);
+XFree (vPtr);
+ }
+ }
+
internal override IntPtr CreateWindow(IntPtr Parent, int X, int Y, int Width, int Height) {
CreateParams create_params = new CreateParams();
@@ -5998,7 +6033,13 @@
internal extern static void XkbSetDetectableAutoRepeat (IntPtr display, bool detectable, IntPtr supported);
[DllImport (libX11)]
- internal extern static void XPeekEvent (IntPtr display, ref XEvent xevent);
+ internal extern static void XPeekEvent (IntPtr display, ref XEvent xevent);
+
+ [DllImport (libX11)]
+ internal extern static IntPtr XGetVisualInfo (IntPtr display, int vinfo_mask, ref XVisualInfo vinfo_template, ref int nitems);
+
+ [DllImport
Re: [Mono-dev] CodeBehindService, ICodeBehindProvider - no support for partial classes?
Pardon me as this was supposed to go to the monodevel list. On 7/26/07, Ivan N. Zlatev [EMAIL PROTECTED] wrote: To me it seems that the current CodeBehindService implementation is based on class names and assumes that the code behind file will have a different class name than the code-in-front file. What about partial classes, where the class name will be the same? Regards. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] CodeBehindService, ICodeBehindProvider - no support for partial classes?
To me it seems that the current CodeBehindService implementation is based on class names and assumes that the code behind file will have a different class name than the code-in-front file. What about partial classes, where the class name will be the same? Regards. -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-winforms-list] WS_EX_TRANSPARENT implementation for the X11 backend
I have hacked up the following implementation for WS_EX_TRANSPARENT
for the X11 backend. It will try to get a RGBA Visual, create a RGBA
Colormap and set that as the colormap to be used for CreateWindow.
The issue is that even with the RGBA colormap and
BackColor.Transparent set for the control it isn't transparent. I have
tried filling the client area in OnPaintBackground with
Brushes.Transparent but that also just results a black client
rectangle. Could it be that Color.Transparent doesn't match what is
expected by X?
May be someone can take a look and help me to figure out what is
wrong? Patch and test case attached.
Regards.
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs (working copy)
@@ -1659,4 +1659,19 @@
public int nimage; /* number of images */
public IntPtr images; /* array of XcursorImage pointers */
}
+
+ [StructLayout(LayoutKind.Sequential)]
+ internal struct XVisualInfo
+ {
+ internal IntPtr visual;
+ internal int visualid;
+ internal int screen;
+ internal uint depth;
+ internal int klass;
+ internal uint red_mask;
+ internal uint green_mask;
+ internal uint blue_mask;
+ internal int colormap_size;
+ internal int bits_per_rgb;
+ }
}
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/Xlib.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/Xlib.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/Xlib.cs (working copy)
@@ -346,5 +346,11 @@
[DllImport (libX11)]
public extern static void XPeekEvent (IntPtr display, ref XEvent xevent);
+
+ [DllImport (libX11)]
+ internal extern static IntPtr XGetVisualInfo (IntPtr display, int vinfo_mask, ref XVisualInfo vinfo_template, ref int nitems);
+
+ [DllImport (libX11)]
+ internal extern static IntPtr XCreateColormap (IntPtr display, IntPtr window, IntPtr visual, int alloc);
}
}
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/X11Display.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/X11Display.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/X11Display.cs (working copy)
@@ -1214,8 +1214,32 @@
((X11Hwnd)ModalWindows.Peek()).Activate ();
}
}
-}
+ }
+ public IntPtr GetRGBAColormap ()
+ {
+ IntPtr rgbaColormap = IntPtr.Zero;
+
+ // try to find the rgba visual
+ XVisualInfo visual = new XVisualInfo ();
+ visual.screen = (int) display;
+ visual.depth = 32;
+ visual.red_mask = 0xff;
+ visual.green_mask = 0x00ff00;
+ visual.blue_mask = 0xff;
+ int mask = 0x2 /* VisualIDMask */ | 0x04 /* VisualDepthMask */ | 0x10 /* VisualRedMaskMask */ |
+0x20 /* VisualGreenMaskMask */ | 0x40 /* VisualBlueMaskMask */;
+
+ int nitems = 0;
+ IntPtr vPtr = Xlib.XGetVisualInfo (display, mask, ref visual, ref nitems);
+ if (vPtr != IntPtr.Zero nitems 0) {
+rgbaColormap = Xlib.XCreateColormap (display, this.RootWindow.Handle, vPtr, 0x0 /* AllocNone */);
+Xlib.XFree (vPtr);
+ }
+
+ return rgbaColormap;
+ }
+
public void GetDisplaySize (out Size size)
{
XWindowAttributes attributes = new XWindowAttributes();
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/X11Hwnd.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/X11Hwnd.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms.X11Internal/X11Hwnd.cs (working copy)
@@ -130,7 +130,7 @@
!StyleSet (cp.Style, WindowStyles.WS_POPUP)) {
if (x0) x = 50;
if (y0) y = 50;
- }
+ }
// minimum width/height
if (width1) width=1;
if (height1) height=1;
@@ -154,7 +154,13 @@
ValueMask = ~(SetWindowValuemask.OverrideRedirect | SetWindowValuemask.SaveUnder);
- if (display.CustomVisual != IntPtr.Zero display.CustomColormap != IntPtr.Zero) {
+ if (ExStyleSet (cp.ExStyle, WindowExStyles.WS_EX_TRANSPARENT)) {
+IntPtr colormap = Display.GetRGBAColormap ();
+if (colormap != IntPtr.Zero) {
+ ValueMask |= SetWindowValuemask.ColorMap;
+ Attributes.colormap = colormap;
+}
+ } else if (display.CustomVisual != IntPtr.Zero display.CustomColormap != IntPtr.Zero) {
ValueMask |= SetWindowValuemask.ColorMap;
Attributes.colormap = display.CustomColormap;
}
using System;
using System.Collections;
using System.Drawing;
using System.Windows.Forms;
namespace mwfbugs
{
public class
Re: [Mono-winforms-list] WS_EX_TRANSPARENT implementation for the X11 backend
Rolf pointed out that I have been modifying the new tree, which is not
yet in use.
I have attached an updated patch. Unfortunately it causes a black
client rectangle instead of a transparent control. It also causes a
BadMatch[1] error and a lot of BadWindow errors.
Any X11 gurus around? :|
[1]
Error: BadMatch (invalid parameter attributes)
Request: 1 (0)
Resource ID: 0x3400012
Serial: 189
Hwnd:Hwnd, Mapped:False ClientWindow:0x3400014,
WholeWindow:0x3400012, Zombie=False, Parent:[Hwnd, Mapped:False
ClientWindow:0x34F, WholeWindow:0x34E, Zombie=False,
Parent:[Hwnd, Mapped:False ClientWindow:0x34D,
WholeWindow:0x34C, Zombie=False, Parent:[null]]]
Control: handle 54525972 non-existant at
System.Environment.get_StackTrace()
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/X11Structs.cs (working copy)
@@ -1659,4 +1659,19 @@
public int nimage; /* number of images */
public IntPtr images; /* array of XcursorImage pointers */
}
+
+ [StructLayout(LayoutKind.Sequential)]
+ internal struct XVisualInfo
+ {
+ internal IntPtr visual;
+ internal int visualid;
+ internal int screen;
+ internal uint depth;
+ internal int klass;
+ internal uint red_mask;
+ internal uint green_mask;
+ internal uint blue_mask;
+ internal int colormap_size;
+ internal int bits_per_rgb;
+ }
}
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs (revision 82534)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs (working copy)
@@ -2621,7 +2621,13 @@
if (WholeWindow != IntPtr.Zero) {
ValueMask = ~(SetWindowValuemask.OverrideRedirect | SetWindowValuemask.SaveUnder);
- if (CustomVisual != IntPtr.Zero CustomColormap != IntPtr.Zero) {
+ if (ExStyleSet (cp.ExStyle, WindowExStyles.WS_EX_TRANSPARENT)) {
+ IntPtr colormap = GetRGBAColormap (Display, RootWindowHandle, Screen);
+ if (colormap != IntPtr.Zero) {
+ ValueMask |= SetWindowValuemask.ColorMap;
+ Attributes.colormap = colormap;
+ }
+ } else if (CustomVisual != IntPtr.Zero CustomColormap != IntPtr.Zero) {
ValueMask = SetWindowValuemask.ColorMap;
Attributes.colormap = CustomColormap;
}
@@ -2711,6 +2717,30 @@
return hwnd.Handle;
}
+ public IntPtr GetRGBAColormap (IntPtr display, IntPtr rootWindow, int screenNo)
+ {
+ IntPtr rgbaColormap = IntPtr.Zero;
+
+ // try to find the rgba visual
+ XVisualInfo visual = new XVisualInfo ();
+ visual.screen = screenNo;
+ visual.depth = 32;
+ visual.red_mask = 0xff;
+ visual.green_mask = 0x00ff00;
+ visual.blue_mask = 0xff;
+ int mask = 0x2 /* VisualScreenMask */ | 0x04 /* VisualDepthMask */ | 0x10 /* VisualRedMaskMask */ |
+0x20 /* VisualGreenMaskMask */ | 0x40 /* VisualBlueMaskMask */;
+
+ int nitems = 0;
+ IntPtr vPtr = XGetVisualInfo (display, mask, ref visual, ref nitems);
+ if (vPtr != IntPtr.Zero nitems 0) {
+rgbaColormap = XCreateColormap (display, rootWindow, vPtr, 0x0 /* AllocNone */);
+XFree (vPtr);
+ }
+
+ return rgbaColormap;
+ }
+
internal override IntPtr CreateWindow(IntPtr Parent, int X, int Y, int Width, int Height) {
CreateParams create_params = new CreateParams();
@@ -5998,7 +6028,13 @@
internal extern static void XkbSetDetectableAutoRepeat (IntPtr display, bool detectable, IntPtr supported);
[DllImport (libX11)]
- internal extern static void XPeekEvent (IntPtr display, ref XEvent xevent);
+ internal extern static void XPeekEvent (IntPtr display, ref XEvent xevent);
+
+ [DllImport (libX11)]
+ internal extern static IntPtr XGetVisualInfo (IntPtr display, int vinfo_mask, ref XVisualInfo vinfo_template, ref int nitems);
+
+ [DllImport (libX11)]
+ internal extern static IntPtr XCreateColormap (IntPtr display, IntPtr window, IntPtr visual, int alloc);
#endregion
}
}
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] Transparent Control on X11?
Hello, As part of the requirements for implementing the System.Windows.Forms.Design.Behavior (for the winforms designer GSoC) namespace I will have to implement a Control with a transparent background to act as a transparent layer on top of the design surface. Some custom drawing will take place in the foreground. While this works on win32 with the use of the WS_EX_TRANSPARENT [1] CreateParam, this is not supported by the X11 backend. I had a bug filed [2] a few months ago, but I do understand implementing support for transparency is not in the list of high priority items. Is there a way to P/Invoke into something from the X libraries in order to achieve the effect of WS_EX_TRANSPARENT on X? A small example will be very appreciated as I don't have any experience in X programming. Regards. [1] http://support.microsoft.com/kb/92526 [2] http://bugzilla.ximian.com/show_bug.cgi?id=81135 -- Ivan N. Zlatev Web: http://www.i-nZ.net It's all some kind of whacked out conspiracy. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Transparent Control on X11?
On 7/23/07, Rafael Teixeira [EMAIL PROTECTED] wrote:
I would look at some other MWF control, to see how it is doing things
about transparency, as I think some of them have support for it.
I grepped through the MWF code for transparency and stumbled upon
SetWindowTransparency in X11Hwnd.cs. But this seems to ignore the
Color key parameter [1] and makes the whole window (of the control)
transparent (I might be wrong?), which means that whatever I draw in
the foreground will be transparent as well. I just want a
transparent background.
[1]
private void SetWindowTransparency (IntPtr handle, double
transparency, Color key)
{
IntPtr x11_opacity;
opacity = (uint)(0x * transparency);
x11_opacity = (IntPtr)((int)opacity);
IntPtr w = WholeWindow;
if (reparented)
w = display.XGetParent (WholeWindow);
Xlib.XChangeProperty (display.Handle, w,
display.Atoms._NET_WM_WINDOW_OPACITY, display.Atoms.XA_CARDINAL, 32,
PropertyMode.Replace, ref
x11_opacity, 1);
}
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [Patch] ShouldSerialize additions
Attached patch adds ShouldSerializePROPERTYNAME for several properties
in order to prevent default value serialization during design time
serialization. ChangeLog entry included. Please review.
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs (revision 82206)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs (working copy)
@@ -2049,7 +2049,7 @@
#if NET_2_0
[Browsable (false)]
- [DefaultValue ({X=0,Y=0})]
+ [DefaultValue (typeof (Point), 0, 0)]
[EditorBrowsable (EditorBrowsableState.Advanced)]
public virtual Point AutoScrollOffset {
get {
@@ -2102,6 +2102,11 @@
}
}
+ internal bool ShouldSerializeMaximumSize ()
+ {
+ return this.MaximumSize != DefaultMaximumSize;
+ }
+
public virtual Size MinimumSize {
get {
return minimum_size;
@@ -2113,6 +2118,11 @@
}
}
}
+
+ internal bool ShouldSerializeMinimumSize ()
+ {
+ return this.MinimumSize != DefaultMinimumSize;
+ }
#endif // NET_2_0
[DispId(-501)]
@@ -2144,6 +2154,11 @@
}
}
+ internal bool ShouldSerializeBackColor ()
+ {
+ return this.BackColor != DefaultBackColor;
+ }
+
[Localizable(true)]
[DefaultValue(null)]
[MWFCategory(Appearance)]
@@ -2460,6 +2475,10 @@
}
}
+ internal bool ShouldSerializeCursor ()
+ {
+ return this.Cursor != Cursors.Default;
+ }
[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
[ParenthesizePropertyName(true)]
@@ -2596,6 +2615,11 @@
}
}
+ internal bool ShouldSerializeEnabled ()
+ {
+ return this.Enabled != true;
+ }
+
[EditorBrowsable(EditorBrowsableState.Advanced)]
[Browsable(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
@@ -2635,6 +2659,11 @@
}
}
+ internal bool ShouldSerializeFont ()
+ {
+ return !this.Font.Equals (DefaultFont);
+ }
+
[DispId(-513)]
[MWFCategory(Appearance)]
public virtual Color ForeColor {
@@ -2657,6 +2686,11 @@
}
}
+ internal bool ShouldSerializeForeColor ()
+ {
+ return this.ForeColor != DefaultForeColor;
+ }
+
[DispId(-515)]
[Browsable(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
@@ -2724,6 +2758,11 @@
}
}
+ internal bool ShouldSerializeImeMode ()
+ {
+ return this.ImeMode != ImeMode.NoControl;
+ }
+
[EditorBrowsable(EditorBrowsableState.Advanced)]
[Browsable(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
@@ -2822,6 +2861,11 @@
}
}
+ internal bool ShouldSerializeLocation ()
+ {
+ return this.Location != new Point (0, 0);
+ }
+
#if NET_2_0
[Localizable (true)]
public Padding Margin {
@@ -2833,6 +2877,11 @@
}
}
}
+
+ internal bool ShouldSerializeMargin ()
+ {
+ return this.Margin != DefaultMargin;
+ }
#endif
[Browsable(false)]
@@ -2866,6 +2915,11 @@
}
}
}
+
+ internal bool ShouldSerializePadding ()
+ {
+ return this.Padding != DefaultPadding;
+ }
#endif
[Browsable(false)]
@@ -2996,6 +3050,11 @@
}
}
+ internal bool ShouldSerializeRightToLeft ()
+ {
+ return this.RightToLeft != RightToLeft.No;
+ }
+
[EditorBrowsable(EditorBrowsableState.Advanced)]
public override ISite Site {
get {
@@ -3017,6 +3076,11 @@
}
}
+ internal bool ShouldSerializeSite ()
+ {
+ return false;
+ }
+
[Localizable(true)]
[MWFCategory(Layout)]
public Size Size {
@@ -3029,6 +3093,11 @@
}
}
+ internal virtual bool ShouldSerializeSize ()
+ {
+ return this.Size != DefaultSize;
+ }
+
[Localizable(true)]
[MergableProperty(false)]
[MWFCategory(Behavior)]
@@ -3101,7 +3170,7 @@
}
}
}
-
+
internal virtual void UpdateWindowText ()
{
if (!IsHandleCreated) {
@@ -3177,6 +3246,11 @@
}
}
+ internal bool ShouldSerializeVisible ()
+ {
+ return this.Visible != true;
+ }
+
[EditorBrowsable(EditorBrowsableState.Always)]
[Browsable(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/ButtonBase.cs
===
--- mcs/class/Managed.Windows.Forms/System.Windows.Forms/ButtonBase.cs (revision 82206)
+++ mcs/class/Managed.Windows.Forms/System.Windows.Forms/ButtonBase.cs (working copy)
@@ -209,6 +209,11 @@
}
}
+ internal bool ShouldSerializeImage ()
+ {
+ return this.Image != null;
+ }
+
[Localizable(true)]
[DefaultValue(ContentAlignment.MiddleCenter)]
[MWFDescription(Sets the alignment of the image to be displayed on button face), MWFCategory(Appearance)]
Index: mcs/class/Managed.Windows.Forms/System.Windows.Forms/ChangeLog
