Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Contents tagged with Windows Forms

  • Beware when using .NET's named pipes in a windows forms application

    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.

  • Video: LLBLGen Pro v3 designer and runtime framework

    With DevExpress' Seth Juarez I recorded a webinar / video (Length: 1:25:05) which shows the most important features of the LLBLGen Pro designer (roughly the first hour of the video) and how to use the LLBLGen Pro runtime framework with DevExpress' reporting tools using Linq to LLBLGen Pro and normal databinding. Enjoy! :)

  • The evil of the Office UI ribbon license

    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.

  • VS.NET 2008 Beta 2 / .NET 3.5: Windows Forms ComboBox contains nasty bug.

    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.

  • .NET 2.0's ToolStripMenuItem are hard to disable...

    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?