|
Does StgOpenStorageEx() work any better?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I have a problem regarding keyboard navigation in child controls of dialog boxes. I have mentioned the style of the child controls to Tab stop while desining the dialog boxes . It works fine when I test the dialog boxes from Layout->Test menu option in Developer Studtio. But when i run the program the keyboard navigation does not work.
Can any one tell me the solution?
|
|
|
|
|
If you create your dialogs using the DialogBox API then there is nothing further to do. However if you have modeless dialogs (CreateDialog API) then you need the IsDialogMessage API in you main-message loop.
|
|
|
|
|
Hi,
I'm trying to program a custom control using VS2005 MFC AppWizard.
The framework code built by the wizard produces several errors, when I try to built it:
for instance:
IMPLEMENT_OLETYPELIB(CEchoCtrl, _tlid, _wVerMajor, _wVerMinor)
error C2065: '_tlid' : undeclared identifier
error C2065: '_wVerMajor' : undeclared identifier
error C2065: '_wVerMinor' : undeclared identifier
Any ideas how to fix this bug?
Thanks a lot in advance.
Matthias
|
|
|
|
|
I've had this happen when trying to add OLE automation support after my project was already created.
I had to use the GUID generator tool, to create a GUID in the IMPLEMENT_OLECREATE format and place something like the following in my Application implementation file. Your needs may be slightly different but maybe this'll help you work out the details. For what it's worth...
// {EF6B41DD-E766-45d8-B731-5923AF4B105A}
const GUID CDECL BASED_CODE _tlid =
{ 0xef6b41dd, 0xe766, 0x45d8, 0xb7, 0x31, 0x59, 0x23, 0xaf, 0x4b, 0x10, 0x5a } };
const WORD _wVerMajor = 1;
const WORD _wVerMinor = 0;
|
|
|
|
|
Hi,
Could someone please show me how to insert data to a number field in an access database. I am using ADO with safe arrays. I can insert and retrieve strings but havent got the hang of working with numbers and boolean data.
Thanks
|
|
|
|
|
Currently I am using the LVN_ITEMCHANGED notification message to update some controls containing data related to the items selected in the a list control. The problem is that since LVN_ITEMCHANGED gets called for every item that changes state even if they all change state at the same time, say 100 items get deselected at once, it makes the processing very slow.
My question is: do list controls send some kind of message notifying the parent of when they're going to start to select/deselect multiple items (I haven't found any such notifications) or what would be the best method of implementing this type of behavior?
Thanks in advance.
|
|
|
|
|
_johan wrote: do list controls send some kind of message notifying the parent of when they're going to start to select/deselect multiple items
Do you mean LVN_ITEMCHANGING?
_johan wrote: ...what would be the best method of implementing this type of behavior?
After each item has been selected, why not just iterate through each one using:
POSITION pos = m_list.GetFirstSelectedItemPosition();
while (pos != NULL)
{
int nItem = m_list->GetNextSelectedItem(pos);
}
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thanks for your reply. I wasn't clear enough in my original post.
Let's say 50 items are deselected at the same time by clicking on the list view outside of an item. The list view sends notifications for every single item thats deselected. I was wondering if there was a way to know when all 50 items have been deselected, instead of processing each one independently. I suppose the only way to do this is to manually handle mouse and keyboard messages...
|
|
|
|
|
If change bk color of CPropertySheet and CPropertyPage by OnCtrlColor(), the CTabCtrl's bk color is not changed.
how to change bk color of CTabCtrl which is used by CRropertySheet?
|
|
|
|
|
Hi All,
Please briefly explin the difference between the CList and CArray.
regards
Mohan.
-Mohan-
|
|
|
|
|
CArray is a sequentially allocated chunk of memory containing a series of objects. It is comparable to a standard C++ array, but resizeable (and with some helper functions.)
CList is a double linked list of objects. For all intents and purposes each object is placed in a container with a pointer to the previous object and one to the next.
Interestingly, I've actually never used a CList in a commercial program, though I've used single linked lists many times.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
|
The core thing to understand is that MFC containers were written to fill a gap, which no longer exists. They are in every way inferior to STL containers list and vector. The same limitations exist ( one is an array, one is a linked list ), but the extra features and standard nature of the STL makes them far more useful.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
"The core thing to understand is that MFC containers" is that they were written with CObject derived classes in mind so they fit into an MFC application very nicely. I can serialize my CTypedPtrXXX collections with a simple statement like
m_ImageObjectMap.Serialize(ar);
All of my object allocations are handled for me. After that single statement, the code used to manipulate these collections can get to work. Multi-dimensional collections are a breeze and they are type-safe. In a typical MFC doc/view based application, the MFC template based containers have made coding complex polymorphic classes fairly easy.
Now with that said, I've never used STL (I use MFC extensively) so please elaborate on your statement...
Christian Graus wrote: They are in every way inferior to STL containers list and vector. The same limitations exist ( one is an array, one is a linked list ), but the extra features and standard nature of the STL makes them far more useful.
How exactly does STL integrate better into MFC application than it's own CObject aware containers? As a novice to STL, I'd love to learn.
|
|
|
|
|
I've not done any MFC (or C++) for ages but I suspect the serialization thing is one area in which the MFC containers are superior. Although the Boost library for STL probably has such features.
Apart from portabaility, which you may or may not need, the main benefit of the STL containers is their algorithm support. Though you can apply many of these algorithms conveniently to CArray classes. STL is well worth learning, especially as it is a part of Standard C++. And you don't have to learn it all at once. Just start with simple stuff such as strings and basic use of collections. There are lots of code snippets in the VC++ online help. That's how I started.
Kevin
|
|
|
|
|
Thanks for the guidance.
My reply was really intended to challenge Mr. Graus to substantiate some of those statements since, in my humble opinion, he's been throwing some pretty big statements around (lately) about STL but backing them with weak generalizations that amount to nothing useful. Just because STL is "great" does not diminish the proven potential of other technologies in their respective arenas.
The question was in regards to CList and CArray which would suggest the use of MFC in the application. Dropping STL containers into an MFC application defeats the purpose of using MFC in the first place in my opinion and it almost seems irresponsible for someone to suggest it. MFC was built with many presumptions about the application and almost requires the program be written the "MFC way" in order to save anybody any reasonable amount of effort. If you deviate from this course, then you really need to ask yourself why your even using MFC. (You in general, not you)
It sure sounds like STL is the way to go IF you've left MFC behind but I beg to differ when MFC is core to the programmer's code. However, I'm open to reasonable debate (if the claims are substantiated) to enlighten me.
|
|
|
|
|
bob16972 wrote: Dropping STL containers into an MFC application defeats the purpose of using MFC in the first place in my opinion and it almost seems irresponsible for someone to suggest it.
I disagree. MFC is not just about containers is it? I tend to take a "choose an appropriate tool for the job" approach to these things. So I would say use the MFC containers if they're good enough but if you find that a particular problem lends itself well to an STL solution then use it. There's no resaon why if you're using MFC you must use only MFC classes.
Kevin
|
|
|
|
|
Would you suggest using STL over the MFC container classes before you knew which was the best for the job? Would you suggest one over the other if you had no clue what the problem context was? Would you dog one over the other blindly evertime I used the words "CArray" or "CList"?
I would surely hope not. Mr. Graus did just that and I find it irresponsible to blindly slap a library on top of an arbitrary problem potentially misguiding people who are asking for solutions in certain contexts. The thread initiator did not ask about STL. He asked about comparing two MFC classes. We don't even know what problem that person is trying to solve yet. How is that choosing an appropriate tool for the job?
User: "I have a question about CArra..."
Mr. Graus: "You should be using STL. It's great! It's what you should be using anyway because it's *standard*. I have no clue what your code is about but MFC is so yesterday so use STL."
Give me a friggin' break. That's just silly!
-- modified at 15:27 Sunday 6th August, 2006
|
|
|
|
|
bob16972 wrote: Would you suggest using STL over the MFC container classes before you knew which was the best for the job? Would you suggest one over the other if you had no clue what the problem context was?
Now, I probably would tend to go for STL first. However, when I was last doing C++ it would also depend on whether I was writing new code or maintaining existing code. With the latter I tend to adapt to the context of the source code. Even when using STL extensively in an MFC app. I would still use CString because it is (a) more convenient and better adapted for use with MFC and (b) has better functionality than STL string. I think it may also be more efficient.
bob16972 wrote: Would you dog one over the other blindly evertime I used the words "CArray" or "CList"?
No.
bob16972 wrote: I find it irresponsible to blindly slap a library on top of an arbitrary problem potentially misguiding people who are asking for solutions in certain contexts.
Yes, I agree with that. Even if STL containers are superior we don't know what the context is. Is the user maintaining legacy code? Does it already contain a bunch of CArray and CList data structures, etc.?
Kevin
|
|
|
|
|
bob16972 wrote: Would you suggest using STL over the MFC container classes before you knew which was the best for the job?
As a general rule, I would suggest STL all the time, yes. If you're getting some serialisation support from the MFC containers, and if you're confident that you'd rather write code to move items between container types in MFC (if you need to), and to do things like sort and search in your MFC containers, and if you're confident that every C++ program you ever write will use MFC, and you feel that writing a function object for use by 'for each' for serialisation is more work than all of the above, then you should stick with MFC.
bob16972 wrote: Would you dog one over the other blindly evertime I used the words "CArray" or "CList"?
*sigh* As has been said, STL is more powerful than MFC containers, and is *standard*. If you were in an automotive forum, would you suggest a car that ran on gas whenever someone asked for help with their steam driven car ? I reckon you would.
bob16972 wrote: The thread initiator did not ask about STL. He asked about comparing two MFC classes.
Yes, and had that question not already been answered, I would have answered it. Especially given that the question was very beginner in nature, I presumed that on top of wanting to know about the different between a dynamic array and a linked list, it was worthwhile for the person who asked the question to be aware that the MFC containers are obsolete, and lacking in many features that are present in C++ containers.
bob16972 wrote: Give me a friggin' break. That's just silly!
No, what's silly is that so many people use containers that they are going to outgrow, because they don't know any better.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: and you feel that writing a function object for use by 'for each' for serialisation is more work than all of the above, then you should stick with MFC.
You do, of course, realize that many of the MFC containers can be used in almost all of the STL algorithms? In fact, many of the STL algorithms can even operate on something so "archaic" as a C-style array.
Christian Graus wrote: As has been said, STL is more powerful than MFC containers
*ehem* You should clarify: As has been stated by you.
Christian Graus wrote: aware that the MFC containers are obsolete, and lacking in many features that are present in C++ containers.
And what features, exactly, are the MFC containers "missing" that STL containers have. Besides the little used ability to change memory allocators or container traits, that is.
Christian Graus wrote: No, what's silly is that so many people use containers that they are going to outgrow, because they don't know any better.
You use a hammer when you need a hammer; a screwdriver when you need a screwdriver; and the proper collection type for the data you are operating on when you need that.
I'm a big fan of STL, and routinely remind programmers that 90% of the time they shouldn't be writing loops when using STL; however, STL is not superior to MFC in the area of collections, it is different. They were designed for different purposes and each should be used appropriately for those purposes.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
bob16972 wrote: (lately)
I've been advocating the use of STL for a long time now, not just lately. Ask some char * questions, and it's likely that as well as answer you, I'll point out that in C++ we have string classes. IMO, answering questions sometimes means more than answering what is asked, it also means pointing out where there are better alternatives.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
bob16972 wrote: Dropping STL containers into an MFC application defeats the purpose of using MFC in the first place in my opinion and it almost seems irresponsible for someone to suggest it.
I wouldn't go quite that far. I've found myself using STL containers in MFC apps quite frequently. Particularly, when the data I'm storing will need to have algorithms sorting, searching, etc. it. That said, you should try to code consistently. If you start using MFC containers in a class, you should continue to do so unless there is a strong reason not to and vice versa.
STL and MFC do not have to be mutually exclusive, and can work together very well if used together properly (e.g. MFC for GUI code and STL for data operations).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
bob16972 wrote: How exactly does STL integrate better into MFC application than it's own CObject aware containers?
It plainly does not. You'd need to write one or two function objects to replace this part of the MFC containers.
bob16972 wrote: As a novice to STL, I'd love to learn.
While I slept, it became clear that you're trying to bait me, but I'll answer anyhow.
1 - MFC containers are convoluted to access compared to STL.
2 - MFC containers all use different iterators, so to move objects from one type of container to another is a pain
3 - MFC containers do not come with any algorithms such as search, sort, binary_search and random_shuffle
4 - I don't believe that MFC containers have a for_each mechanism that allows to easily write small functions that plug into the containers for reuse of code for common operations
5 - MFC containers were written before STL containers, and were intended to be a stopgap until an STL implimentation became available.
6 - MFC containers are not standard, so if you ever find you're writing a program without MFC, you will be forced to learn STL anyhow.
So, it is better IMO to learn the more powerful and more widely available library, although there's nothing wrong with using MFC containers in the knowledge that you've compared the two options and there are reasons for the choice. In my experience, many people don't even know about STL, and certainly people who ask 'what's the difference between an array and a list' are likely to fall into that category. I use CString all the time, but I would use std::string as a first port of call on my own code, unless I knew that CString did something better.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
