Contents tagged with WinForms
Yesterday a user of our .net ORM Profiler tool reported that he couldn't get the snapshot recording from code feature working in a windows forms application. Snapshot recording in code means you start recording profile data from within the profiled application, and after you're done you save the snapshot as a file which you can open in the profiler UI. When using a console application it worked, but when a windows forms application was used, the snapshot was always empty: nothing was recorded.
Today I ran into a breaking change in .NET 4 which I couldn't find in the documentation. It's about binding a linq to objects query to a BindingSource's DataSource in winforms. The code works properly in .NET 3.5, but crashes in .NET 4:
I just ran into a weird issue. During profiling I saw that controls on a form which was already closed were still reacting to events. I checked whether the Dispose() routine of the particular Form was called, but it wasn't. However, the Dispose() routine of other forms was called after it was closed, as in: immediately.
For the next major version of a certain application I'm working on (gee, what might that be ) I'm researching some UI frameworks and techniques. In the past few months I've spend most of my time working on application support library code, language designs, algorithm design etc. etc. (more on that in a later article) and I arrived at the point where I wanted to see how my vision for the major version would work in a draft application, just to see how the various elements would work together visually.
One of the first questions one would ask these days when a new desktop application is started is: WPF or Winforms? The current version is build with Winforms all the way though it's tempting to go for WPF, as it's new, has nice performance and great looks (if you're able to cook up the styles). After a day or 2 of fiddling with the various WPF docking frameworks out there, there's one firm conclusion to be drawn: WPF isn't up to par with Winforms when it comes to serious applications which use a normal windows look and feel: automatic menu, buttonbar handling based on selected docked window for example, one of the cool features of many winforms control libraries, is one of those things which is hard to do in WPF (at least, it's not directly available/build in). One other thing which made me draw the above conclusion was that it in general sucks bigtime when you have a normal windows application with normal menus: the text is in general blurry (or at least blurry in a short period of time after a move/open) and to make the menus to look like normal menus like in VS.NET is a pain (it doesn't get close).
Because we will need a custom rendering system in this major version for some areas, we do need WPF. However, one can host a WPF control just fine in a winforms application, so re-using our already written winforms skeleton was a choice I didn't expect at first but which makes sense.
The Windows Forms combobox control contains a nasty a lot of people who will try .NET 2.0 applications on .NET 3.0 will run into: the Sorted property makes comboboxes unable to bind to data: they stay empty. This is particular bad, because any solid working application for .NET 2.0 using comboboxes in a databinding scenario (and I estimate a lot of applications fall into that category) which uses the Sorted property to get sorted results will run into this problem, and it has huge consequences: any user who has .NET 3.5 installed will run into this, no matter what you defined as supportedRuntime in the .config file of your application.
Say, you have a .NET 2.0 Windows Forms application with one form and on the form one menu strip at the top, you know, very simple. On that menu strip, you have the menu 'Foo' and on that menu you have a menu item 'Bar', which are in .NET 2.0 of type ToolStripMenuItem. You assign a keyboard shortcut to the Bar menu item, say Cntrl+B.
You disable the menu 'Foo', by setting its Enabled property to false. Now it's impossible for the user to click / select the Bar menu item, right?
George asks about SP1 of the .NET Framework 2.0... Again the details have not been 100% worked out, so don’t take this as an official statement, but I expect SP1 of the .NET Framework 2.0 to be at the same time as Orcas .NET Framework ships.
The .NET's garbage collector (GC) is a wonderful thing: you simply instantiate objects and when they're out of scope and / or no reference is known to those instances, they get cleaned up and you don't have to worry.
I've blogged before about wishes I had for the IDE I use on a daily basis: Visual Studio.NET (currently v2003). Since that blog I've made a new list of new wishes not mentioned in the previous wish-list. I've also included wishes for .NET and the .NET API. The list is very long so I decided to post it as a story. You can find the story by clicking here. Below is the list of items I discuss.
I saw several "Is IE dead?" blogs and most recently DonXML's blog about this subject and I really think this discussion is not focussing on the real issue.
What's the problem with current browsers? It's not that they can't render version ABC of a given HTML, XML or XSLT variant. The problem is that they are used as application-GUI hosts while they are intended to be used as stateless viewers of information. Through an evolutionary process, Andreessen's tool to view hyperlinked texts has become an interactive viewer of a GUI for applications but still does that using the same old techniques. Which is a result of the way HTML works, and all mark-up languages in that respect.
I read all kinds of thoughts how and why IE should evolve but it really shouldn't. It should be put to rest, and the focus should be moved to an application which is already at our desktop: the CLR itself. It's a waste of energy when you are trying to re-invent the wheel that is already available: winforms. The majority of web-applications use cumbersome HTML-forms to try to build a workable GUI, while a winforms developer can do that with ease using the winforms glyphs and controls. If there was a way to run a GUI using winforms on the desktop of the website visitor, you can build a rich and powerful GUI with common technology which doesn't suffer from the fact that there is no scripting available, all HTML form glyphs are text based and other nasties related to HTML (or XHTML for that matter) which are totally avoidable when you use a decent GUI framework, like winforms.
I've been developing websites and webapplications since 1994 (ah, those good ol' days without images on pages) and I never understood why on earth a browser is used to host a rich GUI, because HTML is not meant for that, it lacks serious building blocks available in every GUI toolkit on the planet (even the console library Cursus has them!). Trying to keep it alive for webapplication GUI's is not the way IE should be evolved, IMHO.
The problem is platform independence. When Mono sees the light of day, a CLR with decent winforms is available everywhere. It should then be possible to run any decent winforms GUI frontend for any webapplication out there on every decent system and OS. IE as an application is then not needed anymore, the browser is then obsolete.
HTML, or its markup successor, will not go away of course. It will be rendered by components embedded in other applications, like helpviewer, blog readers and other tools. Such a component can be embedded in winforms as well, as a control.
The concept of the 'browser' is a concept of the past. Let it rest, let it die in peace, it's about time users move on to richer environments and technologies which truly connect user with application, no matter what type of connection (local system pipe/lan/wan/Internet via modem/ADSL/WiFi, you name it) is used and whatever flavor of browser and client side settings.