Click here to Skip to main content
15,881,248 members
Please Sign up or sign in to vote.
1.00/5 (2 votes)
See more:
Rather than a problem it is more a question, I have some code that was implemented by my co-worker using a Windows Form with framework 3.5. The application consists of a Windows Form and using a trial version of DotNetBar, C1FlexGrid, C1Input.... The application menus and button act as Windows 8 Start Menu sort of but the application was never completed and I was asked to complete it. Practically this application will be used on MicroTerminals (Windows 7 Based with a resolution of 1024x600 where screen is resistive)

The application was never completed, and he was making use of a trial version of DotNetBar, now I was asked to try to use something else rather than DotNetBar to avoid license cost.

My question is if I have to create a new GUI would it be best to go to a WPF framework or use a Windows Form?

The main use of the application will be of DataEntry, several buttons available to users so that once clicked existing forms will load for data entry.

What I have tried:

Not tried, as it is a question rather than a problem
Posted
Updated 18-Apr-16 7:34am
v3
Comments
Richard MacCutchan 18-Apr-16 10:30am    
You first need to define 'best'. The ultimate object of any application is to fulfill a business need. Whether it is web, form, wpf etc is dependent on that business need.
Philippe Mori 18-Apr-16 12:55pm    
You should not decide by the license cost alone. If the license save you months of development, it might make sense.
However, you have to be sure that those component allows you to do what you want to do and that you can live with its limitations.
While the question by itself is clear, more information is need to make appropriate decision.
For sure WPF framework would be more appropriate if you application has a non standard UI as far more customization could be done.

Your question was clear and concise.

As far as WPF vs WinForms goes... I'm a big fan of WPF. Having done WinForms for many years you learn to work around a lot of limitations. With WPF, you can pretty much design anything. I've done forms and controls in WPF that would be impossible in WinForms.

Given that the current app is incomplete, who not go with WPF? You'll end up with a cleaner, more easily maintainable UI.
 
Share this answer
 
Comments
datt265 18-Apr-16 11:08am    
Thanks, I know that winforms are stable and can find many online help. I did small things with WPF and I really like, what I am afraid is if Microsoft discards it like they did with others such as Silverligth.
Sergey Alexandrovich Kryukov 18-Apr-16 11:52am    
It's very likely that having legacy of a Form application is the most important factor, so you may prefer staying with Forms, which would be quite acceptable choice.

However, "I did small things with WPF" cannot be a decisive factor. WPF might be beneficial, and all the popular "learning curve" considerations are just irrelevant trash. If it pays off, it will pay off despite some learning time, which can also be beneficial itself.

Same thing is about the rumors (or whatever your thinking is) about possible discontinuation of WPF support. Microsoft may decide to discontinue Forms as well. How can we know? But you may be able to use your WPF code on the platforms derived from WPF, after some modifications. Also note that 3rd party CLI (Mono) supports Forms but not WPF. The choice is yours. But that's right: be prepared for the changes.

—SA
Kevin Marois 18-Apr-16 11:13am    
WPF isn't going anywhere. I hear that all the time an I don't know where people get their info. See this: https://blogs.msdn.microsoft.com/dotnet/2014/11/12/the-roadmap-for-wpf/
Sergey Alexandrovich Kryukov 18-Apr-16 11:42am    
Kevin, your advice reasonable, but I would never agree that WPF makes a clear-cut choice. There are many situations where it might be impractical. Having good quality legacy written with some other library is one of the factors. I am a fan of rewriting everything from scratch (and still mean it), but even I clearly understand that this is not always the best decision.

Another concern is: being a fan of WPF, can you see its inherent fallacies? If not, it's no good...

And finally, I think it's important to criticize the question for being not 100% constructive; it may help the inquirer to pose better questions in future. "Clear" is not the only important thing (yes, comparing to majority of the question on this forum, this one looks not bad). It's good to understand that we have less reasons for a definitive suggestion than the inquirer. In big part of it, this is a question about nothing.

Voted 4 for this answer.
—SA
This is not a good question. We have to little information to give your the definitive suggestions on the choice. We don't have the information on what is implemented in the existing Form application you got, how valuable is the code, how much of it depends on that DotNetBar. You did not provide a reference to this component. You are really the one who needs to make all the decisions.

If you don't have a working version of the component used before, develop an application which does not use it. What kind of application, what UI framework/library you should use, depends on many factors. First of all, it depends on what that available incomplete application used. You may want use the same (Forms), but not necessarily.

[EDITED according the reasonable comments to the answer be Kevin Marois.]

[EDIT #2] See also my comments to the Solution 2.

—SA
 
Share this answer
 
v4
Comments
Kevin Marois 18-Apr-16 11:09am    
Maybe you should go back and re-read his post. His question was clear and he adequately defined the problem and purpose of his app. Nothing you stated in your answer is true.

"You did not inform us what is the existing application, Forms, WPF, or anything else" - He said WinForms

"So, there is no the alternatives you mention" - He provided his two alteratives - WinForms or WPF.

"If you don't have a working version of the component used before"
He has a working, unfinished WinForms version.

"did not reference that DotNetBar" - What does that mean??

Maybe take some more time reading the questions before you answer.
Sergey Alexandrovich Kryukov 18-Apr-16 11:29am    
Okay, re-reading...
You are right. I edited the answer accordingly. Your comment is credited.
Thank you very much, Kevin.
—SA
Philippe Mori 18-Apr-16 13:04pm    
Effectively, while the question itself is clear, in practice we don't have enough information to decide.

It depends a lot on OP skills, the state of the existing application, which compromise are acceptable, how much time to invest in it and the potential of the application.
Sergey Alexandrovich Kryukov 18-Apr-16 13:12pm    
Precisely!
—SA
In addition to other solutions, you have to evaluate if it would be wiser to buy one or more of the trial components than to do the equivalent yourself.

One thing would be to evaluate for each component how much there are presently used and which features that are used are not available in either WinForms or WPF.

Then you have to know on many licenses you need. If you are single developer and the application has many screens, you might save a lot of time and monet by buying appropriate components.

By the way, how large is your application? How many forms do you have? If it is quite large and almost working, it is probably best to make it work first (and buy necessary components). Often just the time to evaluate component might pay them... Or how to avoid them in your case.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900