headers
stifu | 2 Jan 2011 21:45
Picon
Favicon
Gravatar

Quick question about bug 661750

Bug 661750 is about an exception when converting the value of a NumericUpDown control to hexadecimal, if
the value is 0.
This conversion happens in the UpdateEditText method of the NumericUpDown control. The author of the code
added the following comments:

// Decimal.ToString doesn't know the "X" formatter, and
// converting it to an int is narrowing, so do it
// manually..

It'd be possible to fix this conversion bug by updating the conversion code a little, but instead, Oliver
proposes (in bug report 661750) that we do this instead:

Text = ((Int64)dvalue).ToString("X", CultureInfo.CurrentCulture);

Which seems right, as Int64.MaxValue is actually the maximum value of a NumericUpDown in hexa mode, not
Decimal.MaxValue. So there would be no precision loss, actually.
I support this suggestion very strongly, as that'd mean we'd replace 131 lines of code with a single one.
Slimming down the NumericUpDown code from 615 lines to 485, and therefore avoiding more potential bugs.

Does this seem alright?

Oh, and while I'm here, do you prefer "Int64" or "long"? I don't think I've seen that specified in the Mono
guidelines. But from what I've seen "int" is more commonly used than "Int32", so it'd probably make sense
to go for "long".
_______________________________________________
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
stifu | 5 Jan 2011 08:38
Picon
Favicon
Gravatar

Re: Quick question about bug 661750

Hi guys,

I'll go ahead and do this in the next few days, unless someone pops up and objects.
I'll add a nice comment explaining why it's okay to cast to Int64.

----- Mail Original -----
De: stifu <at> free.fr
À: "mono-winforms-list" <mono-winforms-list <at> lists.ximian.com>
Cc: "Miguel de Icaza" <miguel <at> novell.com>
Envoyé: Dimanche 2 Janvier 2011 21:45:33 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Quick question about bug 661750

Bug 661750 is about an exception when converting the value of a NumericUpDown control to hexadecimal, if
the value is 0.
This conversion happens in the UpdateEditText method of the NumericUpDown control. The author of the code
added the following comments:

// Decimal.ToString doesn't know the "X" formatter, and
// converting it to an int is narrowing, so do it
// manually..

It'd be possible to fix this conversion bug by updating the conversion code a little, but instead, Oliver
proposes (in bug report 661750) that we do this instead:

Text = ((Int64)dvalue).ToString("X", CultureInfo.CurrentCulture);

Which seems right, as Int64.MaxValue is actually the maximum value of a NumericUpDown in hexa mode, not
Decimal.MaxValue. So there would be no precision loss, actually.
I support this suggestion very strongly, as that'd mean we'd replace 131 lines of code with a single one.
Slimming down the NumericUpDown code from 615 lines to 485, and therefore avoiding more potential bugs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
cs_eps | 5 Jan 2011 13:37
Picon

Copy rather than drawing an image to a graphics object?


Hello!

I use the classic double buffering pattern for drawing a user control
avoiding flicker
1) override the OnPaintBackground with an empty body
2) in the OnPaint override draw all stuff (including the background) in a
buffer bitmap and draw it at the end with the graphics object in the event
args with eventArgs.Graphics.DrawImage.

This works fine if the control has a solid color, but my control has a
transparent background. It is kind of a window on a video frame with some
overlay graphics.

The problem is that DrawImage paints the new image on the old image because
of the transparent backgound. The only way to avoid this, is to call
eventArgs.Graphics.Clear(Color.Transparent) before calling the DrawImage
(could be done in OnDrawBackground)... but this flickers!

So I need to copy rather than draw the image. Any idea on how to achieve
this?
--

-- 
View this message in context: http://mono.1490590.n4.nabble.com/Copy-rather-than-drawing-an-image-to-a-graphics-object-tp3175423p3175423.html
Sent from the Mono - WinForms mailing list archive at Nabble.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
Stifu | 5 Jan 2011 14:10
Picon
Favicon
Gravatar

Re: Copy rather than drawing an image to a graphics object?


Hi,

How about defining clip regions for the parts that should be transparent,
before calling Clear?
However, I remember getting into issues doing something similar with Mono.
It worked fine with .NET, though.
See: https://bugzilla.novell.com/show_bug.cgi?id=492299

cs_eps wrote:
> 
> Hello!
> 
> I use the classic double buffering pattern for drawing a user control
> avoiding flicker
> 1) override the OnPaintBackground with an empty body
> 2) in the OnPaint override draw all stuff (including the background) in a
> buffer bitmap and draw it at the end with the graphics object in the event
> args with eventArgs.Graphics.DrawImage.
> 
> This works fine if the control has a solid color, but my control has a
> transparent background. It is kind of a window on a video frame with some
> overlay graphics.
> 
> The problem is that DrawImage paints the new image on the old image
> because of the transparent backgound. The only way to avoid this, is to
> call eventArgs.Graphics.Clear(Color.Transparent) before calling the
> DrawImage (could be done in OnDrawBackground)... but this flickers!
> 
> So I need to copy rather than draw the image. Any idea on how to achieve
(Continue reading)

Permalink | Reply | 2 comments |
headers
cs_eps | 5 Jan 2011 15:25
Picon

Re: Copy rather than drawing an image to a graphics object?


Thanks for your answer!
Right, I could clear/redraw the control only partially. This would reduce,
but not completely avoid flicker and would raise the complexity of the code.

I'm still looking for copying, instead of drawing. I just saw that cairo
uses the CAIRO_OPERATOR_OVER compositing operator by default, but it could
be set to CAIRO_OPERATOR_SOURCE before drawing my buffer and then set it
back.

Is that a way? How can it be realized without modifying the
System.Drawing.Graphics class (It still should build with .NET).

Stifu wrote:
> 
> Hi,
> 
> How about defining clip regions for the parts that should be transparent,
> before calling Clear?
> However, I remember getting into issues doing something similar with Mono.
> It worked fine with .NET, though.
> See: https://bugzilla.novell.com/show_bug.cgi?id=492299
> 
> 

--

-- 
View this message in context: http://mono.1490590.n4.nabble.com/Copy-rather-than-drawing-an-image-to-a-graphics-object-tp3175423p3175621.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stifu | 5 Jan 2011 17:35
Picon
Favicon
Gravatar

Re: Copy rather than drawing an image to a graphics object?


Hmm... Random idea: isn't there a mode in WinForms that lets a parent draw
its children? I forgot the details.
Maybe something like that: http://support.microsoft.com/kb/943454
Except that example uses P/Invokes, unfortunately.

I also found this:
http://stackoverflow.com/questions/592538/how-to-create-a-transparent-control-which-works-when-on-top-of-other-controls

Last random idea: use parent.DrawToBitmap(), then draw your child control on
top of it?

cs_eps wrote:
> 
> Thanks for your answer!
> Right, I could clear/redraw the control only partially. This would reduce,
> but not completely avoid flicker and would raise the complexity of the
> code.
> 
> I'm still looking for copying, instead of drawing. I just saw that cairo
> uses the CAIRO_OPERATOR_OVER compositing operator by default, but it could
> be set to CAIRO_OPERATOR_SOURCE before drawing my buffer and then set it
> back.
> 
> Is that a way? How can it be realized without modifying the
> System.Drawing.Graphics class (It still should build with .NET).
> 
> 
> Stifu wrote:
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
maditude | 8 Jan 2011 20:54

winforms and sqlite3


I want to try be able to run my .net Windows program under MacOS and Linux,
but I'm not sure what, if anything, needs to be done, to enable sqlite3 to
work.  The MoMA tool didn't complain about anything except for my use of
System.Data.SQLite.dll, about which it complained a great deal.

Can anyone tell me what I need to change, to make my program conditionally
reference either System.Data.SQLite.dll, or Mono.Data.SqliteClient (.so?),
while keeping source changes to a minimum?

Thanks!
--

-- 
View this message in context: http://mono.1490590.n4.nabble.com/winforms-and-sqlite3-tp3205309p3205309.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
_______________________________________________
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
cs_eps | 9 Jan 2011 10:38
Picon

Re: winforms and sqlite3

You must have SQLite installed on your linux system and make sure you use the small System.Data.SQLite.dll managed wrapper only (about 150 kb).

http://sourceforge.net/projects/sqlite-dotnet2/files/SQLite%20for%20ADO.NET%202.0/1.0.66.0/

The bigger binary dll (about 800 kb) contains the native windows sqlite binaries too. This one will not run under linux.

 

Hope this helps

 

From: maditude [via Mono] [mailto:[hidden email]]
Sent: Samstag, 8. Januar 2011 20:55
To: Schmid Christian
Subject: winforms and sqlite3

 

I want to try be able to run my .net Windows program under MacOS and Linux, but I'm not sure what, if anything, needs to be done, to enable sqlite3 to work.  The MoMA tool didn't complain about anything except for my use of System.Data.SQLite.dll, about which it complained a great deal.

Can anyone tell me what I need to change, to make my program conditionally reference either System.Data.SQLite.dll, or Mono.Data.SqliteClient (.so?), while keeping source changes to a minimum?

Thanks!

View message <at> http://mono.1490590.n4.nabble.com/winforms-and-sqlite3-tp3205309p3205309.html
To start a new topic under Mono - WinForms, email [hidden email]
To unsubscribe from Mono - WinForms, click here.


View this message in context: RE: winforms and sqlite3
Sent from the Mono - WinForms mailing list archive at Nabble.com.
_______________________________________________
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
user65 | 10 Jan 2011 12:05
Picon

Winform - this.Region property implemented on Linux?


Hi there

I would like to know whether the intended behavior of this.Region on a
Winform form is implemented on linux?

If i run the following code on OpenSuse 11.3 with mono stable 2.8.2 it has
no effect.

Rectangle rect = new Rectangle(0, 0, 200, 200);
this.Region = new Region(rect);
this.Invalidate();
this.Refresh();

Any help / suggestions / alternatives are welcome?

Regards,
user65

--

-- 
View this message in context: http://mono.1490590.n4.nabble.com/Winform-this-Region-property-implemented-on-Linux-tp3206956p3206956.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
_______________________________________________
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
maditude | 10 Jan 2011 16:29

Re: winforms and sqlite3


Thanks very much cs_eps, that's working nicely now, using identical source
code for win/linux.

What's my best bet for debugging things?  Some odd things like drag/drop
image file onto my app don't work, (while explicitly loading the same file
via file-dialog does work) have me scratching my head wondering what's going
on.  I'm terribly spoiled by VizStudio's debugger, hoping there's better
options than writing trace statements to a log file!

--

-- 
View this message in context: http://mono.1490590.n4.nabble.com/winforms-and-sqlite3-tp3205309p3207380.html
Sent from the Mono - WinForms mailing list archive at Nabble.com.
_______________________________________________
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