Emery Conrad | 6 Mar 19:06 2006
Picon

Splitter doesn't work

All,

Splitter seems not to be able to resize... a simple two panel form with a splitter in between should resize, right? The following code exhibits the problem (if run with MS.NET, works fine... mono doesn't allow resize). Am I misunderstanding how splitter is intended to work? It seems like this behavior should be the default.

Emery



using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespace SplitterTest
{
    /// <summary>
    /// Summary description for Form1.
    /// </summary>
    public class Form1 : System.Windows.Forms.Form
    {
        private System.Windows.Forms.Panel panel1;
        private System.Windows.Forms.Splitter splitter1;
        private System.Windows.Forms.Panel panel2;
        /// <summary>
        /// Required designer variable.
        /// </summary>
        private System.ComponentModel.Container components = null;

        public Form1()
        {
            //
            // Required for Windows Form Designer support
            //
            InitializeComponent();

            //
            // TODO: Add any constructor code after InitializeComponent call
            //
        }

        /// <summary>
        /// Clean up any resources being used.
        /// </summary>
        protected override void Dispose( bool disposing )
        {
            if( disposing )
            {
                if (components != null)
                {
                    components.Dispose ();
                }
            }
            base.Dispose( disposing );
        }

        #region Windows Form Designer generated code
        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {
            this.panel1 = new System.Windows.Forms.Panel();
            this.splitter1 = new System.Windows.Forms.Splitter();
            this.panel2 = new System.Windows.Forms.Panel();
            this.SuspendLayout();
            //
            // panel1
            //
            this.panel1.Dock = System.Windows.Forms.DockStyle.Left;
            this.panel1.Location = new System.Drawing.Point(0, 0);
            this.panel1.Name = "panel1";
            this.panel1.Size = new System.Drawing.Size(65, 266);
            this.panel1.TabIndex = 0;
            //
            // splitter1
            //
            this.splitter1.BackColor = System.Drawing.SystemColors.Highlight ;
            this.splitter1.BorderStyle = System.Windows.Forms.BorderStyle.Fixed3D;
            this.splitter1.Location = new System.Drawing.Point(65, 0);
            this.splitter1.Name = "splitter1";
            this.splitter1.Size = new System.Drawing.Size(8, 266);
            this.splitter1.TabIndex = 1;
            this.splitter1.TabStop = false;
            //
            // panel2
            //
            this.panel2.Dock = System.Windows.Forms.DockStyle.Fill;
            this.panel2.Location = new System.Drawing.Point(73, 0);
            this.panel2.Name = "panel2";
            this.panel2.Size = new System.Drawing.Size(219, 266);
            this.panel2.TabIndex = 2;
            //
            // Form1
            //
            this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
            this.ClientSize = new System.Drawing.Size(292, 266);
            this.Controls.Add(this.panel2);
            this.Controls.Add(this.splitter1);
            this.Controls.Add (this.panel1);
            this.Name = "Form1";
            this.Text = "Form1";
            this.ResumeLayout(false);

        }
        #endregion

        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            try
            {
                Application.Run (new Form1());
            }
            catch(Exception e)
            {
                MessageBox.Show(e.Message);
            }
        }
    }
}


--
Emery Conrad
Department of Mathematics
Virginia Tech
5076 Derring Hall
Blacksburg, VA 24061-0406
(540) 231-3324

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Paul F. Johnson | 9 Mar 12:06 2006
Picon

Not sure if this is an event or code problem

Hi,

The source for this question is at

http://www.smmp.salford.ac.uk/csharp/list7.cs

(it's about 8k in length so I'd rather not post it here).

I've got an event connected to a button which is set up in the Form
definition in the usual way

this.Connect.Click += new System.EventHandler(this.Connect_Click)

This is made active when either the username and password are entered or
an IP address and username and password are entered. The event will do
two things, though only does one currently and it's that which I'm not
sure about.

The event checks the contents of the IP boxes to ensure they're less
than 255 (the boxes only accept numbers, so letters aren't a problem).
The problem is that if you enter a value > 255, the code generates a
message box and then clears the box using ((TextBox)IP[i]).Clear(); the
button is then disabled.

The clear does as it should, but then won't allow a new number to be
entered. Have I used the correct method or is this a mono problem?

TTFN

Paul

P.S. Before anyone says, it's not very pleasant to look at when it's
compiled (and executed) and under Linux, the number box event handler
isn't doing as it should and rejecting non-numbers
--

-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Peter Dennis Bartok | 9 Mar 12:52 2006

Re: Not sure if this is an event or code problem

>The clear does as it should, but then won't allow a new number to be
>entered. Have I used the correct method or is this a mono problem?
This was due to a bug in TextBox, not resetting the char count on a Clear(). 
I just fixed it in svn head.

>P.S. Before anyone says, it's not very pleasant to look at when it's
>compiled (and executed) and under Linux, the number box event handler
>isn't doing as it should and rejecting non-numbers
That bug has already been fixed in svn and marked as fixed in bugzilla.

Cheers,
  Peter 

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Paul F. Johnson | 9 Mar 12:55 2006
Picon

Re: Not sure if this is an event or code problem

Hi,

> >The clear does as it should, but then won't allow a new number to be
> >entered. Have I used the correct method or is this a mono problem?
> This was due to a bug in TextBox, not resetting the char count on a Clear(). 
> I just fixed it in svn head.

Excellent :-) Looks like I'm going to have to move back to the source
version over the FC rpms on the laptop and main box at home. Oh well -
it was fun having the rpms ;-)

> >P.S. Before anyone says, it's not very pleasant to look at when it's
> >compiled (and executed) and under Linux, the number box event handler
> >isn't doing as it should and rejecting non-numbers
> That bug has already been fixed in svn and marked as fixed in bugzilla.

Thanks again for that Peter :-)

TTFN

Paul
--

-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Paul | 12 Mar 22:17 2006
Picon

Book recommendation

Hi,

Most of the SWF books I've come across seem to be specifically targetted
at those using VS.NET, so don't go into the design of windows or how
forms access other forms. Most also don't show what the generics looks
like of the events they generate (although Brown's "Windows Forms
Programming with C#" does give at least the events)

Can anyone recommend a book which does cover the aspects above?

I'm trying to solve a problem with a WinForms program I was playing with
at the end of last week, but sadly, my knowledge isn't there yet (the
sources can be grabbed from
http://www.smmp.salford.ac.uk/csharp/[clock.cs|alarmset.cs|soundset.cs]
(they are 3 different files).

TTFN

Paul
--

-- 
"Träum's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Timothy Graupmann | 12 Mar 22:36 2006
Picon

Re: Book recommendation

I'd recommend this one:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8a2e454d-f30e-4e72-b531-75384a0f1c47&displaylang=en

--- Paul <paul <at> all-the-johnsons.co.uk> wrote:

> Hi,
> 
> Most of the SWF books I've come across seem to be specifically targetted
> at those using VS.NET, so don't go into the design of windows or how
> forms access other forms. Most also don't show what the generics looks
> like of the events they generate (although Brown's "Windows Forms
> Programming with C#" does give at least the events)
> 
> Can anyone recommend a book which does cover the aspects above?
> 
> I'm trying to solve a problem with a WinForms program I was playing with
> at the end of last week, but sadly, my knowledge isn't there yet (the
> sources can be grabbed from
> http://www.smmp.salford.ac.uk/csharp/[clock.cs|alarmset.cs|soundset.cs]
> (they are 3 different files).
> 
> TTFN
> 
> Paul
> -- 
> "Tr�um's nicht, Lebe schon" - Dr. Frankenfurter, Rocky Horror Show
> > _______________________________________________
> Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-winforms-list
> 

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Nikolaus Heger | 15 Mar 02:21 2006
Picon

Forms Architecture

Hi Developers,

I would like to know what the current direction of the Forms  
implementation is and why the decision was made to go the way that  
it's going now. I am a full time Java Swing developer and looking to  
see if Mono/Windows.Forms could become a credible alternative. I  
would be thrilled if it did.

 From the Forms home page: "The current approach is to implement all  
controls fully in managed code, it uses an abstract theme interface  
to paint the widgets. The default theme interfaces renders the  
widgets using System.Drawing".

This sounds exactly like Swing to me. There are two crucial problems  
with this approach:

1 - It's slow or there is an enormous effort required to make it  
fast. Hand-drawing widgets is not as fast as letting the OS do it,  
Swing has struggled with that for years. As of today, Swing is pretty  
good on Windows, but still dead slow on other platforms. That's due  
to years and years of effort by Sun to make Swing fast on Windows  
which resulted in making most of it HW accelerated - on Windows.
Even using system libraries which of course run on the graphics card  
- this is a slow approach, and making it fast requires insane effort.

2 - It doesn't look native. No matter how good your themes are, you  
are forced to play catch-up with the latest OS release. The apps  
always look a little bit off. It's impossible to make an application  
that will look "right" on different versions of an OS, like look  
right on Windows XP _and_ Windows 2000. In Swing, I have to choose  
the XP or the 2000 look, and my app will be stuck with it and look  
out of place on the other platform.

This is even worse with older apps - the look does not automatically  
update with the OS like native apps do. I have some software written  
in JDK 1.3 and because of subtle incompatibilities between 1.3, 1.4  
and 1.5 I had to ship the app with the JVM. Realistically, this is  
the _only_ way to ship reliable Java apps. The idea was of course  
that the users always have the latest and greatest JVM is installed  
on the system and apps run on it happily, but that is not a realistic  
approach (think QA time and maintenance effort here). So my app ships  
with 1.3 and will look like Windows 2000 on Win XP. Lame.

There is also a solution to these problems: Use native widgets. AWT  
was a bust, but SWT works quite well and I use it everyday with  
Eclipse. Despite all the obstacles that have to be overcome using  
such an approach, I think it's the best way to do a cross platform  
GUI. If the OS handles the drawing of widgets, it gets you speed and  
perfect looks for free. Clearly, there are drawbacks, and clearly,  
the Forms team has decided that the drawbacks are severe...

I realize that I was not there for the initial discussion of this, so  
if anyone wants to either point me to an archive of discussions or  
explain why the current Swing-like approach was chosen as the way to  
go forward, please respond.

Best regards,

	Nikolaus Heger
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Peter Dennis Bartok | 15 Mar 02:40 2006

Re: Forms Architecture

Nikolaus,

The Winforms FAQ ( http://www.mono-project.com/FAQ:_Winforms ) has a section 
on philosophy. I am surprised that you didn't read the paragraphs right 
above what you quoted. It answers why we're doing it the way we are.

I don't have the time for a philosophical discussion right now, since we're 
nearing the Winforms Beta, but I do ask that you try it out before you say 
it's no good. I've seen Swing apps and yes, they sucked. However, purely 
going on my personal impressions, our (unoptimized) UI speed when using SWF 
apps is much better than that of any Swing app I've ever seen.

Also, our approach does allow native drawing of widgets, there is a theme 
interface that does allow that, and I Alexander Olk has made a driver for 
native Gtk drawing on Linux, for example.

The fun thing is, Sun could pretty much define their own toolkit API and it 
still sucked. We have a given API we need to implement. We don't have the 
luxury of defining what a control should do or not do, MS defined that, and 
they defined it very close to Win32.
To then say 'lets use native', unless that native is Win32 is fatal, since 
the other 'native' toolkits just don't implement the same features. And it 
does nobody any good if the app expects a feature that the native toolkit 
doesn't deliver.

As I said, give it a try before you say it's no good.

Cheers,
  Peter

-----Original Message-----
From: "Nikolaus Heger" <nheger <at> gmail.com>
To: <mono-winforms-list <at> lists.ximian.com>
Date: 14 March, 2006 18:22
Subject: [Mono-winforms-list] Forms Architecture

>Hi Developers,
>
>I would like to know what the current direction of the Forms
>implementation is and why the decision was made to go the way that
>it's going now. I am a full time Java Swing developer and looking to
>see if Mono/Windows.Forms could become a credible alternative. I
>would be thrilled if it did.
>
> From the Forms home page: "The current approach is to implement all
>controls fully in managed code, it uses an abstract theme interface
>to paint the widgets. The default theme interfaces renders the
>widgets using System.Drawing".
>
>This sounds exactly like Swing to me. There are two crucial problems
>with this approach:
>
>1 - It's slow or there is an enormous effort required to make it
>fast. Hand-drawing widgets is not as fast as letting the OS do it,
>Swing has struggled with that for years. As of today, Swing is pretty
>good on Windows, but still dead slow on other platforms. That's due
>to years and years of effort by Sun to make Swing fast on Windows
>which resulted in making most of it HW accelerated - on Windows.
>Even using system libraries which of course run on the graphics card
>- this is a slow approach, and making it fast requires insane effort.
>
>2 - It doesn't look native. No matter how good your themes are, you
>are forced to play catch-up with the latest OS release. The apps
>always look a little bit off. It's impossible to make an application
>that will look "right" on different versions of an OS, like look
>right on Windows XP _and_ Windows 2000. In Swing, I have to choose
>the XP or the 2000 look, and my app will be stuck with it and look
>out of place on the other platform.
>
>This is even worse with older apps - the look does not automatically
>update with the OS like native apps do. I have some software written
>in JDK 1.3 and because of subtle incompatibilities between 1.3, 1.4
>and 1.5 I had to ship the app with the JVM. Realistically, this is
>the _only_ way to ship reliable Java apps. The idea was of course
>that the users always have the latest and greatest JVM is installed
>on the system and apps run on it happily, but that is not a realistic
>approach (think QA time and maintenance effort here). So my app ships
>with 1.3 and will look like Windows 2000 on Win XP. Lame.
>
>There is also a solution to these problems: Use native widgets. AWT
>was a bust, but SWT works quite well and I use it everyday with
>Eclipse. Despite all the obstacles that have to be overcome using
>such an approach, I think it's the best way to do a cross platform
>GUI. If the OS handles the drawing of widgets, it gets you speed and
>perfect looks for free. Clearly, there are drawbacks, and clearly,
>the Forms team has decided that the drawbacks are severe...
>
>I realize that I was not there for the initial discussion of this, so
>if anyone wants to either point me to an archive of discussions or
>explain why the current Swing-like approach was chosen as the way to
>go forward, please respond.
>
>Best regards,
>
> Nikolaus Heger
>_______________________________________________
>Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>
> 

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Nikolaus Heger | 15 Mar 04:19 2006
Picon

Re: Forms Architecture


On Mar 15, 2006, at 8:40, Peter Dennis Bartok wrote:

Nikolaus,

The Winforms FAQ ( http://www.mono-project.com/FAQ:_Winforms ) has a section 
on philosophy. I am surprised that you didn't read the paragraphs right 
above what you quoted. It answers why we're doing it the way we are.

I did read these paragraphs. They mention GTK and Wine. IMHO, both are not suited for a native implementation approach. I agree with all that was said about why not to use these frameworks and I could think of a few more. 
GTK sucks as a cross platform framework to begin with, and basing the forms implementation on it could not possibly make it better. 
As "better" my definition would be that the Forms application is indistinguishable from a native application on the respective platform.

I was thinking about SWT. SWT is a native GUI framework for Java. Eclipse is based on it, and Azureus, too. 

I don't have the time for a philosophical discussion right now, since we're 
nearing the Winforms Beta, but I do ask that you try it out before you say 
it's no good. I've seen Swing apps and yes, they sucked. However, purely 
going on my personal impressions, our (unoptimized) UI speed when using SWF 
apps is much better than that of any Swing app I've ever seen.

Also, our approach does allow native drawing of widgets, there is a theme 
interface that does allow that, and I Alexander Olk has made a driver for 
native Gtk drawing on Linux, for example.

That sounds very promising, I will definitely check it out.

The fun thing is, Sun could pretty much define their own toolkit API and it 
still sucked.

Agreed. I could elaborate on why Swing is broken, but that's not the topic here. The important thing is to learn from its failures.

There are two basic mistakes in the Swing architecture. These mistakes are conceptual and can not be fixed. I was somewhat afraid that the Forms project is about to repeat these mistakes.

#1 - Emulating native looks with theme
#2 - Hand-drawing widgets

If I can define a Forms theme that just uses the OS for widget-drawing, that might be enough to get around both. But I am concerned because the whole "theme and hand drawing" philosophy wasn't dismissed outright. 

We have a given API we need to implement. We don't have the 
luxury of defining what a control should do or not do, MS defined that, and 
they defined it very close to Win32.
To then say 'lets use native', unless that native is Win32 is fatal, since 
the other 'native' toolkits just don't implement the same features. And it 
does nobody any good if the app expects a feature that the native toolkit 
doesn't deliver.

That's the problem with all cross platform GUIs. There certainly is validity to it, but the problem is limited in scale. SWT seems to deal with that just fine. 

It seems to me that you want to achieve two things

1 - Provide Windows.Forms as a means to create a cross platform GUI. You can mark the windows-only functions of the API as "bad, do not use" and developers can develop wonderful cross platform GUIs with no problems by just avoiding these Win32-only things.

2 - Provide Forms as a way to quickly / easily port Windows native applications. This will be hard as MS will "allow" if not encourage .Net developers to dig deep into the Win32 API. The only solution to this is to provide workarounds for this on other platforms where possible, and skip the impossible-to-emulate things. Developers not wise enough to avoid those, or those who simply don't care just cannot be accommodated on other platforms.

I, for one, would be happy with just #1. There will always be people who program in a Windows-only way and MS will obviously not prevent them from doing that.

As I said, give it a try before you say it's no good.

I didn't say it's no good. I can believe it's "fast enough" because on a modern machine almost anything is fast enough and there is differences in perception as to what constitutes fast enough. I have written Swing apps that are fast enough - at least on Windows. The bigger problem is that they stick out as non-native.

It is my experience that the Swing approach with themes is plainly wrong. The reason is that while themes are cute, no one really needs them. If you look at Swing themes, there are some nice ones from JGoodies - they are nice, but I would much rather have a 1:1 native look. The only reason I need the nice themes is that there isn't a 1:1 native look that works everywhere. 
And if you look at the most other themes (including and especially the ones from Sun) they are just horribly ugly. 

Themes have little value other than to approximate the native look, and at that task, they are always worse than using native in the first place. 

I have used Swing since it first came out, and written many client applications in it (yes, they can be fast) and never have I had the need to have themes. Every single app though had a problem with not looking exactly like a native app. 

I didn't find an archive where these questions were discussed in the past. If there is such a thing, please let me know.

Best regards,

Nik



_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Pedro Martínez Juliá | 15 Mar 14:00 2006
Picon

Re: Forms Architecture

I really don't know what you means with "native implementation".
System.Windows.Forms would be cross-platform and it includes platforms
without native controls/widgets. In Linux there are many GUI toolkits,
using, for example, GTK should angry KDE users... providing a Theme
oriented way is very fun because we can have GTK, KDE, Fox, SWT or other
toolkit you can use with MONO (through PInvoke or as managed toolkit).

The theme engine implemented in Managed.Windows.Forms could use an
unoptimized design but it has, at least, all controls drawed with
System.Drawing, and I think it's a very good way.

Yes, you can help a lot with this and I encourage you to take a look at
the Theme Engine and see if you can help in it's design. I think we (all
SWF developers) should write a WhitePaper describing a good way to write
a control using theme engine.

Thank's all Managed.Windows.Forms developers for their great work!!!

Regards,

    Pedro

--

-- 
Pedro Martínez Juliá
\   pedromj <at> gmail.com
)|      WebLog: http://www.pedromj.com/blog
/           Página web: http://www.pedromj.com
GoogleTalk: pedromj <at> gmail.com
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list


Gmane