arcpy.mapping.MapDocument('CURRENT') error in Debug only

[BillRichards]

When attempting the command from ArcMap in Debug mode:

mxd = arcpy.mapping.MapDocument('CURRENT')
I now receive the error: "Object: CreateObject cannot open map document"

However, when I "run" the script in ArcMap, the error does NOT occur. Why would this be the case? This makes debugging impossible...

Yes, I have "Always Run in foreground" checked (and even disabled all background processing as a test as well).

Any suggestions?

running ArcGis Desptop Advanced 10.2.2 and using PyScripter IDE

Bill D. Richards

North IDaho College

Dept of Geography/Geology

[curtvprice]

What's "debug mode"? The Python window?

A standalone script running in its own process (say, from PyScripter) isn't using ArcMap's arcpy process so it won't be able to see "CURRENT".

[BillRichards]

By "debug" mode I mean: In ArcMap (with the map document open), open the Toolbox window, right-click on the script and select "Debug" rather than "Open" or "Edit". In other words, this is NOT a standalone script to be run outside of ArcMap..... I have this script set to run "in process" not in it's own process......

[DanPatterson_Retired]

The documentation can be found in arcpy.mapping discussion here and in here .

Visually, here is a picture of running the command line within PythonWin and ArcMaps IDLE script editor access.  PythonWin gives an error since it does not know what CURRENT is

Now give it a name for use outside arcmap

[BillRichards]

So, what you are saying is that, even though I am within ArcMap and have activated the "Debug" for the script from with the ArcMap-based toolbox, the debug session is running "outside" of ArcMap. How, then, can ANY debugging occur while in ArcMap if you need to access the current map document unless you hard-code the document each time you debug (and then reset to "CURRENT" for run-time)?

As an update: setting the document argument to the fully qualified filename does allow me to continue my debug session, but causes other issues that I will need to investigate....

[DanPatterson_Retired]

I have PythonWin set as my debug and it was running when I gave that example in the image.  If I was editing a script and then used a tool in arctoolbox which used that script, the script gets reloaded with the changes.  It has to be refreshed.

On a side note, using the IDE within ArcMap means you don't have to load arcpy when you try code snippets.  Try that with your editor IDE...won't work...you have to load it.  I like this scenario because I don't have to worry about conflicts.  I can run Pyscripter, Pythonwin and the Python IDE in ArcMap and the software doesn't get confused (...although sometimes the user does...)

[BillRichards]

As noted previously,

once I hard-code the map document with a fully qualified path and name, the call to "arcpy.mapping.MapDocument(filepath)" succeeds and debugging in Pyscripter can continue. However, calls to change the DefinitionQuery, for example, have no effect (even after a call to RefreshActiveView). It's as if the debug session is sending nothing back to ArcMap (or ArcMap is ignoring it). As per your response, I am aware that code snippets should operate fine from with the "Python window", but I want to debug the entire script, not just bits of it. Is this simply not possible in ArcMap (as in ArcCatalog)?

Also, you make mention of "Python IDE", are you referring to IDLE?

[DanPatterson_Retired]

My workflow if I have to have arcmap open...which is rarely....

• create a simple tool in a simple toolbox (I call this JunkTools)
• I attach any parameters to the tool so that they are associated with my script, for example, you can have your project as one of your parameters, a featurelayer as another etc.
• this now just allows your script to communicate with a project and its components in ArcMap.
• If I have a script error, or I want to edit the script to change its functionality, I will edit the script in PythonWin or PyScripter depending on how I am feeling that day
• I then rerun the script tool from the toolbox
• In the above scenario, you don't have to really modify your script since your script still needs parameters but running the script from a tool allows the association between the script and ArcMap.

It works for me, when I have to 'do something' and have arcmap open.

Another trick I often use (not just with arcmap) is to place the script in the same folder as the 'object' that you want to work with...say an *.mxd.  You can then exploit fact that sys.argv[0] is the running script.  This you may find useful. It is what I use when I have to work with *.mxd's

import sys
import os
import numpy as np
script = sys.argv[0]
path,name = os.path.split(script)
mxd = path + '\\test.mxd'
print('\nScript:... {}\nFolder:... {}\nProject:... {} '.format(name,path,mxd))

[curtvprice · Accepted solution]

> It's as if the debug session is sending nothing back to ArcMap (or ArcMap is ignoring it).

Yes, that's exactly right. The debug opens a new python.exe process in IDE (Interactive Development Environment, i.e. IDLE, PyScripter, etc).

Using arcpy.mapping to alter the current map is a special case, as to alter the current map you need to be in the ArcMap python session. (sys.executable is ArcMap.exe).

The IDE is in its own python.exe shell apart from ArcMap, even running "in-process" it's a sub process, it can't "reach back" to the objects loaded  in ArcMap's "CURRENT" document.

The easiest way to test python code that uses arcpy.mapping to alter the ArcMap current session is to load it or paste it into the ArcMap Python window.

[BillRichards]

Thanks for EXPLICITLY clearing that up

My experience has been significantly concentrated on standalone geoprocessing (as well as high-performance computing - HPC - from the "old" days). I am creating some exercises for students to compare creating/debugging tools for ArcMap with Autocad and the Visual Lisp IDE. In Visual Lisp IDE, the code is always connected to the map document and you can always see (in the Autocad map document) the immediate actions during debugging...

Thanks again.