IContentsView3 behavior in Windows 7 (success in 32 bit vs failure in 32/64 bit OS)

479
0
04-08-2014 10:08 AM
MichaelHatmaker
New Contributor
IContentsView3 behavior in Windows 7 (success in 32 bit vs failure in 32/64 bit OS environment)

I have upgraded a very dated set of ArcMap extensions and toolbars from ArcGIS 9.3 to 10.x.  Many of the components for this system synching gps-embedded video with map tracking were developed in Delphi.  Since a number of other COM dll???s are also involved in related ArcMap extensions, some developed on very old versions of Delphi, the decision was made to make the upgrades to 10.x using Delphi 7, in a 32 bit Windows 7 environment.  This means that everything comes from ???Program Files???, rather than ???Program Files (x86)??? and system libraries are in ???System32??? rather than in ???sysWoW64???.

One of the components is an Image Browser thumbnail viewer that was a tab in the 9.3 TOC.  In 10.x, the IContentsView2 and IContentsView3 interfaces had to be added to enable it to display an icon in the TOC banner, along with the usual layer display options.  TheDelphi custom TOC addition implements the three methods required by the interfaces.

Everything works perfectly in the 32 bit Windows 7 environment.  The custom tool has its .ecfg entry included in the CATID folder.  The icon is loaded from a resource compiled with the dll and displays magnificently in the TOC banner as shown in the attached png, and the contents and sorter tools, etc. work:

[ATTACH=CONFIG]32929[/ATTACH]

At startup on a Windows 7 32/64 bit system, ArcMap 10.1 (SP1) and 10.2 fails to start.  If I replace the custom TOC item dll with the version that worked with 9.3, ArcMap starts, but displays a blank icon where the custom tool icon should be.  Hovering over the blank icon displays the tool???s name.  Clicking on it provides the full functionality of the thumbnail list displayed above, including sorting and filtering.

I have developed two python programs to facilitate identifying missing or mismatched dll???s on the various systems where we are testing the application.  The first reads the registry entry for about 60 dll???s, and logs the file path that was read from the directory InProcServer32 key for the dll.  The second searches all the installation folders and windows system folders for presence or absence of a list of the many files that we see in Dependency Walker for many of the dll???s involved.

The results of this Dependency Walker exercise and python processing is that only one noticeable difference is left.  Displaying the lists of items found or missing in the various directories shows something odd for gpsvc.dll.

Windows 7 32 bit system:

gpsvc    CLSID : Classes\CLSID\{ADAB9B51-4CDD-4af0-892C-AB7FA7B3293F}
   C:\Windows\System32\gpsvc.dll
      last mod : Sat Nov 20 14:29:07 2010

Windows 7 32/64 bit system:

gpsvc    CLSID : Classes\CLSID\{ADAB9B51-4CDD-4af0-892C-AB7FA7B3293F}
   C:\Windows\System32\gpsvc.dll
      last mod : Fri Sep 20 12:25:33 2013

You would expect it to be in sysWOW64, as demonstrated by the results for msxml4:

msxml4 MSXML 4     CLSID : Classes\CLSID\{00B7E0AB-817A-44AD-A04B-D1148D524136}
   C:\Windows\SysWow64\msxml4.dll
      last mod : Tue Jul 21 01:05:40 2009

gpsvc.dll exists in both the System32 and sysWoW64 folders, but the sysWoW64 location does not have any references in the registry.  Attempting to register the copy in sysWoW64 with regsvr32.exe in that folder complains that the entry point was missing.

The gpsvc.dll oddity might not have anything to do with the successful behavior on the 32 bit system and the failure on the 32/64 bit system.  After all, why would adding the IContentsView2 and IContentsView3 interfaces have anything to do with ???Group Policies???, as indicated by gpsvc.dll?  I included it in this discussion to provide context to the extent of the investigation we have conducted.

Several old Borland dll???s are among the static and run-time dependencies for this and other tools.  However, in addition to the TOC tool using the Borland libraries, a couple of command bars, with many commands, all executed in all environments tested.  And, as mentioned above, the Image Browser tool with an eight year old dll that worked in ArcMap 9.3 works perfectly, except for the blank icon on the TOC banner in 10.x.

I would appreciate any thoughts on what is allowing this tool to run perfectly in a 10.x installation on a 32 bit Windows 7 system, implementing the three IContentsView interfaces, while it fails to even start on a 32/64 bit Windows 7 system, unless I use a dll where IContentsView2 and IContentsView3 are not implemented.

In case it might help in your analysis, here are the Delphi implementations of the IContentsView2 and IContentsView3 interface methods:
        
function TRhImageBrowserInterface.BasicActivate(parentHWnd: OLE_HANDLE; const Document: IDocument): HResult; stdcall;
begin
  result := S_OK;
end;

function TRhImageBrowserInterface.Get_Bitmap(out Bitmap: OLE_HANDLE): HResult; stdcall;
begin
  try
    if not assigned(bmp1) then
    begin
      bmp1 := TBitmap.Create;
      bmp1.LoadFromResourceName(HInstance, 'SHOWIMGBROWSE');
    end;
    //Need to turn off range checking to pass the handle value greater than max Integer value
    {$R-}
    Bitmap := bmp1.Handle;
    {$R+}
    Result := S_OK;
  except
    on E:Exception do
    begin
      raise Exception.Create('TShowImageBrowser.Get_Bitmap error: ' + E.Message);
    end;
  end;
end;

function TRhImageBrowserInterface.Get_Tooltip(out Tooltip: WideString): HResult; stdcall;
begin
  Tooltip := 'PixPoint Image Browser';
  result := S_OK;
end;

I am not a Delphi programmer, and I understand that support for Delphi should not be expected.  However, I hope I have provided enough detail that you might see something obvious that I have missed.

Thank you.
0 Kudos
0 Replies