While simple scripts can generally be developed from example using only the Wing IDE binary distribution, more advanced scripts require Wing to be run from the source code distribution, usually as a debug process being controlled by another copy of Wing IDE.
This provides not only more complete access to the source code for scripts that reach through the API into Wing internals, but also more complete support for debugging the scripts as they are developed.
To obtain Wing's source code, you must have a valid license to Wing IDE Professional or higher and must fill out and submit a non-disclosure agreement. Once this is done, you will be provided with access to the source code and more information on working with Wing IDE's sources.
For an example of an advanced script that adds a tool panel to the IDE's interface, see templating.py in the scripts directory inside the Wing IDE installation.
Advanced scripters working outside of the API defined in wingapi.py should note that Wing only clears code objects registered through the API. For example, a script-added timeout (using CAPIApplication.InstallTimeout() method) will be removed and re-added automatically during reload, but a tool panel added using Wing internals will need to be removed and re-added before it updates to run on altered script code. In some cases, when object references from a script file are installed into Wing's internals, it will be necessary to restart Wing IDE.
Script files that define a global _no_reload_scripts will never be reloaded or unloaded. Files that define _ignore_scripts or that exist outside of the script path are also never reloaded.
Here is how reloading works:
Note that reloading is by design slightly different than Python's builtin reload() function: Any old top-level symbols are blown away rather than being retained. This places some limits on what can be done with global data: For example, storing a database connection will require re-establishing the connection each time the script is reloaded.