|
This is a multifaceted problem. Firstly, what is happening is that when you load a C++ DLL into a C# project/environment (such as .Net), it will attempt to convert all existing datatypes inside the DLL into CLR-compliant (.Net Framework compliant) types. The SBYTE structure represents a non-CLR-compliant 8-bit signed integer.
The reason, most obviously, for this is that your C++ DLL is created as ANSI-compilant, in which a char represents a signed 8-bit integer. However, in the C# environment, a char stands for an Unicode character.
Now, the solving might be attempted through the importing settings of the IDE. There should be, somewhere, an option to specify how non-CLR types are imported. I have never done this myself, so I am uncertain of where the actual option might be. Naturally, if you could specify HOW you are actually using the DLL (Importing it through a directive, linking with it, or by some other means), it might provide helpful.
Additionally, as char* types represent strings, and the concept of strings is wrapped into the 'String' type in C#, a viable approach into this problem would be to create a cross-platform DLL.
Did you know that you can use the Managed Extensions of C++ to write C++ code that takes advantage of the .Net framework ? In this approach, you can specify all special types, such as 'String' types, into your code, and they should be correctly imported by the C# project. The most magnificient thing is that if you use MC++ (Managed Extensions for C++), you can write code that runs on both a CLR-system (OS with .Net support) or a non-CLR one (Windows 95/98/old NT's). Special care should be taken, however, when developing this type of a solution.
One alternative would be to write your DLL as Unicode-compilant, in which you'd be required to change all your char types to TCHAR constants, that are mapped by the compiler based on what character set you've selected (This option is found under Project Settings). Additionally, you'd need to use the wide versions of all character manipulation routines. Consult MSDN with the keyword 'TCHAR' for further information about character mappings.
Lastly, you could try a different approach altogether: create your own class that encapsulates a string. Then pass these classes around when you need string variables. This is like re-inventing the wheel, but at least you don't need to use the MC++, if you feel uncomfortable with it.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
I'm a newbie.
Could someone give me a code Sample How to place a CFormView inside a CTabCtrl? 
|
|
|
|
|
look in this if anything could satisfy you... sorry but personnaly, i don't know.
TOXCCT >>> GEII power
|
|
|
|
|
Hi,
I work with the Visual Studio .net 2003,
and I write an application with Windows.Forms.
Now, I search a C++ solution which placed an image at the menuItem (left).
(This solution shouldn't use the MFC).
Can anybody help me?
Thanks
blue-marie
|
|
|
|
|
there are many good articles on CP not to ask this...
TOXCCT >>> GEII power
|
|
|
|
|
Have you got some links to this articles?
I have such found articles about C#, but I search a solution for C++.
thanks
blue-marie
|
|
|
|
|
|
I do not have a solution, but I do have a suggestion. If you can not find an example of drawing custom menus in MSDN, a book or on the www, then you could look at one of the projects at CP or elsewhere that use MFC and work you way backwords. That is examine what messages (see "Menu Messages" in MSDN) you need to handle and how they are being handled.
Good Luck!
INTP
|
|
|
|
|
I am trying to access the msaccess file throught odbc dsn
seemslike the password and user name set in dsn option is not
working is there something i have to do inorder to enable this
security?
Shinya
|
|
|
|
|
Maybe yout DSN connection is not properly configured. Try this. If it does not work, send me the full specs of you database (name,location,username and password)and i will build a small application to sort this out for you.
Cheers
Krugger
Plan tomorrow todays cos' tomorrow will be too late...
|
|
|
|
|
Hi,
Until today I used timers on dialog based applications and the app wizard did all the work of setting up the message map etc.
If I have a regular c++ class, how do I use timers on it ?
Any short example will be helpful.
Thanks,
Shay
|
|
|
|
|
on MFC, you can use CWnd::SetTimer() if your delays aren't bigger than 55ms
TOXCCT >>> GEII power
|
|
|
|
|
SetTimer() is used, with or without MFC.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
If your 'regular C++ class' represents a Window then you can use ::SetTimer and handle the message. If it doesn't then you could look at ::CreateTimerQueueTimer , which requires W2000 or later but which will regularly call a function for you.
class HasATimerCallback
{
private :
HANDLE hTimer_ ;
static void CALLBACK TimerFunc ( void * param, BOOLEAN bTimer )
{
if ( param )
{
reinterpret_cast < HasATimerCallback*>( param )->DoTimerFunc () ;
}
}
void DoTimerFunc ()
{
}
public :
HasATimerCallback ()
{
::CreateTimerQueueTimer ( &hTimer_,
0,
TimerFunc,
this,
60000,
60000,
WT_EXECUTEINTIMERTHREAD
} ;
}
~HasATimerCallback ()
{
::DeleteTimerQueueTimer ( 0, hTimer_, INVALID_HANDLE_VALUE ) ;
}
} ;
I haven't compiled this, just cut'n'paste from some code I had lying around.
Paul
|
|
|
|
|
Got the idea, but....
When I try to copile it I get:
error C2039: 'CreateTimerQueueTimer' : is not a member of '`global namespace''
Any idea why ?
shay
|
|
|
|
|
The documentation for CreateTimerQueueTimer here[^] suggests that you have to define _WIN32_WINNT=0x0500 or greater. I usually do this in the project settings, where it may already be set to a lower level. The thread pool functions are only available on W2000 and later, which is slightly constraining but makes for a very quick example.
The documentation also says that the function will be called every 'interval' whether or not the previous call has returned. IOW your timer call back must be 're-entrant'. The Thread Pool functions make life easier but they don't save you from synchronisation issues.
Paul
|
|
|
|
|
I have a problem concerning the preprocessor.
How is it possible to use a #if within a macro?
I give u an example:
#define MACRO( x, y ) \
x *= y; \
#if y == 3 \
x /= 2; \
#endif
void main()
{
int iTemp = 10;
MACRO( iTemp , 1 );
MACRO( iTemp , 2 );
MACRO( iTemp , 3 );
MACRO( iTemp , 4 );
}
Is there a way to do that?
Thx
Don't try it, just do it! 
|
|
|
|
|
well, is there a problem with that code ?
it seems to be right, even if i really dislike that way of coding (i prefer inline functions to macros...)
TOXCCT >>> GEII power
|
|
|
|
|
i can't use inline functions here because the code in the macro is not c code... it is SSE assembler code 
Don't try it, just do it!
|
|
|
|
|
Why not use this instead?
#define MACRO(x,y) { x *= y; if (y == 3) x /= 2; }
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
here, the "if" test will be performed every time the macro is called, where in the other case, it will be defined only if the y is set to 3.
(you're probably right, in your code, david, but i continue thinking that i prefer inline functions than macros).
TOXCCT >>> GEII power
|
|
|
|
|
The compiler will see if ( 3 == 3 ) or if ( 2 == 3 ) etc and shouldn't actually generate any code for the 'if' statement. Possibly worth trying and checking the generated code to see.
Paul
|
|
|
|
|
thx guys, i will check this.
Don't try it, just do it!
|
|
|
|
|
Paul Ranson wrote:
and shouldn't actually generate any code for the 'if' statement
There is generated code. It looks like:
int iTemp = 10;
{ iTemp *= 1; if (1 == 3) iTemp /= 2; };
{ iTemp *= 2; if (2 == 3) iTemp /= 2; };
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I meant that the compiler wouldn't generate any code for tests that only have one outcome.
This code,
#define MACRO(x,y) { x *= y; if (y == 3) x /= 2; }
int main()
{
int iTemp = 10;
MACRO( iTemp , 1 );
MACRO( iTemp , 2 );
MACRO( iTemp , 3 );
MACRO( iTemp , 4 );
std::cout << "Ends up with " << iTemp << std::endl ;
return 0;
}
in an optimised build turns into
push 120
call ostream etc
IOW the compiler has taken all the fun out of it.
This function
int UseMacro ( int i )
{
MACRO( i , 1 );
MACRO( i , 2 );
MACRO( i , 3 );
MACRO( i , 4 );
return i ;
}
compiles to
?UseMacro@@YAHH@Z PROC NEAR ; UseMacro, COMDAT
; 10 : MACRO( i , 1 );
; 11 : MACRO( i , 2 );
; 12 : MACRO( i , 3 );
mov eax, DWORD PTR _i$[esp-4]
lea eax, DWORD PTR [eax+eax*2]
shl eax, 1
cdq
sub eax, edx
sar eax, 1
; 13 : MACRO( i , 4 );
shl eax, 2
; 14 :
; 15 : return i ;
; 16 : }
ret 0
?UseMacro@@YAHH@Z ENDP ; UseMacro
So I don't think we have to worry about optimising the Macro.
Interesting stuff to look at though, this is VC++ 7.1 and it seems pretty clever to me.
Paul
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
