|
This is for any Microsoft employees lurking around:
While prototyping our application, I have become very annoyed that MFC does not support the XP look and feel. Specifically, it uses the old style menus.
We have looked at some well known third party UI libraries and haven't been pleased with them; not only are they bloated, but they offer far more functionality than we need and don't quite give us the exact look and feel we want. (And the documentation for all of them sucks big time.)
The real irony is that WTL offers the look and feel we want, but since it's not officially supported, we are very unlikely to get a green light to use it. Besides, the documentation for it is a pitiful fraction of that for MFC.
Frankly, I don't care if Microsoft throws its weight behind WTL and updates and documents it (it's missing some common classes for app development) or if it updates MFC. But I wish they would make up their minds and do something other than let both wither and die.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
Joe,
Just curious ( I don't have XP so I am not familiar with the new mens) what do you have to do to support them? I am asking so that I know what to be aware of for the VCF. What features would you expect to find?
What do you mena by the "exact look and feel" surely if tehy are following the SDK API's they'll look right, correct? That's certainly the case with previous versions of Windows.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Basically, the new design is like IE--the menu is a toolbar with flat buttons. I found some code on CodeGuru that mostly works, but it's a real pain and should be supported by MFC, IMHO. Actually, the real problem is that the color of the old style menus look out of place with a new style button bar. (This is arguably a problem with XP itself, but can't do much about that.)
"Exact look and feel" are the small things like whether to allow a docking menu or customizeable toolbar.
This has been an issue with all versions of windows, but has gotten worse in recent years due to the legacy support of all the old versions. Even with Office, Microsoft changes UI elements with every release.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
the menu is a toolbar with flat buttons
This is applied across the board for all apps? Ick, what a pain.
"Exact look and feel" are the small things like whether to allow a docking menu or customizeable toolbar.
So all menus can now be tear offs like Visual Studio or Office?
Even with Office, Microsoft changes UI elements with every release.
Right, but at least with Office it was localized to a singele app (or set of apps), and it was clearly a completely custom effort.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
This is applied across the board for all apps? Ick, what a pain.
Well, no, that's the problem.
So all menus can now be tear offs like Visual Studio or Office?
If they are toolbars and you've done a few other things, yes. But that's the point--we don't want menus to be tear offs--it messes me up when it happens, imagine what it will do to our mass-market grandmotherly types! However, we do want the menus to match the look of the button bar.
and it was clearly a completely custom effort.
Well, yes and no. If the look catches on, it usually works its way into comctl32.dll and shows up in IE. The look of the gripper, for example, is constantly changing--now it's a vertical line of dots.
MFC has also been modified in the past to have the look and feel of Office apps. But then that stopped, largely with the .NET push.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
The offical line from MS is that there won't be any new enhancements in MFC, only bug fixes.
The want you to use .NET.
|
|
|
|
|
Anonymous wrote:
The want you to use .NET.
Fine, I'll use .NET. Oh yeah, .NET is missing even more features for stand-alone application development. (Actually, I really would use .NET IF I had some clear indication Microsoft was going to enhance it for stand-alone application development and not let it wither like MFC/ATL/WTL....)
This is my gripe: I'll use whatever Microsoft is going to push for the future. Problem is that they are being half-assed about every possible solution!
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
Joe Woodbury wrote:
that MFC does not support the XP look and feel.
Isn't that what the manifest is for? Tell XP what your App shall look like.
Do not ask me about details - my company is just leaving NT4, and we are developing under W2K.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
The manifest gets you partly there.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
Have you looked at CNewMenu here on CP. This is easy to integrate into existing apps. Also Prof-UIS gives you all the latest look and feel, but doc's aren't the best. I use CNewMenu in ED (see sig) and Prof-UIS in a new app I'm working on. See: www.prof-uis.com[^]
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
I'll look at CNewMenu today after going over some code I found on CodeGuru. I'll also look at Prof-UIS, which sounds like it has the same problem as everyone else: bad docs.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
I'm thinking of how a linked list verifies whether a given node pointer points to a valid node in the list.
For example, suppose we have a linked list which chains up 10000 NODE, the user calls one member functions which takes a NODE* as parameter: InsertBefore(const NODE* pBefore, LPVOID lpData), now how does the linked list verify if pBefore points to a valid NODE which is contained in the list? I think basically there would be 2 possibilities:
Solution 1, Use ::IsValidReadPtr and ::IsValidWritePtr to check if the memory is available to current process and the consecutive memory block space are large enough to be read/written against a NODE object.
Solution 2, Travel through the whole list and exam pBefore with address of each NODE, stops whenever a match is found.
Personally I think solution 2 is definitely a no go because that would make the linked list ultimately slow if it contains a larget amount of nodes. Solution 1 is faster but not safe, because that way we cannot really make sure if pBefore really points to a NODE or not, it could be any object whose size is same or greater than a NODE and if we use some iterating method like while (pNode->pNext != NULL) {...;} we'll get our system hang...
So I really want to know how a linked list verify a NODE*, is there any better solution, thanks.
|
|
|
|
|
AFAIK, many linked lists use the "honor system"... that is, when you insert a node, it takes your word for it that it's a valid node. 
The STL linked list uses iterators for this purpose, which makes it less likely to err. You can still mess up if you pass in a list an iterator from a different list, though.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
I don't think there is any way you could 100% guarantee that a node passed to one of the member functions was valid. However, you could add an extra member to the NODE that was a pointer back to the linked list. This would reduce the chances of a node being passed in from another list, but even that is still not a guarantee that it is valid.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
how could i place two more toolbars in just one row?
Thank you, anyway!
Hello World!
|
|
|
|
|
|
I have a ReBar on this rebar has one toolbar and one DialogBar. The DialogBar contains a ComboBox.
On this comboBox I am not able to do copy/paste buy use keyboard. But when I right mouseclick I get copy/paste menu.
How can I enable the copy/paste through Keyboard ?
Sandeep Naik
|
|
|
|
|
Hi all. New here to coding kind of. Check out the following code.
#include "iostream.h"<br />
#include "cstdio.h"<br />
#include "cstring.h"<br />
<br />
int main()<br />
{<br />
char str[80];<br />
cout << "Enter a sentence: ";<br />
gets (str)<br />
cout << "\nYou entered: " << str<br />
<br />
return 0;<br />
}
What it does is nothing, but prompts you to enter the string BEFORE it couts "Enter a sentence: ". Why would this be, cout is clearly supposed to be executed before the statement gets (str);.
How the heck does it get that out of what I coded. Wrong version of VC or something ? using MS VC 6.0. How can this be. I am banging my head against the wall.  lol
Thank you much people.
|
|
|
|
|
I don't know, how about a carriage return after "Enter a sentence\n" ?
|
|
|
|
|
If I remember, add a "endl" to the end.
i.e.
count << "Enter a sentence: " << endl;
An endl not only adds a CR/LF, it also flushes the output buffer.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
You're mixing iostreams (cout) and stdio (gets), so the streams are not synchronized.
This should work:
#include "iostream.h"
#include "stdio.h"
#include "string.h"
int main()
{
char str[80];
cout << "Enter a sentence: ";
cout.flush();
gets (str);
cout << "\nYou entered: " << str;
return 0;
}
As should this:
#include <iostream>
#include <string>
int main()
{
std::string str;
std::cout << "Enter a sentence: ";
std::getline(std::cin, str);
std::cout << "\nYou entered: " << str;
return 0;
}
(But, for some reason I don't understand, the latter requires you to hit enter twice.)
--------
There are 10 types of people in this world. Those who know binary and those who don't.
|
|
|
|
|
So, if that is true, then why would Herb Schildt produce this code in his book(C++ from the Ground Up, 3rd edition):
#include "iostream.h"<br />
#include "cstdio.h"<br />
<br />
<br />
int main()<br />
{<br />
char str[80];<br />
<br />
cout << "Enter a string: ";<br />
gets(str); <br />
cout << "Here is your string: ";<br />
cout << str;<br />
<br />
return 0;<br />
}
It might make sense that the two streams are not synchronized which is the only thing I could think of, however Mr. Schildt has produced otherwise. Possibly a different compilor configuration?
Mr. Schildt shows this in his book:
Enter a string: This is a test<br />
Here is your string: This is a test
|
|
|
|
|
#include "iostream.h"
This is the old way of including the C++ standard headers, which indicates that the book may be a bit outdated. The new headers don't have an extension, e.g.:
#include <iostream><br />
#include <cstdio>
It is up to the iostreams implementation to decide how to handle buffering, and some older implementations may have synchronization between iostreams and stdio turned on by default.
- Mike
|
|
|
|
|
Okay, however it is due to my mistake that the includes are listed as so. I had actually changed the <iostream> to "iostream.h" because the web forum didn't display that till I figured out that feature.
Which leads me to my main point, which is how am I supposed to learn this book of the stuff doesn't compile. I paid alot of money for this book, and I don't think it's old either.
|
|
|
|
|
I haven't read any of the C++ books by Herb Schildt, but I've heard both good and bad things about them. The edition you mentioned was published in March 2003, which is indeed fairly recent, so I would expect it to follow more modern conventions.
The code snippet you posted earlier should work fine (it compiles fine in VC6 for me, with the using namespace std; line and the includes changed to their modern versions) since all the input is coming from one type of stream and all the output is going to another type of stream. The problem arises when you read in data from two different types of streams or write data to two different types of streams.
Stylistically, I would argue that mixing cstdio and iostream is generally a bad idea, even in a case like this. Also, gets() is inherently unsafe, since the program would break if a line longer than 80 characters was entered. Hopefully, this was noted in the book. If not... eep. 
shawnsch wrote:
how am I supposed to learn this book of the stuff doesn't compile.
What was the compiler error? I'm curious, since, as I mentioned, I just tried it in VC6 and it compiled and ran. Here is the version I tried:
#include <iostream><br />
#include <cstdio><br />
<br />
using namespace std;<br />
<br />
int main()<br />
{<br />
char str[80];<br />
<br />
cout << "Enter a string: ";<br />
gets(str); <br />
cout << "Here is your string: ";<br />
cout << str;<br />
<br />
return 0;<br />
}
- Mike
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
