Talk:Windows Forms

This article is a sad

This article is a sad, sad little stub. Can anybody flesh out some extra information? See the article on MFC for an idea.

The MdiContainer Property of a Windows Form seems to be very similar to the Document/View architecture of MFC. I think the note to the contrary is wrong.

Some comments after reading (except the obvious small size):

• The MVC comment is a bit strange. If you look at the MVC page, only webapps have strict V-C separations, and for that we have ASP.NET. All other application widget set roughly treat it the same as Winforms.
• Vista part, and connection to WPF. Is WPF a sucessor, competing technology? Will Winforms become (slow) GDI+?

Windows Forms doesn't have anything to do with Microsoft Foundation Classes (MFC), MVC, or Java's Abstract Windows Toolkit (AWT). There should be more explanation about what Windows Forms are rather than what they are not. 70.167.10.194 (talk) 21:15, 19 August 2011 (UTC)

Is this a correct

Is this a correct explanation for the Swing-link?

"Swing, the equivalent GUI application programming interface (API) for the Java programming language"

I think, from a programming point of view, it might be correct, but technically, it's something completely different (since WinForms is native and Swing is drawing everything by itself).

Merger proposal (controls)

BackgroundWorker and RichTextBox are two .NET components that strangely have their own articles. These should just be made into a list as part of an article covering a larger subject. While RichTextBox definitely fits in the Windows Forms article (along with other controls), as a part of System.Windows.Forms, BackgroundWoker is actually a part of System.ComponentModel, but may fit in this article nonetheless. Both of those namespaces are listed in Base Class Library, and a quickly located list of some controls (as an example) is here: [1]. --David Gannon (talk) 05:36, 6 December 2007 (UTC)

If there is no discussion, I will perform the mergers I find necessary and expand this into an appropriate article. --David Gannon (talk) 06:07, 6 December 2007 (UTC)

I consent your proposal, and propose that Windows Forms application be merged into the Windows Forms article. QQ (talk) 18:57, 13 January 2008 (UTC)

Windows Forms and Windows Forms Application are two different things in this context. The first one refers to the .NET API and the second one to a application type (opposed to console applications). Da Stranger - 27 February 2008.

While may technically refer to windows in Windows Forms Applications, I think merging Windows Forms application, Windows Forms, Windows Forms component and BackgroundWorker together make tons of sense and should be done ASAP, with the other articles deleted. We can clarify the App vs. Window nuance in the article. We probably should compare WinForm App with WPF app. Christopher G Lewis (talk) 19:16, 1 March 2008 (UTC)

Let the merger happen. Fleet Command (talk) 18:52, 22 June 2008 (UTC)

Support. +mt 07:15, 12 July 2008 (UTC)

Not single-threaded

I've removed this section from the article because it is incorrect:

This is partially because the underlying Windows API restricts functions on a particular Window handle to a single thread.

The underlying Windows API does allow some functions on a particular window handle from multiple threads. sending a message from one thread to a window owned by another thread is just fine, but it causes the calling thread to block. Posting a message from one thread to a window owned by another thread adds the message to the target queue for later processing by the owning thread and lets the sending thread continue. But the problem is tha the sending thread doesn't know when the receiving thread has processed the message, and has the issue of freeing memory associated with the message's parameters. The threading issues, then, aren't problems in the Windows API--they're a failure of the WinForms wrappers to completely mimic the Windows API and instead invent a different contract. The passage in the article was fully uncited, anyway, so it's no surprise that this oversimplification crept in. -- Mikeblas (talk) 17:01, 19 January 2009 (UTC)

Regarding: User Interface Process Application Block

Isn't it an irrelevant detail who has released User Interface Process Application Block ? (Microsoft patterns & practices group)

And why is the link a direct link? Shouldn't it be in an external links section at the end? And the direct link a Wikipedia link? —Preceding unsigned comment added by Mortense (talk • contribs) 12:17, 14 September 2009 (UTC)

I agree. Furthermore, MSDN lists UIPAB as "retired" content. Todd (talk) 14:38, 19 September 2010 (UTC)

WinForms vs. Windows Forms

Some use "WinForms" for Windows Forms. Perhaps that should be mentioned in the text?

E.g. replace "Windows Forms is the name" with "Windows Forms (or WinForms) is the name"?

However it should be researched first. Microsoft does not use "WinForms".

Mortense (talk) 19:36, 15 September 2009 (UTC)

The term WinForms was previously used for the "Microsoft Forms" ActiveX/OLE object.203.206.162.148 (talk) 10:01, 7 June 2012 (UTC)

WPF is not platform independant

"The Windows Presentation Foundation addresses these problems by providing a much more platform-independent way of designing graphical user interfaces." --> This is not true. There is a lightweight implementation of Windows Forms called "Managed Windows Forms" which uses System.Drawing to draw an application's user interface using managed code, just like Java's Swing does. There's also a GTK+ binding for managed code called gtk-sharp. These might be considered "platform independant". However, WPF is not platform independant at all. It makes heavy use of Direct3D, which is a proprietary API only available on Microsoft Windows systems or on x86 based Unix-like systems using Wine. It does also heavily rely on the graphics hardware as Direct3D doesn't offer a full-featured software renderer as OpenGL does with Mesa 3D. Because of WPF being so closely tied to Microsoft Windows and the underlying system hardware, the Mono project doesn't have any WPF support yet. 217.94.187.150 (talk) 14:08, 26 November 2009 (UTC)

The image should be updated

.NET 4.0 is already out. Also, Windows 7 should appear there. The reference to Longhorn, in my opinion, is very outdated and potentially confusing, so it should be removed.--Amatriain (talk) 18:57, 24 April 2010 (UTC)

Link to Rocket Framework for Windows is suitable

There is an 'Open Source' framework with the name Rocket Framework is gaining popularity. That help creating DB driven Windows Form based application with Entity Framework back end. I propose to add a link to that site under external link section.

Rocket Framework for Windows Form Development

--123.231.21.131 (talk) 11:36, 25 January 2011 (UTC)C_nirosh

Recommend that Advantages of WPF be Stated in Article

Hello,

I have used both Windows Forms and WPF extensively for multiple projects. WPF has: a.) Imaging effects, b.) Shading, c.) Styling, d.) Grids and Stack Panels, e.) Support for the newer font technology OpenType, and f.) An editable and much more efficient designer language. As a professional, I only recommend WPF if using Visual Studio and developing GUI for the Windows (R) operating system. I propose that someone update the article to include the capabilities that WPF has, that are not present in Windows Forms. (Reference: www.msdn.com).

It's horses for courses. The big advantage of Windows Forms is that it is a stable platform. Microsoft are not longer mucking about with it. Not everyone needs the features you mention. Clearly the WPF article is the place to describe them. Please sign your posts. 86.128.64.58 (talk) 08:51, 7 February 2015 (UTC)

Relationship between WinForms and XForms

XForms was an X11 GUI toolkit with a very similar name to Windows Forms, and it predated WinForms by quite a bit. Does anyone know if WinForms was in any way inspired by XForms? 184.57.129.13 (talk) 06:10, 3 May 2015 (UTC)