Hi,

I've used MapWinGIS.ocx in known and fixed Delphi example. It works for me apart from some warning in MapWinGis_tlb.pas:

{ Conversion log:
Warning: 'Label' is a reserved word. Label changed to Label_
Warning: 'Object' is a reserved word. Parameter 'Object' in _DMap.AddLayer changed to 'Object_'
....

It doesn't matter but I see that the main control of MapWinGIS.ocx

Class_Map: TGUID = '{54F4C2F7-ED40-43B7-9D6F-E45965DF7F95}';

has the following definition:

{ Dispatch interface for Map Control }

_DMap = dispinterface
['{1D077739-E866-46A0-B256-8AECC04F2312}']
property BackColor: TColor dispid 1;
property ZoomPercent: Double dispid 2;
property CursorMode: tkCursorMode dispid 3;
property MapCursor: tkCursor dispid 4;
property UDCursorHandle: Integer dispid 5;
property SendMouseDown: WordBool dispid 6;
property SendMouseUp: WordBool dispid 7;
property SendMouseMove: WordBool dispid 8;
.....

It is like _DMapEvents. Compare it with event interface, please:

{ Event interface for Map Control }

_DMapEvents = dispinterface
['{ABEA1545-08AB-4D5C-A594-D3017211EA95}']
procedure MouseDown(Button, Shift: Smallint; x, y: Integer); dispid 1;
procedure MouseUp(Button, Shift: Smallint; x, y: Integer); dispid 2;
procedure MouseMove(Button, Shift: Smallint; x, y: Integer); dispid 3;
procedure FileDropped(const Filename: WideString); dispid 4;
procedure SelectBoxFinal(left, right, bottom, top: Integer); dispid 5;
procedure SelectBoxDrag(left, right, bottom, top: Integer); dispid 6;
procedure ExtentsChanged; dispid 7;
procedure MapState(LayerHandle: Integer); dispid 8;
procedure OnDrawBackBuffer(BackBuffer: Integer); dispid 9;
procedure DblClick; dispid -601;
end;

I know that implementation of DISPINTERFACE can be the VERY HARD work for C++ (without ATL) and other languages with support of COM automation.
So the many of users of other languages haven't chance to apply the power of MapWindow Gis tool!
To avoid this it will be better to have _DMap with dual interface, as IShapefile has, for example:

{ IShapefile Interface }

IShapefile = interface(IDispatch)
['{5DC72405-C39C-4755-8CFC-9876A89225BC}']
function Get_NumShapes: Integer; safecall;
function Get_NumFields: Integer; safecall;

and

{ DispInterface declaration for Dual Interface IShapefile }

IShapefileDisp = dispinterface
['{5DC72405-C39C-4755-8CFC-9876A89225BC}']
property NumShapes: Integer readonly dispid 1;
property NumFields: Integer readonly dispid 2;
property Extents: IExtents readonly dispid 3;

As you can see this work is to add some implementation into source of MapWinGIS.ocx.

Is there chance to have soon (in near future) the more completed and perfect design of the great MapWinGIS.ocx?

Is there chance to have source of MapWinGIS.ocx to redisign it?

Thank you in advance,
Valery

BTW. You can use the Delphi demo fixed by me. It is in attachment of this message.

Valery,

thanks for pointing this out. Generally the control is used in .NET environment (MapWindow 4) so interaction with other environments sometimes not duly considered.
Some time ago I tried to import Map interface to MFC project myself to test whether it is working. The _DMap members listed as properties in the MapWinGIS.odl file were missing. All the methods were accessible all right. So it appears in MFC some kind of problem exists indeed.

>>>Is there chance to have soon (in near future) the more completed and perfect design of the great MapWinGIS.ocx? >>>

Without some kind of external help and advice from people who use those languages, it's quite unlikely. We mostly use .NET, so it's not a pressing issue and there is certain lack of expertise to do it. But I strongly encourage you to take lead in the issue and elaborate what is needed to be done. But bear in mind that MapWinGIS should be backward compatible, so we can't just change the interface.

>>>Is there chance to have source of MapWinGIS.ocx to redisign it? >>>

Certainly. The latest source is here: [mapwingis.codeplex.com]

BTW, I got an exception while running your demo: EOleSysError: Unspecified error.

Thanks,
Sergei

Sergei,

Thank you for quick answer.

>>>we can't just change the interface.
The dual interface (more common type) in this case purpotes just the same definition for any interfaces of your ActiveX including _DMap. Exception is the _DMapEvents dispinterface.

Example of this definition can be IVector Interface:

{ IVector Interface }

IVector = interface(IDispatch)
['{C60625AB-AD4C-405E-8CA2-62E36E4B3F73}']
function Get_i: Double; safecall;
procedure Set_i(Value: Double); safecall;
function Get_j: Double; safecall;
procedure Set_j(Value: Double); safecall;
function Get_k: Double; safecall;
procedure Set_k(Value: Double); safecall;
procedure Normalize; safecall;
function Dot(const V: IVector): Double; safecall;
function CrossProduct(const V: IVector): IVector; safecall;
function Get_LastErrorCode: Integer; safecall;
function Get_ErrorMsg(ErrorCode: Integer): WideString; safecall;
function Get_GlobalCallback: ICallback; safecall;
procedure Set_GlobalCallback(const Value: ICallback); safecall;
function Get_Key: WideString; safecall;
procedure Set_Key(const Value: WideString); safecall;
property i: Double read Get_i write Set_i;
property j: Double read Get_j write Set_j;
property k: Double read Get_k write Set_k;
property LastErrorCode: Integer read Get_LastErrorCode;
property ErrorMsg[ErrorCode: Integer]: WideString read Get_ErrorMsg;
property GlobalCallback: ICallback read Get_GlobalCallback write Set_GlobalCallback;
property Key: WideString read Get_Key write Set_Key;
end;

{ DispInterface declaration for Dual Interface IVector }

IVectorDisp = dispinterface
['{C60625AB-AD4C-405E-8CA2-62E36E4B3F73}']
property i: Double dispid 1;
property j: Double dispid 2;
property k: Double dispid 3;
procedure Normalize; dispid 4;
function Dot(const V: IVector): Double; dispid 5;
function CrossProduct(const V: IVector): IVector; dispid 6;
property LastErrorCode: Integer readonly dispid 7;
property ErrorMsg[ErrorCode: Integer]: WideString readonly dispid 8;
property GlobalCallback: ICallback dispid 9;
property Key: WideString dispid 10;
end;

So, the update could be the new additional definition of dual _DMap. It has sense to rename this interface, too.

_DMap -> IMap

From Delphi help:
================================
Advantages of using dual interfaces

Dual interfaces offer the combined advantages of vtable interfaces and dispatch interfaces. These advantages are:

Dual interfaces allow clients written in compiled languages, that know the names of automation object members, to perform vtable binding, compiling directly against the function pointers in the vtable.
Dual interfaces provide the high-speed advantages of custom interfaces by calling directly through the vtable for in-process dual objects. Therefore you can still get the efficiency of a custom interface when accessing in-process objects.
Dual interfaces have the advantage of early binding that gives you compile-time type checking.

Dual interfaces allow automation controllers that cannot obtain type information, and that can call only IDispatch members, to access your object.
Dual interfaces have the added benefit that OLE Automation provides, which is auto-marshaling for both IDispatch and custom portions of the interface. When you have an out-of-process object, you benefit from auto-marshaling. The system provides a universal proxy/stub implementation that can marshal the interface based on the information contained in a type library.

Restrictions when using dual interfaces

For an interface to be a dual interface it must derive from IDispatch and it must use OLE Automation compatible types. These type restrictions are required for OLE's auto-marshaling support to work properly. This means that:

A dual interface has the restrictions imposed by automation compatibility: no data structures (other than implementing another property object), no unsigned arguments, having to use wide strings, and so on.
All members of a dual interface must pass an HRESULT as the function's return value.
Members of a dual interface that need to return other values should specify the last parameter as var or out, indicating an output parameter that returns the value of the function.
================================

This optional definition will only improve your ActiveX.

BTW. This is full list of warns from Delphi:

{ Conversion log:
Warning: 'Object' is a reserved word. Parameter 'Object' in _DMap.AddLayer changed to 'Object_'
Warning: IGridHeader.Owner return parameter: Too many indirections, type changed to Pointer.. [ ^SYSINT ]
Warning: 'Type' is a reserved word. IField.Type changed to Type_
Warning: 'Type' is a reserved word. Parameter 'Type' in IUtils.TinToShapefile changed to 'Type_'
Warning: IGridHeader.Owner return parameter of type Pointer was written as OleVariant
Warning: IGridHeader.Owner return parameter of type Pointer was written as OleVariant
Warning: IGridHeader.Owner return parameter of type Pointer was written as OleVariant
Warning: IShapefile.QuickPoints return parameter of type TSafeArray(Double) was written as OleVariant
Warning: IShapefile.QuickPoints return parameter of type TSafeArray(Double) was written as OleVariant
Warning: ITin.CreateTinFromPoints parameter Points of type TSafeArray(IPoint) was written as OleVariant.
Warning: ITin.CreateTinFromPoints parameter Points of type TSafeArray(IPoint) was written as OleVariant.
}

Maybe this warning will be useful for future fixing.

>>>BTW, I got an exception while running your demo: EOleSysError: Unspecified error.

The source of fixed Demo project (Delphi 3) is attached here.

>>>Certainly. The latest source is here: [mapwingis.codeplex.com]
I have problem with download from this page.

Sincerely,
Valery

Valery,

ok, I see the advantages of it. I'm also interested to define such interface because we have obsolete members in _DMap, then I can simply not include them in IMap.

Let's think how to do it. It's quite possible:
- to define IMap dual interface in odl file;
- to add a property to _DMap interface to get the new IMap interface (it's very clumsy of course);
- to create CMap CoClass which will hold pointer to the CMapView class, where I redirect the calls to the underlying methods and properties (with returning HRESULT, using OLE compatible types, excluding obsolete members, etc).

Is there a better way when CMapView is actually a CoClass for IMap?

Here is how CoClass for dual interface is defined (CShapefile inherit from the 3 classes listed):

class ATL_NO_VTABLE CShapefile :
public CComObjectRootEx<CComSingleThreadModel>,
public CComCoClass<CShapefile, &CLSID_Shapefile>,
public IDispatchImpl<IShapefile, &IID_IShapefile, &LIBID_MapWinGIS, /*wMajor =*/ 4, /*wMinor =*/ 7>
{
...
}

Here is the definition of CMapView class, underlying _DMap interface:

class CMapView : public COleControl
{
...

// with a dispatch map somewhere
BEGIN_DISPATCH_MAP(CMapView, COleControl)
...

}

If I change the definition of CMapView class to show that it's actually a CoClass for IMap dual interface, do you think it will work?

<<<I have problem with download from this page.
Try to update your browser. I got some issues with access to the site with old browser as well. Also I can e-mail you the source: lsu [at] mail [dot] by

Thanks,
Sergei

Sergei,

>>>Is there a better way when CMapView is actually a CoClass for IMap?
Absolutely! This is a true choice. And you can add that _DMapEvents for IMap to handle it's events.

>>>If I change the definition of CMapView class to show that it's actually a CoClass for IMap dual interface, do you think it will work?
I'm not Lord, though... But this is worthy.
:-)

Sincerely,
Valery

Valery,

ok. I'm not that sure though that it will work, but I'll try it when there is time (probably during the week). It'll be quite enough to test an interface with a single function I expect.

Thanks,
Sergei

Valery,

Some new info. Control actually can expose several interfaces:

[ uuid(54F4C2F7-ED40-43B7-9D6F-E45965DF7F95), helpstring("Map Control"), control ]
coclass Map
{
[default]dispinterface _DMap;
[default, source] dispinterface _DMapEvents;
interface IMap; // was added
};

But one of them should be default. This interface can be accessed directly from the client code. For other interfaces casting should be made:
IMap map = axMap1.get_Ocx() as IMap;

IDispatch interface can't be a default one, as it breaks existing code (unless all the definitions will be exactly the same, which is nearly impossible considering that various client environments are involved). More likely that member definitions for IDispatch will be different from _DMap (HRESULT has to be returned, different syntax for properties). Which gives us 2 sets of names and lots of confusion for the users. So it's not an approach to hide obsolete properties I was thinking of (I'd rather expose second dispinterface).

I haven't found any examples of implementation of IDispatch and dispinterface in a single control class. Maybe it's possible but definitely it's not a common practice. Also there is a good chance to introduce bugs while implementing this, considering the size of CMapView class.

Probably better solution is to expose second control, for example Map2 based upon IDispatch interface. CoClass for this interfaces can be inherited from CMapView.

In general, considering my lack of time, there is little chance that I'll implement it in near future. But I'd recommend to take initiative in your own hands ;)

Regards,
Sergei

Hi, Sergei!

Sorry for late answer. I was in other place without internet there.

>>>Probably better solution is to expose second control, for example Map2 based upon IDispatch interface. CoClass for this interfaces can be inherited from CMapView.

I've already written special dll with new MyMap Class implementation. It is wrapping _DMap and _DMapEvents interfaces into two new default interfaces
IMyMap (IDispatch) and DMyMap (dispinterface for Events). It works fine with my AutoIt scripts, so thank you for your thinking about other forms of MapWindowGis API.

Sincerely,
Valery