|
I have tried a variation of just about all the flags, none of which work. The STG_E_SHAREVIOLATION is returned for each. After spending quite some time searching the web for an answer I have concluded that there isn't one. However, I am going to try copying the file to the temp directory and opening it from there. This app is a simple reader, the file would not be modified in any way at all.
|
|
|
|
|
Creating a temp copy of the file seems to work. For anybody with a similar problem here is the modified code:
if(FAILED(hr)) {
if(hr == STG_E_SHAREVIOLATION ) {
char tmpPath[MAX_PATH];
char tmpName[MAX_PATH];
GetTempPath(MAX_PATH,tmpPath);
GetTempFileName(tmpPath,"TMP",0,tmpName);
if (!CopyFile(filename,tmpName,FALSE) )
return 0;
MultiByteToWideChar(CP_ACP, 0, tmpName, strlen(filename)+1, wcFilename, 1024);
hr = ::StgOpenStorage(wcFilename, NULL, STGM_READ|STGM_SHARE_EXCLUSIVE , NULL, 0, &pStorage);
if(FAILED(hr))
return 0;
}
else
return 0;
}
|
|
|
|
|
waldermort wrote: Everything works perfectly, but
If I had a nickel for every time somebody said that in this forum...;P
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
