|
I don't know - I try to assume literal interpretations of questions. I could easily be wrong. 
I guess another option for him is WM_COPYDATA.
|
|
|
|
|
I also assumed they wanted to pass data or a pointer to some data.
|
|
|
|
|
The command line parameter is a string. Because it's a wide string, each character is two bytes. You should pass the parts of the struct as a comma seperated string and rebuild it in the process.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Generate a new GUID.
Make a memory mapped file (MMF) using this GUID as its name.
Pass this name as a command line argument to the new process.
Open the MMF from the second process and read your data from the MMF.
|
|
|
|
|
in jscript:
var shell = new ActiveXObject("WScript.Shell");
var fso = new ActiveXObject("Scripting.FileSystemObject");
Is there a way for MFC to do this and how?
Tnx in advance....
quistiun
|
|
|
|
|
Hello my fellow programmers,
I am in the process of writing some front end software that takes to an engine management unit that will program it and perform data acquisition in real time.
I have written software for this before using the MFC Doc View Framework and I have had considerable success with this. However this new project is for a newer unit and will most probably have a life span for the next 5 years. The target operating systems for this will be Win98 SE through to XP.
My question is Should I be writing this in MFC or should I consider using managed C++ and the new .NET Framework. Any inputs/questions would be greatly appreciated.
Best Regards
Danny Nowlan
|
|
|
|
|
MFC. Simply because I don't think the .NET framework in C++ will give you anything that justifies having the ship the framework.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian,
I must admit that is a very valid point. Some of the machines we will ship too are very underspeced Win98 machines and I don't think they would take too kindly to the .NET framework. MFC I know very well and I know it works. Thank you for your consuel.
Danny
|
|
|
|
|
|
LOL - when I last used WTL it was really interesting, due to lack of support and docs. Do Microsoft officially support it now ? Is it being developed still ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
It is open source now[^] and still developed by original Microsoft guys.
I have seen quite a number of job ads mentioning WTL, so I wouldn't count it out.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Given what you've seen of the requirements, why would WTL be a better choice than MFC?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
why would WTL be a better choice than MFC
Adding a new skill to his resume? 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
David,
That's what I'm trying to figure out. I want to select the right tool for the job.
Danny
|
|
|
|
|
Understood, but a blanket statement like, "MFC, or even better, WTL." without any reasoning, is hardly useful.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
I have a window that has four static and 4 edit fields.
I am changing data outside to finish my beta-testscript. The app is done in MFC.
Using spy++ I can see the 4 edit fields and the four static fields.
Is there a possible way to see which are related to eAch other.
I seriously doubt it. but maybe someone may know the answer.
Thanks,
Nick
I'm not an expert yet, but I play one at work. Yeah and here too.
|
|
|
|
|
You could check their window positions.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
You can check their positions, as C. Graus suggested, or you can check the tab order of the controls.
If you enumerate the dialog controls using GetNextDlgTabItem, each static control should be right before its corresponding edit field, because that's what you need to make the shortcuts on the static controls activate the appropriate edit controls. I think it makes sense for a test script, because if the controls aren't ordered that way you have a design problem, anyway.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
