I recently started playing with C#, but I am finding it very frustrating. It seems every time I want to add what I think is a simple control, I end up either scouring the internet or writing my own. I just feel like I spend more time recreating controls to get them to work the way they should, and less time actually creating applications.
For example: In another question, I asked if it was possible to remove the border on a combobox; something I thought should be built into the control, but alas I had to build my own control for this simple alteration.
Am I just too new to C#/.net, or am I just expecting too much? I know SO loves C# so don't bite my head off for feeling this way, just help me understand what I am missing and whether I should continue learning and working with C#.
I spent 4+ hours today tracking down an 8 byte memory leak in a C++ program. There are threads involved and attaching the debugger would alter the thread timing so I couldn't do even something as simple as breaking on the Nth alloc to see where the leak was. Additionally I knew generally in between which two events the memory was allocated. Unfortunately both threads thought that was a great time to allocate lots and lots of 8 byte size objects. At the end of the investigation I found a ref count error on a COM pointer was leading to the leak.
Not having to pull your hair out over investigations like this is why you should move to C#.
For example. In another question I asked if it was possible to remove the border on a combobox; something I thought should be built into the control, but alas I had to build my own control for this simple alteration.
Of course you can't remove the border on combo boxes. They are Win32 controls and they have to play by the rules of Win32. That inlcudes giving the OS and the user, not the application control over styling.
If you want something you can style completely on Windows then you need to look at WPF.
I think what you really mean is:
Windows Forms on .NET is increasing my development time - am I missing something?
I think you are missing several things:
Open mindedness - with any new programming language comes not only new syntax, but new paradigms. If you come from C++ paradigms such as garbage collection may sound "too automatic" from you and you'd like to have more control but alas, you have to let go. Whenever you jump from one paradigm to another the prerequisite is always the ability to unlearn what you've always known.
Windows controls aren't the same as web controls - I've checked your previous questions and they look like you've been from VBScript, which probably means that you use it either from Office or ASP Classic. That being said your demand for controls that were easy to conjure when you were in the web would be much tougher for Windows -- Windows was not designed to be easily modifiable. That's why WPF/Silverlight was made.
Productivity is a function of ability to learn - There, I said it. It might hurt but, if you have cynicism or hostility blocking your learning process, you will simply not become productive soon. If you've been used to not having to learn new things, you will also not become productive soon. If you think you're really good at learning new things you will find ways to become productive in that language -- and then we can discuss about merits of your arguments vis-a-vis development time.
With any new technology there is a substantial learning curve at first, and some have a higher learning curve then others. I think you will see as you gain more experience that these things become substantially easier. C# has a lot of power with the .Net architecture to leverage from, but a lot of it takes time to really appreciate. C# is also changing and growing to allow for new coding styles (newer versions incorporate a lot of influences from functional programming) that keep it both in vogue and powerful. Stick with it and keep learning.
You're not the first, nor the last developer to have this sentiment. It always seemed to me that every time I needed to do something that wasn't part of a demo, I had to spend hours trying to figure out how to accomplish one small task. Much of my frustration was with ASP.NET web controls.
That being said, I found that once I got over the (steep IMHO) learning curve of control development, many of my frustrations were eliminated. I feel that using inheritance and overriding virtual members to create new behavior is a very clean approach. Plus, it creates output that can be very easily reused. Using OO practices just always seemed better to me than pasting JavaScript snippets all over the place.
Microsoft does a good job of providing many base controls to use out of the box, but every application always seems to need something that's missing. I would recommend learning control development, or looking to third party solutions if possible. There are many companies that exist solely to fill the voids. Either way, I wouldn't judge the whole language based off of the default control set.
It sounds like you are just new to it. It's not C# that's the problem it's the .net framework. If you used VB.net for example you'd likely have the same issue.
I went through this issue when I went from classic ASP to ASP.net. For half a year or so I felt the things I wanted to do in ASP.net were so much easier in classic ASP. Eventually that went away. Now I'm going through it again as I try to learn ASP.net MVC. Things I could do in 5 minutes in ASP.net are taking me days to figure out in ASP.net MVC.
In your case it sounds like you are using windows forms. Were you working with winforms before (i.e. VB6)? If you want more control over styling you might want to look at WPF.
Yes. You are missing something -- experience with the tools you are using.
For example, a few months ago I decided that my next project would be in ASP.NET MVC. I had been doing WebForms for several years and had dabbled with RubyOnRails for a couple of personal apps. MVC fit in with my desire to increase the testability of my apps and I prefer writing my own HTML for the most part anyway.
Despite my experience with ASP.NET, C#, and experience with MVC in RoR, it still took my awhile to match the velocity I had with WebForms. I felt like I had to spend all my time looking for how to do stuff. Now, a few months later I feel like I'm able to develop just as quickly as before. More to the point, I know the various paradigms and can apply them easily when faced with a similar problem to one I've solved before. I'm also building up a collection of extensions, snippets, and components that can be reused over and over.
I suggest that you give C#/.NET a chance for long enough to get over the inevitable early struggle and then decide whether it's the technology that's the problem.
Could it be that what you're trying to do is not, let's say, common? Most GUI developers follow some sort of human interface guidelines so that their application fits in well with the window manager of the OS being used. It helps with the user experience. Most GUI elements are designed with this in mind. So, it could be that you're trying to make your interface radically different than most, and thus, are finding that you have to do some custom work. That would be normal.
Depends on where you are coming from. I find c# to be very effective.
I rarely if ever use other controls as they often do not work 100% to my use cases and they create dependencies on your app.
So when you want to upgrade your project to c# 4 and can't because control X Y and Z don't work in c# 4 ... your SOL.
So I just take the hit up front and write my own controls which causes less grief later.
Related
In our company we develop and sell a VB6 application and we think it's about time to migrate it to .NET.
The main reasons are:
We expect VB6 runtime support to end at some point in time, and we do not want to start the migration just then since it's probably gonna be a lengthy process.
There is just 1 1/2 VB6 developers left. The half one being me.
More and more customers asking for features like cloud and mobile device support.
I know that rewriting an application from scratch is the least recommended way for migrating to .NET. I totally aggree with that! Throwing away over a decade of code feels just wrong and would be such a waste of money spent, that I have a hard time recommending and justifying it towards our management.
But right now I don't see another way to do it.
Let me tell you a little bit about the application:
Like I said it has been developed for over a decade. There have been numerous developers working on it, most of them rather unexperienced at that time. We have one developer left from the initial team. That application has been his first and biggest software project and by now he realizes that many of the architectural decisions made over last 15 years have been horribly wrong, others were right at that time but have not been refactored to meet changes made in other parts of the application and so have become wrong at some point in time. This application seems to be a showcase example of code rot.
We are talking about an application of about 150 KSLOC, all in one single executable. It uses about 15 external DLLs, some of them third party ActiveX controls, some of them are our own .NET assemblies.
Adding new features to the application is still possible and being done, but takes ages compared to our other .NET applications. The reason is that every little change in the codebase requires changes all over the place. The only reason why changes are possible at all is because that one developer simply knows most the dependencies and quirks of the application. As you might have guessed the rate of unexpected side effects and bugs is quite high.
My first thought about migrating that application was to first clean up and refactor, then migrate/convert possibly using tools from Artinsoft/Microsoft/WhoEver and then refactor again to get a nice and clean .NET application.
But I see some problems:
There seems to be no way of refactoring the old application. There is no automated testing whatsoever, not even a formal method for manual testing. Every little change requires manual testing by experienced users who just know where defects might hide.
on the other hand I have established a process and set of tools for testing of our .NET applications which gives us a solid base for making refactorings
Converting that code to .NET without major refactoring feels like: Garbage in, garbage out. Even though I hate calling the old application garbage because somehow it works and has proven itself useful.
Our management has a habit of explicitly demanding quick and dirty solutions, disregarding the effects it has on the productivity and against all recommendations from the development team which has at some point started to deny the existence of quick and dirty solutions in order to be able to do things right. That does not mean that we polish features, but we do include the time to write tests and do refactoring in our estimates. So knowing this, I suspect that once the code is converted to .NET and fixed to the point where the application starts and seems to work, the refactoring-phase will be canceled and the application will be shipped to some customers.
So. What I think is that, despite the fact that rewriting from scratch will take a lot of time and resources, it might still be our only option.
Am I missing an option? Do you see possibilities of not having to rewrite that application?
I suggest that you take a step back and read this paper by Brian Foote & Joseph Yoder (University of Illinois). It provides some architectural insight into the problem you have and options to solve it. It's titled 'Big Ball of Mud' (please don't laugh, it is a serious paper). Here is the abstract:
While much attention has been focused on high-level software
architectural patterns, what is, in effect, the de-facto standard
software architecture is seldom discussed. This paper examines the
most frequently deployed architecture: the BIG BALL OF MUD. A BIG BALL
OF MUD is a casually, even haphazardly, structured system. Its
organization, if one can call it that, is dictated more by expediency
than design. Yet, its enduring popularity cannot merely be indicative
of a general disregard for architecture.
These patterns explore the forces that encourage the emergence of a
BIG BALL OF MUD, and the undeniable effectiveness of this approach to
software architecture. In order to become so popular, it must be doing
something right. If more high-minded architectural approaches are to
compete, we must understand what the forces that lead to a BIG BALL OF
MUD are, and examine alternative ways to resolve them.
A number of additional patterns emerge out of the BIG BALL OF MUD. We
discuss them in turn. Two principal questions underlie these patterns:
Why are so many existing systems architecturally undistinguished, and
what can we do to improve them?
BTW, I think your best option is to use the current application as your Requirements and rewrite everything in VB.NET or C# using a proper design.
There are four main options when you have an application like this:
Do nothing: this is always an option, as everybody knows, if it ain't broke don't fix it. However this might not be an option for several reasons such as needing to comply with some security requirements at the company, or simply because one of the components doesn't work in new platforms.
Rewrite: This would be the dream, right? being able to get rid of all the bad practices and duplicated code and so on? Well, it might be that way, however you have to think all the risks involved in developing a new application from scratch. Do you have all the formal requirements? what about test cases? do your team know every little detail in the code or would you need to go line by line trying to figure out how why that if is there? Also, how many bugs do
Buy something off-the-shelf: Since you are an ISV this won't be an option.
Migrate: Of course you'll be bound by the programming practices you used for the original development but you'll get to a new platform faster, all your business logic will be automatically migrated, you can actually hire developers for the new platform and you can get rid of the legacy elements. From here you can also take advantage of all the tools available to refactor code, continuous integration, unit testing, etc.
Also, with an automatic migration you can actually go further than just WinForms. There are also tools that can take your C# code all the way to the web using a modern architecture.
Of course, I work for Mobilize.Net (previously Artinsoft) and this is my biased perspective.
We've been working on this for around 15 years and have seen dozens of clients who come to us after trying to re-write their application and fail after months or even years of struggling without being able to deliver a working application.
I am new here and new to windows mobile development. But I have seen and experienced, for new developers having no trainers or experienced people around windows mobile development is like a hell shaking one. In complex topics you are going to find help from nowhere except you are lucky.
So my question is how should I gain expertise in windows mobile without having any trainer. The thing that i only know is C# and have a rough experience of one and a half months in windows mobile development
Yea.... it's quite a step to be honest. It's evil as well because at first glance it looks to be so very simple but then it turns around and bites you.
I speak from experience as I made this journey starting in 2003. Oh, I had no trainer either so I just learnt via bitter experience.
Know your limitations
I remember the first ever CF application. I was such an idiot..... I wasn't much good at developing back then either. First mistake I made was overestimating CF 1.0. I couldn't possibly imagine that the CF didn't have a read-write datagrid so I specced it...... then found out that oh yes, there wasn't one. So I had to write one myself (and remember I was rubbish at this time too). I hacked one into the existing datagrid (although tbh I should have just started from scratch). I remember that the "delete" function where I had to remove a row and then select the "now currently selected row" was hellish because it would go up or down depending on how many items were in the collection and where the scrollbar was.
There are many times that my desktop development buddies will categorise me as mad when I tell them what i'm working on.
"You're doing manual Xml Parsing? Are you crazy?"
"Ewwww code gen?"
"You.... re-use your windows forms?"
Yes, working on CF will make you look crazy to outsiders.
Performance
This can be taken to extremes but every little does help. If your building a big flexible application then think very carefully about perf. Consider replacing Reflection with codegen. Consider using an XmlReader instead of an XmlDocument. Sure this advice might be crazy in most cases for desktop but for CF it is sensible.
Know your PInvokes
In desktop land you can live in pure managed. No chance of that happening on CF. Some of the simplest things (playing a sound, setting the time, changing the volume, networking, etc etc) still only exist in the unmanaged world in Mobile. OpenNETCF have done an awesome job in exposing some of these but you will always stumble into one or two where you will need to write your own.
There is true, there is false but there is also FILE-NOT-FOUND
PowerManagement, how I love thee. In a usual C# app code goes the way of the logic (like a fork with an IF), perhaps an exception will be thrown and perhaps there will be many threads treading the path of the code. This is already complex. Add into the mix the idea that the power might vanish at any point. That's right, the using statement you were relying on to call Dispose might never call dispose because the device was turned off and then it ran out of power.
Device specific fun
Another big difference in desktop/mobile world is hardware and manufacturers. On the PC you can generally assume that the hardware will be okay and firmware updates should do the job. In CF a firmware update may well kill your code. Some hardware might sorta, kinda work if you bash it round the head in a certain way. Basically your device integration can (worst case) be a big black hole of time. Remember to work this into your estimates.
Learning to write actual maintainable, saleable and usable applications for the Compact Framework is difficult. The CF is way, way scaled down, so there is a lot that a desktop developer will not have that they are used to. I'd been developing CF applications since before the CF existed and I still find many things difficult (just try getting a control with transparency drawn into a container on a form with a background image and doing it without looking at the code in Project Resistance).
In my opinion, there really are 2 things that are essential.
You must be able to read and understand C/C++. All of the SDK docs are in C and a large amount of samples for using anything useful on the device tend to be in native code. If you can't translate that, you're at a serious disadvantage and you have to hope someone else has already done the work. Even if they have, they you have to rely on them having done it right.
You need CF experience. Desktop experience is largely worthless in the CF environment once you get past syntax. Laziness like data binding, using Data Sets, not cleaning up objects and all of those things that desktop developers do every day will kill a CF app. You need to throw out what you think you know and start re-learning. You do that by simply writing code every day.
Don't expect miracles either. I've been writing code for Windows CE for over a decade now and the amount of things I don't know about the platform still far outweighs the things that I do know.
If I understand your question....
If you have c# experience, you will not really need a trainer.
Building on Windows Mobile is very straight forward and easy if you know .net.
If you have Visual Studio (I think any edition apart from express), it is simply a matter of starting a new project and selecting mobile device.
I honestly love it! I build small applications all the time for my phone... little calculators for when I go shopping, programs that fire off a trigger and get a response from a web service and more... basically to make my phone do what I want (and no one else would be interested in).
I go by the method of simply writing an application the way I want and then if a feature is not supported by the cut down .net compact framework, I try and search for an alternative method that is - however, I have found little that doesn't work.
Developing in the CF can be challenging. Knowing C# is important before moving forward with the Compact Framework - to which you have. I would suggest that you start with smaller applications. Once you get the feel of Visual Studio and working with the emulator, I would suggest that you play around with a setup project. Once you get an idea on the flow of CF development, deployment will probably be your next step.
One area that I find that I spend time on is Designer support. If you are writing controls for other developers - design time support is crucial. Checkout the article at http://www.mooseworkssoftware.com/VS2005%20Control.htm for more information (I know its for VS2005, but it really helped our development).
As you move forward, create small projects in different areas and learn the pitfalls to each. An example would be GUI and dealing with different screen resolutions that are supported by different devices. Next, maybe DB support. After you get comfortable with a couple of areas, bring them together in a project and build from there.
Give it time - sometimes it will be painful, but the possiblities are endless in writing applications for the CF and what the market is calling for.
Craig
To answer your question, Windows Mobile is like paradise for new developers. You use the same tools and languages you are used to from the desktop world and essential things like in device debugging and emulators are just there for you. You can build simple applications with no training, just by following one of the many beginners tutorials available.
After that, there are of course many complicated and difficult issues to overcome, but in my opinion the fact that you will be able to start quickly is very important.
Also, you need to also need to compare Windows Mobile with other mobile platforms. Compared to platforms like Symbian, Brew and J2ME Windows Mobile is much more advantageous for new developers. I don't have experience with iPhone and can't comment about it, but comparing to everything else, Windows Mobile is easier.
So I've been learning C# for like a year now (I'm 20 years old) and I'm getting pretty confident with it. I've also been meddling with C++ every now and again. For example just recently I've been following the Nehe OpenGL tutorials for C++ and I find it a fun way of learning.
I want to start looking at creating cross platform GUI software after I stumbled across this library called FLTK (fluid something rather). After finally and painfully getting it to work I found it refreshing to know that there are solutions for GUI creation in C++, however I think FLTK looked pretty old.
So I googled around for some newer GUI frameworks and decided to start playing with wxWidgets (decided against Qt because of licensing).
I downloaded it, compiled it, and looked to see if there were any IDE plug-ins for RAD development, as you can imagine going from drag and drop a component onto a form in C# I was hoping for something similar.
I learned that code::blocks has something of the sort so I tried that out. It was alright but the thing that turned me off was the horrible code completion; it would only show members and methods in the current object and nothing for the #included header files. I understand that code completion/IntelliSense isn't easy for C++ but Visual Studio 2008 handles it pretty good. I did find some other RAD tools like wxFormBuilder but it costs money, not something I want to do for simply learning.
So my TLDR question is if anyone has had experience with wxWidgets? Do you just develop in whatever IDE you're comfortable with and just code the GUI? Meaning no visual helpers? Perhaps you could give me a nudge in what direction I should be going :)
Thanks, this is also my first post on this site albeit I have read many threads before that have helped me solve copious problems. Cheers!
My suggestion is to learn how to do GUI layout with wxWidgets in code, then when you get good at it learn how to use the GUI tools.
Doing this kind of work manually for a while gives you the understanding about what you need ("Ok, I need a wxSizer, vertical, to put these two horizontal wxSizers into, where I put my a wxStaticText and a wxTextCtl for each line ...")... where as I think if you started out with the GUI tools you'd just tend to get annoyed because (last time I looked) none of them were Drag And Drop editors like you get with .NET.
Definitely give Code::Blocks another try. It is a WONDERFUL environment to work with wxWidgets in. It comes with a form designer and templates for wxWidgets projects, so I can't imagine working without it.
Also, for a good beginner's introduction to wxWidgets, try this page. It helped me alot when I started with it.
I use wxWidgets without using a drag and drop designer. There are obviously drawbacks to that approach but an advantage is that you don't have any horrible automatically generated code to deal with. In the past I've found having such code in the middle of my project has caused various types of grief - especially if you decide it needs some serious changes it is often necessary to start from scratch because form designers are so much better at "writing" as opposed to "editing".
For simple applications you can assemble a UI using a mixture of customized and standard widgets without too much difficulty. Check out the wxWidgets samples and demos, which use that approach. My chess app (see my website) uses this approach too.
A more elaborate UI could possibly be implemented by writing something special at a higher level of abstraction. The kind of thing I am thinking of would be a subsystem that accepts high level flexible requests to provide different types of user interface functionality, and then sorts out the details of the controls to create and the positioning etc. of those controls itself. That is kind of a technical fantasy of mine but I haven't ever really attempted to do it. Actually, a fairly primitive facility of this type is already available and used by the demos I mentioned; It is called a "Sizer" (class wxSizer) and is basically a control container.
Finally I would point out that problems with the Qt licence have basically gone away since Nokia bought Trolltech and made it "more" free (LGPL licence). Many people think Qt is the way to go these days. I am pretty happy with wxWidgets but will definitely evaluate Qyt seriously one day. Good luck with your projects.
I have developed a number of application GUIs using wxWidgets - you can see screenshots at http://ravenspoint.com/
IMHO, you should distinguish between designing a GUI and implementing it. Expecting to use the same program to design your GUI and to automatically emit all the code to implement the design is expecting too much.
A design program should be fast and simple. I recommend http://www.balsamiq.com/
Once you have settled on the design, then you can turn to the coding. Personally, I find that placing widgets on a panel using the wxPosition and wxSize parameters of the wxWidget constructors to be trivial - easier than trying to nudge widgets into their exact positions using the mouse.
The trouble with using some kind of form builder to emit all the code for a significant GUI is that you end up with a morass of automatically generated code that is hard to find your way around in. If the code has been handwritten, then you already know where everything is located.
wxFormBuilder but it costs money
wxFormBuilder is Free and Open source
Also Visual Studio is best for C++ coding in wxWidgets, but you will run into lots of issues on Linux due to the way Visual Studio handles a lot of things, like file names you have to take extra care for case sensitivity.
Also regarding the GUI, add the wxFormBuilder to the Visual Studio solution, add the file type handler to Visual Studio. Now just double click on it and add your dialogs, like you do it in C#.
Just add the generated code files to the Visual Studio project once and you are done.
It's very easy to use Visual Studio with GUI programming in wxWidgets.
Also don't forget to watch the CodeLite editor if you want to port on Linux. It is very much compatible with the Visual Studio projects and shortcut keys.
There is wxGlade and wxFormBuilder.
I don't know if there is another one, but the wxFormBuilder I know is free and open source.
You will find links to other tools on the homepage
of wxGlade (http:// wxglade.sourceforge.net/).
Most of these programs are able to output xrc files, which are are an XML representation of your GUI. It address the issue of complexity of the generated code but is not as powerful.
Yet personally I don't use any of these tools, except sometimes to see what it's going to look like before I do it but never to actually generate code.
I just finished doing a hello world program in both wx and fltk using the netbeans IDE. Microsoft Visual Studio WinForms or MFC was much easier than either. I needed cross platform capability so I could not use it for this application. I finished fltk in much less time than wx. The program was simpler, smaller, faster, and easier to write. Wx had pretty disjointed documentation and organization. Fltk was designed back in the "old days" when small fast and efficient was valued. That's probably why it seems "old" to you. I'm an old guy so it worked for me. YMMV
A few days ago, I read a question asking how many developers hand code their HTML/XHTML rather than rely on the WYSIWYG tools - https://stackoverflow.com/questions/406052/do-most-web-programmers-not-designers-use-wysiwyg-editors-or-hand-code-their
I tend to lean towards designing ASP.NET server controls rather than User Controls for use in my code. I do this so that I can reuse them by drag and drop into WYSIWYG and just set the few pertinent properties. This does cost a little extra in time designing the components, but simplifies things a lot when I come to using them in larger applications.
After having read that most developers seem to hand code rather than use WYSIWYG, it leads me to wonder: Am I wasting my time developing components this way?
Edit: To clarify - mostly, the original intent has been that these controls are for my own use. However, there have been a number of occasions when they could be useful for the rest of my team or potentially for public release. However, like most things, I tend to see the huge potential extra value provided by comparatively little extra work regardless of the probability that the extra value will be realized.
No, you are not wasting your time. Your potential user base will be larger if WYSIWYG users can easily use your components. If you are the only user of these components design them so they fit your development style. If you design visually then it makes sense to have WYSIWYG support.
You could create a UserControl and using different techniques get it compile into a dll that can then be referenced by your web applications:
Overview of some methods:
Link
Detailed method:
http://webproject.scottgu.com/CSharp/UserControls/UserControls.aspx
I never use the WYSIWYG tools cause it never trully is WYSIWYG once you facter javascript, and CSS and other things. (I know VS2008 got better but not perfect). And the designers are always sooo slow. I prefer to code using markup.
If your developing a commercial component that you intend to sell you should spend the time on having the most complete feature set IMHO. Including WYSIWYG. If your building components so that your or your team can use them, then you should evaluate the cost benefit of the time it takes to get your components that extra step.
I think you're not wasting your time, especially if you want to release these controls for other developers to use. If the effort required is truly "a little extra" and you find it helps you in larger projects I think your controls are improved by being WYSIWYG tool compatible.
Personally, I generally hand code HTML/XHTML but I like using WYSIWYG functionality on occasion. I've always found that controls that were WYSIWYG friendly were easier to use than controls that relied on all code being written manually.
For your own use you already know if you are wasting your time or not.
[me enters karma-bomb shelter]
For the public and the rest of your team I'm going to offer an opinion against the flow that you probably are... well not wasting your time, but possibly not making the best use of it.
I think very few web developers will take WYSIWYG offerings seriously, however if the majority can use your controls at a hand code level and the minority can do their drag and dropping then you've provided the benefit of choice which is never an outright bad thing. Except possibly where small children and good behaviour are concerned.
If you are more comfortable with your work in the WYSIWYG editor and developing server components makes your job easier, then I don't see why you should attempt to conform to other developers methods if what you do works for you.
I think you have to take that poll with a grain of salt. Just because most people on Stack Overflow say they hand-code their HTML doesn't mean that most web developers do. Tools like Dreamweaver and Microsoft Frontpage are highly popular tools, for instance, mainly because of their WYSIWYG features. Web hosting companies usually have WYSIWYG web page builders that are also highly popular. I hand-code most of my stuff too, but I do a lot of freelance work working with web developers from other companies around the world, and from my personal experience I would probably go so far as to say that most web developers DO use WYSIWYG tools. The more experienced a web developer is, the less likely they are to use a WYSIWYG tool, but those with less experience far outnumber those with a lot of experience.
You might pose the question, to yourself, "are other developers wasting their time hand coding controls?".
I'd typically just drag and drop controls on a page and alter the generated html when needed, if it's only used on one page. If the control and it's functionality are used on more than one page in the same web app, then I'd go to a user control. When it's going definitely going to be used across apps, then I only want to code once so I go to a server control I can easily distribute. I think the key is that it (the layout and functionality) are being used in multiple places, or you're about to use it in multiple places. It's just as much a "mistake" to have duplicate code in many places as it is to have spent more time developing reusable code for one use. Plus, it's software, so you can change it later!
I think your real question probably is, "is there a way to develop my UI that I should learn more about, because it might be better than the way I'm doing it now?"
Considering how fast things are changing, that's a question we are all asking pretty frequently. I reember the first time I saw sites that were developed with Ruby on Rails; and then I ran through a tutorial that had no step for wysiwyging; but everything was accomplished with CSS and themes; and it hit me that maybe Dreamweaver isn't the most productive environment for everything, and the result could be at least equally attractive.
Working through the MVC tutorials gave me the same jolt.
So I think it's at least worth trying the alternatives to make an intelligent decision about what works best for me, my skills, and my requirements. I want the best tools in my toolkit, even if I don't need them for every project.
Especially since you seem to appreciate that your current approach is taking a substantial amount of your time.
I would say that if it is indeed only a little extra work and it adds so much extra value it's hard to conceive it could be a waste of time. Users coming in behind you that look to use your components in future will find it a lot easier and will be saving a lot of time that would otherwise be spent coding by hand. Not to mention that if you can drag and drop a component with a mouse click and drag, then why waste the keystrokes?
Like everything else, the appropriate answer is 'it depends' ...
You have to measure the ROI of adding this functionality.
For the 'I'; Personally, I've never created a web control that would work for a wysiwyg editor, so I don't know how much of effort it is.
For the 'R'; If you work on a large development team, distribute your code, will reuse these controls yourself in a wysiwyg editor, or even just want the experience, then you will definitely get your return. But if doing this is based on future maintainence programmers; you may be leaning a bit into the over optimization side. (IMHO)
I would agree with the previous posts. I don't think you are wasting your time. Making your control WYSIWYG enabled allow users to do things both ways, threw the designer and threw code. Also some times it is easier to discover what a control does when you use the property editor, apposed to making your changes in code and then compiling and running the app.
When I started to program I loved WYSIWYG and used it for almost everything.
I started to code html by necessity, there was always something that i just coul not get right using just the WYSIWYG editor. Has time passed i realised that it was faster for me to simply right the html than using the mouse to set the properties, so as time passed i used more and more html until no more WYSIWYG editors for me.
Why did i tell you this story? because my personal experience tells me that a beginner programmer will love WYSIWYG and your efforts to make server controls and a advanced programmer wont give you any credit for it.
My opinion is that you should do as you prefer. If you do this way to please others, don't bother to if there is no beginner programmer on your team.
That's my 5 cents ;)
I think I would create the control if it's used in many places. Even you hand code the html, it still saves time, and simplify the work.
but I agree that hand-coding html/css is more efficient, WYSIWYG web page builders don't support this very well.
My company has developed a long standing product using MFC in Visual C++ as the defacto standard for UI development. Our codebase contains ALOT of legacy/archaic code which must be kept operational. Some of this code is older than me (originally written in the late 70s) and some members of our team are still on Visual Studio 6.
However, a conclusion has thankfully been reached internally that our product is looking somewhat antiquated compared to our competitors', and that something needs to be done.
I am currently working on a new area of the UI which is quite separate from the rest of the product. I have therefore been given the chance to try out 'new' technology stacks as a sort of proving ground before the long process of moving over the rest of the UI begins.
I have been using C# with Windows Forms and the .net framework for a while in my spare time and enjoy it, but am somewhat worried about the headaches caused by interop. While this particular branch of the UI won't require much interop with the legacy C++ codebase, I can forsee this becoming an issue in the future.
The alternative is just to continue with MFC, but try and take advantage of the new feature pack that shipped with VS2008. This I guess is the easiest option, but I worry about longevity and not taking advantage of the goodness that is .net...
So, which do I pick? We're a small team so my recommendation will quite probably be accepted as a future direction for our development - I want to get it right.
Is MFC dead? Is C#/Winforms the way forward? Is there anything else I'm totally missing? Help greatly appreciated!
I'm a developer on an app that has a ton of legacy MFC code, and we have all of your same concerns. A big driver for our strategy was to eliminate as much risk and uncertainty as we could, which meant avoiding The Big Rewrite. As we all know, TBR fails most of the time. So we chose an incremental approach that allows us to preserve modules that won't be changing in the current release, writing new features managed, andporting features that are getting enhancements to managed.
You can do this several ways:
Host WPF content on your MFC views (see here)
For MFC MDI apps, create a new WinForms framework and host your MFC MDI views (see here)
Host WinForms user controls in MFC Dialogs and Views (see here)
The problem with adopting WPF (option 1) is that it will require you to rewrite all of your UI at once, otherwise it'll look pretty schizophrenic.
The second approach looks viable but very complicated.
The third approach is the one we selected and it's been working very well. It allows you to selectively refresh areas of your app while maintaining overall consistency and not touching things that aren't broken.
The Visual C++ 2008 Feature Pack looks interesting, I haven't played with it though. Seems like it might help with your issue of outdated look. If the "ribbon" would be too jarring for your users you could look at third-party MFC and/or WinForms control vendors.
My overall recommendation is that interop + incremental change is definitely preferable to sweeping changes.
After reading your follow-up, I can definitely confirm that the productivity gains of the framework vastly outweigh the investment in learning it. Nobody on our team had used C# at the start of this effort and now we all prefer it.
Depending on the application and the willingness of your customers to install .NET (not all of them are), I would definitely move to WinForms or WPF. Interop with C++ code is hugely simplified by refactoring non-UI code into class libraries using C++/CLI (as you've noted in your selection of tags).
The only issue with WPF is that it may be hard to maintain the current look-and-feel. Moving to WinForms can be done while maintaining the current look of your GUI. WPF uses such a different model that to attempt to keep the current layout would probably be futile and would definitely not be in the spirit of WPF. WPF also apparently has poor performance on pre-Vista machines when more than one WPF process is running.
My suggestion is to find out what your clients are using. If most have moved to Vista and your team is prepared to put in a lot of GUI work, I would say skip WinForms and move to WPF. Otherwise, definitely look seriously at WinForms. In either case, a class library in C++/CLI is the answer to your interop concerns.
You don't give a lot of detail on what your legacy code does or how it's structured. If you have certain performance criteria you might want to maintain some of your codebase in C++. You'll have an easier time doing interop with your old code if it is exposed in the right way - can you call into the existing codebase from C# today? Might be worth thinking about a project to get this structure right.
On the point of WPF, you could argue that WinForms may be more appropriate. Moving to WinForms is a big step for you and your team. Perhaps they may be more comfortable with the move to WinForms? It's better documented, more experience in the market, and useful if you still need to support windows 2000 clients.
You might be interested in Extending MFC Applications with the .NET Framework
Something else to consider is C++/CLI, but I don't have experience with it.
Thank you all kindly for your responses, it's reassuring to see that generally the consensus follows my line of thinking. I am in the fortunate situation that our software also runs on our own custom hardware (for the broadcast industry) - so the choice of OS is really ours and is thrust upon our customers. Currently we're running XP/2000, but I can see a desire to move up to Vista soon.
However, we also need to maintain very fine control over GPU performance, which I guess automatically rules out WPF and hardware acceleration? I should have made that point in my original post - sorry. Perhaps it's possible to use two GPUs... but that's another question altogether...
The team doesn't have any significant C# experience and I'm no expert myself, but I think the overall long term benefits of a managed environment probably outweigh the time it'll take to get up to speed.
Looks like Winforms and C# have it for now.
Were you to look at moving to C# and therefore .NET, I would consider Windows Presentation Foundation rather than WinForms. WPF is the future of smart clients in .NET, and the skills you pick up you'll be able to reuse if you want to make browser-hosted Silverlight applications.
I concur with the WPF sentiment. Tag/XML based UI would seem to be a bit more portable than WinForms.
I guess too you have to consider your team, if there is not a lot of current C# skills, then that is a factor, but going forward the market for MFC developers is diminishing and C# is growing.
Maybe some kind of piecemeal approach would be possible? I have been involved with recoding legacy applications to C# quite a bit, and it always takes a lot longer than you would estimate, especially if you are keeping some legacy code, or your team isn't that conversant with C#.