Hot answers tagged mfc
Both MFC and WPF (along with Windows Forms, VB6 forms, and plenty of other things) contain concepts that come from the Windows UI - the basic set of controls (button, text box, checkbox etc), the idea of properties for those controls (text, contents, checked...) and that some properties are common to all controls while others are just for certain controls. ...
INI files are an old way of storing application configuration, particularly in Windows 3.x, such as WIN.INI, and Windows 9x, and SYSTEM.INI. Windows NT used BOOT.INI as part of its boot process. Later applications used registry keys and more recent .Net applications store settings in app.config XML files.
Microsoft (almost) never deprecate core API functionality. And new major libraries almost never get rewritten. There is too much risk of breaking something for no obvious benefit at great expense
Multiple places to change, all places need to know the current value...sounds like the Observer Pattern. a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement ...
The first thing I'd do in trying to estimate the amount of work involved in this or any port is to figure out how much of the code needs to change and how much should work unmodified on the target platform. If half the code is platform-neutral, the size of the porting project changes accordingly. It may be worthwhile to refactor the code on the original ...
MFC and WPF are completely different technologies and methodologies. If you are getting into Windows desktop development right now then I'd recommend just learning WPF - this is the skill that will be transferable to to Metro development (both use XAML to define the UI). MFC was used for C++ projects before .NET was developed and is effectively dead - ...
I do not think this is a great approach: For starters Oracle BLOB/CLOB handling in the ODBC and MFC classes is not great and can be subject to some non-trivial rules (e.g. The LOB columns must be last in the select statement, positional updates are not always possible). Secondly, by hiding it all in the blob you lose ability to easily query content (e.g ...
MFC was a nice framework for its time. It let you abstract the Win32 API, and made things much simpler to develop, especially when it came to GUI and MVC development. I developed in it for several years, it was much nice than using straight Win32 api. There is nothing particularly terrible about MFC. Bad software can be written in any language. And ...
This is one area where its very difficult to beat Delphi. It's able to build standalone, native Win32 (and 64 now) executables. No runtimes, not even .NET is required. (its possible some dll's would be required, if you were specifically using them) Or the Delphi-like, open-source Lazarus IDE
Tcl/tk fits your requirements, when you add in the starpack / starkit technology. Essentially, you can wrap up an entire virtual filesystem and executable into a single executable that runs as-is, no unpacking or installation required.
As your update suggets, the repository pattern would be able to help seperate the database calls from your UI. And replacing the database calls with calls to an IDatabase interface is certainly an improvement. The repository pattern will allow you to further abstract the the data retrieval into something meaningful to the application. UserRepository, ...
Ok I have solved this problem using Dependency Injection and the Observer pattern. To pass settings around I have a single Settings object that I instantiate in my MFC app object, MyApp (a subclass of CWinApp). Previously I added a getter function call GetSettings() on my MyApp. This allowed me to get the settings from any window class because there is ...
In the days of MFC, my go to book was: Think of it as an MFC cookbook chock full of pragmatic MFC code that solves specific problems. Certainly remember dipping into this book with greater frequency than any other MFC book I owned.
I found MFC Internals by Shepherd/Wingo an excellent resource. Covering the internals means it's not bogged down in beginner stuff and IDE explanations and it draws quite some lines between "raw" Win32 programming and using the MFC.
I'm no MFC expert but have used it off and on over the last several years. It doesn't always follow a standard convention and is based a lot on the underlying Win-32 API. If your stint is short lived, you might want to look at Programming Windows with MFC (the link is for you read reviews, I'm not advocating the retailer) If you are going to be using MFC ...
Only top voted, non community-wiki answers of a minimum length are eligible