Is there any other class library like MFC which provides Document/View architecture or is it totally unique concept of MFC?
I realize that this is an old question, but for the benefit of those seeing this question via Google searches, the wxWidgets cross-platform GUI API contains a document-view framework as well. I never used it before, so I cannot tell how it comparess with the MFC implementation.
No, it is not, Apple used it for iPhone programming, at least until iOS 5 and if you take a look at the Stanford Universirty iOS Programming courses on iTunesU, you'll see that they'll teach it too. Moreover I've studied it in my OOP course here in Italy, so I can guess it's a worldwide accepted way to organize your code.
Certainly the concept can be found in other languages/frameworks. But, if you compare MFC with WinForms and WPF, then yes, this technique is unique.
Related
I had some trouble figuring out how to funnel users through different stages on a website I'm building and I figured that drawing a flowchart might help me see things clearer. So I started drawing a chart in Dia and an hour later I'd figured out what models and views I need to add and how to interconnect them. Given a little time, I can really see this kind of charting becoming a useful asset in my web development skill set.
One thing that bothered me though was the lack of symbols for common stuff related to web development. A symbol for forms would be nice. Maybe a way to indicate AJAX requests. I'm sure you can think of lots of other stuff. What are people using to visualise such things? Is there a standard set of symbols that I should use? I stumbled across UML years ago but never really got comfortable with it. Could that be used for charting web sites or is it not well suited to this task?
I use sequence diagrams to document the flow from page to page (including Ajax requests). Within a page, activity diagrams are often useful
For an excellent, short, and readable introduction to the use of UML, see UML Distilled
Another option: Jesse James Garrett's visual vocabulary for interaction architecture and design.
I don't use it personally, prefer using UML Activity/State diagrams. However a few UX designers I know are strong advocates. ymmv.
I don't beleive there are official standards but the shapes never seem to differ likewise. For an operation use a box. Start and end use an oval. For a decision use a diamond. The graphical ones aren't standard, but can still be used.
I have been using jQuery/Prototype/ExtJs and other frameworks for last two years. These frameworks have been very useful.
I switched to YUI recently and finding the learning curve a bit too steep. Also the framework is not making my life as easy as with Extjs or Jquery.
When I consulted several other developers no one seems to be very enthusiastic about YUI. Very few of them have actually used it. Of course this depends on where I stay and what kind of people I interact with but can I say safely that YUI is not beign received as enthusiastically as jQuery? Why is it so ?
NB: I'm an engineer on the YUI team! I think you ask a great question, something I have wondered myself.
IMO, jQuery is more widespread than YUI because it is easy to sprinkle it on web pages that need simple DOM manipulations and basic AJAX or animations. That said, YUI is an extremely popular library that has historically been a favorite of more advanced developers and application builders. We do have a huge and thriving online community on yuilibrary.com -- perhaps folks are too busy writing great code to make a lot of noise? ;-)
That said, we are hearing a lot of buzz these days from jQuery folks hitting the limits of that library as they transition from throwing together simple effects to needing more maintainable, performant, and well-architected code. YUI 3 takes you from the basics to the most complex applications without missing a beat. It is a world-class platform for novices, hackers, and application developers alike: a concise, convenient, and intuitive API that is lightweight and lightning fast, PLUS a well-thought-out infrastructure and comprehensive suite of tools to help you code like a professional.
I agree that the learning curve for YUI has been high -- we are in the midst of a website redesign and writing an O'Reilly cookbook to address exactly that issue. We're also hosting our second annual YUIConf this November to unveil our latest and greatest. We've coming a long way since the days of YUI 2 and we're excited to make it as easy as possible for folks like you to ramp up on YUI 3.
Akshar -- my response is YUI-centric, for sure, but the YUI developer community is huge, enthusiastic, and growing. Check out http://yuiblog.com/blog/category/in-the-wild for some of the implementations we've seen recently. In addition to what's out there in open source, the Yahoo! home page, Yahoo! Search, Flickr, and the upcoming redesign of Yahoo! Mail are all based on YUI 3, the next generation of the library -- which has been welcomed by developers as having industrial strength power along with the concision and selector-driven syntax that makes libraries like Prototype and jQuery so fun to use. My advice: Try it out. YUI 3 is a unique, incredibly powerful library, and its 200 community contributed gallery modules (a number that grows by the week) make it one of the most comprehensive libraries out there.
As a user of both jQuery and YUI, I have to admit that I look at them in almost completely different lights. I use jQuery for custom effects, animation, interactivity on our externally-facing website. The visual extensibility of jQuery means that we can customize the look and feel of these elements to match the rest of our website. I've used YUI as a quick and easy way to develop a snazzy front interface for some of our internal applications. These internal applications are simple Apache/MySQL/PHP apps, and YUI allows for simplified data visualization, form handling, tabs, etc. without having to worry about the look and feel as much. The standardized, slightly bland interface elements are a perfect, no-nonsense approach to quickly developing and rolling out these apps.
I found the learning curve to be a bit steep myself, but the examples help out a lot.
I've been using ExtJS and JQuery for some time, but now i'm experimenting with YUI 3. I like the general idea behind YUI (modules, async loader, plugins) but some things annoy me:
lots of documentation, but some things aren't documented at all or very scarcely
some features are very basic (data grids) compared to their ExtJS counterparts.
you never know which features are there in the core, in gallery or aren't implemented at all. You need to do the research yourself.
the framework feels less coherent than ExtJS
I'm trying to find a replacement for ExtJS for building business applications, but didn't find any framework that would be as rich and complete as ExtJS. I don't like how ExtJS looks and how it forces some strange implementation/architecture decisions on you (MVC!), but have to admit it's really hard to replace.
I'm interested in creating a visual programming language which can aid non-programmers(like children) to write simple programs, much like Labview or Simulink allows engineers to connect functional blocks together without the knowledge of how they are internally built. Is this called programming by demonstration? What are example applications?
What would be an ideal platform which can allow me to do this(it can be a desktop or a web app)
Check out Google Blockly. Blockly allows a developer to create their own blocks, translations (generators) to virtually any programming language (or even JSON/XML) and includes a graphical interface to allow end users to create their own programs.
Brief summary:
Blockly was influenced by App Inventor, which itself was based off Scratch
App Inventor now uses Blockly (?!)
So does the BBC microbit
Blockly itself runs in a browser (typically) using javascript
Focused on (visual) language developers
language independent blocks and generators
includes a Block Factory - which allows visual programming to create new Blocks (?!) - I didn't find this useful myself...except for understanding
includes generators to map blocks to javascript/python
e.g. These blocks:
Generated this code:
See https://developers.google.com/blockly/about/showcase for more details
Best wishes - Andy
The adventure on which you are about to embark is the design and implementation of a visual programming language. I don't know of any good textbooks in this area, but there are an IEEE conference and refereed journal devoted to this field. Margaret Burnett of Oregon State University, who is a highly regarded authority, has assembled a bibliography on visual programming languages; I suggest you start there.
You might consider writing to Professor Burnett for advice. If you do, I hope you will report the results back here.
There is Scratch written by MIT which is much like what you are looking for.
http://scratch.mit.edu/
A restricted form of programming is dataflow (aka. flow-based) programming, where the application is built from components by connecting their ports. Depending on the platform and purpose, the components are simple (like a path selector) or complex (like an image transformator). There are several dataflow systems (just I've made two), some of them has no visual editor, some of them are just a part of a bigger system, and there're some which don't even mention the approach. (Did you think, that make, MS-Excel and Unix Shell pipes are some kind of this?)
All modern digital synths based on dataflow approach, there's an amazing visual example: http://www.youtube.com/watch?v=0h-RhyopUmc
AFAIK, there's no dataflow system for definitly educational purposes. For more information, you should check this site: http://flowbased.org/start
There is a new open source library out there: TUM.CMS.VPLControl. Get it here. This library may serve as a basis for your purposes.
There is Snap written by UC Berkeley. It is another option to understand VPL.
Pay attention on CoSpaces Edu. It is an online platform that enables the creation of virtual worlds and learning experiences whilst providing a more flexible approach to the learning curriculum.
There is visual coding named "CoBlocks".
Learners can animate and code their creations with "CoBlocks" before exploring and sharing them in mobile VR.
Also It is possible to use JavaScript or TypeScript.
If you want to go ahead with this, the platform that I suggest is the one used to implement Scratch (which already does what you want, IMHO), which is Squeak Smalltalk. The Squeak environment was designed with visual programming explicitly in mind. It's free, and Smalltalk syntax can learned in half an hour. Learning the gigantic class library may take just a little longer.
The blocks editor which was most support and development for microbit is microsoft makecode
Scratch is a horrible language to teach programming (i'm biased, but check out Pipes Visual Programming Language)
What you seem to want to do sounds a lot like Functional Block programming (as in functional block programming language IEC 61499 and other VPLs for mechatronics development). There is already a lot of research into VPLs so you might want to make sure that A) what your are trying to do has an audience and B) what you are trying to do can be done easily.
It sounds a bit negative in tone, but a good place to start to test the plausibility of your idea is by reading Davor Babic's short blog post at http://blog.davor.se/blog/2012/09/09/Visual-programming/
As far as what platform to use - you could use pretty much anything, just make sure it has good graphic libraries (You could use Java with Swing - if you like pain - or Python with TKinter) just depends what you are familiar with. Just keep in mind who you want to eventually launch the language to (if its iOS, then look at using Objective-C, etc.)
I am from .net C# background and I want to learn DirectX. I have knowledge of C++ but I am fairly new to graphic world.
I am little confused about how to start learning directx, should I start learning direct directly or buy a basic graphic book like hern and baker and then jump to directx.
Which is the recommended book for learning basic graphic concepts, is it hern and baker? Is there any directx book which will cover graphic concepts as well?
I think that keeping a basic graphics book is allways good, because i can use it as reference anytime
Any suggestions from experts here?
You say that you have a C# background so I am going to assume you are more comfortable with C# then C++. Also, you say that you have knowledge of C++ so I will assume that you already have an understanding of memory management.
If you just want to learn and become more comfortable with the graphics pipeline you should check out SlimDX and XNA. They both allow you to use DirectX without having to dive into C/C++.
As for whether to learn the theory or API first I don't think you should do either one first. It makes sense to learn them asynchronously. Pick up a book on the theory but mess around with an API at the same time.
I highly recommend XNA. People commonly say that you should stick with C++ if you want to develop games but I strongly disagree. XNA will allow you to learn more high level game concepts in less time than if you use C++ and DirectX alone. You will be able to focus on learning why you are doing something rather than how to manage the memory. If in the future you decide that game development is a serious passion then by all means C++ is the way to go. You will find that XNA's graphics pipeline closely mirrors DirectX 9 and wont have much trouble moving to C++.
Also, DirectX 9 should be good enough for any beginner and it will give you a better understanding of how and why things have changed in 10 and 11. However, if you really want bleeding edge technologies you can try out SlimDX which is a C# wrapper for DirectX.
With all this said, XNA offers many easy to understand samples that you can start playing with on their educational catalog page. Also, check out ziggyware (great collection of xna tutorials).
Also, there are many blogs you can check out. A lot of them have excellent tutorials on them. Here are some off the top of my head:
Reimer Grootjans
Shawn Hargreaves
Richard Dodsworth
Renaud Bédard
Nick Gravelyn
Finally, here are 2 graphics books that I highly recommend (they are pretty complex and will last you a long time):
Fundamentals of Computer
Graphics
Real-Time Rendering
They are not directly related to DirectX, but rather they cover the theory every graphics developer should know. (from linear algebra to texture mapping to volumetrix rendering...)
Well I have to disagree with the C# option. If you don't have a deadline to finish the game, then I recommend using the language that teach you most. Working with 3d graphics is A LOT about management so if you are avoding it you are not actually learning but just using it, ie. you not only have to manage memory but the actual render calls you make and the device state changes, a lot of things that you will never know by avoding lower level, and which applies for other APIs too such as OpenGL or for other kind of devices. I think the best way of knowing how the api works is by using the api, instead of a bunch of helper libraries. You can use the helper libraries when you really need it instead (which you can find in their C++ version anyway).
In the DX SDK you can also find the Sample Browser with some sample applications with their documentation and you have the DirectX Utility Toolkit which contains a framework and libraries to make a DirectX app without having to worry much about the nasty device things such as enumeration and config. It also comes with a GUI system and a settings dialog for the device config. I doubt you can find those in C# and they are very good if you want to start with DX.
Some resources that helped me when I started were
the zophusX tutorials
and a book called "Introduction to 3D Game Programming with DirectX 9.0c", by Frank D. Luna (there is the DX10 version now)
and probably the book 3d Game Engine Programming by Stephan Zerbst also helped me to understand some things about how to work better with the apis. Though you may have to buy them in order to read them. They are helpful to start with both some theory and using the API at the same time.
I think if your target is to learn how to make a game then you can use any language/library you want you don't even need to know a programming language :) but if your target is learning DirectX and graphics APIs you should definitively start with the C++ api which is the "actual" DX.
If you have a bit of extra money, I was very impressed with the DirectX graphics courses from http://www.gameinstitute.com. The textbook they provide was very good as far as the other DirectX books I've seen are concerned. The first module DirectX Graphics I starts off with a bit of a math review and some 3D fundamentals before diving into setting up and using DirectX. By the end of the first module you will have built a textured terrain renderer and an indoor scene.
Overall the courses are not that expensive when you consider how much books on the subject cost. I would definitely recommend checking it out!
I've never been a big fan of MFC, but that's not really the point. I read that Microsoft is due to release a new version of MFC in 2010 and it really struck me as odd - I thought MFC was dead (no ill intention, I really did).
Is is MFC used for new developments? If so, whats the benefit? I couldn't imagine it having any benefit over something such as C# (or even just c++ using Win32 APIs for that matter).
There is a ton of code out there using MFC. I see these questions all the time is this still used is that still used the answer is yes. I work in a very large organization which still employs hundreds of people who write in cobol. If it has ever been used in the enterprise it will continue to be used until there is no more hardware to support it, then some company will pay someone to write an emulator so that the old code will still work.
The navy still uses ships with computers with magnetic cores for memory and I'm sure they have people to work on them. Technology once created can never not be supported. its a bit of the case of Deus ex machina where large organizations aren't completely sure what their system do and have such an overriding sense of fear of brining the enterprise to its knees they have no desire to try out you new fangled technologies(BTW we pay IBM for best effort support on OS2).
Also mfc is a perfectly acceptable solution for windows development given it is an object model which wraps the System API which is pretty much all that most people get out of .net.
As an addendum and since this question is up for a bounty this is a quote from MS regarding mfc in VS 11
In every release we need to balance our investment across the various areas of the product. However, we still believe that MFC is the most fully-featured library for building native desktop applications. We are fully committed to supporting and maintaining MFC at a high level of quality. Here’s a short list of some of the issues that we fixed in MFC for Visual Studio 11:
Here is the link if you want to read the full post
Coolness does not factor in choosing the technology for a new system. Yes if you are a student or want to play around you choose whatever you want.
But in the real world each technology has advantages and drawbacks. A year ago one of the teams started a new project, it was decided that it will be done in MFC.
The reason is very simple: they have to use windows api a lot for low level operations with the printer, internet explorer and god knows what else.
C# was not even in the game, the decision was made between MFC and QT, both had the needed functionality, both could easily integrate the low level functionality, the only difference was that some team members already had MFC experience, so they didn't have to waste time and money with trainings.
Let's suppose they choose C# and WPF:
-1 You have to wrap all native C++ and ASM code in a DLL (ouch this can be painful, instead of coding you write wrappers).
-1 You probably need two teams now, one for the ui one for the winapi stuff. It is very unlikely that you'll find a lot of people able to write both C# and winapi stuff. Agreed that either way you need someone to make the interface pretty (programmers usually suck at this and they cost more) but at least with C++ only code, there is no more wait time between two teams, need a ui modification, no problem I don't have to wait for the ui designer, he will make it pretty later.
+1 You can write the UI code in C# and WPF, let's say the UI development is faster, but the UI is only 1/4 of the project, so the total gain is probably very small.
-1 Performance degradation: for every small operation you can't do in C# you call a external DLL (this is a minor issue since the program runs on 8GB RAM Quad Cores).
So in conclusion: MFC is still used for new development because the requirements and the costs decide the technology for a project and it just so happens that MFC is the best in some cases.
MFC is still used for some new development, and a lot of maintenance development (including inside of Microsoft).
While it can be minutely slower than using the Win32 API directly, the performance loss really is tiny -- rarely as much as a whole percent. Using .NET, the performance loss is considerably greater (in my testing, rarely less than 10%, with 20-30% being typical, and higher still for heavy computation. Just for example, I have a program that does Eigenvector/Eigenvalue computation on fairly large arrays. My original version using C++ and MFC runs one test case in just under a minute on our standard test machine. Some of my coworkers decided it would be cool to re-implement it in C#. Their version takes almost three minutes on the same machine (quad core, 16-gigs of RAM, so no, not "legacy" hardware). I'll admit I haven't looked at their code too closely, so maybe it could be improved, but they're decent coders so a 3:1 improvement strikes me as unlikely.
With MFC, it's also easy to bypass the framework and use the Win32 API directly when/if you want to. With .NET, you can use P/Invoke for that, but it's quite painful by comparison.
MFC has been updated with every release of Visual Studio. It just isn't the headline feature item.
As for new development, yes. It is still used and will continue to be so (even though I, like you, prefer not to). Many organizations made the technology decision years ago and have no reason to change.
I do think you are talking about well-established shops though, folks with more interest in maintaining / enhancing what has been written rather than stay on the cutting edge.
The release of the MFC Feature Pack (one or two years ago, iirc) was the biggest extension of MFC since around 10 years and it gave quite a new boost to MFC development. I guess a lot of companies decided to maintain their legacy applications, push them forward and delevelop new applications on its basis.
For me (as someone who has to maintain a large MFC application) the bigger problem is the decreasing development and support of (Microsoft and third-party) components rather than MFC itself. For instance is porting to 64bit not easy if a lot of old and unsupported pure 32bit Active-X components are assembled in the application.
I did a project last year based on MFC. I'm not sure why MFC was chosen, but it was adequate for making a virtual 3D graphic user interface—a building management security system—with 10 frame per second refresh rate run efficiently on win32-based PCs dating back to the mid-1990s. The executable (which requires only core win32 system DLLs) is less than 400K—not an easy accomplishment with modern tools.
There are advantages to staying away from managed code (maybe you're writing a driver UI, or doing COM).
That and there's tons of MFC code out there. Maybe you work for Company X, and need to use one of the zillion DLLs they've been writing over the last dozen years.
I can think of one commercial software title that benefits from using MFC over C#: Wwise[1]. C++ is an obvious choice for the sound engine, so it makes sense to write the authoring tool in C++ as well. It's both an authoring tool and a sound engine. They could have built the authoring tool in C#, and the sound engine in C++, but if they're debugging a problem with the sound engine that's reproducible through the wwise authoring tool, it's easier for them to see the whole call stack just like that.
I think there's some ways of doing a mixed call stack nowadays, but maybe that wasn't there when they first made Wwise? In any case, using MFC ensured that they wouldn't need a solution to the problem of mixed call stacks. The call stack just works.
[1]Wwise is built on MFC: https://www.audiokinetic.com/fr/library/edge/?source=SDK&id=plugin_frontend_windows.html