|
|
Please post on the Visual C++/MFC board[^].
This board is for Managed C++/CLI questions only.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I have a Managed C++ Windows Forms program that I'm compiling in Visual Studio 2003. When I try to run it, it tells me "Program too big to fit in memory" in a command prompt.
Does anyone know why it would even pop up with a command prompt window when this is a Windows application? Secondly, why would I get this error? Sources from google tell me that usually, this has to do with a corrupt installer issue, but this is not an installer at all.
Thanks.
|
|
|
|
|
I think I might've found the issue. I believe it lies with trying to reference an unmanaged lib (not compiled with managed extensions in C++), from a project that is compiled into a managed executable (managed extensions enabled). From what I've read, it seems to me (so far) that the only way to do this is to use a .dll and PInvoke, but is there any way to simply use a .lib?
|
|
|
|
|
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++
|
|
|
|
|
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++
|
|
|
|
|
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
|
|
|
|