|
The lib should work fine. C++/CLI lets you call code in static and
dynamic libraries without p/invoke.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi Mark,
Thanks for the info, however, here's the problem. The first time I do a build, it always fails with a LNK1000 error where essentially, VC7's link.exe throws some kind of exception. If I try to build it again, it succeeds. Always. The only problem is, that the generated executable is invalid. At first, I couldn't figure out what was wrong. Then, because I suspected some kind of dependency issue, I ran depends.exe on the generated executable, and it told me that the PE header was invalid (or something to that effect). Then, that was where I suspected the managed/unmanaged stuff.
I should also note that I have a solution of 3 projects, 1 of which is the executable (managed), 1 of which is a static library (managed), 1 of which is a static library (unmanaged). If I remove the unmanaged static library from its reference list or dependency chain, building the executable complains about linker errors (as expected, since I have not defined the symbols). As soon as I add the unmanaged static library, I get the LNK1000.
|
|
|
|
|
Cyrilix wrote: 1 of which is a static library (managed)
I'm not sure how well that's going to work, nor can I find any
solid confirmation one way or the other.
Binding of managed types in a library is done at the assembly level.
I'm not sure how well the linker's going to handle that.
A managed class library (DLL) is the appropriate way to make a managed
library (even if it has native code in it as well).
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Well, the way it works is that I have a managed static lib that contains my __gc classes. Then, I have an unmanaged static lib depending on and using the managed static lib that contains regular (non __gc) classes, which is sort of my interface to the native world. I've been able to use this interface with other classes from native code without problem. Then, I have a Winforms app which depends on that native interface. Now that I think of this, it doesn't really make sense as to why I'm doing it this way. I'm sort of going Managed->Unmanaged->Managed... might as well see if I can cut out the middle layer.
|
|
|
|
|
Cyrilix wrote: I'm compiling in Visual Studio 2003
I definitely recommend moving to at least VS 2005 (VC 8) any way you can,
as soon as you can, before investing a lot of time in code that is incompatible
with newer/future C++ compilers.
With VC8+, you get the actual C++/CLI language instead of the Managed Extensions
you are using with VC7, which aren't supported anymore (there's a compiler switch
to allow it...for now).
The Managed Extensions for C++ syntax is deprecated.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
I am pushing for this as well, but I'm not sure if I'll be able to convince them to allocate hours to upgrade our entire system before I finish this small project. Also, I think the Managed C++ in VC8+ definitely also looks much nicer in terms of syntax.
|
|
|
|
|
Hi,
I am porting my vc2003 app to vc2008 and have come across somthing like this...
LPCTSTR lpsz = _T("myString");
SomeObject *obj = Afunc( lpsz );
under vc2003 this compiles and works file however in vc2008 it seems that i need to do...
LPCTSTR lpsz = _T("myString");
SomeObject ^obj = Afunc( gcnew String(lpsz) );
the documentation on string literals in C++/CLI migration primer suggest that the following could be done.
SomeObject ^obj = AFunc( safe_cast<string^>(lpsz) );
this is wrong as it not compile.
I not sure the gcnew string( lpsz ) method is ideal. is there a better way or what is the propper way of doing this.
thanks
Robin
|
|
|
|
|
Robin Imrie wrote: I not sure the gcnew string( lpsz ) method is ideal. is there a better way or what is the propper way of doing this.
in general gcnew is how you create managed objects in C++/CLI so that is always a correct way to do it. Of course strings can be different like in Native C++ based on what you need them for. In your code you are creating a native string and then converting it to a managed string.
If you only need a managed string then you could do this.
System::String^ lpsz = "myString";
There is a series of introductory C++/CLI articles here on CodeProject. I suggest you take advantage of them.
led mike
|
|
|
|
|
Thanks mike for that i had suspected as much.
Will give the C++/CLI articles a good look.
|
|
|
|
|
Hi all,
We installed gtk from the following site
http://crossfire.real-time.com/clients/win32_gtk.html
please help us how to compile and run our own c++ files
Thank You
Sesha Sridhar
|
|
|
|
|
Hi to all,
I have an 'Windows Form Control Library' "VideoWindow.dll" in VC#.Net 2008, having code as following,
<block><br />
using DirectShowLib;
<br />
<br />
public partial class VideoWindow : UserControl<br />
{<br />
public VideoWindow()<br />
{<br />
InitializeComponent();<br />
}<br />
<br />
Label m_picVideoWindow = new Label();<br />
<br />
public int SetPreview(IVideoWindow vwRenderer)<br />
{<br />
int hr = 0;<br />
if (m_picVideoWindow.Bounds.IsEmpty)<br />
return hr;<br />
try<br />
{<br />
hr = vwRenderer.put_WindowStyle(WindowStyle.Child | WindowStyle.ClipChildren | WindowStyle.ClipSiblings);<br />
DsError.ThrowExceptionForHR(hr);<br />
hr = vwRenderer.put_Owner(m_picVideoWindow.Handle);<br />
DsError.ThrowExceptionForHR(hr);<br />
hr = vwRenderer.SetWindowPosition(0, 0, m_picVideoWindow.Width, m_picVideoWindow.Height);<br />
DsError.ThrowExceptionForHR(hr);<br />
hr = vwRenderer.put_Visible(OABool.True);<br />
DsError.ThrowExceptionForHR(hr);<br />
}<br />
catch (Exception ex)<br />
{<br />
}<br />
return hr;<br />
}<br />
}<br />
</block>
When I am calling SetPreview() from my VC++.Net 2008 MFC Application as follows,
<block><br />
IVideoWindow *pWidnow;
CWinFormsControl<VideoWindow::VideoWindow> *a1 = new CWinFormsControl<VideoWindow::VideoWindow>();<br />
<br />
(*a1)->SetPreview(pWidnow);<br />
</block>
It gives compile error as,
error C2664: 'VideoWindow::VideoWindow::SetPreview' : cannot convert parameter 1 from 'IVideoWindow *' to 'DirectShowLib::IVideoWindow ^'
Please help me to solve this error.
Regards,
Aniket A. Salunkhe
|
|
|
|
|
Aniket Salunkhe wrote: Please help me to solve this error.
Well a Native C++ pointer
Aniket Salunkhe wrote: IVideoWindow *pWidnow;
Is not going to be convertible to a managed object.
Aniket Salunkhe wrote: DirectShowLib::IVideoWindow ^
If you don't know that, then you need to do some studying of C++/CLI basics and fundamentals. There is a series of CLI beginner articles here on Code Project.
led mike
|
|
|
|
|
Aniket Salunkhe wrote: When I am calling SetPreview() from my VC++.Net 2008 MFC Application as follows,
IVideoWindow *pWidnow;//C++ DirectShow Library
CWinFormsControl<videowindow::videowindow xmlns:videowindow="#unknown"> *a1 = new CWinFormsControl<videowindow::videowindow>();
Handles to managed objects use ^, not * in C++.
Also you use gcnew, not new, to allocate them on the managed heap.
Aniket Salunkhe wrote: (*a1)->SetPreview(pWidnow);
Huh?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark, FYI, Aniket Salunkhe is trying to call managed code from native C++ according to this quote: "When I (Aniket Salunkhe) am calling SetPreview() from my VC++.Net 2008 MFC Application ...".
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
That was pretty obvious from the error message as well 
I only commented about the syntax/language use.
I suppose I could have mentioned that (s)he'll have to
compile with /CLR.
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: he'll have to
compile with /CLR.
I am already using this flag (/CLR).
|
|
|
|
|
I knew that from the error message.
You're using the wrong syntax for managed objects.
The error message is fairly clear.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
The C++ DirectShow Library's IVideoWindow and C#'s DirectShowLib::IVideoWindow^ are not the same interface (at least externally). SetPreview is looking for C#'s IVideoWindow; thus, you may need to use COM callable wrapper (CCW) of your DirectShowLib::IVideoWindow^.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
modified on Wednesday, October 1, 2008 2:05 PM
|
|
|
|
|
George L. Jackson wrote: you may need to use COM callable wrapper (CCW) of your DirectShowLib::IVideoWindow^.
What is that?
|
|
|
|
|
I have a question regarding STA/MTA in .net
I need to build a COM object in .net whose threading model is required to be STA only (not Both,..) because it is not safe to be used in MTA apartment.
How to do it?
Thank you very much!
|
|
|
|
|
I have some code which use Debug::Print() to output some debug strings. I notice it also prints in the release build version. IIRC, this is not the case in C#.
Folks, any explanation for this anormaly?
Thank you very much!
Edited: I am using Visual Studio 2005. Looks like I got to use a #ifdef guard to prevent the Debug::Print from printing in the release build.
modified on Sunday, September 28, 2008 9:57 PM
|
|
|
|
|
Just for the record, the MSDN Library says (http://msdn.microsoft.com/en-us/library/system.diagnostics.debug.aspx[^]):
"ConditionalAttribute is not supported by the C++ compiler. To provide equivalent functionality, you must enclose calls to the methods of Debug in an #if defined(DEBUG) ... #endif block, and add the /DDEBUG option to the compiler command line or add #define DEBUG to the file."
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
Hi,
I have one JNI shared libray which depends on a CPP library.
In my module loading CPP shared library first and loading JNI library, eventhough the dependant library is loaded JNI library tries to load CPP shared library.
Please let me know how to avoid loading an already loaded shared library ....
Thanks,
Yashu
|
|
|
|
|
Yashusid wrote: I have one JNI shared libray
As in Java Native Interface? If so this is not even close to being the correct forum. If not then what is it? Supply a link.
In terms of loading modules into Windows Processes put all the modules in a single location. The loader will see that it is already loaded and not load it again.
link[^]
Note Use extreme care when using this value. If LoadLibrary or LoadLibraryEx is called for the same DLL after the DLL is loaded, then the DLL references will not have been resolved. This is because the second call to LoadLibrary or LoadLibraryEx simply returns a handle to the already loaded DLL. In this case, the process is likely to terminate abnormally.
led mike
|
|
|
|
|
I have some code that fails when I do this:
Char mgData[] = new Char[numBytes];
Marshal::Copy(data, mgData, 0, numBytes);
...but does not fail when I do this:
Byte mgData[] = new Byte[numBytes];
Marshal::Copy(data, mgData, 0, numBytes);
data is of type char*, and contains binary data in the form of individual bytes (not represented as text at all). numBytes is the length of char*, when it was created with...
char* data = new char[numBytes]
The specific error that I'm getting is in Marshal::Copy, and the debugger points me to memcpy.asm. This leads me to believe that it's something unconventional, or that I'm simply not handling my unmanaged to managed conversions properly. There's a bit of background though... the reason why I'm trying to convert from unmanaged char* to managed Byte[] is because a BinaryWriter object won't properly write binary data when it's in the form of char*. If I were to call...
BinaryWriter.Write(char*), it would simply write until it thinks that it's at the end of a text string (likely a null-terminated character, or something along those lines). Furthermore, I'm not sure if using the Byte instead of the Char is incorrect, since Byte is an unsigned type, and Char (I think) is signed, which matches char* (also signed).
Any suggestions?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
