Latest Contributions by StephenKilburn

If for some reason anyone needs it, the Arcmap 9.3 version is still here: https://www.ferit.ca/patchanalyst/Patch93_Install.htm ... View more

I have encountered this problem in the past, and have just encountered it again using 10.5.1.) I finally decided to give it a good hard look and try to understand it. I believe I can explain what is going on, and I have a kludge to get around it. Cutting to the chase for those who want the kludge: 1. Add the image to the MXD. 2. Add any single arbitrary georeferencing point to the link table. 3. Georeferencing > Update Georeferencing 4. Remove the image from the MXD. 5. Delete the aux.xml file associated with the image. 6. Add the image. (It will pop in at a somewhat different location.) 7. Georeference as usual. (This slightly messes up my workflow, as I normally Build Pyramids and Statistics for all images, and deleting the aux.xml file deletes the statistics, but these can be built later.) OBSERVATIONS AND EXPLANATION: In my current project, I am working in NAD 1983 BC Albers (WKID 102190), which has a linear unit of meters. Choosing one of my problem images and using ImageMagick identify, the TIFF has tags (among others): Geometry=16853x10772+0+0, Resolution=300x300, units=PixelsPerInch, Print size=56.1767x35.9067", Orientation=TopLeft. When I insert a problem image and mouse over the approximate top left and bottom right corners the projected location reads as approximately 0,36 and 56,0 meters. (The image is inserted into the MXD with no projection information. However, when it is inserted it still needs to be mapped to some location in the CRS [i.e, to zoom to the image it cannot be outside the space mapped by the CRS]. The mapping apparently is transforming 300 pixels per inch to 300 pixels per meter, hence 0,36 and 56,0, ballpark original image locations in inches.) If I georeference points close to these corners to known locations, the coordinate pairs in the link table are: 1.351994  34.575973  952183.094839  856847.715658 51.362419  1.250201  1034479.259431  801983.605930 (As it happens, the second pair in each case are absolute, known coordinates that are provided by snapping to a grid.) When I update the georeferencing the TIFF file size increases by around 170KB. Arc is writing something to it. Whatever it is is not seen in the tags ImageMagick reads -- they look exactly the same. However, something in that 170KB makes Arc add the image in a different location, where the approximate corners are 0,0 and 56,-36 meters. Presumably this is the correct location, trusting that Orientation=TopLeft means that 0,0 should be the top left corner and that Arc is ignoring that the mapping should be pixels per inch instead of pixels per meter. If I georeference this with the two corners my coordinate pairs in the link table are: 0.937064  -0.727514  952183.094839  911711.825387 50.812487  -34.239148  1034479.259431  856847.715658 And that works fine. (Of course, I'm simplifying and using only two points when I'd normally use more.) I note that looking at the (incorrect) first aux.xml and (correct) second aux.xml that they have different values for <XOrigin>, <YOrigin>, and <XYScale>. I'd be happy if ESRI would look into this. The details above should be enough for a programmer to determine why images are being added apparently using the wrong corner as the origin. ... View more

I encountered the same problem, slightly different environment (ArcGIS 10.5.1, Visual Studio 2015, Win 7 Ultimate sp1). The solution did not work for me, but manually editing the project files did: Have a look at How to: Troubleshoot Unsuccessful Visual Studio Project Upgrades. I changed all the references to ESRI.ArcGIS elements in the .vbproj file to Version=10.5.0.0. (My project was created under 10.1 but the version was 10.0.0.0 in this file for some reason.) Tangentially, I subsequently encountered a problem compiling that led me to this: Error: The ValidateAddInXMLTask task failed unexpectedly...  The link to the Visual Studio redistributable in that is no longer valid, but I found the file for download here: Visual Studio Shell Redistributable Download. I hope this helps someone. ... View more

In my opinion, this is important if a web map is to be embedding in a site. The current behaviour may make sense for a map-centric site, but if the map is intended to add value to a site, rather than be central, it is not ideal. For instance, I was asked to produce a web map to embed in a site that has information about a planning proposal. The site has text and images on various elements of the proposal. The map locates those elements. What I wanted was for the popups to link to anchors within site sub-pages so that if the popup is clicked through the browser jumps away from the map to the detailed descriptive text. Opening the content in new tabs instead (_blank) is clunky. I hope the workaround posted works, but this seems easy enough to support in HTML that we shouldn't be forced to use a workaround. ... View more

I encountered the same frustrating problem and eventually found a solution. Cutting to the chase, I'll give the solution first, then the explanation: Open Task Manager. End Process for any copy of ArcMap.exe. Open a Windows Explorer. Navigate to C:\Users\\Local Settings\ESRI\Desktop10.. If you don't see AssemblyCache, Organize > Folder and search options > View > uncheck "Hide protected operating system files (recommended)" In the directories in AssemblyCache, look for the one containing your .dll. Delete the .dll. Rebuild the project and debug. Once your add in activates you should see the cache contents get refreshed. If desired, re-hide the protected OS files. The problem for me was that there was an old instance of my DLL in the C:\Users\\Local Settings\ESRI\DesktopX.X\AssemblyCache\ folder, and I also couldn't see \AssemblyCache because I didn't realize it was a hidden OS file. There was also a zombie instance of ArcMap running, and when I tried to delete the DLL initially it was locked. My suspicion is that what caused the problem in the first place is that I didn't quite fully shut down a debugging session of ArcMap before recompiling the code and starting another. The old DLL in the cache couldn't get overwritten because the old ArcMap instance still had it locked, and once it got out of synch with the new code the cached version no longer got updated. (I can see by file dates that the .config, .pdb, and .xml are being updated but not the .dll.) ... View more

I could be wrong but I believe IActiveView.FullExtent is automatically calculated and this will overwrite any custom value you set.  In order to set a custom full extent, I believe you need to set IMap.AreaOfInterest. You're right. I thought maybe I should be looking at an attribute of the Map, but I missed that one (even though I'm actually setting the default extent to an IRasterLayer.AreaOfInterest --should have figured that one out!) Thanks! ... View more