Re: [Mono-winforms-list] Odd StatusStrip.PreferredSize behavior
Hello, This seems to be a bug in our implementation. If you provide a test case (a small one ideally) we can try to figure out what's happening. Carlos. 2010/5/17 Mike Fried michaelbfr...@gmail.com I'm writing a program under Windows in Visual Studio (2008, switching to 2010 soon) that will target Linux using Windows Forms and .NET Framework/CLR 2, but I started testing under Mono and making changes to work around issues in Mono and in Mono under Linux only recently (using Ubuntu 10.4 and SUSE). I discovered a bunch of bugs that don't reproduce on Windows, many of which I could simply work around by switching off the System.Environment variable or working around in trivial ways, but I'm looking for a better solution in particular for one bug. The current bug that's biting me is that in a custom editor that I have written, I perform manual layout of the scrollbars and status bar, but when I go to get the PreferredSize from the StatusStrip in Mono (Windows and Linux), it returns (22, Height) and in .NET it returns (Width, 22). I took a peek at the source code to the Mono 2.6.4 branch of StatusStriphttp://anonsvn.mono-project.com/viewvc/branches/mono-2-6-4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/StatusStrip.cs?revision=155916sortby=fileand ToolStriphttp://anonsvn.mono-project.com/viewvc/branches/mono-2-6-4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ToolStrip.cs?revision=155916sortby=file to try and understand what's going on, and I tried a number of things without making some kind of test against the width or height to work around the preferred size being wrong, but I couldn't get the desired behavior. I've searched the web without finding anything else about this. Is this a known issue? Does anyone have any alternative APIs that they suggest I use instead? I'd like to fix this code and move on so that regardless of what kind of Fix mono takes later, it won't break my code in the future. Thanks, Mike Fried ___ 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
Re: [Mono-winforms-list] TreeView.TreeViewNodeSorter seem to have no effect
Hey!
This should be fixed in rev 155655 (svn).
Thanks,
Carlos.
2010/3/24 Latif Khalifa lati...@radegastclient.org
I finally managed to figure out under what circumstances the bug
shows. I have a single root node, creatively labeled root. In that
case TreeView ignores the sorter and sorts alphabetically. Here is my
simple Compare() that is supposed to sort nodes in reverse
alphabetical order:
public class SorterClass : System.Collections.IComparer
{
public int Compare(object a, object b)
{
int res = string.Compare(((TreeNode)a).Text,
((TreeNode)b).Text);
res *= -1;
return res;
}
}
And here is a short example that creates TreeView:
invTree = new TreeView();
invTree.Dock = DockStyle.Fill;
invTree.TreeViewNodeSorter = new SorterClass();
Controls.Add(invTree);
TreeNode root = new TreeNode(My root);
invTree.Nodes.Add(root);
for (char c = 'A'; c = 'Z'; c++)
{
TreeNode n = new TreeNode();
n.Text = c.ToString();
n.Name = c.ToString();
for (int i=0; i20; i++)
{
TreeNode inside = new TreeNode(i.ToString());
n.Nodes.Add(inside);
}
root.Nodes.Add(n);
}
invTree.Sort();
Two observed behaviors differ from .net
1) Bug, Setting TreeViewNodeSorter has no effect if there is only one
top level node. (actually it does have an effect of turning on
sorting, just that the Compare() is never called and sorting is done
by a default system function).
2) Different behavior. On Windows under .NET one does not need to
explicitly call Sort(). Nodes are sorted as they are inserted.
Latif
On Tue, Mar 23, 2010 at 7:03 PM, Carlos Alberto Cortez
calberto.cor...@gmail.com wrote:
Hey!
I tested this on those same versions, and I cannot get the error. Could
you
cook a small test case?
Carlos.
2010/3/23 Latif Khalifa lati...@radegastclient.org
Hello,
I have had this problem with both 2.4.2.3 and 2.6.3. Identical code
works on .net side, in mono's TreeView sorting is always alphabetic
and my Compare() never gets called.
Latif
On Tue, Mar 23, 2010 at 4:00 PM, Carlos Alberto Cortez
calberto.cor...@gmail.com wrote:
Hey,
This should be working. Maybe you hit a bug, but it seems, based on
the
other information, that you are using an old version. Take a look at
that
and let us know.
Carlos.
2010/3/23 Latif Khalifa lati...@radegastclient.org
Hi,
I'm trying to cure a few last quirks an an application I'm porting
from windows. The problem I'm having is that setting
TreeView.TreeViewNodeSorter seem to have no effect. The nodes gets
sorted alphabetically and Compare() in my IComparer class never gets
called. Any ideas?
Also TreeView seem to be missing [+] and [-] images next to the nodes
that can be expanded and collapsed.
Latif
___
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
Re: [Mono-winforms-list] Transparency Problem
Hey, On my machine (openSuse 11.1) using 2.4/2.6 series it works fine. Basically our code tries to detect a property in the window manager to detect whether there's transparency support or not. So it should work *at least* in Linux. Could you elaborate more so we can try to figure out what's happening? Carlos. 2010/4/3 Natalia Portillo clau...@claunia.com I had the same problem. Tried in Mac OS X (both Carbon and X11), no success. Of course both Carbon and X11 do support transparency, overlays and OpenGL (AGL and XGL respectively). Tried in Linux, no success. KDE4 transparencies and effects are working. The X.Org configuration file contains the values indicated by Mono documentation. I found no solution at all. El 03/04/2010, a las 14:13, Tommi Laukkanen escribió: Hi I think X-window also has some options which affect the transparency support. You might need to enable transparency supporting window manager / theme to be able to use transparencies. -tommi On Sat, Apr 3, 2010 at 3:39 PM, Stefano Del Furia de...@edudotnet.itwrote: HI, i have found that the Opacity works if the graphic card support 3d acceleration, but i haven'r find any way of getting TransparencyKey to works. Is this feature has been implemented in Winforms or not ?? Thanks in advance Stefano ___ 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 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
Re: [Mono-winforms-list] TreeView.TreeViewNodeSorter seem to have no effect
Hey, This should be working. Maybe you hit a bug, but it seems, based on the other information, that you are using an old version. Take a look at that and let us know. Carlos. 2010/3/23 Latif Khalifa lati...@radegastclient.org Hi, I'm trying to cure a few last quirks an an application I'm porting from windows. The problem I'm having is that setting TreeView.TreeViewNodeSorter seem to have no effect. The nodes gets sorted alphabetically and Compare() in my IComparer class never gets called. Any ideas? Also TreeView seem to be missing [+] and [-] images next to the nodes that can be expanded and collapsed. Latif ___ 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
Re: [Mono-winforms-list] TreeView.TreeViewNodeSorter seem to have no effect
Hey! I tested this on those same versions, and I cannot get the error. Could you cook a small test case? Carlos. 2010/3/23 Latif Khalifa lati...@radegastclient.org Hello, I have had this problem with both 2.4.2.3 and 2.6.3. Identical code works on .net side, in mono's TreeView sorting is always alphabetic and my Compare() never gets called. Latif On Tue, Mar 23, 2010 at 4:00 PM, Carlos Alberto Cortez calberto.cor...@gmail.com wrote: Hey, This should be working. Maybe you hit a bug, but it seems, based on the other information, that you are using an old version. Take a look at that and let us know. Carlos. 2010/3/23 Latif Khalifa lati...@radegastclient.org Hi, I'm trying to cure a few last quirks an an application I'm porting from windows. The problem I'm having is that setting TreeView.TreeViewNodeSorter seem to have no effect. The nodes gets sorted alphabetically and Compare() in my IComparer class never gets called. Any ideas? Also TreeView seem to be missing [+] and [-] images next to the nodes that can be expanded and collapsed. Latif ___ 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
Re: [Mono-winforms-list] Wrong icons on OpenSuse, right on Ubuntu
Hey Pablo, What version of OpenSuse are you using? I'm trying 11.1 and it's working fine. Also, any chance to attach a screenshot? Carlos. 2010/3/1 pablosantosl...@terra.es pablosantosl...@terra.es Hi there, We're experiencing some graphical issues with Plastic on OpenSuse (latest) while they work well on Ubuntu (latest). Message boxes (and dialogs) without icon (we don't set them) show up without icon on Ubuntu (as they do on Windows) but display a weird default one on OpenSuse. Any idea why? Thanks, pablo ___ 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
Re: [Mono-winforms-list] TextBox bugs
Hey Dick! I will take a look at them this weekend. Carlos. 2010/2/26 Dick Porter dpor...@codicesoftware.com Hi all I recently submitted a couple of bugs to do with keyboard handling in TextBox: https://bugzilla.novell.com/show_bug.cgi?id=582691 - Return key works intermittently in TextBox https://bugzilla.novell.com/show_bug.cgi?id=582703 - Pressing Command key in TextBox activates context menu but does not show it The second one is especially irritating when it happens, as it can delete the entire contents of the TextBox. Is anyone looking at these? If not, can anyone give me some pointers as to where I might start trying to fix them myself? I've figured out what I think are the causes, but I'm now at a dead-end in the depths of the MWF code. Thanks, - Dick ___ 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
Re: [Mono-winforms-list] Runtime error accessing Icons in Resources
This seems to be a resources issue. Would it be possible to get the code producing this error, so we could test what's happening? Carlos. 2010/1/18 georgec giorgos.constanti...@gmail.com The following code is running fine on .NET but produces a runtime error with Mono: 1: relationsTreeView.ImageList = new ImageList(); 2: relationsTreeView.ImageList.Images.Add(Resources.nodeIcon); This error exists in all the cases that I reference images and icons from the Resources as specified in VS 2008. Is there something that I am missing? (also MoMA did not find any problems with my code compatibility on mono) The following error is reported: Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.ComponentModel.Win32Exce ption: No valid icon entry were found. at System.Drawing.Icon.InitFromStreamWithSize (System.IO.Stream stream, Int32 width, Int32 height) [0x0056e] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4.2 .3\mcs\class\System.Drawing\System.Drawing\Icon.cs:807 at System.Drawing.Icon..ctor (System.Runtime.Serialization.SerializationInfo i nfo, StreamingContext context) [0x000b2] in C:\cygwin\tmp\monobuild\build\BUILD\ mono-2.4.2.3\mcs\class\System.Drawing\System.Drawing\Icon.cs:229 at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (o bject,object[],System.Exception) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invok eAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globa lization.CultureInfo culture) [0x000a6] in C:\cygwin\tmp\monobuild\build\BUILD\m ono-2.4.2.3\mcs\class\corlib\System.Reflection\MonoMethod.cs:444 --- End of inner exception stack trace --- at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invok eAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globa lization.CultureInfo culture) [0x000b8] in C:\cygwin\tmp\monobuild\build\BUILD\m ono-2.4.2.3\mcs\class\corlib\System.Reflection\MonoMethod.cs:450 at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] par ameters) [0x0] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4.2.3\mcs\class \corlib\System.Reflection\MethodBase.cs:111 at System.Runtime.Serialization.ObjectRecord.LoadData (System.Runtime.Serializ ation.ObjectManager manager, ISurrogateSelector selector, StreamingContext conte xt) [0x000d7] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4.2.3\mcs\class\corl ib\System.Runtime.Serialization\ObjectManager.cs:578 at System.Runtime.Serialization.ObjectManager.DoFixups () [0x00066] in C:\cygw in\tmp\monobuild\build\BUILD\mono-2.4.2.3\mcs\class\corlib\System.Runtime.Serial ization\ObjectManager.cs:84 at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadNextObject (System.IO.BinaryReader reader) [0xf] in C:\cygwin\tmp\monobuild\build\BUILD \mono-2.4.2.3\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\Ob jectReader.cs:115 at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectGraph (System.IO.BinaryReader reader, Boolean readHeaders, System.Object result, Sys tem.Runtime.Remoting.Messaging.Header[] headers) [0x00041] in C:\cygwin\tmp\mon obuild\build\BUILD\mono-2.4.2.3\mcs\class\corlib\ System.Runtime.Serialization.Fo rmatters.Binary\ObjectReader.cs:99 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeser ialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging. HeaderHandler handler) [0x00076] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4 .2.3\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\BinaryForma tter.cs:177 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream) [0x0] in C:\cygwin\tmp\monobuild\buil d\BUILD\mono-2.4.2.3\mcs\class\corlib\ System.Runtime.Serialization.Formatters.Bi nary\BinaryFormatter.cs:134 at System.Resources.ResourceReader.ReadNonPredefinedValue (System.Type exp_typ e) [0x0] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4.2.3\mcs\class\corli b\System.Resources\ResourceReader.cs:397 at System.Resources.ResourceReader.ReadValueVer2 (Int32 type_index) [0x001f3] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4.2.3\mcs\class\corlib\System.Reso urces\ResourceReader.cs:355 at System.Resources.ResourceReader.LoadResourceValues (.ResourceCacheItem[] st ore) [0x00076] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4.2.3\mcs\class\cor lib\System.Resources\ResourceReader.cs:433 at System.Resources.ResourceReader+ResourceEnumerator.FillCache () [0x00049] i n C:\cygwin\tmp\monobuild\build\BUILD\mono-2.4.2.3\mcs\class\corlib\System.Resou rces\ResourceReader.cs:686 at System.Resources.ResourceReader+ResourceEnumerator..ctor (System.Resources. ResourceReader
Re: [Mono-winforms-list] Native Menu Bars in Winforms on OSX
The support for this hasn't been implemented in winforms, and we don't have plans to implement it in a near future. Patches are accepted, however ;-) Carlos. 2010/1/20 Daniel Rosenstark dr.public.dev...@confusionists.com I think I may have asked this before: it is totally absurd that Winforms apps should run on OSX without being able to have normal menu bars like every other application. Even in Java I've managed to do this http://stackoverflow.com/questions/2061194/swing-on-osx-how-to-trap-command-q and I know that GTK# apps do it. How can I do this on Winforms? ___ 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
Re: [Mono-winforms-list] gnome white font color and mono WinForm issue..
We had an issue but it was only happening for ToolStrip menus. Is that the case, or is it happening with other controls as well? I remember testing extensively with dark themes and the only issue was related to ToolStrip (which has been fixed in 2.4/2.6/trunk, but didn't make it in the version you have). As Stifu mentioned, you can force the controls using the ForeColor property (that applies as well for ToolStrip). Otherwise, there's no way to force our theme engine to *not* detect the system colors unfortunately (given a gnome session running). Carlos. 2010/1/7 buhochile...@gmail.com buhochil...@gmail.com Hi guys, I have strage behaviour of mono Winform in a gnome theme that put most of the font colour used by the system in white. The gnome theme is mostly black, so all of the fonts in the desktop are white (gnome bar, menus and so on...), the problem is when I run a mono winform app, since the mono winform windows don't take the gnome theme (it don't get blackish it keeps the regular winform colors), but the winform fonts it do take the white colour of the gnome theme and of course white on a gray winfor window is hard to see/read... So, I know that mono winform currently don't apply the gnome theme, that's ok, but I want that the winform don't take the font color neither to keep the regular black font color in the gray winform window. any way to chage/force that?, or I forced to use a black font theme...? I currently using mono and libgdiplus at version 2.4.2-3 on a fedora 12 machine... Thanks. Mauricio P.S: Please don't tell me to update to mono 2.6 to see if is fixed :-) ___ 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
Re: [Mono-winforms-list] gnome white font color and mono WinForm issue..
Not in the last release sadly, as it was committed after the release. So I take for granted is only happening with ToolStrip? One possible workaround is to set DESKTOP_SESSION to any string starting with 'KDE' - this way our theme engine will try to detect the KDE settings (will print a warning if it couldn't find the libs). This way the winforms app will not be loading the gnome settings, and it should work 'fine' (remember to set this env var only in the terminal where you execute your winforms app ;-) ) Try something like: env DESKTOP_SESSION=KDE mono MyApp.exe Carlos. 2010/1/7 buhochile...@gmail.com buhochil...@gmail.com On 01/07/2010 11:05 AM, Carlos Alberto Cortez wrote: We had an issue but it was only happening for ToolStrip menus. Is that the case, or is it happening with other controls as well? yeap, all kind of winform controls like texboxes, menus, labels, etc... I remember testing extensively with dark themes and the only issue was related to ToolStrip (which has been fixed in 2.4/2.6/trunk, but didn't make it in the version you have). As Stifu mentioned, you can force the controls using the ForeColor property (that applies as well for ToolStrip). Otherwise, there's no way to force our theme engine to *not* detect the system colors unfortunately (given a gnome session running). sadly is a complex and large app to change the code to force a forecolor, and is not ideal to change the code just for that since the current code works ok on windows with .net and themes, so it going to need compiler conditions, etc.. So, this supose to be fixed in mono 2.6 then? thanks Mauricio Carlos. 2010/1/7 buhochile...@gmail.com buhochil...@gmail.com Hi guys, I have strage behaviour of mono Winform in a gnome theme that put most of the font colour used by the system in white. The gnome theme is mostly black, so all of the fonts in the desktop are white (gnome bar, menus and so on...), the problem is when I run a mono winform app, since the mono winform windows don't take the gnome theme (it don't get blackish it keeps the regular winform colors), but the winform fonts it do take the white colour of the gnome theme and of course white on a gray winfor window is hard to see/read... So, I know that mono winform currently don't apply the gnome theme, that's ok, but I want that the winform don't take the font color neither to keep the regular black font color in the gray winform window. any way to chage/force that?, or I forced to use a black font theme...? I currently using mono and libgdiplus at version 2.4.2-3 on a fedora 12 machine... Thanks. Mauricio P.S: Please don't tell me to update to mono 2.6 to see if is fixed :-) ___ 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 maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] gnome white font color and mono WinForm issue..
Ah! I missed that info.
Buho: would you mind supplying the dark theme you are using? I already tried
several dark themes from art.gnome.org and the only control having issues
was ToolStrip.
Carlos.
2010/1/7 Stifu st...@free.fr
Mauricio: you could just add a runtime condition.
Like: if (Type.GetType(System.MonoType, false) != null) { Form1.ForeColor
= Color.Black; }
Carlos: not just the ToolStrip, from what he says, but all controls.
Carlos Alberto wrote:
Not in the last release sadly, as it was committed after the release. So
I
take for granted is only happening with ToolStrip?
One possible workaround is to set DESKTOP_SESSION to any string starting
with 'KDE' - this way our theme engine will try to detect the KDE
settings
(will print a warning if it couldn't find the libs). This way the
winforms
app will not be loading the gnome settings, and it should work 'fine'
(remember to set this env var only in the terminal where you execute your
winforms app ;-) ) Try something like:
env DESKTOP_SESSION=KDE mono MyApp.exe
Carlos.
2010/1/7 buhochile...@gmail.com buhochil...@gmail.com
On 01/07/2010 11:05 AM, Carlos Alberto Cortez wrote:
We had an issue but it was only happening for ToolStrip menus. Is that
the
case, or is it happening with other controls as well?
yeap, all kind of winform controls like texboxes, menus, labels, etc...
I remember testing extensively with dark themes and the only issue was
related to ToolStrip (which has been fixed in 2.4/2.6/trunk, but didn't
make
it in the version you have).
As Stifu mentioned, you can force the controls using the ForeColor
property
(that applies as well for ToolStrip). Otherwise, there's no way to force
our
theme engine to *not* detect the system colors unfortunately (given a
gnome
session running).
sadly is a complex and large app to change the code to force a
forecolor,
and is not ideal to change the code just for that since the current code
works ok on windows with .net and themes, so it going to need compiler
conditions, etc..
So, this supose to be fixed in mono 2.6 then?
thanks
Mauricio
Carlos.
2010/1/7 buhochile...@gmail.com buhochil...@gmail.com
Hi guys,
I have strage behaviour of mono Winform in a gnome theme that put most
of
the font colour used by the system in white.
The gnome theme is mostly black, so all of the fonts in the desktop are
white (gnome bar, menus and so on...), the problem is when I run a mono
winform app, since the mono winform windows don't take the gnome theme
(it
don't get blackish it keeps the regular winform colors), but the
winform
fonts it do take the white colour of the gnome theme and of course
white
on
a gray winfor window is hard to see/read...
So, I know that mono winform currently don't apply the gnome theme,
that's
ok, but I want that the winform don't take the font color neither to
keep
the regular black font color in the gray winform window.
any way to chage/force that?, or I forced to use a black font theme...?
I currently using mono and libgdiplus at version 2.4.2-3 on a fedora 12
machine...
Thanks.
Mauricio
P.S: Please don't tell me to update to mono 2.6 to see if is fixed :-)
___
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 maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
--
View this message in context:
http://old.nabble.com/gnome-white-font-color-and-mono-WinForm-issue..-tp27060097p27060992.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
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] menustrip
With Mono 2.4/2.6/trunk it's working fine. Please update.
Carlos.
2009/12/14 andi ari twentyfirsta...@gmail.com
Hi All,
My name is Andi. Im a newbie
it tried to run some lines of c# code using monodevelp on Ubuntu 8.10. Here
are the codes
using System;
using System.Drawing;
using System.Windows.Forms;
class MForm : Form {
public MForm() {
Text = Submenu;
MenuStrip ms = new MenuStrip();
ms.Parent = this;
ToolStripMenuItem file = new ToolStripMenuItem(File);
ToolStripMenuItem exit = new ToolStripMenuItem(Exit, null,
new EventHandler(OnExit));
ToolStripMenuItem import = new ToolStripMenuItem();
import.Text = Import;
file.DropDownItems.Add(import);
ToolStripMenuItem temp = new ToolStripMenuItem();
temp.Text = Import newsfeed list...;
import.DropDownItems.Add(temp);
temp = new ToolStripMenuItem();
temp.Text = Import bookmarks...;
import.DropDownItems.Add(temp);
temp = new ToolStripMenuItem();
temp.Text = Import mail...;
import.DropDownItems.Add(temp);
file.DropDownItems.Add(exit);
ms.Items.Add(file);
MainMenuStrip = ms;
Size = new Size(380, 200);
CenterToScreen();
}
void OnExit(object sender, EventArgs e) {
Close();
}
}
class MApplication {
public static void Main() {
Application.Run(new MForm());
}
}
The result should appear like this:
[image:
?ui=2view=attth=1258c0e8656b53f6attid=0.1disp=attdrealattid=ii_1258c0e8656b53f6zw]
but in my machine the result didn't appear as it should be. here is the
result of the code in my machine :
[image:
?ui=2view=attth=1258c10c352b0e0cattid=0.1disp=attdrealattid=ii_1258c10c352b0e0czw]
it seems that there is trouble with the font. how do I solve this problem?
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Screenshot-Submenu.pngsubmenu.png___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Some Winforms Questions
Hey! I'm not our OSX expert, so I will leave those questions unanswered. 3) The RichTextEditor in Winforms on Mono is mostly useless. Does GTK# provide something better? Or can anyone recommend any libraries for Winforms? I actually don't need richtext, but I do need undo, hyperlinks, indenting and bullets What are the issues you were/are getting with RichTextBox? I fixed some stuff there some months ago, so it should be working better now. Anyway, it you find any error, please report it so we can fix it. 5) What is the present/future of Winforms on Mono for IPhone? Android? No plans on the mobile segment for now. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Using Windows Forms over Linux
Hey, There are some limitations on our implementation of Windows.Forms, just as any other re-implementation can have. We provide it however, to let developers to bring their applications from .net to linux with Mono. Now: if you are going to create a new app, then you can go with Gtk#, and that's a different story, with its own advantages/disadvantages. Carlos. 2009/11/18 StApostol stapos...@gmail.com Frankly, the best way to create a cross-platform GUI is to use GTK# from the beginning. With WinForms, you'll encounter several issues that will make things rather difficult down the road: flaky databinding, slow rendering (especially for grid views), inconsistent rendering between versions, inconsistent ordering of events (quite, eh, fun to debug), lack of theming. By far the best solution is to abstract the GUI away from the main application and use different technologies for different platforms (e.g. WPF on Windows, GTK# on Linux and Mac OS X). However, this takes a lot of resources and planning to implement correctly. The second best option is to use GTK# all the way. You'll trade some of the native look and feel for easier development (see e.g. MonoDevelop on Windows). The third option is to use WinForms everywhere, keeping in mind the caveats I mentioned. WinForms is not meant for cross-platform development - it has no native look and feel (unless you create custom widgets for everything, which is certainly an option) and it is painful even on Windows (try using native Vista fonts, for example or creating a DPI-independent GUI - that's right, you can't really do that). Finally, it's a pretty much dead technology that hasn't been updated in the last 5 years. (Yes, there are still good reasons for using it, as long as you keep the drawbacks in mind). Finally, it might be worth checking out Silverlight/Moonlight. These have a pretty nice development environment and can be used both online and offline (with a little work). My 2cc :) 2009/11/18 Petit Eric surfz...@gmail.com 2009/11/18 Dimitris Karantonis dkaranto...@soft4real.com: Hi, This is an interesting solution, but does it actually works? And what about maintenance through the application's lifecycle? Meaning, how do you handle situations when you want to add a new event? It work, i don't really practice it for professional, most for hobbies. I often hack by the hand the .Designer.cs file, rather restart a VM. Does Mono opens Visual Studio solutions and furthermore, does it compile Window Forms properties like anchoring, docking, etc... Compile is most good What about installing Win Forms Designer kit on your MonoProject IDE? Have you ever thought of this? I would like a winforms designer in MonoDevelop, Ivanz started working on it but http://www.mono-project.com/WinForms_Designer http://www.mono-project.com/WinForms http://www.mono-project.com/Guide:_Porting_Winforms_Applications http://www.mono-project.com/Category:WinForms Regards, Dimitris -Original Message- From: Petit Eric [mailto:surfz...@gmail.com] Sent: Τετάρτη, 18 Νοεμβρίου 2009 12:28 To: Dimitris Karantonis Cc: Mono-winforms-list@lists.ximian.com Subject: Re: [Mono-winforms-list] Using Windows Forms over Linux To write MonoOSC, i used VS C# express to design my winforms and generate needed event (through an VBox machine) and then i wrote all code/class with MonoDevelop under Linux :-) 2009/11/18 Dimitris Karantonis dkaranto...@soft4real.com: Hi to all, I am new to .net development over Linux platforms (I have always used MS Visual Studio platform) and I would like to ask what is the best way of implementing a Window Forms application in order to be able to deploy it on both Windows and Linux OS. 1) Should i use MS visual Studio 2008 on my Windows Machine to develop the application and then use some tool in order to migrate the application to the Mono format? 2) Should i use a Mono plug-in for the MS Visual Studio platform and develop the application? 3) Should I use MonoDevelop on my Linux machine and install the Win Forms Designer toolkit? Could you give me some advices concerning what is the best way to follow and some instructions of how to implement it (meaning, instructions of how to install and use the Visual Studio - Mono migration tool, the Mono plug-in for VS Studio and the Win Forms Designer toolkit on MonoDevelop. Best regards, Dimitris ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list -- Cordially. Small Eric Quotations of the days: --- I have no special talents. I am only passionately curious -- Cordially. Small Eric Quotations of
Re: [Mono-winforms-list] [PATCH] For MouseClick Event in SWF
Hey, I will review the patch later, but there's no need to send the patch to the mono develop list, since the change is related to windows.forms. Also, the mono-patches list is used to receive/catch the changes in svn. Next time send the patch to the winforms list, please. Carlos. 2009/10/27 Petit Eric surfz...@gmail.com Hi Mouse Click Event was missing in SWF implementation, here it is a patch to fix that [?] it is released under MIT/X11 or what ever you want. Carlos, if you apply the patch, could you think about my coding for fun and add my nickname in the log ?[?] -- Cordially. Small Eric Quotations of the days: --- I have no special talents. I am only passionately curious 329.png330.gif___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] PrintPreviewControl
As I said before, you need to print here the entire message error you are getting, so we can get an idea ;-) 2009/6/9 Jyoti Seth jyotiseth2...@gmail.com Hi All, I am trying to use PrintPreviewControl on Mono 2.4 on Suse linux. It is throwing GDI32.dll error. Libgdiplus package is already installed on the sytem. If anyone has idea about this problem please let me know. Thanks, Jyoti ___ 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
Re: [Mono-winforms-list] C# 2008 - Buttons not showing up on RHEL 5
Hey! Well, it sounds like a bug, but it sounds like an old version, too. Would you mind running mono --version? Carlos. 2009/6/4 Aatif_Chaudhry gaa...@gmail.com I have a simple form application made in C# (MS VS 2008), it has two buttons, but when I run it on RH Linux 5 through mono, the buttons are not visible on the form. What I see is two black lines which on click, initiate the respective button's event. -- View this message in context: http://www.nabble.com/C--2008---Buttons-not-showing-up-on-RHEL-5-tp23864848p23864848.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 ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] MessageDialog.Show() Wont close
I extracted this from your file:
using System;
using System.Windows.Forms;
public class Test
{
static void Main ()
{
string outputText = Succesfully STARTED MySQL CHECKER;
MessageBox.Show(outputText, SUCCES,
MessageBoxButtons.OK,
MessageBoxIcon.Information);
}
}
And it seems to work fine in trunk/2.4.
Would you mind testing this sample? Also, can you tell us what version are
you using?
Carlos.
2009/6/3 mickvdv mick...@teux.net
Hi all
I got a problem. I wrote an console app that checks if there is a new entry
in a mysql tabel. It uses a popup, MessageDialog. But if i push the OK
button the dialog wont close! When i put
Form form1 = new Form();
form1.Show();
form1.Hide();
After it the popup does close when pushing OK. But that is a littlebit
ugly%-|
The code:
Without the form option
http://pastebin.com/f59a267b8
Using the form option
http://pastebin.com/f2416633a
Is this a bug or am I just being stupid (or both:P)?
Mickvdv
--
View this message in context:
http://www.nabble.com/MessageDialog.Show%28%29-Wont-close-tp23857718p23857718.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
___
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
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-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
Re: [Mono-winforms-list] Clipboard.SetDataObject() doing nothing
I already did some refactoring code to handle formats other than text, we
only need to copy the information just as other x11 applications do that :-)
But anyway, feel free to send (me) those notes as well :-)
Carlos.
2009/5/24 Ivan N. Zlatev cont...@i-nz.net
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-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
--
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] [PATCH] System.Windows.Forms.Form ControlBox bug
Hey! Would it be possible to fill a bug report with the attached patch, so we don't forget about it? Thanks! Carlos. 2009/5/22 Lachlan Keown lachlanke...@gmail.com Hi, I've been working on getting my Windows Forms app to work under Mono and finding a few bugs along the way... This one relates to the ControlBox property of the Form class. When ControlBox is set to false, the form should have a title bar only if the Text property is not empty. So whenever the Text or Controlbox properties change this needs to be tested for and the Window size adjusted accordingly. See the attached patch, which is probably overkill. I haven't written or run any tests for this sorry as I'm still getting familiar with the Mono environment. Lachlan Keown ___ 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
Re: [Mono-winforms-list] Problems WinForms in Linux
I filled a new bug report regarding your application's issue: https://bugzilla.novell.com/show_bug.cgi?id=498963 Thanks! Carlos. 2009/4/27 v567 viv...@yandex.ru MSI MegaBook M510A (CPU Intel Pentium-M 1.7 Gb, Memory 2 Ggb, ATI Mobility Radeon 9700 64 Mb) test.exe: 1. XP SP2 .NET FrameWork 2.0 - 4.3 sek 2. XP SP2 mono 2.4 - 7.7 sek 3. OpenSUSE 11.1 (Gnome) Mono 2.4 - 494.2 sek Why?:confused: Code: http://www.nabble.com/file/p23262446/Test.zip Test.zip Source: http://www.nabble.com/file/p23262446/Test_source.zipTest_source.zip -- View this message in context: http://www.nabble.com/Problems-WinForms-in-Linux-tp23262446p23262446.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 ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Strange exception related to TableLayoutPanel?
It seems like a bug. Would you mind filling a bug with an attached test case? Thanks! 2009/4/22 noda www@free.fr Hello, I have the strange exception below that is raised when I try to create a new instance of my MainForm class (a classic windows Form): -- Exception has been thrown by the target of an invocation. at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] at System.Reflection.MonoProperty.SetValue (System.Object obj, System.Object value, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] index, System.Globalization.CultureInfo culture) [0x0] at System.Reflection.PropertyInfo.SetValue (System.Object obj, System.Object value, System.Object[] index) [0x0] at System.ComponentModel.ComponentResourceManager.ApplyResources (System.Object value, System.String objectName, System.Globalization.CultureInfo culture) [0x0] at System.ComponentModel.ComponentResourceManager.ApplyResources (System.Object value, System.String objectName) [0x0] at MAEVA.GUI.MainForm.InitializeComponent () [0x0] at MAEVA.GUI.MainForm..ctor () [0x0] at (wrapper remoting-invoke-with-check) MAEVA.GUI.MainForm:.ctor () at MAEVA.Editor.NeedReload () [0x0] -- It contains an inner exception suggesting a problem related to the TableLayoutPanel: -- LayoutSettings value cannot be set directly. at System.Windows.Forms.TableLayoutPanel.set_LayoutSettings (System.Windows.Forms.TableLayoutSettings value) [0x0] 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) [0x0] -- I'm running Mono 2.4 on windows when this exception occurs. It does not occur when using the MS .Net framework. The binary is compiled with MSVC# 2008, and the form has nothing special and was designed using the form designer of visual studio. Do you have any idea on how to resolve this problem? Or maybe it is a bug with Mono? Thanks a lot! Yohan -- View this message in context: http://www.nabble.com/Strange-exception-related-to-TableLayoutPanel--tp23172152p23172152.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 ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Very slow performance in WinForms ListView
I commited some changes some weeks ago (not available in 2.4, but they will be ready for 2.6) that improve the rendering, with less flicker changing columns width/position. But anyway, would you mind filling a bug report with a test case? There are different things that can affect the performance of the ListView, and unfortunately we don't have an universally way to make fast the ListView (such ListView.SuperFast = true). If we have a specific usage scenario, we can try to improve the performance - specially when other users have notified of the bad performance and we have tuned the performance in the past. Carlos. 2009/4/21 jyoti_C# jyoti.b.ko...@intel.com Using BeginUpdate() and EndUpdate() worked well for adding items. But, I still see very slow listview refresh when a column is resized. Do I need to capture these events and add above function calls in the event handler? Basically, the problem is that refresh of listview is very slow. Is there any solution that will fix the list view performance universally(column reszing, scrolling, coming out of screensaver etc.) and not just when I add items. Thanks. -- View this message in context: http://www.nabble.com/Very-slow-performance-in-WinForms-ListView-tp20725159p23162133.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 ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] [Patch] CausesValidation handling
On IRC Andreia pointed out the case when a Control is part of the pending
validation chain, and then this Control is removed. So the attached codes
adds the check to look for any control (or children) that could be int the
pending validation chain, and thus need to be removed (this is what .Net
does).
Comments?
Carlos.
2009/2/16 Carlos Alberto Cortez calberto.cor...@gmail.com
Hey,
The attached patch basically adds support for Control.CausesValidation,
which means that in some scenarios the validation is postponed (when
CausesValidation if false, basically).
I'm concerned -specially- about the code readibility (it also includes the
description of the algorithm in the patch). I mention this because I spent
some time trying to understand this little documented algorithm (AFAIK) and
want the code to be easily understandable.
As test I used the very complete ones in
https://bugzilla.novell.com/show_bug.cgi?id=457170 . One test is still
failing, but that's due to the controls receiving focus/validation when
closing (which needs to be fixed too, but it's a little different issue).
Carlos.
Index: ContainerControl.cs
===
--- ContainerControl.cs (revisión: 129872)
+++ ContainerControl.cs (copia de trabajo)
@@ -39,6 +39,7 @@
public class ContainerControl : ScrollableControl, IContainerControl {
private Control active_control;
private Control unvalidated_control;
+ private ArrayList pending_validation_chain;
// This is an internal hack that allows some container controls
// to not auto select their child when they are activated
@@ -139,15 +140,33 @@
walk = walk.Parent;
}
-validation_failed = false;
-for (int i = 0; i validation_chain.Count; i ++) {
- if (!ValidateControl ((Control)validation_chain[i])) {
- active_control = value = (Control)validation_chain[i];
- fire_enter = true;
- validation_failed = true;
+// Validation can be postponed due to all the controls
+// in the enter chain not causing validation. If we don't have any
+// enter chain, it means that the selected control is a child and then
+// we need to validate the controls anyway
+bool postpone_validation;
+Control topmost_under_root = null; // topmost under root, in the *enter* chain
+if (value == root)
+ postpone_validation = false;
+else {
+ postpone_validation = true;
+ walk = value;
+ while (walk != root walk != null) {
+ if (walk.CausesValidation)
+ postpone_validation = false;
+
+ topmost_under_root = walk;
+ walk = walk.Parent;
}
}
+Control failed_validation_control = PerformValidation (form == null ? this : form, postpone_validation,
+ validation_chain, topmost_under_root);
+if (failed_validation_control != null) {
+ active_control = value = failed_validation_control;
+ fire_enter = true;
+}
+
if (fire_enter) {
walk = value;
while (walk != root walk != null) {
@@ -196,6 +215,72 @@
}
}
+ // Return the control where validation failed, and null otherwise
+ // @topmost_under_root is the control under the root in the enter chain, if any
+ //
+ // The process of validation happens as described:
+ //
+ // 1. Iterate over the nodes in the enter chain (walk down), looking for any node
+ // causing validation. If we can't find any, don't validate the current validation chain, but postpone it,
+ // saving it in the top_container.pending_validation_chain field, since we need to keep track of it later.
+ // If we have a previous pending_validation_chain, add the new nodes, making sure they are not repeated
+ // (this is computed in ActiveControl and we receive if as the postpone_validation parameter).
+ //
+ // 2. If we found at least one node causing validation in the enter chain, try to validate the elements
+ // in pending_validation_chain, if any. Then continue with the ones receives as parameters.
+ //
+ // 3. Return null if all the validation performed successfully, and return the control where the validation
+ // failed otherwise.
+ //
+ private Control PerformValidation (ContainerControl top_container, bool postpone_validation, ArrayList validation_chain,
+Control topmost_under_root)
+ {
+ validation_failed = false;
+
+ if (postpone_validation) {
+AddValidationChain (top_container, validation_chain);
+return null;
+ }
+
+ // if not null, pending chain has always one element or more
+ if (top_container.pending_validation_chain != null) {
+// if the topmost node in the enter chain is exactly the topmost
+// int the validation chain, remove it, as .net does
+int last_idx = top_container.pending_validation_chain.Count - 1;
+if (topmost_under_root == top_container.pending_validation_chain [last_idx])
+ top_container.pending_validation_chain.RemoveAt (last_idx);
+
+AddValidationChain (top_container
[Mono-winforms-list] [Patch] CausesValidation handling
Hey, The attached patch basically adds support for Control.CausesValidation, which means that in some scenarios the validation is postponed (when CausesValidation if false, basically). I'm concerned -specially- about the code readibility (it also includes the description of the algorithm in the patch). I mention this because I spent some time trying to understand this little documented algorithm (AFAIK) and want the code to be easily understandable. As test I used the very complete ones in https://bugzilla.novell.com/show_bug.cgi?id=457170 . One test is still failing, but that's due to the controls receiving focus/validation when closing (which needs to be fixed too, but it's a little different issue). Carlos. container-validation.patch Description: Binary data ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Question about Linux compatibality
Yeah, VB.Net is cross platform and the .exe you get should work in Mono without problems. The difference between using VB.Net and C# is mostly the fact, as far as I know, that the first uses some additional libraries (that btw have been implemented in Mono already). If your application doesn't work, just let us know and fix a bug. Carlos. 2009/2/8 Anthony Papillion papill...@gmail.com I'm interested in Mono. I love the promise that I can really write my application once and have it be fairly cross-platform. But I have a question that I've not really found the final answer to: I write most of my code on Windows. I don't use the API and I usually use mostly the built-in controls (with the exception of a calendar control that I really like). While I like C#, I'm writing most of my code in VB and that is where my question comes in. How cross platform is VB.NET code if I'm using most stock stuff without any Win32 API calls? Will it usually compile and run or should I write all of my stuff in C#? Thanks! Anthony ___ 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
Re: [Mono-winforms-list] Can I execute the exe file of visual studio project on linux+MONO ?
Yes, you can run winforms apps in linux. Basically you take the .exe produced by Visual Studio (usually under MyProjectName/MyProjectName/bin/Release) and then you have to run it (from the console): mono MyProjectName.exe Carlos. 2009/2/3 mohammed_aid mohammed_...@yahoo.com hello everybody, this is the second day for me in this forum and really I am very happy with you all. today I have small problem which is I can't run the executable file which released by visual studio on Linux Fedora with MONO 2. is it possible to do that ? if not please suggest any solution to help me because my project was developed by visual studio and I have used winforms inside it that is way I could not modify it on MonoDevelop and I do not want to convert it to GTK# forms. thank you in advance. best regards. -- View this message in context: http://www.nabble.com/Can-I-execute-the-exe-file-of-visual-studio-project-on-linux%2BMONO---tp21823667p21823667.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 ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Treeview select bug
This sounds like a bug. Please fill a bug report. Thanks! Carlos. 2009/2/2 qed naoti...@gmail.com The Treeview control wants to select its first item when it gains focus for the first time (after the application starts running) via a mouse-click whether the user clicked on the first item or a different item. If the user did not select the first item, then the control incorrectly generates two select events, one for the first item, and another one for the actual item that the user clicked on. The .NET Treeview control does not exhibit this behavior. Version: Mono Winforms 2.2 OS: Win XP (haven't tested this on other platforms, but they possibly have this bug too) -- View this message in context: http://www.nabble.com/Treeview-%22select%22-bug-tp21784923p21784923.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 ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] works!
You should always include the error message ;-)
I suspect you are not telling the compiler to reference
System.Windows.Forms:
gmcs hello-winforms.cs -r:System.Windows.Forms
Carlos.
2008/12/9 pepe_eloy [EMAIL PROTECTED]
Thanks Andy for your help.
I ran the program as you tell me and works! This means the libraries are
installed, but why the program didn't compile?
I show the code I'm, using
//Code for hello-winforms.cs
//this file is in /home/proyectos-mono
using System;
using System.Windows.Forms;
public class HelloWorld : Form
{
static public void Main ()
{
Application.Run (new HelloWorld ());
}
public HelloWorld ()
{
Text = Hello Mono World;
}
}
Need I to specify the path of libraries?
Thanks for the help
José Eloy
--
View this message in context:
http://www.nabble.com/I-get-error-compiling-in-ubuntu-tp20786571p20921951.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
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Usercontrol inheritance not working with mono 1.2.6
Besides what Rafael mentioned, it's important to send the code, so we can test it. Carlos. 2008/11/27 Rafael Teixeira [EMAIL PROTECTED] 1.2.6 is too old, specially for WinForms. Please upgrade to 2.x. On Wed, Nov 26, 2008 at 1:14 PM, RobWeatherford [EMAIL PROTECTED] wrote: Hi, I was wondering if there is a solution to my problem. Basically I have a windows form that contains a user control, and this user control that inherits from another abstract user control. The abstract user control includes a few base / standard controls that I would like to see on all the controls I develop. When I run the form on linux using mono the base user controls do not display (i.e. they are not visible), e.g. buttons, labels etc. Only the controls on the subclass usercontrol, or the derived usercontrol are visible. This works normally on .net windows, but I am having problems with my version of mono. Has anyone seen anything like this. I am using mono 1.2.6 Much thanks, Rob -- View this message in context: http://www.nabble.com/Usercontrol-inheritance-not-working-with-mono-1.2.6-tp20702666p20702666.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 -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ 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
Re: [Mono-winforms-list] Scrolling performance isues
El dom, 10-08-2008 a las 18:55 -0700, Chris Toshok escribió: Nice. That look pretty good, with the only issue being performance over an X connection with high latency - it'll block all UI until the redraws complete. I thought that was exactly we wanted to do ;-) That said, it's definitely better than what we have now :) Ok to commit for now? Specially for 2.0 :-) Carlos. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] DataGrid
Probably it's a regression. Would you mind filling a bug report? This way we can track the error with the details. Carlos. El lun, 11-08-2008 a las 03:41 -0700, mbertoli escribió: Do anyone of you use a DataGrid in your applications? Does it work? I tried various applications on various systems and it never works. I always get the IndexOutOfRangeException when I try to add a new row. Only in the ReportBuilder compiled application founded in the vmware image downloaded from this site I've seen it works. But if I compile the source, it doesn't work. Can anyone help me, please? ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [PATCH] Avoid sending MouseEnter messages when clicking
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
Carlos.
Index: XplatUIX11.cs
===
--- XplatUIX11.cs (revisión: 110030)
+++ XplatUIX11.cs (copia de trabajo)
@@ -4009,7 +4009,7 @@
if (!hwnd.Enabled) {
goto ProcessNextMessage;
}
- if (xevent.CrossingEvent.mode != NotifyMode.NotifyNormal xevent.CrossingEvent.window != hwnd.client_window) {
+ if (xevent.CrossingEvent.mode != NotifyMode.NotifyNormal) {
goto ProcessNextMessage;
}
msg.message = Msg.WM_MOUSE_ENTER;
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] [DataGrid] System.IndexOutOfRangeException: list position
Hey, If it works on .net, and not in mono, please fill a bug report at http://mono-project.com/Bugs in the System.Windows.Forms section, so we can fix it. Thanks, Carlos. El dom, 10-08-2008 a las 00:08 -0700, mbertoli escribió: Hi, I have a simple DataGrid in which I load data from a DataSet. Data loading works fine but when I try to add a row I get a MessageBox that tells me to correct the value. Then I get this error: System.IndexOutOfRangeException: list position. Can anyone help me? Thanks, Michele Mono 1.9.1 / Suse 10.3 ___ 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
Hey Chris
Comments below.
I'm also not sure flushing the paint queue before doing the XCopyArea
(suggestion 1 above) will be enough either. It's very easy to imagine
a scenario where you're scrolling and we do another ScrollWindow
before all the GraphicsExpose events have been received. We really do
need to block things somehow. And it'll be more than just blocking
the message queue - we'll need to actually stop the thread if there's
a call to ScrollWindow (or anything else that ends up copying) until
the GraphicsExposes have been handled.
I went and began to review our code and wondering how to do it the
proper way - then went to Gtk+ scrolling code once more, and then could
see that the gtk textbox was handling the scroll itself (it seems the
algorithm is what's called 'smooth scrolling', not sure).
The idea is that after each request to scroll, they call XIfEvent to
wait for GraphicsExpose/NoExpose events on the scrolled window, blocking
the thread until they get one of them (so you can invalidate or exit the
loop), and adding a expose operation on the window.
I implemented this today for our implementation and it seems to work
just fine, and it seems it follows your idea ;-)
Take a look and tell what you think.
Carlos.
PD - The patch is a test, so needs to be beautified still ;-) But should
work.
Index: XplatUIX11.cs
===
--- XplatUIX11.cs (revisión: 109846)
+++ XplatUIX11.cs (copia de trabajo)
@@ -4860,6 +4860,33 @@
y = dest_y_return;
}
+ bool GraphicsExposePredicate (IntPtr display, ref XEvent xevent, IntPtr arg)
+ {
+ return (xevent.type == XEventName.GraphicsExpose || xevent.type == XEventName.NoExpose)
+arg == xevent.GraphicsExposeEvent.drawable;
+ }
+
+ delegate bool EventPredicate (IntPtr display, ref XEvent xevent, IntPtr arg);
+
+ void ProcessGraphicsExpose (Hwnd hwnd)
+ {
+ XEvent xevent = new XEvent ();
+ IntPtr handle = Hwnd.HandleFromObject (hwnd);
+ EventPredicate predicate = GraphicsExposePredicate;
+
+ for (;;) {
+XIfEvent (Display, ref xevent, predicate, handle);
+if (xevent.type != XEventName.GraphicsExpose)
+ break;
+
+AddExpose (hwnd, xevent.ExposeEvent.window == hwnd.ClientWindow, xevent.GraphicsExposeEvent.x, xevent.GraphicsExposeEvent.y,
+ xevent.GraphicsExposeEvent.width, xevent.GraphicsExposeEvent.height);
+
+if (xevent.GraphicsExposeEvent.count == 0)
+ break;
+ }
+ }
+
internal override void ScrollWindow(IntPtr handle, Rectangle area, int XAmount, int YAmount, bool with_children) {
Hwnd hwnd;
IntPtr gc;
@@ -4913,6 +4940,8 @@
Rectangle dirty_area = GetDirtyArea (area, dest_rect, XAmount, YAmount);
AddExpose (hwnd, true, dirty_area.X, dirty_area.Y, dirty_area.Width, dirty_area.Height);
+ ProcessGraphicsExpose (hwnd);
+
XFreeGC(DisplayHandle, gc);
}
@@ -4966,94 +4995,10 @@
visible_area.Intersect (r);
}
- // If region is null, the entire area is visible.
- // Get the area not obscured otherwise.
- Region visible_region = GetVisibleRegion (c, visible_area);
- if (visible_region != null) {
-RectangleF rectf = visible_region.GetBounds (Hwnd.GraphicsContext);
-visible_area = new Rectangle ((int) rectf.X, (int) rectf.Y,
- (int) rectf.Width, (int) rectf.Height);
-
-visible_region.Dispose ();
- }
-
visible_area.Location = c.PointToClient (visible_area.Location);
return visible_area;
}
- // Obscured area by other toplevel windows
- Region GetVisibleRegion (Control c, Rectangle visible_area)
- {
- Region visible_region = null;
- IntPtr Root;
- IntPtr Parent;
- IntPtr Children;
- int ChildCount;
-
- Control form = c.FindForm ();
- if (form == null || !form.IsHandleCreated)
-return null;
-
- Hwnd hwnd = Hwnd.GetObjectFromWindow (form.Handle);
- IntPtr form_handle = hwnd.whole_window;
-
- lock (XlibLock) {
-XQueryTree (DisplayHandle, RootWindow, out Root, out Parent, out Children, out ChildCount);
- }
-
- int intptr_size = IntPtr.Size;
- bool above = false;
-
- for (int i = 0; i ChildCount; i++) {
-IntPtr window = Marshal.ReadIntPtr (Children, i * intptr_size);
-
-XWindowAttributes win_attrs = new XWindowAttributes ();
-lock (XlibLock) {
- XGetWindowAttributes (DisplayHandle, window, ref win_attrs);
-}
-
-Rectangle win_area = new Rectangle (win_attrs.x, win_attrs.y,
- win_attrs.width, win_attrs.height);
-
-if (win_attrs.map_state != MapState.IsViewable || !win_area.IntersectsWith (visible_area))
- continue;
-
-IntPtr SubChildren;
-int SubChildCount;
-
-if (above) {
- if (visible_region == null)
- visible_region = new Region (visible_area);
-
- visible_region.Exclude (win_area);
- continue;
-}
-
-lock (XlibLock) {
- XQueryTree (DisplayHandle, window, out Root, out Parent, out SubChildren, out SubChildCount);
-}
-
-if (SubChildren !=
[Mono-winforms-list] Scrolling performance isues
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). 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). 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. 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). Hope it's clear ;-) Carlos. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [Patch] Navigation for auto complete in TextBox
Hey,
The attached patch adds support for navigation in TextBox.
It also tries to show the auto complete window when a new char has been
typed, instead of trying to do so when the Text changes. The reason is
that the auto complete window should only appear when the user types,
but not when Text is changed from code, or pasted in the TextBox;
finally, because the auto complete code can set the Text property a lot
of times.
Carlos.
Index: TextBox.cs
===
--- TextBox.cs (revisión: 107820)
+++ TextBox.cs (copia de trabajo)
@@ -59,6 +59,7 @@
private AutoCompleteMode auto_complete_mode = AutoCompleteMode.None;
private AutoCompleteSource auto_complete_source = AutoCompleteSource.None;
private AutoCompleteListBox auto_complete_listbox;
+ private string auto_complete_original_text;
private ComboBox auto_complete_cb_source;
#endif
#endregion // Variables
@@ -71,7 +72,7 @@
this.LostFocus +=new EventHandler(TextBox_LostFocus);
this.RightToLeftChanged += new EventHandler (TextBox_RightToLeftChanged);
#if NET_2_0
- TextChanged += new EventHandler (TextBox_TextChanged);
+ MouseWheel += new MouseEventHandler (TextBox_MouseWheel);
#endif
BackColor = SystemColors.Window;
@@ -121,12 +122,27 @@
}
#if NET_2_0
- void TextBox_TextChanged (object o, EventArgs args)
+ private void TextBox_MouseWheel (object o, MouseEventArgs args)
{
+ if (auto_complete_listbox == null || !auto_complete_listbox.Visible)
+return;
+
+ int lines = args.Delta / 120;
+ auto_complete_listbox.Scroll (-lines);
+ }
+
+ private void ShowAutoCompleteListBox ()
+ {
if (auto_complete_mode == AutoCompleteMode.None || auto_complete_source == AutoCompleteSource.None)
return;
- // We only support CustomSource by now
+ //
+ // We only support CustomSource *and* Suggest mode by now
+ //
+
+ if (auto_complete_mode != AutoCompleteMode.Suggest)
+return;
+
IList source;
if (auto_complete_cb_source == null)
source = auto_complete_custom_source;
@@ -146,12 +162,6 @@
if (auto_complete_listbox == null)
auto_complete_listbox = new AutoCompleteListBox (this);
- // If the text was just set by the auto complete listbox, ignore it
- if (auto_complete_listbox.WasTextSet) {
-auto_complete_listbox.WasTextSet = false;
-return;
- }
-
string text = Text;
auto_complete_listbox.Items.Clear ();
@@ -184,6 +194,53 @@
auto_complete_cb_source = value;
}
}
+
+ void NavigateAutoCompleteList (Keys key)
+ {
+ int index = auto_complete_listbox.HighlightedIndex;
+ if (index == -1)
+auto_complete_original_text = Text;
+
+ switch (key) {
+case Keys.Up:
+ index -= 1;
+ if (index -1)
+ index = auto_complete_listbox.Items.Count - 1;
+ break;
+case Keys.Down:
+ index += 1;
+ if (index = auto_complete_listbox.Items.Count)
+ index = -1;
+ break;
+case Keys.PageUp:
+ if (index == -1)
+ index = auto_complete_listbox.Items.Count - 1;
+ else if (index == 0)
+ index = -1;
+ else {
+ index -= auto_complete_listbox.page_size - 1;
+ if (index 0)
+ index = 0;
+ }
+ break;
+case Keys.PageDown:
+ if (index == -1)
+ index = 0;
+ else if (index == auto_complete_listbox.Items.Count - 1)
+ index = -1;
+ else {
+ index += auto_complete_listbox.page_size - 1;
+ if (index = auto_complete_listbox.Items.Count)
+ index = auto_complete_listbox.Items.Count - 1;
+ }
+ break;
+default:
+ break;
+ }
+
+ auto_complete_listbox.HighlightedIndex = index;
+ Text = index == -1 ? auto_complete_original_text : auto_complete_listbox.Items [index];
+ }
#endif
private void UpdateAlignment ()
@@ -512,6 +569,29 @@
protected override void WndProc (ref Message m)
{
switch ((Msg)m.Msg) {
+case Msg.WM_KEYDOWN:
+ if (auto_complete_listbox == null || !auto_complete_listbox.Visible)
+ break;
+
+ Keys key_data = (Keys)m.WParam.ToInt32 ();
+ switch (key_data) {
+ case Keys.Down:
+ case Keys.Up:
+ case Keys.PageDown:
+ case Keys.PageUp:
+ NavigateAutoCompleteList (key_data);
+ m.Result = IntPtr.Zero;
+ return;
+ default:
+ break;
+ }
+ break;
+case Msg.WM_CHAR:
+ // Need to call base.WndProc before to have access to
+ // the updated Text property value
+ base.WndProc (ref m);
+ ShowAutoCompleteListBox ();
+ return;
case Msg.WM_LBUTTONDOWN:
// When the textbox gets focus by LBUTTON (but not by middle or right)
// it does not do the select all / scroll thing.
@@ -636,12 +716,11 @@
Liststring items;
int top_item;
int last_item;
- int page_size;
+ internal int page_size;
int item_height;
int highlighted_index = -1;
bool user_defined_size;
bool resizing;
- bool was_text_set;
Rectangle resizer_bounds;
const
Re: [Mono-winforms-list] X11 Scrolling Regressions
This is likely caused by my last scrolling patch. I'm taking a look now, Carlos. 2008/6/4 Ivan N. Zlatev [EMAIL PROTECTED]: 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 maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [Patch] Invalidate non visible areas in scrolling
Hey Chris,
Attached is an updated patch that basically incorporates all the things
you mentioned in your last mail:
* Determines the visible rectangle, and intersects it with the required
area (this is, we copy only the visible area).
- First by determining the visible area based on its size and its
parents.
- Second, by looking for toplevel windows that intersect the window,
and excluding that area.
* Then compute the destination rectangle, by applying the
XAmount/YAmount values and intersecting it with the area passed to
ScrollWindow (thus we clip it as needed). This is the way Gdk does it.
* Finally, exclude the destination rectangle from the total requested
area, and pass it to AddExpose method.
With this patch everyting is working as expected, but I have some
issues:
* Region needs a Graphics instance to return its Bounds, which *could*
be expensive.
* After taking a look at the way scrolling is done in Gdk, it *seems*
that the Region implementation lack some of the functionality we need
(like, returning in a simple operation the Rectangles describing the
region).
Comments?
Carlos.
Index: XplatUIX11.cs
===
--- XplatUIX11.cs (revisión: 93328)
+++ XplatUIX11.cs (copia de trabajo)
@@ -4791,48 +4791,21 @@
gc = XCreateGC(DisplayHandle, hwnd.client_window, IntPtr.Zero, ref gc_values);
- int src_x, src_y;
- int dest_x, dest_y;
- int width, height;
+ Rectangle visible_rect = GetTotalVisibleArea (hwnd.client_window);
+ visible_rect.Intersect (area);
- if (YAmount 0) {
-src_y = area.Y;
-height = area.Height - YAmount;
-dest_y = area.Y + YAmount;
- }
- else {
-src_y = area.Y - YAmount;
-height = area.Height + YAmount;
-dest_y = area.Y;
- }
+ Rectangle dest_rect = visible_rect;
+ dest_rect.Y += YAmount;
+ dest_rect.X += XAmount;
+ dest_rect.Intersect (area);
- if (XAmount 0) {
-src_x = area.X;
-width = area.Width - XAmount;
-dest_x = area.X + XAmount;
- }
- else {
-src_x = area.X - XAmount;
-width = area.Width + XAmount;
-dest_x = area.X;
- }
+ Point src = new Point (dest_rect.X - XAmount, dest_rect.Y - YAmount);
+ XCopyArea (DisplayHandle, hwnd.client_window, hwnd.client_window, gc, src.X, src.Y,
+ dest_rect.Width, dest_rect.Height, dest_rect.X, dest_rect.Y);
- XCopyArea(DisplayHandle, hwnd.client_window, hwnd.client_window, gc, src_x, src_y, width, height, dest_x, dest_y);
+ Rectangle dirty_area = GetDirtyArea (area, dest_rect, XAmount, YAmount);
+ AddExpose (hwnd, true, dirty_area.X, dirty_area.Y, dirty_area.Width, dirty_area.Height);
- // Generate an expose for the area exposed by the horizontal scroll
- // We don't use AddExpose since we're
- if (XAmount 0) {
-AddExpose(hwnd, true, area.X, area.Y, XAmount, area.Height);
- } else if (XAmount 0) {
-AddExpose(hwnd, true, XAmount + area.X + area.Width, area.Y, -XAmount, area.Height);
- }
-
- // Generate an expose for the area exposed by the vertical scroll
- if (YAmount 0) {
-AddExpose(hwnd, true, area.X, area.Y, area.Width, YAmount);
- } else if (YAmount 0) {
-AddExpose(hwnd, true, area.X, YAmount + area.Y + area.Height, area.Width, -YAmount);
- }
XFreeGC(DisplayHandle, gc);
}
@@ -4848,6 +4821,127 @@
ScrollWindow(handle, rect, XAmount, YAmount, with_children);
}
+ Rectangle GetDirtyArea (Rectangle total_area, Rectangle valid_area, int XAmount, int YAmount)
+ {
+ Rectangle dirty_area = total_area;
+
+ if (YAmount 0)
+dirty_area.Height = total_area.Height - valid_area.Height;
+ else if (YAmount 0) {
+dirty_area.Height = total_area.Height - valid_area.Height;
+dirty_area.Y = total_area.Y + valid_area.Height;
+ }
+
+ if (XAmount 0)
+dirty_area.Width -= valid_area.Width;
+ else if (XAmount 0) {
+dirty_area.Width -= valid_area.Width;
+dirty_area.X += valid_area.Width;
+ }
+
+ return dirty_area;
+ }
+
+ Rectangle GetTotalVisibleArea (IntPtr handle)
+ {
+ Control c = Control.FromHandle (handle);
+
+ Rectangle visible_area = c.ClientRectangle;
+ visible_area.Location = c.PointToScreen (Point.Empty);
+
+ for (Control parent = c.Parent; parent != null; parent = parent.Parent) {
+Rectangle r = parent.ClientRectangle;
+r.Location = parent.PointToScreen (Point.Empty);
+
+visible_area.Intersect (r);
+ }
+
+ // If region is null, the entire area is visible.
+ // Get the area not obscured otherwise.
+ Region visible_region = GetVisibleRegion (c, visible_area);
+ if (visible_region != null) {
+Graphics g = c.CreateGraphics ();
+RectangleF rectf = visible_region.GetBounds (g);
+visible_area = new Rectangle ((int) rectf.X, (int) rectf.Y,
+ (int) rectf.Width, (int) rectf.Height);
+
+visible_region.Dispose ();
+g.Dispose ();
+ }
+
+ visible_area.Location = c.PointToClient (visible_area.Location);
+ return
Re: [Mono-winforms-list] [Patch] Invalidate non visible areas in scrolling
Ah!, perfect! We wll be using that one, instead. Carlos. El lun, 21-01-2008 a las 19:25 -0600, Jonathan Pobst escribió: I just added a public property called Hwnd.GraphicsContext that is a cached Graphics we keep around for measuring and such. If you don't need a specific Graphics, you can just use this one. Jon Carlos Alberto Cortez wrote: Hey Chris, Attached is an updated patch that basically incorporates all the things you mentioned in your last mail: * Determines the visible rectangle, and intersects it with the required area (this is, we copy only the visible area). - First by determining the visible area based on its size and its parents. - Second, by looking for toplevel windows that intersect the window, and excluding that area. * Then compute the destination rectangle, by applying the XAmount/YAmount values and intersecting it with the area passed to ScrollWindow (thus we clip it as needed). This is the way Gdk does it. * Finally, exclude the destination rectangle from the total requested area, and pass it to AddExpose method. With this patch everyting is working as expected, but I have some issues: * Region needs a Graphics instance to return its Bounds, which *could* be expensive. * After taking a look at the way scrolling is done in Gdk, it *seems* that the Region implementation lack some of the functionality we need (like, returning in a simple operation the Rectangles describing the region). Comments? Carlos. ___ 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
Re: [Mono-winforms-list] [PATCH] Invalidate non visible areas when scrolling
Hey Chris, Sorry for the late answer (spent some time fixing some other winforms bugs). Commnts below. El lun, 01-10-2007 a las 22:03 -0700, Chris Toshok escribió: It does, but I don't think we need to add tracking of invalid areas which are offscreen - the whole point of the invalid area tracking is to track things that need to be repainted *because* they're visible. If it's offscreen, we shouldn't need to do anything that complicates it. It seems like a better solution to just figure in the clipping by parent forms into the pseudo clipping we already do. The scroll code takes into account that a child's view can be larger than the child (the AddExpose calls). It shouldn't be too hard to figure out the *actual* visible rectangle of that child, if it's not already done someplace, and make the AddExpose calls take that into account, without the additional calculation (and invalidation, which will just be ignored anyway). As I can understand it, the AddExpose calls (in ScrollWindow method) are not there to take into account the possibility of child can be larger than its parents, but to invalidate the area not being copied when doing the scroll. For example, to try this thing, I put a listview in a form, with the listview being smaller than the form, and I still see the AddExpose calls (from console messages indicating so). And not, it's not being done already somewhere else. Taking a look at the sample at 324513 could help. Probably I'm still missing something? Hope this helps, Carlos. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] New to the list
Hello Heh... yes, I have that feeling too. I just didn't want to made design-level changes (and even if I did want, I didn't dare since this is my first day with the winforms source code). However, I can explain how I see the problem so you guys decide if deeper changes are necesary. The ListView problem: 1) When a new SubItem is added, the ListViewSubItem constructor sets the SubItem text. 2) Text.set in the SubItem Text property calls Invalidate(Bounds). 3) Bounds.get calls GetBounds() and this calls GetItemLocation(). 4) GetItemLocation() uses the items_location[] array. Now, items_location[] is set to an initial lenght of [16] by the ListView constructor, and extended by AdjustItemsPositionArray if needed. AdjustItemsPositionArray is only called by CalculateListView, which is called only before a redraw. So, if you add a 17th item before a redraw, you get an index out of bounds at ListView.GetItemLocation(). I think the problem here is that Invalidate() ends up usign items_location[], which is only calculated when redrawing. That doesn't seem to make sense sometimes, since Invalidate() happens _before_ the redraw. Actually the sequence is: Redraw () - Invalidate () - Update (Paint) The thing is is that Redraw (and thus AdjustItemsPositionArray) is _always_ called before Invalidate or Update (or Paint, which actually requests Items count info and more). So this should be a problem _apparently_. The problem anyway seems to be an out of synch state between them. The problem is: I can't reproduce it. Do you have a sample case? Carlos. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [PATCH] ToolTip patch
Hey,
The small attached patch changes a pair of bits of the ToolTip class.
The first change is that calling SetToolTip for a control that already
shown its associated tooltip should make it visible _again_ if the mouse
pointer is inside its bounds.
The second one is that we were not updating fine the tooltip text when
SetToolTip was called for a control showing the tooltip at the moment;
it also should reset its internal timer (based on the MS behaviour).
Comments?
Carlos.
Index: ToolTip.cs
===
--- ToolTip.cs (revisión: 77422)
+++ ToolTip.cs (copia de trabajo)
@@ -121,6 +121,12 @@
base.OnPaint(pevent);
}
+ protected override void OnTextChanged (EventArgs args)
+ {
+Invalidate ();
+base.OnTextChanged (args);
+ }
+
protected override void Dispose(bool disposing) {
if (disposing) {
this.string_format.Dispose();
@@ -377,13 +383,17 @@
}
// if SetToolTip is called from a control and the mouse is currently over that control,
- // make sure that tooltip_window.Text gets updated
- if (caption != null last_control == control) {
+ // make sure that tooltip_window.Text gets updated if it's being shown,
+ // or show the tooltip for it if is not
+ if (active_control == control caption != null state == TipState.Show) {
Size size = ThemeEngine.Current.ToolTipSize(tooltip_window, caption);
tooltip_window.Width = size.Width;
tooltip_window.Height = size.Height;
tooltip_window.Text = caption;
- }
+timer.Stop ();
+timer.Start ();
+ } else if (MouseInControl (control))
+ShowTooltip (control);
}
public override string ToString() {
@@ -452,10 +462,8 @@
timer.Stop();
state = TipState.Initial;
- // if we're in the same control as before (how'd that happen?) or if we're not active, leave
- if (!is_active || (active_control == control)) {
+ if (!is_active)
return;
- }
if (!show_always) {
IContainerControl cc = last_control.GetContainerControl ();
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Again problems with ListView
El jue, 15-02-2007 a las 15:15 +0100, pablosantosluac escribió: Hi all, I've just detected the following problem in our GUI client (a WinForms app running on Mono/Linux). In a listView the AfterLabelEdit event doesn't seem to be working correctly. It should receive a System.Windows.Form.LabelEditEventArgs argument with some information like the label name, item index and so on. It arrives uninitialized. Is it a known problem? or I'm doing something wrong? It is one of the three (hopefuly) remaining blockers we have at the moment. Could you fill a bug in bugzilla with the sample? Carlos. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] ListView fails to update ListViewItem display on submember updates
El dom, 28-01-2007 a las 15:05 -0600, Brian Wolfe escribió: I wrote an application in VisualStudio that uses a ListView. On windows, when I call myListView.Update() it repaints all of the changed items jsut fine. When I compile it under Mono it fails to update the rows. It should behave exactly as .Net. Could you please fill a bug report? Carlos. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] [PATCH] Correct behavior for PrintDialog.PrinterSettings/Document
Hey,
The attached patch fixes the behaviour in
PrintDialog.PrinterSettings/Document, to be consistent with .Net.
I also included some simple nunit tests that ran fine with .Net too.
Carlos.
Index: PrintDialog.cs
===
--- PrintDialog.cs (revisión: 63089)
+++ PrintDialog.cs (copia de trabajo)
@@ -40,7 +40,6 @@
[DefaultProperty(Document)]
public sealed class PrintDialog : CommonDialog {
PrintDocument document;
- PrinterSettings printer_settings;
bool allow_current_page;
bool allow_print_to_file;
bool allow_selection;
@@ -83,7 +82,7 @@
public override void Reset ()
{
- current_settings = null;
+ current_settings = new PrinterSettings ();
AllowPrintToFile = true;
AllowSelection = false;
AllowSomePages = false;
@@ -157,12 +156,8 @@
}
set {
-if (value == null)
- return;
-
document = value;
-current_settings = value.PrinterSettings;
-printer_settings = null;
+current_settings = value == null ? new PrinterSettings () : value.PrinterSettings;
}
}
@@ -171,11 +166,14 @@
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public PrinterSettings PrinterSettings {
get {
-return printer_settings;
+return current_settings;
}
set {
-current_settings = printer_settings = value;
+if (value != null value == current_settings)
+ return;
+
+current_settings = value == null ? new PrinterSettings () : value;
document = null;
}
}
//
// PrintDialogTest.cs: Tests for PrintDialog class.
//
// Permission is hereby granted, free of charge, to any person obtaining
// a copy of this software and associated documentation files (the
// Software), to deal in the Software without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//
// Copyright (c) 2006 Novell, Inc. (http://www.novell.com)
//
// Authors:
// Carlos Alberto Cortez [EMAIL PROTECTED]
//
using System;
using System.Collections;
using System.Drawing;
using System.Drawing.Printing;
using System.Windows.Forms;
using NUnit.Framework;
namespace MonoTests.System.Windows.Forms
{
[TestFixture]
public class PrintDialogTest
{
[Test]
public void DefaultValues ()
{
PrintDialog pd = new PrintDialog ();
Assert.IsTrue (pd.AllowPrintToFile, #1);
Assert.IsFalse (pd.AllowSelection, #2);
Assert.IsFalse (pd.AllowSomePages, #3);
Assert.IsNull (pd.Document, #4);
Assert.IsNotNull (pd.PrinterSettings, #5);
Assert.IsFalse (pd.PrintToFile, #6);
Assert.IsFalse (pd.ShowHelp, #7);
Assert.IsTrue (pd.ShowNetwork, #8);
}
[Test]
public void DocumentTest ()
{
PrintDialog pd = new PrintDialog ();
PrintDocument pdoc1 = new PrintDocument ();
PrinterSettings ps1 = new PrinterSettings ();
pdoc1.PrinterSettings = ps1;
pd.Document = pdoc1;
Assert.AreEqual (pdoc1, pd.Document, #1);
Assert.AreEqual (ps1, pd.PrinterSettings, #2);
PrinterSettings ps2 = new PrinterSettings ();
pdoc1.PrinterSettings = ps2;
pd.Document = pdoc1;
Assert.AreEqual (pdoc1, pd.Document, #3);
Assert.AreEqual (ps2, pd.PrinterSettings, #4);
pd.Document = null;
Assert.IsNull (pd.Document, #5);
Assert.IsNotNull (pd.PrinterSettings, #6);
if (pd.PrinterSettings == ps1)
Assert.Fail (#7);
}
[Test]
public void PrinterSettingsTest ()
{
PrintDialog pd = new PrintDialog ();
PrinterSettings ps1 = new PrinterSettings ();
pd.PrinterSettings = ps1;
Assert.AreEqual (ps1, pd.PrinterSettings, #1);
Assert.IsNull (pd.Document, #2);
pd.PrinterSettings = null;
Assert.IsNotNull (pd.PrinterSettings, #3);
Assert.IsNull (pd.Document, #4);
if (pd.PrinterSettings == ps1)
Assert.Fail (#5);
}
}
}
___
Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] [PATCH] Correct behavior for PrintDialog.PrinterSettings/Document
I removed the printer_settings field, since it wasn't necessary. Maybe we could just change current_settings to printer_settings, like a cosmetic change. Carlos. El vie, 28-07-2006 a las 16:24 -0400, Chris Toshok escribió: These look fine, particularly if the unit tests pass. Is there any way we can either 1) clear up the names (current_settings and printer_settings are confusing), or 2) get rid of one of them and only have one PrinterSettings object? Chris On Fri, 2006-07-28 at 14:53 -0500, Carlos Alberto Cortez wrote: Hey, The attached patch fixes the behaviour in PrintDialog.PrinterSettings/Document, to be consistent with .Net. I also included some simple nunit tests that ran fine with .Net too. Carlos. ___ 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] SWF test applications
Hey, We are putting some small SWF applications in mono-cvs.ximian.com/extras/trunk/wf-apps (from sites such CodeProject and SourceForge, and free applications in general). Some of they expose small problems (bugs or performance issues). I'm taking note of some problems and trying to cook small test cases for them, but it would be a good idea to take a look at them (specially for the guys working in this area). Carlos. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
