Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MapWinGIS OCX - Image Class

Status
Not open for further replies.

Alec_Gagne

Programmer
Apr 14, 2022
15
US
I'm using the code below to create an instance of the MapWinGIS IMAGE class so that the resulting IMAGE object can be passed into a shape file. The image object is successfully created however, my call to the .Open() method creates an OLE Error Code "Type Mismatch".

Code:
* Create a MapWinGIS image object based on local image file
#DEFINE ImageType_Bitmap_File                   0
#DEFINE ImageType_Use_File_Extension            2
#DEFINE ImageType_JPEG_File                     4

loImg     = CreateObject("MapWinGIS.Image")
loImg.Open("s:\mapwingis\car.jpg", ImageType_Use_File_Extension )

The documentation for the Image.Open() method is here. I've confirmed that the file exists in the specified path and that the file is in fact a jpg file type. I've also tried using a Bitmap image with ImageType_Bitmap_File and ImageType_Use_File_Extension

Also tried passing all 4 parameters (even though only the 1st parameter is required) as follows.

Code:
loImg.Open("s:\mapwingis\car.jpg", ImageType_Use_File_Extension, .F., .NULL. )

Any thoughts on what might be the source of a type mismatch error ?

Alec (Santa Barbara, California)
 
All parameters but the first are optional, by intellisense description. So my guess is that the type mismatch problem already is in the first parameter, in string encoding. VFP is not a Unicode application, so your filename is an ANSI string. I tried using strconv(filename,5) but that still results in a type mismatch.

There are very few things you have in VFP to adjust codepage conversions, there is COMPROP() and SYS(3101).

In some cases, it is advised to use CreateBinary(string) to have a byte array that's independent of any encoding and would come over correctly, but that also doesn't work here. I don't know how to overcome that hurdle.

Chriss
 
Hi Chris,

Thanks for trying.

Hmm... If the string was required to be unicode I suspect the docs might say that. No?? I've done quite a bit with the control so far and other VFP strings have worked fine. Something about this method is different.

I sent a message off to the OCX developers to see if there is a property in the image object that is accessible to just stuff the binary image into. My thought was maybe using the VFP FileToStr() to create a binary string and just set the image property directly. IDK, if that would work but it may be worth a try if the 1st parameter literal string of the .Open() method remains an issue.


Alec (Santa Barbara, California)
 
Well, Unicode, UCS--22, is quite the norm in Windows and usual applications are Unicode. ANSI is not the norm. So conversion is the norm. But iff you look into it closely you see many Windows API functions exist for Ansi or Unicode with W or A suffix in the name. If an Ansi application like built with VFP declares an API function you can usually omit this suffix, it's automatically using the A for Ansi version. So Unicode vs Ansi applications are really a category apart from 32bit vs 64bit.

Auto conversions are the topic of both COMPROP() and SYS(3101), and in rare cases this can still be a hurdle. In VFP strings are not objects and have no property of their encoding. So usually it works to convert within VFP ith STRCONv. The letters usually convert by having the ASCII code plus a 0 byte. And now in C/C++ what gets you is that 0 terminates a string. It's unusual this would lead to type mismatch errors, indeed. I've never seen this before. But I do get the type mismatch error also when just using the first parameter. So how could it be anything else but this file name parameter?

Chriss
 
But here is something interesting. If I change the code as follows:

Code:
loImg     = CreateObjectEX("MapWinGIS.Image","","")
loImg.Open( 's:\mapwingis\car.jpg', ImageType_JPEG_File)

The .OPEN() method generates a different error. 'Must specify additional parameters'. So I add the remaining optional parameters, as shown below and the line of code does not error!

Code:
loImg     = CreateObjectEX("MapWinGIS.Image","","")
loImg.Open( 's:\mapwingis\car.jpg', ImageType_JPEG_File, .F., .NULL. )

With that modification I did get the picture to display as a Shape on the map so this approach worked for creating the IMAGE object.

Alec
Santa Barbara, California
 
I would never have guessed this works since we found out that creating MapWinGIS.Point objects with CreateObjectEx causes c5 error problems. Good to know. What's unfortunate about it is I don't see a recipe or pattern about when to use CreateObjectEx and when not. I pointed out the difference I find is about the interface used (IDispatch vs. others).

As we recently had the discussion about the inofficial VFFP 10 version VFPA, it may be another reason to try out VFPA, though I don't find anything related to fixes or advances made in ActiveX handling of VFPA vs VFP9.

Chriss
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top