Re: DirectX in /clr

Ok, found the problem. I needed to add the folloing line of code:

presentParams.Windowed = true ;

Now it compiles and runs just fine... : )


"Peter Oliphant" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
> Yup, I was able to disable the warning, thanks!
> Now I have a new roadblock. The following code, located as a public method
> in a Form1 class, produces a RUNTIME error (listed afterwards):
> void InitializeGraphics()
> {
> PresentParameters^ presentParams = gcnew PresentParameters() ;
> presentParams->SwapEffect = SwapEffect::Discard ;
> device = gcnew Device( int(0), DeviceType::Hardware, this,
> CreateFlags::SoftwareVertexProcessing, presentParams ) ;
> }
> "An unhandled exception of type
> 'Microsoft.DirectX.Direct3D.InvalidCallException' occurred in
> Microsoft.DirectX.Direct3D.dll Additional information: Error in the
> application."
> It is the line where the device is created that causes this problem. The
> error message is not exactly helpful, as all it says is 'error in
> application'. So it leaves me with no way to investigate this, since it
> basically says there is something in the DirectX closed dll that went
> wrong when I tried to create a simple device...
> I have been able to create a >>> C# <<< program that runs analogous
> DirectX code, so it has nothing to do with hardware. But I have to do this
> in >>> C++ <<<, which doesn't seem as easy to get working...
> First, is there a way to fix this (since it is so simple it must be some
> project setup problem I'm guessing)? Second, isn't there any available
> example source MS has create in VS C++.NET 2005 in /clr mode (no , NOT C#
> that I can 'easily' translate) that does something simple in DirectX? The
> recent SDK only provides examples in C#, and require 2003 to use...
> [==P==]
> "punkrock" <punkrock@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:B5655DA7-100F-4724-BDC6-D7464AD39177@xxxxxxxxxxxxxxxx
>> This isn't your fault at all. There was an issue with version 1 of the
>> .NET
>> framework where mixed DLLs (those with both managed and unmanaged code)
>> could
>> potentially crash the application due to restrictions inherant in the
>> Windows
>> application loader (if you want the gory details, search for mixed-mode
>> dll,
>> or loader lock on MSDN, there's a very good article that you shouldn't
>> have
>> too much trouble finding).
>> Because the MDX DLLs are essentially just wrappers around DirecX's native
>> interfaces, they are by nature mixed-mode DLLs and suffer from the loader
>> lock issue. While the MDX DLLs have been specially compiled to make sure
>> they
>> don't actually crash the process that's using them, to the CLR they still
>> look like they might.
>> The .NET framework 2.0 has added the Managed Debugging Assistants, one of
>> which now checks for this potential issue, and raises a warning.
>> The reason you're getting the error is that while your application is
>> loading, it forces the CLR to load the MDX DLLs as well, which trips the
>> LoaderLock MDA. If you comment out that line, then the device ends up
>> unused
>> and unreferenced so the compiler optimizes it out, and since nothing from
>> MDX
>> is used the DLLs aren't loaded (thus no error).
>> It is safe to ignore the warning, in this case. If it irritates you, you
>> can
>> turn the LoaderLock MDA off in VS. The options should be under Debug |
>> Exceptions, though I'm typing from memory and I could be off. Search help
>> if
>> you can't find them.
>> MS has implemented a workaround for the LoaderLock issue in the 2.0
>> version
>> of the CLR so it's my understanding that the official .NET 2.0 release of
>> MDX
>> won't suffer from this problem.
>> Regards,
>> Phill