humate Posted September 12, 2003 Posted September 12, 2003 What's the easiest way to get a large number of Win 32 API declarations into a VB.NET project? I've got a VB6 program that uses lots and lots of GDI functions, which was very easy to do, by just referencing Win.tlb. I don't want to wrap it all in GDI+ which will probably make it slower anyway, I just want to be able to use all the functions inside GDI32.DLL from VB.NET. Do I have to declare them all one by one? That'd take years! Quote
Leaders dynamic_sysop Posted September 12, 2003 Leaders Posted September 12, 2003 why not just use the in-built graphics in .net? System.Drawing.Graphics Quote
humate Posted September 12, 2003 Author Posted September 12, 2003 because it would involve completely rewriting the whole project! And because it uses BitBlts and memory DCs, etc, i.e. not just lines and circles. Quote
*Experts* Volte Posted September 12, 2003 *Experts* Posted September 12, 2003 If you really want to port it to .NET, rewriting the whole project will be largely necessary. Otherwise, leaving it in VB6 would be wisest. Also, I suggest you take a closer look at GDI+ - it can do far more natively than GDI32 can. It's far more flexible, and more imporantly, object oriented. :) Quote
humate Posted September 12, 2003 Author Posted September 12, 2003 Given time and money, we would re-write it all, to take advantage of the cool things that GDI+ can do. But at the moment I just want to have it working from a .NET environment and assumed that there'd be a file or something out there that effectively includes declarations for all the Win32 API calls, in whatever wrappers are necessary. For example, if you want to use OpenGL in VB.NET, you can, you just have to reference a special wrapper DLL first. The graphics have to run as fast as possible and redraw themselves at a high frame rate. From some of the other threads in this forum I'm not convinced that GDI+ will be an improvement in that respect. An object orientated approach is clearly 'better', but how does it help if I just want to blast lines and polygons onto the screen in a set order, fast? Probably the program lends itself more to a C++ type thing but it all worked great in VB6 and was very readable and easy to maintain. I don't want to use VB6 for ever, that can't be right... Quote
AndreRyan Posted September 16, 2003 Posted September 16, 2003 Microsoft is trying to get everyone to switch to GDI+. It does have many more features and some features compare to line drawing funtions in Direct3D. You can get a reasonable speed out of GDI+ if you only draw when you have to rather than constant looping, just override PAINT. There is no DLL for wrapping GDI32 the only one avaliable is System.Drawing for GDI+. If you want GDI32 you have to use the declaration statements as these are still applicable. To use OpenGL you have to import the VB6 COM wrapper after running it through the wrapper program, so you end up with OpenGL32.DLL>OpenGL COM Wrapper>.Net Wrapper for the COM Wrapper>.Net program using OpenGL You could get past this with direct declartions though. BitBlt: Declare Function BitBlt Lib "gdi32.dll" (ByVal hDestDC As Int32, ByVal x As Int32, ByVal y As Int32, ByVal nWidth As Int32, ByVal nHeight As Int32, ByVal hSrcDC As Int32, ByVal xSrc As Int32, ByVal ySrc As Int32, ByVal dwRop As Int32) As Int32 Or the better method: <DLLImport("gdi32.dll")>Public Function BitBlt(ByVal hDestDC As Int32, ByVal x As Int32, ByVal y As Int32, ByVal nWidth As Int32, ByVal nHeight As Int32, ByVal hSrcDC As Int32, ByVal xSrc As Int32, ByVal ySrc As Int32, ByVal dwRop As Int32) As Int32 End Function .Net forms no longer are tyed to GDI(at least noticably) so there is no hDC or ForeColor of BackColor properties so you'll need GetDC and ReleaseDC APIs to use GDI32 functions or the Get DC function in Drawing.Graphics GDI+ will get faster, it's slower than GDI32 because of all the new graphics effects that aren't easily achievable in GDI32 Quote .Net allows software to be written for any version of Windows and not break like Unmanaged applications unless using Unmanaged procedures like APIs. If your program uses large amounts of memory but releases it when something else needs it, then what's the problem?
Recommended Posts