Okay, I'm biting the bullet and deciding to get into the whole Microsoft/C#/.NET culture and I'm going to do this by putting together a simple (hah!) application.
It will basically be an application in which I want to store images and associate with them other optional things.
It must be able to import images from the filesystem (and hopefully camera/scanner) then allow the user to add text, audio and other information.
I plan to store the images and auxillary information into a database. What the application will do with said data isn't important (yet).
Keep in mind I know absolutely nothing about C# or .NET although, as an old codger, I know a great deal about many other things and will regale/bore you with stories and anecdotes until you quietly slip away :-)
What are the first steps to take in developing such an application? I've already set out UI layouts and likely process flows although it may be that the development environment dictates changes.
Development environment is currently XP SP3 + VS2008 (though I can upgrade if absolutely necessary).
What should I be looking at as the first step? Are there any gotchas I should be looking out for?
Have you decided for win forms or WPF? I've been doing win forms for the past 4 years and WPF was a great discovery for me, with the flexibility it affords. It might be fitted for your application and the different types of content you'll want to add and give you a flexibility that win forms can't give.
As for actually developing, I think loading images from the disk would be the first step, showing them in the UI and getting user input for them - you would get to work with the different objects and see how the framework handles things.
A tutorial about the field validation I mentioned in my comment is here - haven't done it, but something similar. You can also see the xaml code paired with the C# code there.
After looking for the differences between win forms and WPF I found that there are a few win forms controls that are missing from WPF. More on that on MSDN (compariosn chart) and a post from March with a more detailed chart.
It's also worth mentioning that you can include win forms controls in WPF applications and vice versa, but there are some limitations.
Just a couple of pointers, it would be easy to overwhelm you as you are just starting with this tech stack. First step, use SQLServer 2008 Express, it has better ability to deal with image data (images can be saved directly to the filesystem, but they are still in a table).
Apart from that, you can design your screen with the GUI, and then hook the bits up one by one to your retreived data. Create a new Windows Forms app, or a WPF one, and start from there (i'm assuming that you know about the toolbox window and just dragging components on to the designer and setting their properties in the Properties window).
If you're looking win forms you're going to have drag-and-drop UI pretty easily.
If you want to use a database than you're probably going to find MS-SQL the easiest to cooperate with. Look up LINQ-2-SQL, it lets you access your database through an object layer by simply dragging your tables onto a pane.
Fun things to use: extension methods, partial classes, LINQ (query any collection with inline lambdas) and even class/method attributes.
My $0,02:
a) Get to know the platform a bit, types, collections, events/delegates(/lambdas), etc etc
b) Dive into WPF
c) Learn about database connectivity (LINQ2SQL or NHibernate (or ....)
d) Learn about the MVVM pattern to get to deliver solid wpf applications, doing so forces you to dive deeper into the workings of WPF (routed commands, tunneling/bubbleing etc)
e) Learn more about patterns to get a more solid grasp of OO (this: http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1276066663&sr=8-1 is an absolute pearl for that)
f) etc
If you aren't too desperate to get your hands dirty straight away I'd suggest this book: CLR via C#.
It is written for those with programming experience on platforms other than .Net and provides a clear and comprehensive explanation of C# and how it runs on the .NET CLR.
By reading this initially you might avoid writing some of the poorly constructed applications that many of us wrote before properly understanding the technology.
Buy a book on C# & .NET FW fundamentals!
Read! :-)
Read good books about .NET for example CLR via C#.
Read this:
Hidden Features of C#? https://stackoverflow.com/questions/380819/common-programming-mistakes-for-net-developers-to-avoid
Related
I am trying to port an existing C#-WPF-Project as an iPad-App.
As far as I found out by now, the best way to go would be to use MonoTouch and reuse as much C#-Logic as possible.
As the original project is written with WPF for an actual TabletPC, my question is, if there is any way, to reuse the WPF-sources or at least minimize the part I have to write again.
If there are any good alternatives to MonoTouch, I would appreciate tips too :)
UPDATE: Your comments were helpful, but are not 100% what I was looking for. MonoCross looks nice, but as far as I understand, it just "hides" the iOS-specific part. What I would really love, would be a way to reuse the handwritten "special" WPF-Controls. (Or at least minimize the work/time to transfer them.) This would be awesome.
UPDATE 2: Maybe I should add, that I would also accept some "complicated" three-step-technique. For example, is there a way to translate the XAML-WPF-files to HTML5 (or something equally powerful) and then use Titanium or PhoneGap? The Languages and Frameworks shouldn't be the big problem, I just try to find a way to reuse as much as possible :)
Please see this previous question which is related and may be of interest on creating cross-platform iOS, Android and WP7 applications.
In response to your question, no it is not possible to re-use WPF Guis on iPad, IPhone, Android. Only Windows Phone will support silverlight views. To workaround this you must use a Model View controller architecture (as iOS, Android won't support databinding via MVVM) on all three and create separate views for each architecture.
While this may sound laborious, please note that if you correctly architecture your application so that key business logic and presentation logic is inside the Controller (or services) layers then you can re-use a large proportion of your code. This is the same limitation as if you create cross-platform code to dual deploy to Silverlight and WPF on Windows. The Xaml files often have to be specific to each framework, however often *.cs user controls and viewmodels / code logic can be shared.
UPDATE: Following your Update(2) in question.
Yes, you can use a third party server to translate XAML-WPF-files to HTML5 - the ComponentArt Dashboard Server. This claims to translate WPF/Silverlight applications written using strict MVVM to HTML5/JS for portability across multiple devices. I can't vouch for how effective this is and I do know it is expensive, however if you are seriously stuck and want to port WPF -> HTML5 then it is worth investigating this.
Best regards,
When learning the C# language. With all the applications being developed these days. Would I be better off focusing on windows forms development or WPF development. I want to develop software that uses ADO.net for SQL Server database access. Also stand alone applications to integrate with Microsoft Office to create charts and graphs etc...
Although for the purposes of Windows UI that both can achieve similar results, their function is independent of one another as is their purpose.
WinForms is tried and true, non-evolving due to strong roots. It does not mean WinForms is deprecated. It just means that the foundation classes for WinForms are well established and flexible. Keep in mind the flexibility in extending WinForms via the Control class and deep-engineering UI messaging (via handles exposed by the WinForms classes).
WPF however is an abstraction layer to design user interfaces, not necessarily or exclusively Windows user interfaces. The most difficult hurdle to leap is transitioning from the thought of coordinate based user interfaces (pixel/bitmap/index) to vector based user interfaces where WPF can adapt to virtually any size control or plane of rendering.
The benefit of WPF is that you're learning three different targets for your applications - Windows UI, SilverLight, and now Windows Phone. WinForms targets Windows UI and Windows Mobile (CE). A clean UI based on common widgets has an appropriate foundation in WinForms. If a customized, dynamic UI is your target, take WPF for a spin.
I'd be using WPF as it also allows you to do Silverlight applications using the same XAML markup.
Having said that, there are horses for courses so you need to choose the appropriate tool for the job. That does mean you need to know both to make an informed decision. :)
The learning curve with WPF is definitely much steeper - at the same time you can easily whip up some simple UI in Windows Forms to fill your needs in regards to ADO.net or SQL Server database access. Once you add charts/graphs to the mix, you are going to want to learn WPF hands down though.
Also you might want to look at Lightswitch, which takes care of some of the complexity with Silverlight/WPF.
Though WPF is the future and it gives you so much flexibility, I don't recommend switching completely to WPF. Also, you will be able to make the most out of WPF if you have a designer that will be able to work on the design part. I'm not saying you need to have a designer but based on my experience with WPF, if you want to develop a killer looking application, you definitely need to have some one that knows the bits and bytes of WPF. Just as BrokenGlass said, the learning curve with WPF is too steep. So, just make a gradual switch. If you already have some Windows Form applications, try to rewrite some of those in WPF.
The kind of stuff you're trying to do can be done with both WinForms and WPF. WinForms is a more familiar paradigm but (big but) XAML in general, WPF in particular, is not the future but the current way of doing Windows UI's in .NET, WinForms being the past it is basically in maintenance mode (good for existing apps, dare I say obsolete for new apps). Yes, XAML posses a somewhat steep learning curve, but the abilities you get are worth the effort, besides there are more and more resources (books, libraries) on XAML/WPF/Silverlight while for WinForms there are plenty but stagnant (I haven't seen any new edition of a WinForms book in a couple of years). One thing worth noting is the databinding capacities of XAML which render unnecesary many of the code moving data from/to objects/datasets to/from visual controls.
WPF and XAML is a learning curve but my experience is can build more powerful, concise, and supportable applications in in less time. Can copy and paste XAML from one page to another. On Windows Forms I gave up on copy and past of UI elements from one page (form) to another as too many times it locked the whole app. Two way data binding is a dream. WPF UI has a more commercial grade look. Portability to Silverlight. For me it is 98% of what I would get from C++ in a fraction of the effort.
As your prime objective is to learn C# you should concentrate more on language features rather then your UI. You should try to learn and use various features of C# and what all it supports and how. Learning(C#) will be much more in developing Business layer and Data layer of your application rather then your UI; so you should concentrate on building these layers first(with any presentation framework).
I am not sure whether you have any prior experience in any of console applications, WinForms, WPF or ASP.net but for learning purpose you should pick one you are most comfortable with. In case you are starting a fresh then I would suggest you to first start with WinForms as you will be writing a lot of C# code in WinForms then in WPF, and later pick up WPF.
My answer is totally focused on fact that your prime goal is to learn C# and not on which UI framework is better etc.
I have to develop a basic "line of business" application with the usual functionality like orders, stock control, sales, reports, etc.
I will use WPF to develop this application to run on Windows but I want to develop it "open" so I can do a Windows Forms application using the same structure (maybe to run over Mono) or even a Silverlight module. Can someone that did something like that (and survived) give me a sugestion on a guideline or something like that where I can find good practices? I'm a Delphi developer with some intermediate knowledge on C# but there are so many "amazing" libraries, frameworks and patterns that I'm a little lost on what would be good for that project.
Something like: Use EF (maybe wait for ef4?) or nHibernate, or ADO.NET, and expose your data using WCF, or webservices, or forget Mono because of the flexibility loss, etc. Can someone give me a tip on how you would do it? If someone has a bad experience in this type of project, it would be nice to hear from you as well. There is a lot of learning in the wrong decisions too :)
Mono doesn't implement WPF, it's not even on the roadmap. I'm not sure about Entity Framework...
You could probably do it in Silverlight (which has an open source implementation), but it's not ideal for creating desktop (although it is possible since Silverlight 3)
Where do I start?
First, from your description, you're in over your head.
Second, you're trying to pick a technology stack when everything is new to you.
In the best situation, I'd recommend a good training class in a few of the technologies you mentioned so you get a better understanding of them. I'd also recommend a mentor, someone who's done this before.
Reality though, may not allow for training or a mentor. In that case I'd recommend writing several real-life throw away programs. Take one piece of business functionality and try to write it in a few of the technologies you mentioned. If one feels better, and gives you what you want DECISION MADE! Don't stop with the first one that seems to work, try some more.
You should also listen to some good podcasts. I recommend Dot Net Rocks for a good grasp of the technology. The earlier podcasts for this site were also a very good source for some design discussions StackOverflow podcast
Best of luck.
I had to do something very similar recently in WPF. I have an ASP.NET background, but I have never worked with WPF (or WinForms for that matter), and it had me stumped for a while, but the longer I have been working on it (about 3 weeks now), the easier it has gotten. I really just searched Stack Overflow and Google for code snippets similar to what I was doing, and worked through them and changed them as needed. My company bought a book that helped me out as well (It was WPF Unleashed published by Sams), and it was pretty good. I do wish you luck on your first WPF app.
If you separate the business model and business logic from the user interface,
using MVC (Model View Controller) or MVVM (Model View View-Model) or a simular design pattern,
then you can have multiple user interfaces connected to the same business model + business logic and even connect the same user interface to other business models + business logic.
Thank you all for your suport... Brad, I'm already following your advices, doing some test cases to see what looks good... my problem is that altough I can develop an application in WPF and have a intermediate understanding in using the wpf databindings, generics, linq, anonymous objects, all the cool stuff, I always hear about this and that as the solution for all the worlds problems (like mvvm, or parallel programming, or functional languages, etc) and makes me feel "wrong" in my decisions and a bad developer if I do not use any of this nice technologies. I know the concepts but do not dominate it, and seems a lot of things to learn, sadly I do not have that much time.
Thomas, exactly because mono do not support WPF i want to make the application as isolated as i can, so I can do a simple winform layer to manipulate the data.
darthnosaj, thank you, I'm doing that too, searching internet and found much information (and this nice site full of hellpful people :) )
And Danny, thats what i think i need... will take a look on some sample applications using mvvm and see if that works for me. For what i heard is almost a crime not to use in that case in wich I want that kind of isolation.
Again, thanks all :)
I would suggest you keep your application N-Tier. Make all the entities, data adapter, and business logic separated from the actual desktop application. This way you can use WPF on the Windows platform and use Mono/GTK# on the Linux/Mac platforms.
You will only need to write duplicate code to support the actual GUI application functionality, while your code from the separate entity/data access/business logic library (e.g. DLL/class library) can be used in both your WPF and Mono/GTK# projects. Just add the DLL as a reference to the WPF and Mono/GTK# projects.
There is a good video from Channel 9 on building N-Tier applications
There is also MSDN documentation and guidelines on building N-Tier applications
I am a long time MFC programmer and know it quite well. Recently we are planning for a large desktop application. In order to beat competition, one requirement is polished UI. We narrow down the choices to three:
WinForms
MFC
QT4
We looked at some big WinForms applications, such as Paint.Net, and feel that it still lacks power of performance. The startup takes a while and some UI parts do not look very nice.
We had great hopes in QT4, but after writing several programs on it, we find that the looks of a QT4 application is not at par with native Windows UI. It still looks differently. Also we worry about about lack of widgets (for example, the color picker and calendar control in the library quite suck).
MFC is a safe bet, especially with components from Codejock.com. The UI interface looks quite polished with codeJock toolkit. And all widgets needed are there. The problem is that its coding style is quite outdated.
What will you choose for your next desktop application?
WinForms is effectively at the end of its life now. You should look at WPF.
See WPF: Any cool UI ideas i can look at? for links to some nice examples.
WinForms is really easy to get into if you know MFC (it's still based on the core Win32 concepts, so you don't need to learn much to get up to speed). Compared to MFC, you can develop much faster, and there is so much more library support for everything in .net that you have to write for yourself or find 3rd party libraries for in MFC. Often I find the .net solution to a big problem is around 3-10 lines of code, whereas the equivalent MFC solution would be hundreds or thousands of lines. I wouldn't even consider MFC a starter now that I've used WinForms in C#.
We're building some very large C# applications and the performance is perfectly fine. If any small part of the program is really performance-critical, it's really easy to plug in a bit of unmanaged C++. I found startup times abysmal in XP in the early days, but with more recent .nets and Vista, startup time is comparable to MFC apps.
So I'd go for WinForms/.net at a minimum.
WPF is also a sensible future-facing approach to consider.
WPF is a good option if you've got design skills or can ask for someone to prettify your UI. I think it's definitely one of the most versatile options.
You could also use components like DevExpress or Telerik, both have an extensive library of WinForms controls and as of recently WPF controls. I've used DevExpress myself and am rather pleased with the looks. Although these library don't come cheap, but they do carry quite a lot of functionality.
I've never worked with QT4 so can't judge that.
For my next desktop app I would use:
on Windows:
Probably the old fashioned Windows API (without MFC) because I am familiar with it.
Maybe Qt, because I'd like to try it out.
on MacOSX: Cocoa
on Linux: Qt
Not that I am very fond of MFC, but if you are comfortable with it, go ahead. It is not going away any time soon, although it surely won't be updated and improved as much as WPF.
Having spent 12+ years developing MFC applications, and now using WPF for less than a year, there is no way I would go back to MFC. At previous employers, we would spend countless hours customizing UI behavior and getting the right graphical look that would take a fraction of the time in WPF. Not to mention the added flexibility of being able to work with the UI as XAML (XML,) as opposed to the rather outdated resource editor.
If your application has to be C++ (as opposed to C#,) then I assume that using WPF would be a little more non-trivial. I haven't done .NET inside of C++, but I remember the overviews presenting it as a fair amount of extra work.
We at my work are currently revamping a GUI app from VB6 to make it look "prettier". We've chosen the .NET winforms platform for our upgrade since most of our coders are familiar with it. .NET has a few libraries dedicated to graphics, and there is a wide range of nice-looking user controls already built into the library. Asside from those, there are many, MANY custom-made controls out there such as the ComponentONE library, and there are a lot of opensource controls for enterprise use that look nice as well (you can search CodeProject.com's articles section for some free, downloadable controls that look very vista/windows 7-esk).
The framework also natively doublebuffers windows, and has bufferedGraphics classes that you can use to manually handle doublebuffering if you so choose.
However, windows forms do still ghost when dealing with high res images as background pictures and the only way to really fix it seems to be to use the DirectX libraries to draw using the graphics hardware on the machine (which is difficult, but atleast its free).
Hopefully that helps your decision on the platform form the windows-forms side.
I would still consider MFC. It's far from dead and especially with the new 2008 feature pack. You get a host of updates and can now create those fancy ribbon UI elements. If you already know MFC then you know the pitfalls (old but some are still there) and can knock out the work quite quickly.
There a ton of UI components you can buy for MFC and it has the benefit of being fairly close to the metal as far as speed goes. There is no need for your end users to install a framework or anything else.
I write C# for my day job, but all my personal projects are MFC/C++ since they don't require my users to have additional frameworks,libraries,etc installed.
I have been a web developer for my entire development career. Nearly 100% microsoft focused the entire time. I have been using .Net, both C# and VB.Net, since beta. I now find myself in a position to where I have the opportunity to start doing some WinForms development in C# using the 3.5 framework. As with anything new, I am excited about the learning opportunity in front of me.
I am curious if anyone has any suggested books, articles, feedback, etc on the topic of transitioning from web development to winforms in the .Net world.
I think it goes without saying that the paradigms are very different. I really enjoy C# because of how easy it is to write great windows software.
Start by getting into the IDE and creating a real but small project. One of my first C# projects was a light weight budget program. That took me into many areas of C#, from XML handling to custom windows controls, to debugging, and more.
Experience is the best teacher. Take time to look at the function lists, and peruse the documentation. Get a feel for what is in the thousands of classes that make up .NET.
Reading books can be nice, but getting your hands dirty (in conjunction with a good book) is far more effective.
Set a goal and go for it, you will have no problem learning all about it. Don't be afraid to try things and take risks -- it helps you learn the system.
If you are moving from Web to Windows, there is a some significant differences between the two enviroments. Some good and some are bad. If your .Net based and moving to 3.5 look into WPF since it is the best of both worlds for Web developers converting right now.
I do know of some common mistakes made by web developers making the crossover. They would include:
Opening database connections on every form and every database calls. (In Windows Bad)
There is no ViewState concept or Stateless concept in Windows
I am sure there is a few more that can be added but right now I can't think of an exact list.
I do agree with gahooa, look at doing a small project and read as much as possible on the subject. Approach it as if you never developed before, and the skills you gained over the years will automatically kick in when needed.