CreateSurfaceFromFile() version not working

[Narin]

First of all, GapiDraw is going to save my life.

Now, I just need to get it up and running with C#. I found the ancient C# wrapper on intuitex.com which is a good starting point, now I'm tweaking it.

I've hit a roadblock though. When building off the Minimal sample in C++, I can load a 24-bit PNG just fine using ->CreateSurface and the FULL file name. Works great.

However, when I use C# and P/Invoke CGapiRGBASurface_CreateSurfaceFromFile, passing it the EXACT same filepath produces a GDERR_BITMAPNOTFOUND.

This is on my "stationary PC", and using the win32 build of GapiDraw.dll 401.

Any ideas?

[Johan]

Hm, that was odd. What happens if you don't set any file path and just try with the file name (and place the PNG in the same folder as the exe)?

Also. Are you running your application from the VS2008 environment? That way the current path is different from the .exe file.

Sincerely
Johan

[Narin]

Yeah that doesn't work either. Maybe it has something to do with the "real" C++ method vs. using the CGapiRGBASurface_CreateSurfaceFromFile "helper" function?

At any rate, I got it working by loading it myself in C# into a byte array and passing the pointer to GapiDraw's memory-loading function.

I was thinking about making a Google Code project to host my tweaked "working" version of the C# wrapper library, but I noticed the one mentioned in these forums:

http://code.google.com/p/gapidrawdotnet/

Comes back with "Forbidden". Did that get taken down for some reason?

[Johan]

The other project was discontinued. But I would very much like to help out with making this available!

Can you please send me a PM with your email and we can continue the discussion there!

Cheers
Johan

[InexorableTash]

However, when I use C# and P/Invoke CGapiRGBASurface_CreateSurfaceFromFile, passing it the EXACT same filepath produces a GDERR_BITMAPNOTFOUND.

The first thing I'd check is to make sure the strings are the same type through call. C# will assume UNICODE but the Windows version of the GapiDraw DLL might be expecting ANSI. The P/Invoke declarations should be able to convert the string type on the fly. Contrariwise, DLL might be expecting UNICODE but the P/Invoke declarations are wrong. (Perhaps based an older version of GapiDraw?)

Passing a UNICODE string to something expecting ANSI ends up looking like an empty string (the first byte will probably be 0); passing an ANSI string to something expecting UNICODE will often crash (since it wanders off into memory looking for double null...) but otherwise not be a proper file. :)

(NOTE: I'm using Microsoft's "UNICODE"/"ANSI" terminology for character encodings here, corresponding to WCHAR and char storage types.)

[Narin]

C# will assume UNICODE but the Windows version of the GapiDraw DLL might be expecting ANSI.

That was totally and completely it. Brilliant!

Looks like the "windows version" of GapiDraw is expecting ANSI.

It was a side effect of the way I'm using the C# wrapper - I'm compiling it into its own DLL (a "Compact Framework" DLL) and when I consume the CF DLL from my desktop app, it forces UNICODE.

When the [DllImport] is compiled into my desktop app directly, it auto-selected ANSI.

Definitely a tricky thing to be managing Compact-Framework vs. Full Framework.