|
You need to make a change to the OPENFILENAME struct of the CFileDialog before calling DoModal():
CFileDialog dlg ( ... );
TCHAR szInitialDir[MAX_PATH];
dlg.m_ofn.lpstrInitialDir = szInitialDir;
--Mike--
http://home.inreach.com/mdunn/
"The Earth is doomed." -- Rupert Giles
![Heart | [heart]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/love.gif) your ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) with ![Good Stuff | [The good stuff]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/vegemite.gif) and ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
I use this to get my Application path.
::GetCurrentDirectory(1024, m_strAppPath.GetBufferSetLength(1024));
m_strAppPath.ReleaseBuffer();
You have to use this before you do anything else with files, since you then change the path. For example in InitInstance.
/Fredrik Sigbjörn
|
|
|
|
|
MFC -
Ok I have a combobox (m_cFilters) and in it I have Filters like:
All Files (*.*)
Text Files (*.tx) ...etc.
I want to grab the part between the parenthesis and store it in a var after the combo box is changed (DropDown combo, btw). I tried mapping the standard combo messages but after the functions return they do not update the combo box. What is the proper way to get the effect I am looking for? Is there an easier way to grab data like this other than straight from the combo string?
Thanks.
----
Xian
|
|
|
|
|
I haven't done much work with combo box controls, but I had a similar situation with a list control where i needed to store extra data besides what is displayed. I think you can use the CComboBoxEx object which use the COMBOEXITEM structure instead of LVITEM. You can store a pointer to a filter string (or a pointer to a structure if you need to store more)
<br />
typedef struct { TCHAR szFilter[256];
} FILTERDATA, *PFILTERDATA;<br />
Then just add the structure when adding your items, for list control:
<br />
PFILTERDATA pData = new FILTERDATA;<br />
strcpy(pData->szFilter, szMyFilter);<br />
<br />
COMBOEXITEM item;<br />
memset(&item, 0, sizeof(item));<br />
item.mask = CBEIF_LPARAm | CBEIF_TEXT;<br />
item.lparam = (LPARAM) pData;<br />
item.iItem = -1;<br />
item.pszText = new TCHAR[sizeof(szMyDisplay)];<br />
item.cchText = sizeof(szMyDisplay);<br />
<br />
nItem = m_cFilters.InsertItem(0, &item);<br />
Then when your user selects something do:
<br />
COMBOEXITEM cbi;<br />
ZeroMemory(&cbi, sizeof(COMBOEXITEM));<br />
cbi.iItem = hitTest.iItem;<br />
cbi.mask = CBEIF_PARAM;<br />
m_cFilters.GetItem(&cbi);<br />
<br />
PFILTERDATA pTemp = cbi.lParam;<br />
<br />
CString strTemp;<br />
strTemp.Format("Filter is %s", pTemp->szFilter);<br />
or maybe there's an easier way 
btw don't forget to delete the lparam pointer. probably best to subclass the entire control so you can delete the memory in teh destructor
|
|
|
|
|
 Do you think Microsoft is planning to replace MFC?
|
|
|
|
|
Where do you get this idea? MFC is here and will be here as long as we don't think it's gone. The apparent *less than normal* focus on MFC now a days I believe is due to Microsoft's marketing blitz to promote their new baby .NET and hence shouldn't be attributed to a full-scale *replacement* plan. But hey I may be wrong, I don't work for them and so I can't read their minds.
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
I believe that is what they hope to achieve, in that they want to replace C++ altogether with C#. If it happens or not depends on us as much as them. There are two reasons for people to change from C++ and only develop in C#:
1/ Because M$ gives us a compelling reason to do so ( i.e. a better language )
2/ Everyone blindly follows M$.
I don't care if 1/ occurs, good luck to Microsoft for providing a better option. 2/ scares me, because it seems more than likely to me.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
It's interesting to see so many of us think that MS has set out to kill their own libraries (e.g. MFC/ATL) they spent so many years to build. (Call this a suicide attempt or MS marketing conspiracy? go figure).
One alternative view on the subject could lie in the fact that MS had a monumental task to roll out something as big as .NET and so, despite of their desire to promote new stuff in MFC/ATL/WTL/MC++, they couldn't do that in the past (call it *resource limitation*?).
I honestly hope and believe that the latter is the case and MS will come out soon to do the catch up they haven't done since .NET was released.
I recently suggested a poll to CP on a similar tone (with the title: "the future of native C++ development on Windows") and was told by Chris that Microsoft is planning to conduct the same / similar poll on CP soon (similar to what they have done on C#). Hope this will happen *real* soon, so that we can express what we feel on this subject.
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
It's interesting to see so many of us think that MS has set out to kill their own libraries (e.g. MFC/ATL) they spent so many years to build. (Call this a suicide attempt or MS marketing conspiracy? go figure).
It's not really that much of a thinker. Their libraries have served them well, but the updates to MFC in VS7 are minimal AFAIK. No company grows from resting on past success. Having provided libraries to make it easier to develop Windows programs in C++, does that mean that they will continue on that track, when they are rolling out a brand new language that gives them the double advantage of stopping cross platform development AND means they OWN the standard so they can make the language do whatever they choose without people complaining what a poor job they do ?
One alternative view on the subject could lie in the fact that MS had a monumental task to roll out something as big as .NET and so, despite of their desire to promote new stuff in MFC/ATL/WTL/MC++, they couldn't do that in the past (call it *resource limitation*?).
WTL is not supported by M$ at all. Too bad, because it is cool. I believe there are interesting things in the new ATL ( haven't looked yet ), but I don't see why they would release a new language if they also want to keep pushing and developing the old ones ? Surely it's a case of 'that has done it's job, now we are moving to this'. There sure has been enough hype about C++ being 'too hard' and VB being 'not powerful enough' ( the latter is at least true ), to indicate what they are thinking.
I honestly hope and believe that the latter is the case and MS will come out soon to do the catch up they haven't done since .NET was released.
They still need to work on C# - the recent poll had them asking what we want in C#. Again, where do you think their efforts will go ?
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
WTL is not supported by M$ at all. Too bad, because it is cool.
Yup. It's not officially yet, but from its popularity I see in the WTL newsgroup, I think officially it will be part of VC++ in near future. I also think in recent days, MS has toned down the rhetoric about WTL significantly compared to what it had in the beginning of its release (remember the saying: "WTL should never be released" by Tony G., MS product manager)
I believe there are interesting things in the new ATL ( haven't looked yet ), but I don't see why they would release a new language if they also want to keep pushing and developing the old ones ? Surely it's a case of 'that has done it's job, now we are moving to this'.
I think MS had to release C# because they were under tremendous pressure to compete with Sun's Java. If they have enough resource, they can still make ATL/MFC successful along with new stuff like C#, .NET.
There sure has been enough hype about C++ being 'too hard' and VB being 'not powerful enough' ( the latter is at least true ), to indicate what they are thinking.
I agree. There is much hype on this power and simplicity things. What most of C++ programmers are led to believe that VB is a RAD language while C++ is not. In fact, C++ can have VB-like RAD features, such as "properties" and "events" and products like Borland's C++ Builder (and our own product RadVC on VC++) have proved that a C++ IDE can be made as simple as a VB like RAD IDE. Oh well, that is another story.
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
WTL is not supported by M$ at all. Too bad, because it is cool.
Yup. It's not officially yet, but from its popularity I see in the WTL newsgroup, I think officially it will be part of VC++ in near future. I also think in recent days, MS has toned down the rhetoric about WTL significantly compared to what it had in the beginning of its release (remember the saying: "WTL should never be released" by Tony G., MS product manager)
I doubt it will be supported, it's not in Microsoft's interest to divert attention from C#.
I believe there are interesting things in the new ATL ( haven't looked yet ), but I don't see why they would release a new language if they also want to keep pushing and developing the old ones ? Surely it's a case of 'that has done it's job, now we are moving to this'.
I think MS had to release C# because they were under tremendous pressure to compete with Sun's Java. If they have enough resource, they can still make ATL/MFC successful along with new stuff like C#, .NET.
The only pressure they were under came as a result of their breaking Sun's copyright. If only Stroustrup could sue M$ for their non conformance in the case of C++, then we'd get MS++, the result of reusing the VC++ code. I believe they will run an each way bet, not drop MFC until they are sure people are using C# instead. As for ATL, you need that to write sheel extensions, etc., so ATL is probably safe for now.
There sure has been enough hype about C++ being 'too hard' and VB being 'not powerful enough' ( the latter is at least true ), to indicate what they are thinking.
I agree. There is much hype on this power and simplicity things. What most of C++ programmers are led to believe that VB is a RAD language while C++ is not. In fact, C++ can have VB-like RAD features, such as "properties" and "events" and products like Borland's C++ Builder (and our own product RadVC on VC++) have proved that a C++ IDE can be made as simple as a VB like RAD IDE. Oh well, that is another story.
Indeed. I don't have anything to add, but I thought I'd be polite and leave the plug in. 
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Their libraries have served them well, but the updates to MFC in VS7 are minimal AFAIK. No company grows from resting on past success.
What would you like to see in MFC 7 and it's not there? The library is a mature product IMHO.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
What would you like to see in MFC 7 and it's not there?
Not a thing. I'd rather see Microsoft work on ANSI conformance.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
>> What would you like to see in MFC 7 and it's not there?
MFC is mature, or dated - depends upon your perspective, I suppose.
I'd like to see a lot more integration between MFC and STL for starters. And at least an alternative to the MESSAGE_MAP macro approach to command routing (the current MFC inplementation was designed essentially to overcome size and speed limitations that existed in PCs and operating systems (win 3.x) back in the early nineties - the compromises and limitations that flow from this are no longer valid). Also better use of C++ interfaces, multiple inheritence support for mixin classes for creating command processing controls, and some use of templates - oh, wait, that's probably WTL (maybe I want WTL and MFC to merge ...). And a useful tab control like Delphi/C++ Bulder would make life a lot easier every now and then.
And while I'm at it, I'd also ask for much better code wizard support when using MFC. And how about cleaning up the entire SDI/MDI and Document/View frameworks by allowing easier variations (single document, multiple windows, etc) and Model/View/Controller style interfaces? Does anyone actually create MDI apps anymore ??
And finally, perhaps MS can solve this whole Israel/Palestine/Muslim/Terrorist/USA thing so I can concentrate a little more on how to improve MFC.
>> Not a thing. I'd rather see Microsoft work on ANSI conformance.
Yes, yes, yes. At least get template support up to standard. Please. Pretty Please.
Oh, and Christian - I keep meaning to ask (and I'm too lazy to look it up) - how do I put quotes in italics in a post ??
----------------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."
|
|
|
|
|
The HTML tags for italics are <i> and </i>. Replace the i with a b to get bold text.
And that's all the HTML I know 
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
The thing you're describing wouldn't be MFC anymore.
Does anyone actually create MDI apps anymore ??
Everybody does MDI.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
You're right - it won't be the same as good old MFC. And then we'd need a new name for this new thing. Something very current sounding like, say, ".NET"
And that's why I think MFC is doomed to a long, slow ride into the sunset - it's already dated, and MS has no plans to even try to move it forward. It has no direct support for new C++ concepts/technologies like STL and templates, and little or no direct support for non-C++ things like XML and SOAP. If it doesn't at least try to move/change/evolve then it becomes obsolete, and MFC is well on the way to the destination.
If you want any more proof that MFC is a fading star just look at CodeProject - it exists largely to allow people to extend (ie, overcome the limitations) of MFC in almost every area, and as a clearing house of knowledge of how to deal with MFC's problems.
And some italic text. Hey , whadda know, it works - Thanks Christian
-----------------
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."
|
|
|
|
|
I think you're looking at MFC from the wrong angle. Why the hell should MFC know about SOAP or XML? Use it for what it was created: for encapsulating most often used Win32 stuff, like windowing. I'm using MFC only for rich user interfaces. Personally, I wouldn't be happy if MFC 8 suddenly supported SOAP or had its own XML parser.
We don't live in the world in which there's only one all-encompassing library.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Personally, I wouldn't be happy if MFC 8 suddenly supported SOAP or had its own XML parser.
Well, I'd at least like MFC 8 to allow me to access the MSXML parser if it was installed (via IE5 and above), and to do it easily and quickly. A 'CXMLAchive' object, for example.
We don't live in the world in which there's only one all-encompassing library
I agree , a single all-encompassing library is impractical and undesireable. My point is simply that MFC is not changing, and the operating system, desktop, and 'outside world' are.
Example 1 :
I want to use MFC as the framework for an app. By default, MFC wants me to put my data in the CDocument, and I can get persistence of my document via the Serialize interface. But I want to store my data in an STL map, and write it to/from an XML file. MFC gives me no support at all for this. I have to write it all myself (or get it from CodeProject!), and I also have to 'decouple' various MFC structures (default message map handlers for 'File Open', etc) in order to insert my alternatives. Lots of extra work, plenty of scope for extra bugs. Suddenly MFC starts to look like not so much an App framework, but just a few common controls and GUI wrappers - most of which offer only basic features, and need to be extended to handle 'advanced' operations (which users now consider to be 'basic' functions). IMHO, MFC's serialization framework, the foundation of the whole CDocument persistence mechanism, is dated and inflexible, and requires far too much work to customize. It needs to keep up with changes in the way data lives in the real world, and it isn't doing that!
Example 2 :
I want to use GDI+ for my drawing code. But I can't pass any GDI+ objects to any MFC drawing functions directly, and vice versa. I have to keep track of which font handle is which, and which DC object I am using, and convert between the "wrapper" objects continously. Why can't I pass a GDI+ 'Font' object to the MFC CWnd function "SetFont" ?? MFC's drawing model is dated, and needs to be updated.
I agree that MY wish list for MFC is extensive, and if everything I've mentioned was done then MFC would be not-MFC. But that doesn't mean the MFC should not be changing at all. Any product that wants to be "an application framework" must offer features that are needed by applications!! MFC is starting to fail this on a regular basis, unless the programmer spends the time and effort to 'patch in' the missing pieces.
I use the Accusoft Image Library. It is a mature product - up to version 9 now (well, that's the latest I use, anyway). Each new version adds support for new image formats, and increases performance and flexibility. The product is mature, and growing. It remains 'current'. It added PDF support when PDF became popular, for example. That's what MFC should be doing, and it's not.
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."
|
|
|
|
|
Example 1: well, I have to admit that I'm using MFC as framework, but mostly for UI. My data structures (in CDocument-derived class) are STL-based, file formats are plain text or XML. I don't have much problems with this. However, I understand that it could be made easier.
Example 2: can't comment on GDI+, have zero experience with this.
Example with Accusoft - new image formats are the equivalent of new common controls supported by MFC, right?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I have to admit I haven't seen MFC 7 yet, but from what I gather there aren't major leaps forward (please correct me if I'm wrong, I would like to know more).
What I'd like to see is greater functionality out of the whole thing, especially from a GUI point of view. Just think of all the spare time we'd have if we didn't spend it extending the MFC library
Derek Lakin.
Salamander Software Ltd.
|
|
|
|
|
Just think of all the spare time we'd have if we didn't spend it extending the MFC library
That is an excellent point. It proves that the term "maturity" often used in regards to MFC is rather relative.
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
It proves that the term "maturity" often used in regards to MFC is rather relative.
[edited message]
I strongly disagree. I don't want fancy bitmapped buttons, grids, sliding windows, etc. in MFC. This is a general-purpose library and should not contain any widget that's fashionable this fall.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I don't want fancy bitmapped buttons, grids, sliding windows, etc. in MFC.
Hey, that's why I used the word *relative*. MFC's own history tells us that it has extended and improved its GUI components from version to version. Sure most of them are more of a *wrapper* around their Win32 counterparts, but consider other GUI controls that are *extended* beyond this wrapping business (such as CBitmapButton, CCheckListBox etc.). Adding more controls into the library only makes it rich and thus leaving us, the end users to spend more time to make it even richer.
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
Adding more controls into the library only makes it rich and thus leaving us, the end users to spend more time to make it even richer.
The problem is that rich library becomes bloated library. Take ISAPI helper classes for example. Sure, there are users who benefit from them, but I think they are not majority.
Generally speaking, the life of library writers is not an easy one - they have to hit the bullseye and provide enough functionality within reasonably-sized package.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
