I have a question about the necessity of using MFC's built-in document-view architecture. I was given an old dialog-based project in which I have to replace the main dialog with a frame and add a ribon. It has sort of a doc-view architecture, created without the built-in classes and I preffer to reuse it in the new version. However, if I try to bypass the CDoc and CView derivatives, normally generated by the project wizzard, all I can see is an empty window without a ribon. So... do I REALLY have to implement these built-in doc-view architecture, or am I just missing something? Isn't it possible to use the already existing code from the project?
If you will be using multiple views & documents in your frame then it is advisable to use the existing framework's design (CDocument, CView etc).
If you are doing it only for ribbon and will be just moving your controls from dialog to frame then you can skip the standard Document/View architecture and directly instantiate ribbon control.
If you don't have to re-write a lot of code, then I would suggest that you use standard Document/View architecture as in a long run it will save a lot of time, make your app scalable to a bigger multi-doc design etc.
Related
I am considering a rewrite of an MFC Dialog application I wrote over a decade ago. I originally chose a Dialog application type because in general the user clicks control inputs and the application provides real-time data from hardware via USB and displays the data in edit boxes. The app also writes information to a file. Since the user never does any file editing I didn't see a need for SDI or MDI application type.
I've now learned that the SDI application type along with CFormView provides some interesting advantages such as scrolling, window resizing:
http://forums.codeguru.com/showthread.php?267664-MFC-Dialog-How-to-enhance-a-dialog-based-application-with-Menu-Toolbar
The reason for my rewrite is that my application is un-maintainable and doesn't scale well. Originally I created a CDialog for each type of "screen" that I show but lots of code is common among the various screens. In fact over time I started reusing CDialog classes and with the use of state variables simply hid, renamed, or repositioned many of the controls to make the screen look appropriate in the context of the application.
I tried deriving the CDialog classes from a common base class but I didn't achieve great code reuse this way. I also found that I had common resources that I was constantly passing around to the various windows which just added unnecessary overhead.
As the application evolved it also became difficult to keep track of the state of the application (for processing USB hardware data input, user input, button enabling etc). Using a hierarchical statechart as the basis for my application might clean this up.
Should I consider putting a superset of ALL the necessary controls on ONE CFormView and simply hiding, renaming, and repositioning controls from the very beginning and using a statechart to manage this?
All the examples I see put the code directly in the input control handlers but maybe I should use the handlers to change state and then let the state machine do the decision-making to reduce this spaghetti code.
So my primary questions are:
1. Would SDI would buy me anything for writing and reading files (such as reporting and logging) if the user does not perform editing?
2. Does CFormView make sense?
3. Does it make sense to put all controls on one CFormView instead of multiple classes and Dialog resources?
4. Have you tried using a state machine in MFC such as Boost Statechart or Miro Samek's Quantum Leaps?
http://www.boost.org/doc/libs/1_58_0/libs/statechart/doc/index.html
http://www.state-machine.com/products/index.html
I was able to make a simple docking window in a proof of concept project using CFrameWndEx but in my main project, we use CMDIFrameWnd which you apparently have to use CDockingManager.
I plan on taking the already existing windows in the large program I am working on dockable so i plan on making a class that extends CDockablePane and have the existing windows extend the custom class.
How do I use CDockingManager with the CMDIFrameWnd (any examples out there)? And am I going about this the right way?
I came to the conclusion that it is practically impossible to have a docking view unless you use a 3rd party library called BCG. Here is the link to the library BCGSoft.
The project in particular to look at is called "DockingView". When you install the trial you can run and view the project. You will see that they had to rewrite a lot of the core MFC code in order to allow for docking views. It works great but it literally costs an arm and a leg to buy the license for it. So If you REALLY need to rework your MFC project its worth it.
I have a large C++ application with a mostly homegrown layer for GUI Abstraction etc. The application is plain C/C++ on Win32 API.
So far the application only supports a static horizontal toolbar which can not be modified in any way at runtime (besides enabling/hoovering visualization).
We thought about switching to a ribbon interface but nobody we asked liked that idea.
So we want to add some sort of toolbar with the following capabilities:
Movable and resizeable (acting as floating windows/palettes)
Use Bitmaps of any Size
Supports User configured Toolbars Supports
Enabling/Disabling/Checked State
Preferably create disabled/checked/hoovering state bitmaps automatically
How can this be done with the least effort?
I looked at rebars and the TOOLBAR API. Rebars seem not to be resizeable and i was unable to find a working sample for toolbars.
Working sample: here's what I could find: tutorial with link to full example code, part-3 covers toolbars
I always wondered how software such as iTunes, Winamp etc is able to create its own UI.
How is this accomplished under the Windows platform? Is there any code on the web explaining how one would create their own custom GUI?
WinAmp doesn't usually supply its own GUI at all -- it delegates that to a "skin". You can download dozens of examples and unless memory fails me particularly badly, documentation is pretty easily available as well.
From the looks of things, I'd guess iTunes uses some sort of translation layer to let what's basically written as a native Mac UI run on Windows (the same kind of thing that Apple recently decided was so evil that they're now forbidden on the iPhone and apparently the iPad).
Since saying anything that could possibly be construed as negative about Apple is often treated as heresy, I'll point to all the .xib files that are included with iTunes for Windows. An .XIB file (at least normally) is produced by Apple's Interface Builder to hold resources for OS/X programs, and compiled to a .NIB file prior to deployment. Windows doesn't normally use either .XIB or .NIB files at all, and it appears likely to me that Apple includes a compatibility layer to use them on Windows (though I've never spent any time looking to figure out what file it's stored in or anything like that).
Edit: (response to Mattias's latest comment). Rendering it is tedious but fairly straightforward. You basically take the input from the skin (for example) and create an owner draw control (e.g. a button) and render the button based on that input.
The easiest way to do this is to have fixed positions for your controls, and require the user to draw/include bitmaps for the background and controls. In this case, you just load the background bitmap and display it covering the entire client area of your application (and you'll probably use a borderless window, so that's all that shows). You'll specify all your controls as owner-drawn, and for each you'll load their bitmap and blit it to the screen for that control. Since there won't (usually) be a visible title bar, you'll often need to handle WM_NCHITTEST (or equivalent on other systems) to let the user drag the window around.
If you want to get a bit more complex, you can add things like allowing them to also specify a size and position for each control, as well as possibly specifying that some controls won't show up at all. Again, this isn't really terribly difficult to manage -- under Windows, for example, most controls are windows, and you can specify a size and position when you create a window. If the user loads a different skin at run-time, you can call MoveWindow to move/resize each control as needed.
I'm assuming that you mean creating a GUI application as opposed to a GUI framework.
There are lots of GUI frameworks available for Windows.
Some are
wxWidgets (www.wxwidgets.org)
Qt (http://qt.nokia.com/products)
And of course the venerable MFC framework (http://msdn.microsoft.com/en-us/library/d06h2x6e%28VS.90%29.aspx)
If you want a more complete list, look at the Wikipedia article for MFC (http://msdn.microsoft.com/en-us/library/d06h2x6e%28VS.90%29.aspx) and scroll to the bottom.
Each of these GUI frameworks is amply documented on the web.
I am new to MFC well not entirely new but wanted to ask experts on this forum as why one would choose one project over the other. I hope this is not a stupid question as I am relatively new to MFC.
Thanks so much
Chose based on what template your application fits best into:
Single Document Interface (SDI) - if your application needs to work with only 1 document or data object or data set at a time
Example: notepad.exe
Multiple Document Interface (MDI) - if your applicaiton needs to work with multiple documents or data objects or data set at a time
Example: Visual Studio
Dialog Based - for anything else.
Example: Calculator
No matter what you chose, you still have the same functionality available to you in the end and you can cusotmize it in any way. So you aren't limiting yourself to anything you start with.
All variants come with CWinApp which is the base class for which you derive your MFC applications.
With a dialog based application you start with a CDialog as well. With an SDI application you start with CMainFrame, CDocument, and CView as well.
If you select an SDI project you get a whole Model-View-Controller framework included.
You get a document class (inheriting from CDocument) which ideally should hold all of the data, and a view class (inheriting from CView) to do with the display.
You get given a hosting frame with a menu already attached, and there are functions you can override to save and load to file.
If you have a dialog based application, then you get one dialog. That's it. Of course, this dialog can spawn off others, but the application essentially consists of a dialog.
If you're developing a small application that just does one task, a dialog application is appropriate, because you don't need the overhead.
If you are developing an application where the user will be loading, editing and saving data, then the SDI path would be more appropriate.
Having answered your question, I'd politely ask if there was a compelling reason why you were choosing MFC over Windows Forms. I believe that MFC was an excellent technology for its day, but the Visual Studio suite offers more advanced tools (if you're prepared to go down the .NET path).
If a "document" is the right metaphor for your application, use SDI or MDI. (Single of only one document can be open at a time, Multiple if more than one.) When you think about it, the document metaphor really isn't appropriate for most applications.