|
How to convert CString to LPCTSTR. I use this function:
BOOL CDialogMaintenance::CopyFolder(LPCTSTR pFromFolder, LPCTSTR pToFolder)
{
SHFILEOPSTRUCT fo = {0};
fo.wFunc = FO_COPY;
fo.pFrom = pFromFolder;
fo.pTo = pToFolder;
fo.fFlags = FOF_SILENT | FOF_NOERRORUI;
int rc = SHFileOperation(&fo);
return (rc == 0);
}
But pFromFolder don't works with type cast (LPCTSTR)CString but it's work only with "C:\\directory\\subdirectory" !!!
THANKS
|
|
|
|
|
GetBuffer and ReleaseBuffer.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Sorry but Getbuffer doesn't works with pFromFolder
SHFileOperation return a error.
WORK
CopyFolder("C:\\directoy\\sub","D:\\directoy\\sub");
DON'T WORK
CopyFolder(str.Getbuffer(size),"D:\\directoy\\sub");
CopyFolder((LPCTSTR)str,D:\\directoy\\sub");
BOOL CDialog::CopyFolder(LPCTSTR pFromFolder, LPCTSTR pToFolder)
{
SHFILEOPSTRUCT fo = {0};
fo.wFunc = FO_COPY;
fo.pFrom = pFromFolder;
fo.pTo = pToFolder;
fo.fFlags = FOF_SILENT | FOF_NOERRORUI;
int rc = SHFileOperation(&fo);
return (rc == 0);
}
|
|
|
|
|
|
Yes i'll read this article but the conversion is good in DEBUG mode but the function (SHFileOperation) always returns an error!! Strange
Thanks for help
|
|
|
|
|
jerome_data wrote:
How to convert CString to LPCTSTR.
CString already converts automatically to LPCTSTR (through a cast operator). You don't need to do anything special.
jerome_data wrote:
But pFromFolder don't works with type cast (LPCTSTR)CString
What exactly do you mean? What's your code and what's the error?
The following fragment should compile and run as expected:
CString sFromFolder = "C:\\directory\\subdirectory";
CString sToFolder = "C:\\directory\\OtherSubdirectory";
if (!CDialogMaintenance::CopyFolder(sFromFolder, sToFolder))
{
}
[UPDATE]
If that doesn't work, maybe you have wrong definitions for Unicode/MBCS? You should have one of the following combinations:
a) Unicode project: UNICODE defined, _UNICODE defined, _MBCS not defined
b) MBCS project: UNICODE not defined, _UNICODE not defined, _MBCS defined
c) No setting: UNICODE not defined, _UNICODE not defined, _MBCS not defined
Any other combination may cause problems.
[END UPDATE]
That being said, the documentation for SHFILEOPSTRUCT[^] says the following about both pFrom
and pTo :
"Although this member is declared as a null-terminated string, it is used as a buffer to hold multiple file names. Each file name must be terminated by a single NULL character. An additional NULL character must be appended to the end of the final name to indicate the end of [pFrom or pTo]"
I suggest you modify CopyFolder to something like this:
static LPCTSTR GetBufferWithExtraNull(CString s)
{
int len = s.GetLength();
LPCTSTR p = s.GetBuffer(len+1+1);
p[len+1] = '\0'
return p;
}
BOOL CDialogMaintenance::CopyFolder(LPCTSTR pFromFolder, LPCTSTR pToFolder)
{
SHFILEOPSTRUCT fo = {0};
fo.wFunc = FO_COPY;
CString sFrom = pFromFolder;
fo.pFrom = GetBufferWithExtraNull(sFrom);
CString sTo = pToFolder;
fo.pTo = GetBufferWithExtraNull(sTo);
fo.fFlags = FOF_SILENT | FOF_NOERRORUI;
return (SHFileOperation(&fo) == 0=;
}
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Jose Lamas Rios wrote:
An additional NULL character must be appended to the end of the final name
I know for a fact that this is the problem. Without double terminating the string unpredictable results will occur...
John
|
|
|
|
|
John M. Drescher wrote:
I know for a fact that this is the problem. Without double terminating the string unpredictable results will occur...
I've been bit by this more than once.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Hi
I create a property sheet that include 3 pages and when i display the property sheet, the size of the current dialog box is smaller than the real size of that same dialog box when i design it. How can i keep the original size of my dialog boxes
@ly D
|
|
|
|
|
Are you using CPropertySheet and CPropertyPage?
The property sheet has the same size regardless of the active page. I seem to remember it takes the size from the largest page at the time the sheet is created (plus of course the extra space for the tabs and the buttons). You should take this into account when designing the dialog templates for pages that will share a common property sheet, that is, resize all of them to the size of the biggest one, and arrange the controls in each page so that they look good within that space.
As an alternative, you can use the values defined in PrSht.h, and make your pages adhere to one of the standard page sizes: small, medium, or large, respectively. The sizes are in dialog units (those used in the template dialog editor):
#define PROP_SM_CXDLG 212
#define PROP_SM_CYDLG 188
#define PROP_MED_CXDLG 227
#define PROP_MED_CYDLG 215
#define PROP_LG_CXDLG 252
#define PROP_LG_CYDLG 218
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
HI,
I would like to add URL link in CDialog derived class. Can anybody help or direct me to some resources?
I really appreciate your help.
Thanks,
Sri
|
|
|
|
|
Use a label, color it to look like a link, and handle it's click event. In the event, call ShellExecute with the url.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
http://www.codeproject.com/miscctrl/hyperlink.asp
|
|
|
|
|
|
HI Guys,
Thanks for all ur support...I really appreciate this forum...
Regards,
Sri
|
|
|
|
|
I am using FindowWindow and SendMessage to execute controls on a MFC app to automate my beta-testing
My question:
I have 2 windows both with a blank name listed under spy++ and I need to have a way to identify them both. Is there an API command to get info on the window so I can tell which window Im pointing to?
please help.
Nick
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
|
Do they both belong to the same class (FindWindow's other parameter)?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
no they are different classes.
Is there a window info type structure I could use.
Then I could query the class. and inspect its properties to identify it.
Nick
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
|
You can get the class of a window by using:
int GetClassName(HWND hWnd, LPTSTR lpClassName, int nMaxCount);
Wout Louwers
|
|
|
|
|
Ista wrote:
no they are different classes.
Then use FindWindow() .
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
but I need information on the window. more than just the name. i.e... there could be 2 ListViews and I would need to find a way to differentate.
I think I saw a WindowInfo structure somewhere and that would help me.
thanks for helping but I can probably figure it out.
-- too bad I can't tie static fields to edit fields.
Nick
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
|
well thanks. I just need to enumerate the windows. FindWindow wont work becuase listViews dont have a name.
But enumerating will allow me to check the subclass of each window therefore finding the list view.
But this would only work for one list view and if theres 2 then I'm back to the same spot.
but thnkas everyone for helping.
Nick
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
|
Ista wrote:
...listViews dont have a name.
But they do have a unique identifier. Once you have a handle to the parent window, just use GetDlgItem() to get a handle to the control itself.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
As far as I understand, the CDocument::m_bAutoDelete variable will tell MFC that it should not delete the document when closing the last view attached to it when set to FALSE .
I tried this with a simplistic MDI MFC application, setting m_bAutoDelete to FALSE in the CDocument constructor; but when I close the last view ( WM_CLOSE on the ChildFrame ), it closes the view ( and frame ), but will replace the current menus with the ones for when there is no document active.
I wanted to have the document loaded with all the views closed, and still have the "Window" ( with the new window command ) menu available.
I want to make sure the user close the document with a "Close" document command, not by closing all the views.
Any Ideas ? I google for this, but nothing really interresing came up.
Thanks.
Max.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
This goes back *years*, but...
Back in 1995 when I was at Peachtree we had a similar situation where the document represented the company whose accounting you were doing and each view was based on that document. Therefore, closing the last view didn't close the document/file. (The user either closed the company explicitly or via closing the app)
As you mentioned, setting the m_bAutoDelete member var in a CDocument-derived class does the trick.
Obviously, the framework has to shut down the menu as it's associated with the view/frame in the template.
Therefore, what we did was to share the menu across all views. IOW, we had a menu (named something like IDR_COMPANY_OPEN) that was always displayed when a cmopany was open regardless of how many views were open.
However, the trick is that when constructing templates, you have to specify a res id that among other things identifies the menu. However, we only wanted to share the menu across all views - not anything else. Therefore, we did the following (I'll try and explain it from 10 years of memory.
* In the app object's InitInstance, we manually loaded a menu and stored its handle
* We derived our own CMultiDocTemplate class
* When constructing each template, we passed the menu handle to that c'tor
* The CMultiDocTemplate-derived class's c'tor then set its internal menu handle to that passed
* [IMPORTANT] In the d'tor you have to set the handle to null. Otherwise, the base class's d'tor will attempt to destroy your shared menu.
I'm pretty sure that was all we had to do.
Tom Archer - Visual C++ MVP
Archer Consulting Group.com
|
|
|
|