I'm working on an MFC app that has been localized to multiple languages. It links to MFC dynamically and if the target system has the MFC LOC DLLs installed it automatically uses those DLLs as expected. However, on some of these OSs we have users who prefer English, is there a way for me to force it to use the English DLL instead of the translated MFC LOC DLL?
The MFC LOC mechanism is IMHO terrible. It should be avoided by all means because it causes more harm than good
By its unability to use more than one translation, as you experienced it, MFC LOC deserves a good place in the Hall of Shame of our industry. Just think of all these apps who caused other unrelated MFC-based app to appear partially translated.
That's why I believe it's better to provide the translations for MFC resources in your own resource DLLs.
Disclaimer: My ad follows ;-)
appTranslator is your friend to translate your MFC app. It automatically translate the MFC part of your resources in up to 27 languages. It automatically builds your resource DLLs. And much more...
/End of ad
And this CodeProject article of mine provides ready-to-use code to support loading of resource DLLs and support for a language menu. OK, this was not your question but I thought it may help. Oh, and it's out of the disclaimer since it's free ;-)
Related
Is Qt an interesting platform for business apps development, outside of Nokia phones ?
Why ? Strong points ?
Thanks
I like Qt because:
Very well-designed framework, e.g. signal-slot, model-view, graphics view/scene/item/proxy, painter/paint device/paint engine..., too many to be listed here!
Excellent documentation!
Cross platform language/API, as well as tools like UI designer, creator, and so on.
Rich features, e.g. graphics framework, network library, database engine, and so on.
Active community, and active development.
There should be more. If you have ever used it, you'll find it's easy to build your framework upon Qt.
I didn't have any complain to Qt. If I have to say at least one disadvantage here, "convention". You must adopt the convention of Qt, e.g. You have to use moc to make the meta object of your objects, and it's easier for developers to use Qt's vector, list, auto_ptr than STL, tr1. But I never found any issue caused by that. On the contrary, it works very well.
In my opinion, Qt is the state-of-the-art C++ framework in this modern world!
P.S. There are a lot of commercial applications built on Qt. You can find it under Qt's official website. But I'd like add one more here: Perforce, one of the top commercial source code management tools, built its client tool on Qt for Windows/Linux/Mac.
yes it is .. just look at kde apps :)
or see more applications made by qt
and it has alot of bindings in many languages
Documentation
cross-Platform IDE
further reading
may be this is not so related to the question ... but my first deal with qt was just great starting from their well organized Documentation to their great widgets
the GraphicsView is just ammazing ! :)
It's about the only current/modern C++ gui library on Windows.
MFC is so old you have to write comments in Latin
WTL would be nice if they had finished it before abandoning it.
Winforms/WPF + managed C++/CLR - all the fun of several incompatible new technologies at once.
Bad points:
To fit on lots of platforms they have invented their own solutions to things that are now in the STL/Boost
The signal/slot mechanism - tricky to debug and silently fails (with no error) with simple typos.
Although everything is possible it's sometimes a lot of effort to do simple things (they do love MVC) compared to Winforms.
Qt is simple
Qt is powerful
Qt is NATIVELY-CROSS-PLATFORM
Qt is REALLY-CROSS-PLATFORM
Qt is comprehensive (but the Media side of it still needs to grow)
Qt doesn't require Garbage Collection, but it embeds a GREAT model of memory management that makes you forget about memory deallocation
Qt is solid
Qt is modern
Qt proposes some new paradigm of programming that are really good (Signals-Slots)
Qt runs a lot of VERY successful software: (Skype, Google Earth...)
Are those points strong enough?
Maybe you have heard about Google Earth which happens to be programmed in Qt too.
That aside, I like Qt for my in-house development because it
is very well supported and documented,
allows me to write simple and decent-looking apps that are
works cross-platform for Windows and Linux with little effort, and
contains nice to have components for database access, regexps, guis, xml, ...
I also use the Qwt widgets for easy real-time plotting on top of Qt.
I really dont understand whats the point in underestimating tools/frameworks which makes things easy for programmers. Qt is too good for GUI development, I would say its much better than any current existing crossplatform app development suite.
So many advantages, I have been using it for more than three years now for a product to be deployed in Linux/Win environments. The app is thread intensive and initially we had a tough time using pthreads and its conterpart for windows. Then we switched to Qt(and QThreads eventually) and things were a breeze...
Backed by active development, a highly helpful and supportive community along with excellent documentation, training, certification programs, videos, forums... its easy, fast and effective to develop in Qt. You should see the video which they create a web browser in just five mins!
Its really 'cross platform', and it doesnt have a software wrapper(like Java does) to enable this which makes it faster. Cmon, we all know java apps have buttons which takes a second to respond to even a simple 'click'.
I hope Qt will someday do a take on Java. :D
after all, 350000 developers cant be wrong when they chose Qt.
Pixar uses Qt (or at least, used, as of 2005) internally for certain parts of their tool suite (called "Marionette" in the marketing) collectively called Menv, ("men-vee" for Modelling ENVironment)---at least for their lighting sub-tool Lumos.
When I create a 'Windows Forms Application', the resultant program is a managed one. Creating a 'Win32 Application' results in a native one, but when I try to add a form I'm informed that the project will be converted to CLI if I continue. How do I design a native Windows GUI with Visual C++ 2008 Express Edition? I'm probably being very silly here, but I just can't figure it out.
Either use MFC, WTL, or straight Win32 API. You can't use forms (or any of .NET) without switching into managed code.
MFC is Microsoft Foundation Classes - the most common C++ windows library
WTL is Windows Template library - a better C++ windows library IMO
Win32 is CreateWindow, DialogBox, etc, everything else is a wrapper around the Win32 api.
You just need to avoid the managed libraries. Most likely, this will mean using MFC for the GUI, instead of Windows Forms. For details, see MSDN's MFC pages.
Unfortunately, VC++ Express Edition doesn't support MFC directly, so you'll have be more limited. It is possible to compile MFC projects using the Express Edition, but you lose all of the Wizards, etc. If you are serious about doing non-managed GUI development, you should consider upgrading to a higher level SKU.
Another option would be to use Qt for for GUI. It is now LGPL, so usable, for free, in even commercial C++ projects, and includes a full designer.
This is an answer to the linked question. Unfortunately, that has been closed by Robert Harvey because he thinks it is a duplicate. It is not, sorry Bob.
The best library for creating xll's is http://xll.codeplex.com. You can use that to create rudimentary user interfaces using Excel macros. One example of that can be found in the ALERT.FILTER macro in xll/error.cpp
As Reed Copsey, MFC would be the "default" way of creating a native unmanaged GUI on the Windows platform. However, MFC is not included with Visual Studio Express. Consequently, you would either need to upgrade to the full version or you could look into using a freely available C++ GUI library such as wxWidgets.
There is also wxFormsBuilder if you want a GUI editor.
You could also go down to the "bare metal" and code right to the Win32 API, maybe take some help from the common controls library. But you'll be entering a world of pain ;)
You would need to use a native application framework. For Windows this means MFC or the bare Win32 libraries. WinForms use .NET libraries in the background and therefore need to be managed.
Native applications don't use "forms". For a native application, you could create, for example, an MFC application. If you want it to be something like a form-based application, you can tell the wizard you want a dialog-based application, or (on the last page of the Wizard) have your view derive from CFormView instead of CView.
Alternatively, you might want to use WTL -- though that means writing essentially all your code by hand instead of using wizards and such.
Windows Forms is the name given to the graphical application programming interface (API) included as a part of Microsoft's .NET Framework, providing access to the native Microsoft Windows interface elements by wrapping the existing Windows API in managed code.
Wikipedia
Most of the above answers explain things pretty well - if you want to look into creating a pure Win32 Native App form (no MFC/WTL etc) take a look at the tutorials here: http://www.zetcode.com/tutorials/winapi/ for starters. That's the third time I've linked to this site on here, but his tutorials are very good.
Note - at this stage there's nothing "visual" about it except the result - it is all done in code, although that said I don't think it is too difficult really. It will definitely be good programming experience.
Windows Forms are a GUI framework written in managed code, so you cannot use Forms in a native application.
With a native application, you have to create windows. Programming Windows by Charles Petzold is the definitive how-to book for this. It's a lot of work compared to using a good framework. MFC (Microsoft Foundation Classes) is a framework for native Windows GUIs. I don't know if it comes with VC++ Express.
I noticed that no one mentioned JUCE which can be used to build cross platform user interfaces in C++. I thought it was pretty cool. Looks like it's been expanded to support mobile devices too since I used it.
Personal and Educational licenses are free. 'Pro' and 'Indie' licenses are relatively cheap.
I'm learning programing windows applications with C++. Now I'm reading about messages and I'm playing with the spy++.
What function spy++ use in order to mark/highlight the window under mouse cursor?
Also, can you give me some tips about using MSDN? I'm my opinion is not user friendly at all.
I'm learning programming by myself and i can't get some real life experience tips as those which are learning at college or in teams.
ty
Not sure exactly what your problem with MSDN is ... I tend to go to e.g. Win32 and COM development and look around for a suitable category in the listing to the left, then click down from there. Or just enter function names and search if I already know what I'm looking for but want the reference documentation. On the other hand, I'm not much of a Win32 developer.
I think spy++ is just inverting the colors directly on the window/screen DC (You could use InvertRect() for example) On Windows 2000 and later, it is probably better to use a translucent layered window if you actually wanted to implement this window highlight since some graphic corruption can occur when messing with other windows behind their back.
Writing a Windows application with just the windows API is possible, but you'll end up writing huge amounts of boilerplate code just to create simple things. This is why people normally use libraries built on top of it to make things easier - MFC for example.
The MSDN article Creating Win32 Applications provides a good explanation of the ins-and-outs of a Windows application using the Win32 API. Bare in mind though that you could build the same application in minutes using MFC.
I agree that MSDN is not the most user friendly source of information for a beginner. In my opinion it works much better as a reference.
My advice would be to focus on building some test applications using MFC (assuming you are tied to C++ as a language). Try looking at the codeproject MFC sections for example, and perhaps even buy a book to help get you started. This does of course require Visual Studio, but you can download the free express edition here
We currently maintain a suit of MFC applications that are fairly well designed, however the user interface is beginning to look tired and a lot of the code is in need quite a bit of refactoring to tidy up some duplication and/or performance problems. We make use of quite a few custom controls that handle all their own drawing (all written using MFC).
Recently I've been doing more research into Qt and the benefits it provides (cross-platform and supports what you might call a more "professional" looking framework for UI development).
My question is - what would be the best approach to perhaps moving to the Qt framework? Does Qt play nice with MFC? Would it be better to start porting some of our custom controls to Qt and gradually integrate more and more into our existing MFC apps? (is this possible?).
Any advice or previous experience is appreciated.
In my company, we are currently using Qt and are very happy with it.
I personnally never had to move a MFC-app into using the Qt framework, but here is something which might be of some interest for you :
Qt/MFC Migration Framework
Qt/MFC Migration Framework
It's part of Qt-Solutions, so this means you'll have to buy a Qt license along with a Qt-Solutions license. (edit: not any more)
I hope this helps !
(This doesn't really answer your specific questions but...)
I haven't personally used Qt, but it's not free for commercial Windows development.
Have you looked at wxWindows which is free? Nice article here. Just as an aside, if you wanted a single code base for all platforms, then you may have to migrate away from MFC - I am pretty sure (someone will correct if wrong) that MFC only targets Windows.
One other option would be to look at the Feature Pack update to MFC in SP1 of VS2008 - it includes access to new controls, including the Office style ribbon controls.
It's a tricky problem, and I suspect that the answer depends on how much time you have. You will get a much better result if you port your custom controls to Qt - if you use the QStyle classes to do the actual drawing then you'll end up with theme-able code right out of the box.
In general, my advice would be to bite the bullet and go the whole way at once. Sure, it might take longer, but the alternative is to spend an age trying to debug code that doesn't quite play ball, and end up writing more code to deal with minor incompatibilities between the two systems (been there, done that).
So, to summarise, my advice is to start a branch and rip out all your old MFC code and replace it with Qt. You'll get platform independence (almost) for free, and while it will take a while, you'll end up with a much nicer product at the end of it.
One final word of warning: make sure you take the time to understand the "Qt way of doing things" - in some cases it can be quite different to the MFC approach - the last thing you want to do is to end up with MFC-style Qt code.
I have lead a team doing this kind of thing before (not MFC to QT but the principles should work).
First we documented the dialogs and what their inputs, controls and outputs were. Also, we create several test cases especially for any clever logic inside the GUI.
Sometimes we had to refactor some business logic to provide a clean interface the GUIs but this is the way it should have been done in the first place tbh.
Now we had a list of GUIs, inputs, outputs, tests and an interface that the encapsulated GUI had to match.
We began, project by project, to create equivilant GUIs to the old ones. Once we did that we could slot the GUI in where the old one was, rebuild and test it. At first we tripped a lot but we soon worked out the common errors and fixed them. We navigated (I think) 612 dialogs although there was a team of about a dozen of us working on it.
I see many user interface control libraries for .NET, but where can I get similar stuff for win32 using simply C/C++?
Things like prettier buttons, dials, listviews, graphs, etc.
Seems every Win32 programmers' right of passage is to end up writing his own collection. :/
No MFC controls please. I only do pure C/C++. And with that said, I also don't feel like adding a multi-megabyte framework to my application just so that I can have a prettier button.
I apologize for leaving out one tiny detail, and that is that my development is for Windows Mobile.
So manifest files are out.
I just notice how many developer companies have gone crazy with making pretty looking .NET components and wondered where the equivalent C/C++ Win32 components have gone?
I read about how many people ended up writing their own gradient button class, etc. So you would think that there would be some commercial classes for this stuff. It's just weird.
I'll take a closer look at QT and investigate its GUI support for such things. This is the challenge when you're the one man in your own uISV. No other developers to help you "get things done".
I've used Trolltech's Qt framework in the past and had great success with it:
In addition, it's also cross-platform, so in theory you can target Win, Mac, & Linux (provided you don't do anything platform-specific in the rest of your code, of course ;) )
Edit: I notice that you're targeting Windows Mobile; that definitely adds to Qt's strength, as its cross-platform support extends to WinCE and Embedded Linux as well.
The Code Project has lots of UI controls for C/C++
Most of them are focussed on MFC or WTL but there are some that are pure Win32.
As an aside if you're not using a framework, you really should consider WTL over pure Win32. It's low overhead and about a million times more productive.
For prettier buttons, etc., if you aren't already doing it, embed an application manifest so that your program is linked to version 6 of the common controls library. Doing so will get you the Windows XP- or Vista-styled versions of the standard Windows controls.
If you want types of controls beyond what Windows offers natively, you'll likely have to either write it yourself or be more specific about what kind of control you are looking for.
I you don't mind using the MFC libraries you should try the Visual C++ 2008 Feature Pack
Stingray
CodeJock - Toolkit Pro for MFC/ C++
The MFC feature pack is derived from BCGSoft components.
Using winAPI's you can do almost anything you want and really fast too. It takes some time to figure it out but it works. Go to MSDN, lookup MessageBox(), check out DialogBox() and go from there.
I personally do not care for MFC by the way. If you want to use an MFC like approach I'd recommend Borland's C++ Builder. Pretty old but still very usefull I think.