Contents tagged with Windows Forms
-
LLBLGen Pro v4.0 BETA released!
We've released the first beta of LLBLGen Pro v4.0! We hope you all like the new features and additions we packed into this new release! To make sure stuff is truly tested in a lot of scenario's, the beta is available to all v3.x licensees. -
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! :)
-
Unknown breaking change in .NET 4?
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:
-
Winforms Gotcha: Form.Close() doesn't always call Dispose()
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.
-
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?