|
Yep, I'd say a malloc, or more properly, BYTE* pBuffer = new BYTE[uBufferSize]; is the way to go.
Once you've got your buffer you write the strings in by casting a copy of pBuffer + n to a TCHAR* and
copy your ints in by casting pBuffer + n to an int* and setting its value.
<br />
int* pFirstInt = reinterpret_cast<int*>(pBuffer + 0);<br />
*pFirstInt = nValue;<br />
int* pSecondInt = reinterpret_cast<int*>(pBuffer + 4);<br />
*SecondInt = nValue2;<br />
It's not pretty but then this sort of stuff seldom is. You could create some struct types and cast to
those. Up to you really. There are almost certainly fancier ways to do this with operator << overloading
and stl string stream modifiers but I wouldn't go there unless you've got a lot of complex data to
transfer and you know your stl.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks for the tip, that worked for the ints perfectly but still not getting the strings.
My code now is:
int* pFirstValue = reinterpret_cast<int*>(pBuffer + 0);
int* pSecondValue = reinterpret_cast<int*>(pBuffer + 4);
unsigned int* pStringLength1 = reinterpret_cast<unsigned>(pBuffer + 8);
unsigned int* pStringLength2 = reinterpret_cast<unsigned>(pBuffer + 12 + (sizeof(WCHAR) * firststring));
*pFirstValue = 1;
*pSecondValue = 2;
*pStringLength1 = strlen(firststring);
*pStringLength2 = strlen(secondstring);
strcpy((char*)(pBuffer + 12), firststring);
strcpy((char*)(pBuffer + 16 + (sizeof(WCHAR) * firststring)), secondstring);
</unsigned></unsigned>
That appears to me to be correct but as I've said before, C++ is not my strong point. Does that look correct?
|
|
|
|
|
This won't solve your marshaling problem, but:
You can't use strcpy, or TCHAR. All your strings are wchar_t
in C# so you should be using only wide character functions and types.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hello my dear friends,
I have developed a code to analyze a file (huge size). My application is MFC Dialog based. I use CFiledialog to open the files, after selecting the files I click OK and after that a shadow is appearing on my dialog for the size of the CFiledialog. This is very distraction to the GUI I have developed. Is there any way to remove the shadow after selecting the file.
Code is :
CString Test::OpenFile()
{
CString fname=LPCTSTR("");
CFileDialog fileDlg(TRUE, _T (".dat"),NULL,OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST, _T ("Data File (*.dat)|*.dat|Data File (*.dat)|*.dat|"),this);
if(fileDlg.DoModal()==IDOK)
{
fname = fileDlg.GetPathName();
}
else
{
MessageBox(TEXT("Select the File"));
}
return fname;
}
Please advice. Many thanks in advance.
|
|
|
|
|
|
I don't see any problem in the code you've provided. Probably you must try to do that "huge processing" in a worker thread and see if that helps. 
|
|
|
|
|
You could try using Invalidate(); UpdateWindow(); on your dialog
after the call to fileDlg.DoModal() but before you do any lengthy
processing on the UI thread (which you shouldn't be doing anyway).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi, Did you resolve this issue if yes please let me know how it worked.
Thanks
|
|
|
|
|
Hi,
how to conver char* into BYTE* in C++
Regards
|
|
|
|
|
Short (and dangerous) answer: with a cast, for instance
char * myCharPointer ="hello";
BYTE * myBytePointer = (BYTE *) myCharPointer;
A better answer may follow a more detailed request.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
of course, you're looking for devil every where :p
a char* is not always a string 
char c = 'c';
char* pc = &c;
BYTE* pb1 = (BYTE*)pc;
BYTE* pb2 = reinterpret_cast<BYTE*>(pc);
BTW, looking at the level of the question, i think it's worth saying that a char IS a BYTE:
char c = 'c';
BYTE b = c;
|
|
|
|
|
toxcct wrote: a char* is not always a string
char* is never a string. 
|
|
|
|
|
what do you know about C++, you Mr univoter ?
|
|
|
|
|
nice arguments
|
|
|
|
|
toxcct wrote: of course, you're looking for devil every where [Poke tongue]
of course.
toxcct wrote: BTW, looking at the level of the question, i think it's worth saying that a char IS a BYTE:
Nope. As you know (I know that you know ), char is a signed integer ranging from -128 to 127, while a BYTE is an unsigned integer ranging from 0 to 255.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
but you're already going to far by interpreting the bits pattern.
a BYTE is 8 bits, which is exactly what a char is supposed to be too.
|
|
|
|
|
toxcct wrote: but you're already going to far by interpreting the bits pattern.
Duty sir, duty. 
toxcct wrote: a BYTE is 8 bits, which is exactly what a char is supposed to be too.
float and int (even pointers!) have the same size on 32 bit systems but we usually don't consider them being the same.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Something like:
<br />
BYTE* pByte = reinterpretcast< BYTE* >( pChar );<br />
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Matthew Faithfull wrote: BYTE* pByte = reinterpretcast< BYTE* >( pChar );
quite... reinterpret_cast is the correct word ^^
BTW, i didn't try, but wouldn't static_cast just work here ?
|
|
|
|
|
Right you are, I knew that looked wrong somehow. I don't think static_cast works on pointers even when there are in fact a type match as these probably would be. Would have to try it to be sure.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
toxcct wrote: BTW, i didn't try, but wouldn't static_cast just work here ?
A static_cast won't work.
|
|
|
|
|
A BYTE is nothing but an unsigned char. If you do the math, that would tell you that the conversion may result in data loss, depending on the value stored in the char variable. The following situation may be an example:
char p = -23;
int i;
BYTE b;
|
|
|
|
|
To be very picky you don't actually loose data, as it's still an 8-bit value. It's just that the semantics change, your -23 = 11101001 gets reinterpretted as 233 = 11101001.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
[Footer: not for nitpicks, but for the noob op] 
|
|
|
|
|
I wanted to use a Console Window to output some debug information for my MFC application, that all works fine, but would like to make the Window a bit larger without having to modify the properties of the Console WIndow by hand each time.
I tried this bit of code as the Console was being created - but did not work.
AllocConsole();
m_hConsole = GetStdHandle( STD_OUTPUT_HANDLE );
int handle = _open_osfhandle( (long) m_hConsole, _O_TEXT );
m_fConsole = _fdopen( handle, "w" );
dwSize.X = 120;
dwSize.Y = 50;
SetConsoleScreenBufferSize(m_hConsole, dwSize);
Any sugegstions please
Andy.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
