The death of windows forms?

W3bbo wrote:



vesuvius wrote: What would you do? Which way would you go?

Going by these examples, I'd use it as an excuse to give WPF a good airing and seeing if it lives up to the hype.

Ah, Lee Brimelow's shindig. He is now a platform evangelist at adobe hence his blog suffers as a consequence. That the examples are attractive is unquetionable. The target users for this little app will be more than pleased with an Office 2007 looky-likey. On one hand I want to be safe, on the other there is Brad Abrams prediction no 1.

Minh wrote:



vesuvius wrote:What drives change in your organisation? Technology or Business requirement?

That's a trick question There's only one answer to the question above.

The real question is "How big is your organization?"

How quickly can you update all your desktops to Vista / or install .NET 3.x?

Sagacious perception.

.NET 3 shouldn't be problematical because the machines are all quite new. Albeit unexciting Dual Core's, with questionable graphics.

What business is it of mine to foist Vista based solutions, when Winforms will do? They are unlikely to pay more for one or the other. Resolve their business needs, and laugh all the way to the bank. Look at the Microsoft Dynamics suite, thats based on Office 2003, never mind the shnazy Office 2007 UI.

I'd prefer to maintain a XAML based app though, in the long run.

TommyCarlier wrote:

How is this the death of Windows Forms? I work in a small company (currently 2.5 developers) and we've been writing WinForms applications for years now. I've investigated WPF as an alternative and we've decided to stick with WinForms. There's no point in discarding years of experience just to try out a new exciting technology that is far from mature.

Some of our applications use a UI that is a bit Outlooky (though far from the same). We use the free Krypton Toolkit, the commercial Krypton Navigator and the Xceed Ultimate Suite (contains Xceed Grid, Xceed Compression, Xceed Zip, Xceed Ftp, ...).

Here's a screenshot of the main window of one of our applications:

I guess there is a whole lot of value interfacing with someone who has had to make the choice from a business point of view. I have downloaded and tried your Transceiver Communicator, and you've done a great job. The application excecutes quickly and efficiently. The only problem I found with it was that after un-installing it, the link was left in the context menu trip on the desktop. This cleared itself after a few days though.

From a function/design point of view Tranceiver has 1 task. That is the transmission of files. It needs to relay this information clearly.

Whats missing are progress bars that indicate the progress of the upload or download of a file in the gridview. Think uTorrent, Free Download Manager or Flashget. You know when each file was started, can see the progress (albeit asynchronously) at is happens. You could also do with an outlook style treeview on the left with folders for different file types, i.e you .jpegs and your .mp3 files.

To recify the first problem in the standard datagridview requires this. You then need something like this to make it look a bit better. You also need to fiddle with the double buffering because the datagridview has an awful flickering problem. This may well be available to you in the Xceed suite you have.

If your try this with a Listview you have PInvoke here or here. The worst thing it the databinding which does not exist and you're not programming against rows and columns. It's also a headache to get the Krypton rendering for the listview so it fits in with the rest of your app.

The long and the short of it is you have to work out compromises all the time with Winforms, these compromises are not prevalent in WPF. There is just a shortage of tools and research material. But you're not fighting the tools and having to resort to witchcraft to get a component working the way you want.

CannotResolveSymbol wrote:



vesuvius wrote: What business is it of mine to foist Vista based solutions, when Winforms will do? They are unlikely to pay more for one or the other. Resolve their business needs, and laugh all the way to the bank. Look at the Microsoft Dynamics suite, thats based on Office 2003, never mind the shnazy Office 2007 UI. I'd prefer to maintain a XAML based app though, in the long run.

This isn't really a vista-based solution, though.  You can do everything with WPF/.Net 3.0 in XP that you can with Vista, so there's no extra cost beyond the time it takes to learn the new APIs.

I say, if it suits your needs, use it.  Distribution of .Net 3.0 is what WSUS and Group Policy is for, so unless you've got really limited resources, run with it.

What is a vista based solution? I am beginning to find that there is huge value in just using WPF to perform some tasks that Winforms does, simplly because it's easier. Not because I have transitions, carousel views and all the visual efects. I am championing WPF purely from an implementation point of view.

Yes the drag and drop of winforms increases productivity, but try using third party components. It's a headache to get all your controls looking right. Take Krypton for example. In WPF you have your control templates and resource dictionary. This you apply to everything, even your custom controls. How powerful is that? None of the boilerplate plumbing getting this control to render this way and that control this way.

A prime example  is this Winforms Vista Renderer. This guy has shown whats possible with winforms. Only problem is if you try apply this to a button control or the datagrid view. In WPF you have your global templates. In winforms it's far tricker.


I'm hoping people stop viewing WPF simple as a 'Pizzaz' based utility, but as something that can be used to make 'traditional' applications as well.

TommyCarlier wrote:

Vesuvius, you can follow the progress like you can in Outlook: when the app is sending or receiving files, you get a button in the status bar that says 'Sending/Receiving...'. If you click it, you get a window with the files that are being sent or received, with progress bars in the list. You're right that you have to do some work in WinForms, but it's not that hard. Our grid is actually not the default DataGridView, but a highly customized version of Xceed Grid. It has better performance and more capabilities (also better extensibility).

You are also correct that the primary function of Transceiver Communicator is to send and receive files. We tried to optimize and simplify the UI so that primary function has the main focus. In the latest version we've restructured the UI of the main window considerably. We moved some of the secundary functions (Address Book, Account Settings, ...) to menus to reduce the visual noise of too many buttons.

I will have to look into Xceeds grid then, because performace is critical. I did try the Devexpress grid and that is powerful. The problem is it's optimised for databinding and you have the most unintuative interface. I also hate it when people change grid rows and columns to things like handles and all this mumbo-jumbo. Some things are best left the same and augmented. Devexpress have excellent tutorials, in 30 mins your more or less up and running.

I tried Xceeds WPF grid and the tutorials were out of date. The ones that link to Visual Studio Help, so that was disheartening.

Sven Groot wrote:



vesuvius wrote: What is a vista based solution? I am beginning to find that there is huge value in just using WPF to perform some tasks that Winforms does, simplly because it's easier. Not because I have transitions, carousel views and all the visual efects. I am championing WPF purely from an implementation point of view.

I agree, WPF is a powerful tool even for simple UIs, especially the databinding.

I just wish it wasn't so slow. In one scenario I was trying recently I have a country selection dropdown which has 217 items. This works fine in WinForms (which is the basic Win32 combobox), even on slow computers. In WPF, opening and scrolling the dropdown is painfully slow even on a Dual Core system with a high end videocard. That is quite frankly rediculous.

Sven comments like this are not very helpful. I'm now am no better off than I was at the start. Which way do I go then? Winforms or WPF?

I know that the WPF treeview has abismal performance. Bea Costa has some tricks to improve performance. It appears as if many of the databound controls have performance problems. Bea outlines these 3 tenets;

"I discussed some of the performance limitations of TreeView. In particular, I mentioned the three facts about our current implementation that may lead to performance issues, depending on your scenario:

- UI elements stay in memory even when collapsed.
- There is no UI virtualization.
- There is no data virtualization."

Is is really worth starting a project where performance is at best sketchy? How many other unknowns are there? I know the big component vendors have had tumultous difficulty improving the performance of their datagrids. If you couple this with the fact that the average business is not going to have exceptionally fast PC's the argument really begins to lean in the favour of Windows Forms.

Nothing puts of users that a slowly operating application.

I have decided to go with Windows Forms purely because its a case of "better the devil you know, than the one you don't".

There are still just too many unknowns launching a complete product in WPF, especially in a data driven environment. Information like this on WPF is unavailable, unless I have missed it.
 
The 'crux' of the matter though, is performance of the presentation layer itself, and it's hardware/resource demands. The end user could'nt care less what the product is written in, as long as it solves the 'business need'.

Really, this is quite droll, woe is me! I've not just written this have I?