headers
Andreia Gaita | 1 Aug 2008 12:32
Picon

Re: print/print preview not working for drawstring

On 7/24/08, funkgui <marchino <at> yota.it> wrote:
>  in windows using mono all is ok (version 1.2.5) on linux (same mono version)
>  is all ok but I can't print/print preview strings?????
>
>  Has anybody any idea?
>
>  I can print images and lines and polygons but not strings(method drawstring)

Could you post a small code sample to reproduce this problem, please?

andreia gaita
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 1 comment |
headers
marchino@yota.it | 1 Aug 2008 18:18
Picon

Re: print/print preview not working for drawstring

Yes of course:

here is the code:

        ..............................
        void Button1Click(object sender, EventArgs e)
        {
            stampa();
        }       
        public void stampa()
        {
            PrintDocument Doc = new PrintDocument();
            Doc.DocumentName = "Test di stampa"+DateTime.Now.ToFileTime();//DateTime.Now.Ticks.ToString();
            Doc.DefaultPageSettings.Landscape = false;
            Doc.PrintPage += new PrintPageEventHandler(testToPrinter);
            Margins margins = new Margins(0,0,0,0);
              Doc.DefaultPageSettings.Margins = margins;
            if (chkAnteprima.Checked)
            {
                PrintPreviewDialog Preview = new PrintPreviewDialog();
                Preview.Document = Doc;
                Preview.WindowState = FormWindowState.Maximized;
                Preview.UseAntiAlias = true;
                Preview.ShowDialog();
            }
            else
            {
                PrintDialog Print = new PrintDialog();           
                  Print.Document = Doc;
                  Print.AllowSomePages = true;
                  Print.AllowSelection = false;
                  Print.AllowPrintToFile = false;
                  Print.AllowCurrentPage = false;
                  Print.ShowHelp = false;
                  if(Print.ShowDialog() == DialogResult.OK)
                  {
                    Doc.PrinterSettings = Print.PrinterSettings;
                    Doc.Print();
                  }
            }
        }
        private void testToPrinter(Object sender, PrintPageEventArgs e)
        {
            Graphics g = e.Graphics;
            g.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.HighQuality;
            g.PageUnit = GraphicsUnit.Millimeter;
            Color mioTesto = Color.Red;       
            StringFormat drawNomeFormat = new StringFormat();
            StringFormat drawCorsoFormat = new StringFormat();
            drawNomeFormat.Alignment = StringAlignment.Center;
            drawNomeFormat.LineAlignment = StringAlignment.Center;
            Brush br = new SolidBrush(Color.Black);
            Rectangle r1a = new Rectangle(35,85,135,50);
            Font fontNome = new Font("Arial", 12);
            g.DrawString("nome 1", fontNome, br, r1a, drawNomeFormat);                   
            e.HasMorePages = false;           
        }
       
        ..............................

many thanxs
mARCO

Andreia Gaita ha scritto:
On 7/24/08, funkgui <marchino <at> yota.it> wrote:
in windows using mono all is ok (version 1.2.5) on linux (same mono version) is all ok but I can't print/print preview strings????? Has anybody any idea? I can print images and lines and polygons but not strings(method drawstring)
Could you post a small code sample to reproduce this problem, please? andreia gaita 
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 0 comments |
headers
Chris Toshok | 1 Aug 2008 22:54
Picon
Gravatar

Re: Scrolling performance isues

On Fri, Jul 25, 2008 at 11:34 AM, Ivan N. Zlatev <contact <at> i-nz.net> wrote:
Carlos Alberto Cortez wrote:
> Hey,
>
> The new code that detects not visibles areas of the window to scroll
> (obscured by other mwf windows or x11 top level ones), although working
> fine, is somewhat slow, as some people have noticed.
>
> After some research, I found that getting all the child windows for the
> root window (using XQueryTree on RootWindow, this is, top level windows)
> is the hot spot, and was causing the slow down.
>
> And after some more research in other graphics tool kits, found that:
>
> * Most of them make use of GraphicsExpose event, handling it by directly
> generating expose events or invalidating the area pointed by
> GraphicsExpose (Gtk+ as far as I know, and also Ivan told me other
> frameworks do that).
>

Yes, this is because GraphicsExpose is designed exactly for that
purpose. It is fired when a destination area can't be copied (XCopyArea)
to because the source area is obscured. I still fail to see why we need
special obscured-areas-checking logic when we can just handle that message.

You answer your question below - the reason why we couldn't use GraphicsExpose is precisely because of the timing issue.  Calculating the exact region to expose is just one possible solution (which turns out to likely be the wrong one).
 
I do understand that if we do indeed handle the GraphicsExpose message
we stand the problem that it might get delayed (X11 message roundtrip
time) until after we perform the next ScrollWindow/XCopyArea, so because
the destination area (for the previous ScrollWindow call) won't be
repainted yet we will copy that garbage from it to the next offset.

However we currently have an explicit AddExpose just after the
XCopyArea, so we are working around this problem by forcing a repaint on
the queue, so that we are guaranteed to be repainted prior to the next
ScrollWindow. And this just-works (tm) :-)

If we want to handle it "properly" we can either"

1) Flush the paint queue prior to XCopyArea somehow
... or ...
2) "Block" the message queue until we get the last GraphicsExpose for
the window, invalidate and then "unblock" the message queue.
... or ...
3) Something better

> And also, regarding our code:
>
> * When using composite (Xgl or similar) it's not necessary to do this
> detection, since the window manager (*it seems*) is doing something that
> somehow already knows which areas need to get an expose event (in other
> words: only mwf overlapping detection is needed, not for x top level
> windows).
> * The new code, at least in my laptop, without using composite, seems to
> work fine (no performance lost), and don't know if it's because
> XQueryTree on RootTree returns a minor number of windows (61 with no
> composite, instead of 89 with composite, using 5 terminals and a gtk+
> application, for example).
>

This I think is very implementation/environment/window manager/toolkit
specific. E.g some toolkits/window managers might keep menu windows as
hidden, but still mapped toplevels. I think this was referred to as one
of the reason for the huge number of toplevels in some email I saw on a
mailing list long time ago. Because of the variety of setups out there
(window managers, toolkits, etc, etc) we can't really know with how many
toplevels we are going to deal.

To give you an example of the problem - on my GNOME + Metacity desktop
with a standard set of programs running (Firefox, terminal, pidgin,
nautilus, thunderbird, etc) XQueryTree returns 228 toplevels.

> So, it seems that we should actually handle GraphicsExpose (which all it
> involves) *or maybe* try to detect if we are using composite - if we
> are, simply don't use this new code, but just do simple calculations,
> and if we are not using it, do the detection, since it won't harm the
> performance.
>

My personal position on the matter is that short-term (as in for Mono
2.0) we just handle GraphicsExpose instead of the new code and keep the
AddExpose after XCopyArea to workaround the timing issue. Long-term we
can look into adding a proper handling for the delays of GraphicsExpose
if it's feasible.

This has me a little confused - adding handling for GraphicsExpose isn't going to help anything if it's not done properly.  What I mean is, adding the handling for GraphicsExpose (essentially adding the case statement and doing an AddExpose) won't give us anything more than what we currently have, since we can't guarantee that any of those events will have been received.  It's a trivial change, and might lessen the problem somewhat, but it won't fix it.

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.

chris

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 3 comments |
headers
Jeff Richardson | 2 Aug 2008 18:11

Support for programatic scrolling via WM_VSCROLL and WM_HSCROLL messages

This patch adds support for certain controls to respond to WM_HSCROLL 
and WM_VSCROLL messages to allow them to be scrolled programatically.  
I've implemented this for every control in which both contains an 
instance of ImplicitVScrollBar and ImplicitHScrollBar and have the 
corresponding .NET type respond to sending the WM_HSCROLL and WM_VSCROLL 
messages, with the exception of MdiClient (I'm unsure exactly how to 
test that).
-- 

Jeffrey M Richardson, MCP

Index: System.Windows.Forms/Control.cs
===================================================================
--- System.Windows.Forms/Control.cs	(revision 109230)
+++ System.Windows.Forms/Control.cs	(working copy)
 <at>  <at>  -2024,6 +2024,9  <at>  <at> 
 			if (form != null && form.WindowManager != null)
 				ThemeEngine.Current.ManagedWindowOnSizeInitializedOrChanged (form);
 		}
+
+		internal virtual void OnVScroll(ScrollType s) { }
+		internal virtual void OnHScroll(ScrollType s) { }
 		#endregion	// Private & Internal Methods

 		#region Public Static Properties
 <at>  <at>  -5437,7 +5440,17  <at>  <at> 
 					WmUpdateUIState (ref m);
 					return;
 				}
+				
+				case Msg.WM_VSCROLL: {
+					WmVScroll(ref m);
+					return;
+				}

+				case Msg.WM_HSCROLL: {
+					WmHScroll(ref m);
+					return;
+				}
+
 				default:
 					DefWndProc(ref m);
 					return;
 <at>  <at>  -5931,6 +5944,14  <at>  <at> 
 			}
 		}

+		private void WmVScroll (ref Message m) {
+			OnVScroll((ScrollType)m.WParam);
+		}
+
+		private void WmHScroll (ref Message m) {
+			OnHScroll((ScrollType)m.WParam);
+		}
+
 		#endregion

 		#region OnXXX methods
Index: System.Windows.Forms/ListBox.cs
===================================================================
--- System.Windows.Forms/ListBox.cs	(revision 109230)
+++ System.Windows.Forms/ListBox.cs	(working copy)
 <at>  <at>  -2179,6 +2179,15  <at>  <at> 
 				XplatUI.ScrollWindow (Handle, items_area, 0, delta, false);
 		}

+		internal override void OnVScroll (ScrollType s) {
+			vscrollbar.ScrollBy(s);
+		}
+
+		internal override void OnHScroll(ScrollType s)
+		{
+			hscrollbar.ScrollBy(s);
+		}
+
 		#endregion Private Methods

 #if NET_2_0
Index: System.Windows.Forms/ListView.cs
===================================================================
--- System.Windows.Forms/ListView.cs	(revision 109230)
+++ System.Windows.Forms/ListView.cs	(working copy)
 <at>  <at>  -3317,6 +3317,16  <at>  <at> 
 		{
 			return true;
 		}
+
+		internal override void OnVScroll(ScrollType s)
+		{
+			v_scroll.ScrollBy(s);
+		}
+
+		internal override void OnHScroll(ScrollType s)
+		{
+			h_scroll.ScrollBy(s);
+		}
 		#endregion	// Internal Methods Properties

 		#region Protected Methods
Index: System.Windows.Forms/ScrollableControl.cs
===================================================================
--- System.Windows.Forms/ScrollableControl.cs	(revision 109230)
+++ System.Windows.Forms/ScrollableControl.cs	(working copy)
 <at>  <at>  -1117,6 +1117,16  <at>  <at> 
 			Invalidate(false);
 			ResumeLayout(false);
 		}
+
+		internal override void OnVScroll(ScrollType s)
+		{
+			vscrollbar.ScrollBy(s);
+		}
+
+		internal override void OnHScroll(ScrollType s)
+		{
+			hscrollbar.ScrollBy(s);
+		}
 		#endregion	// Internal & Private Methods

 #if NET_2_0
Index: System.Windows.Forms/ScrollBar.cs
===================================================================
--- System.Windows.Forms/ScrollBar.cs	(revision 109230)
+++ System.Windows.Forms/ScrollBar.cs	(working copy)
 <at>  <at>  -668,6 +668,12  <at>  <at> 
 		}

 		private void SendWMScroll(ScrollBarCommands cmd) {
+			// Since the WM_?SCROLL messages actually trigger
+			// scrolling a control at the same time as the
+			// control responds to the ScrollBar events,
+			// having the ScrollBar send the WM_?SCROLL event
+			// tends to cause a double scroll.
+			/*
 			if ((Parent != null) && Parent.IsHandleCreated) {
 				if (vert) {
 					XplatUI.SendMessage(Parent.Handle, Msg.WM_VSCROLL, (IntPtr)cmd, implicit_control ?
IntPtr.Zero : Handle);
 <at>  <at>  -675,6 +681,7  <at>  <at> 
 					XplatUI.SendMessage(Parent.Handle, Msg.WM_HSCROLL, (IntPtr)cmd, implicit_control ?
IntPtr.Zero : Handle);
 				}
 			}
+			*/
 		}

 		protected virtual void OnValueChanged (EventArgs e)
 <at>  <at>  -1521,6 +1528,35  <at>  <at> 
 				Invalidate (region_to_invalidate);
 			region_to_invalidate.Dispose ();
 		}
+
+		internal void ScrollBy(ScrollType s){
+			switch (s){
+				case ScrollType.SB_LINEUP: {
+					SmallDecrement();
+					return;
+				}
+				case ScrollType.SB_LINEDOWN: {
+					SmallIncrement();
+					return;
+				}
+				case ScrollType.SB_PAGEUP: {
+					LargeDecrement();
+					return;
+				}
+				case ScrollType.SB_PAGEDOWN: {
+					LargeIncrement();
+					return;
+				}
+				case ScrollType.SB_TOP: {
+					SetHomePosition();
+					return;
+				}
+				case ScrollType.SB_BOTTOM: {
+					SetEndPosition();
+					return;
+				}
+			}
+		}
 		#endregion //Private Methods
 #if NET_2_0
 		protected override void OnMouseWheel (MouseEventArgs e)
Index: System.Windows.Forms/ScrollType.cs
===================================================================
--- System.Windows.Forms/ScrollType.cs	(revision 0)
+++ System.Windows.Forms/ScrollType.cs	(revision 0)
 <at>  <at>  -0,0 +1,10  <at>  <at> 
+namespace System.Windows.Forms{
+    internal enum ScrollType{
+        SB_LINEUP =		0,
+        SB_LINEDOWN =	1,
+        SB_PAGEUP =		2,
+        SB_PAGEDOWN =	3,
+        SB_TOP =		6,
+        SB_BOTTOM =		7,
+    }
+}
\ No newline at end of file
Index: System.Windows.Forms/TextBoxBase.cs
===================================================================
--- System.Windows.Forms/TextBoxBase.cs	(revision 109230)
+++ System.Windows.Forms/TextBoxBase.cs	(working copy)
 <at>  <at>  -210,6 +210,16  <at>  <at> 
 				return;
 			base.PaintControlBackground (pevent);
 		}
+
+		internal override void OnVScroll(ScrollType s)
+		{
+			vscroll.ScrollBy(s);
+		}
+
+		internal override void OnHScroll(ScrollType s)
+		{
+			hscroll.ScrollBy(s);
+		}
 		#endregion	// Private and Internal Methods

 		#region Public Instance Properties
Index: System.Windows.Forms/TreeView.cs
===================================================================
--- System.Windows.Forms/TreeView.cs	(revision 109230)
+++ System.Windows.Forms/TreeView.cs	(working copy)
 <at>  <at>  -2310,6 +2310,16  <at>  <at> 
 		}
 #endif

+		internal override void OnVScroll(ScrollType s)
+		{
+			vbar.ScrollBy(s);
+		}
+
+		internal override void OnHScroll(ScrollType s)
+		{
+			hbar.ScrollBy(s);
+		}
+
 		#region Stuff for ToolTips
 #if NET_2_0
 		private void MouseEnteredItem (TreeNode item)

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 2 comments |
headers
Keith Curtis | 5 Aug 2008 07:08
Picon

Re: Resgen2 1.2.6 crash

Hi;

I'm helping someone port a Winforms app to Mono and getting a crash in resgen2.

I'm using Mono 1.2.6 from Ubuntu 8.04.

Here is the problematic resx file and the stack trace http://keithcu.com/resgencrash.zip

Thanks for any help and let me know if anyone needs more info! Generally, things have worked very well so far and the sln files appear to work back and forth between MonoDevelop on Ubuntu and VS.Net, etc.

-Keith

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 3 comments |
headers
David Suarez | 5 Aug 2008 19:13

Macosx support

Hi all, 

I have tested our app with the latest mono 2.0 preview on the mac (both
tiger and leopard). Although the general impression is that it improved a
lot, there are still a few showstoppers and several important usability
problems. 

Showstoppers for us are flicker showing new forms and generalized slow
graphics performance (compared to native mac applications). Other problems
relate to keyboard not working on controls and random crashes with no
output. 

Regarding the graphics performance, do you guys have anything planned?  Are
there any real world MWF applications running on the mac?

Cheers, 

David Suarez
www.plasticscm.com

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 3 comments |
headers
Geoff Norton | 5 Aug 2008 19:33
Picon
Favicon
Gravatar

Re: Macosx support

David,

On Tue, 2008-08-05 at 19:13 +0200, David Suarez wrote:
> Hi all, 
> 
> I have tested our app with the latest mono 2.0 preview on the mac (both
> tiger and leopard). Although the general impression is that it improved a
> lot, there are still a few showstoppers and several important usability
> problems. 
> 
> Showstoppers for us are flicker showing new forms and generalized slow
> graphics performance (compared to native mac applications). Other problems
> relate to keyboard not working on controls and random crashes with no
> output. 

I've fixed a bunch more issues in the branch and have 1 more fix that
I'm working on hopefully for the 2.0 release.  If you're having specific
problems beyond this (performance or otherwise) can you please file
individual bugs with test cases?  It really makes my job much easier if
I can see the problems in smaller applications rather than trying to
delve thru a huge codebase.

Also the newest GDI+ has cairo 1.6 which has a number of performance
increases for the Mac cairo backend.

Thanks

-g

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 2 comments |
headers
Dan Shryock | 5 Aug 2008 19:48
Picon

WebBrowser control on OSX

I'm working on an application, and I would like to determine how much
work would be involved in porting the application to OSX.

The biggest concern I have would be regarding the support for the
WebBrowser control, so I was wondering if there is any support, or
plans to support the WebBrowser control in System.Windows.Forms on
OSX?

If there will be support, would it be Gecko or WebKit?

If it is Gecko, would the necessary libraries be installed along with
mono, or would there be some separate process to get it installed and
running?

Any information would be helpful!

Dan
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 2 comments |
headers
Geoff Norton | 5 Aug 2008 19:57
Picon
Favicon
Gravatar

Re: WebBrowser control on OSX

On Tue, 2008-08-05 at 10:48 -0700, Dan Shryock wrote:
> I'm working on an application, and I would like to determine how much
> work would be involved in porting the application to OSX.
> 
> The biggest concern I have would be regarding the support for the
> WebBrowser control, so I was wondering if there is any support, or
> plans to support the WebBrowser control in System.Windows.Forms on
> OSX?

There is nothing supported or existant at this time, and its not planned
for the immediate future.

> 
> If there will be support, would it be Gecko or WebKit?
> 

What path we'll tak at this time isn't determined yet.

-g

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 1 comment |
headers
Gert Driesen | 5 Aug 2008 21:24
Picon
Favicon

Re: Resgen2 1.2.6 crash

Keith,

 

I think you’re running into this one:

https://bugzilla.novell.com/show_bug.cgi?id=410608

 

I’ll submit a patch for this in the same few days.

 

Gert

 

From: mono-winforms-list-bounces <at> lists.ximian.com [mailto:mono-winforms-list-bounces <at> lists.ximian.com] On Behalf Of Keith Curtis
Sent: dinsdag 5 augustus 2008 7:09
To: mono-winforms-list <at> lists.ximian.com
Subject: Re: [Mono-winforms-list] Resgen2 1.2.6 crash

 

Hi;

I'm helping someone port a Winforms app to Mono and getting a crash in resgen2.

I'm using Mono 1.2.6 from Ubuntu 8.04.

Here is the problematic resx file and the stack trace http://keithcu.com/resgencrash.zip

Thanks for any help and let me know if anyone needs more info! Generally, things have worked very well so far and the sln files appear to work back and forth between MonoDevelop on Ubuntu and VS.Net, etc.

-Keith

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Permalink | Reply | 0 comments |

Gmane