|
hi.
i create a new windows forms application project in visual c++.net2005 and add necessary lib and header files.
and in Form1.h ,add this code:
#pragma once
#include "mclmcr.h"
#include "foo2lib.h"
and i do no change in code.
when i compile this solution .it give me 12 errors.and all of them are "redefinition; different type modifiers":
for example :
Error 1 error C2373: 'matGetDir_proxy' : redefinition; different type modifiers E:\Program Files\MATLAB\R2008a\extern\include\mclmcrrt.h 143
.
.
.
but when i create a new win32 console application project and do same workes,compiler give me no error
and solution is run.
please help me to remove these errors.
|
|
|
|
|
I have a structure in C# which is read using a BinaryReader like so:
binaryReader.ReadInt32();
binaryReader.ReadInt32();
binaryReader.ReadString();
binaryReader.ReadString();
I need to be able to send this structure from a C++ app, I have managed to send across the two ints and I realise that the strings have a length marker in front of them but I cannot get it to send the string.
I am currently using a struct like this:
struct MyData
{
int val1;
int val2;
int strLength1;
LPCTSTR string1;
int strLength2;
LPCTSTR string2;
};
This send the ints fine but I get 2 0 length strings.
What am I doing wrong?
|
|
|
|
|
One way that works AFAIK is using fixed-length strings, put them in length+chararray on the C/C++ side
and in length+array on the managed side, using some Marshal attribute to indicate that the
array data has to be there, not just a reference.
It is something like [MarshalAs(UnmanagedType.ByValArray, SizeConst=16)]
BTW: as always, be wary of different character types.
|
|
|
|
|
At a guess I'd day you need two shorts for your string lengths or possibly even two BYTEs. If C# strings are a development of BSTRs then I doubt the string lengths will be as much as the 4 bytes you get with an int. 4GB long strings are really not what MS want to be supporting I guess. The other thing is you need the character data itself effectively in the structure rather than pointers to the characters (LPCTSTR).
You want something like this.
<br />
struct MyData<br />
{<br />
int val1;<br />
int val2;<br />
unsigned short strLength1;<br />
TCHAR string1[strLength1];<br />
unsigned short strLength2;<br />
TCHAR string2[strLength2];<br />
};<br />
but of course you can't do that directly as strLength1 and strLength2 are not known at compile time. This means you're likely going to have to use some form of serialization/deserilaization rather then just passing a structure unless you can use fixed length strings.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Thanks, I thought I would end up doing some serialization. I have checked the BinaryWriter documentation and it states
This method first writes the length of the string as a four-byte unsigned integer, and then writes that many characters to the stream. This method writes a length-prefixed string to this stream using the BinaryWriter instance's current Encoding.
So it seems it does need a 4-bytes uint to prefix the length. So my next question is how would I create a byte array containing the strings and the lengths? (C++ is not my strong point!), I know how to create the array using malloc and copy the strings in but not the ints.
|
|
|
|
|
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)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
