|
Why do you query the file name and the folder separately and then concatenate them, are you sure this produces a valid path (correctly separated with backslashes)? Use CFileDialog::GetPathName[^] instead. Not to mention you are querying these strings BEFORE you display the dialog to the user, so most likely you get 2 empty strings anyways. Those Get... things will give you something usefull once the dialog has been dismissed via OK. Another thing, _T() is used on string literals, not on CString objects returned by some functions.
Muzammil Saeed wrote: How can I know that which item i present in which header file...just like File Open/Save dialogs are present in afxdlgs.h??Confused
- What do you mean by this?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
1)..As stated earlier, im new to this, next time I"ll use seggested functions i-e GetPathName().
2)..In order to use Open FileDialog / Save File Dialog, w mus incluse afxdlgs.h file (which off course is te required header file), how can I know that which header file to include b4 using something?? I mean where find header files to choose from??
|
|
|
|
|
If you have a "standard" MFC project created for you by Visual Studio then most common things like the CFileDialog you can access freely without explicitly needing to include anything because the headers for these things are included (directly or indirectly) inside stdafx.h which will be included in your cpp files anyways. If for some reason you DO need to add includes explicitly you can check MSDN[^], search for the class or method or whatever you want to use and check its documentation, also, you can google for it, e.g:
1. Google for CFileDialog[^]
2. Click the first hit (it's usually MSDN if you are looking for common MFC/Microsoft things)
3. scroll down till you see this: " Header: afxdlgs.h ", this info is mostly located around the bottom of the page, somethimes there's even a table showing you what header you need to include, what library/DLL contains the implementations, etc.
Another way is to simply hit F1 while the cursor is on what you are looking for, this should give you the documentation for it which should state the header. Also another way is to right-click what you are looking for and select "Go to declaration", if you are lucky it will bring you to the header you need to include to use the given item.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
|
Yourwelcome.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
You should use getpathname method.
or
change code with
PlaySound(filepath +"\\"+ filename,NULL,SND_SYNC);
|
|
|
|
|
Hi all,
i m taking help of this article for printing in my application.
Another ListView print (preview) sample.[^]
but some times in 64 bit machine Print and Print Function not responding.
when i debug the code i found in OnPreparePrinting(CPrintInfo* pInfo) function DoPreparePrinting(pInfo) return false.
but this problem is resolve when i restart the machine.
please tell me how can i resolve the problem without restarting the machine.
thanks in advance.
modified on Monday, July 19, 2010 2:57 AM
|
|
|
|
|
If I open one named pipe and want to communicate both ways between client and server, how do keep the client from reading data it just wrote to the pipe? Or is the data only transfered in one direction, that that the client cannot end up reading the data it writes?
For example: Client writes a string, then assume the server reads the string, so it checks the pipes for a response, then ends up reading the string it just wrote to the pipe.
|
|
|
|
|
AFAIK it is like two uni-directional pipes, similar to a serial port communication.
|
|
|
|
|
The situation cannot happen. One "end's" writes are the other "end's" reads.
|
|
|
|
|
CreateNamedPipe api used to create namedpipes provide you with option duples,inbound or outbound
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
dene99970 wrote: Client writes a string, then assume the server reads the string, so it checks the pipes for a response, then ends up reading the string it just wrote to the pipe.
This should never happen, as previously pointed out. There is a probably a bug in your source code or the "server" echos back received text, can you show example code?
/M
|
|
|
|
|
hello guys...im new to MFC using VS 2008. How can I get the radio buttons status in MFC using VS 2008??
|
|
|
|
|
read the documentation and have a look at CButton::GetCheck[^].
M.
Watched code never compiles.
|
|
|
|
|
BOOL bSelected = (CButton*) GetDlgItem(IDC_XYZ))->GetCheck();
--
"Programming is an art that fights back!"
|
|
|
|
|
GetCheck returns an int in case the radio or more probably the checkbox is a 3 state button; so if you only want to see if it's checked, do something like :
BOOL bSelected = (CButton*) GetDlgItem(IDC_XYZ))->GetCheck() == BST_CHECKED;
(but I'm only nitpicking).
Watched code never compiles.
|
|
|
|
|
Maximilien wrote: BOOL bSelected = (CButton*) GetDlgItem(IDC_XYZ))->GetCheck() == BST_CHECKED;
(but I'm only nitpicking).
While we are picking nits... GetDlgItem() actually returns a pointer to a CTempWnd* object if there is no entry in the internal MFC permanent CHandleMap. The only reason why this code does not cause an access violation is because CButton::GetCheck() is an __inlined SendMessage(m_hWnd,BM_GETCHECK...
You should avoid upcasting a pointer returned from GetDlgItem().
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: You should avoid upcasting a pointer returned from GetDlgItem().
To add to the nitpicking that is exactly what the documentation[^] recommends that you do.
It's time for a new signature.
|
|
|
|
|
Richard MacCutchan wrote: that is exactly what the documentation[^] recommends that you do.
An additional nit to pick: The upcast in the documentation is completely pointless... GotoDlgCtrl[^] takes a pointer to a CWnd* object. The CWnd* pointer returned by GetDlgItem would suffice. The MSDN documentation is full of bad sample codes.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: The upcast in the documentation is completely pointless
I disagree; the upcast makes it clear what the code is trying to do. Since the actual item being returned is a CButton (even though GetDlgItem doesn't know that) it would seem the sensible thing to do, especially if you then want to call some method on the CButton object.
It's time for a new signature.
|
|
|
|
|
Richard MacCutchan wrote: Since the actual item being returned is a CButton
Are you sure saying that GetDlgItem returns a CButton object?
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Are you sure saying that GetDlgItem returns a CButton object?
No, I'm saying it returns the object whose ID is sent to GetDlgItem(), which will be some class derived from CWnd. That is why the upcast is required.
It's time for a new signature.
|
|
|
|
|
Richard MacCutchan wrote:
No, I'm saying it returns the object whose ID is sent to GetDlgItem(), which will be some class derived from CWnd.
Richard,
This is not always the case. GetDlgItem will return a CTempWnd object[^] if there is no entry inside the internal MFC handle map.
You should always avoid upcasting a pointer from GetDlgItem.
Best Wishes,
-David Delaune
|
|
|
|
|
Sorry but I'm still not clear on this. It doesn't matter whether the object pointer is permanent or temporary, it is still a CButton*. If the object does not exist, or the value to GetDlgItem() is not valid you won't get a pointer to anything.
OK David,
I have just read that article again and understand (almost, but not completely) why your assertion was correct. Sorry, for belabouring this but my experience of MFC was that this upcasting always worked; I just hope nobody is still using one of my old programs.
Thanks for the guidance.
Richard
It's time for a new signature.
modified on Tuesday, July 20, 2010 1:28 PM
|
|
|
|
|
Richard MacCutchan wrote: Thanks for the guidance.
Your welcome.
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
