#develop (short for SharpDevelop) is a free IDE for .NET programming languages.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

106 lines
3.8 KiB

* ProcessRunner.Start throws an exception since the python filename
cannot be found.
try {
runner.Start();
} catch (Win32Exception ex) {
if (ex.NativeErrorCode == Win32FileNotFoundErrorCode || ex.NativeErrorCode == Win32PathNotFoundErrorCode) {
throw new NAntAddInException(GetNAntNotFoundErrorMessage(AddInOptions.NAntFileName), ex);
} else {
throw;
}
}
* ActiveWindow is null.
* PythonCompiler.ImageFileMachine
* PythonCompiler.StaticTypes
* Main entry point:
if __name __ == "__main__" or __name__ == sys.executable:
main(sys.argv[1:])
def main(args):
print "Hello, World!"
return 0
* CtrlSpaceHelper.AddUsing should be called in the PythonResolver when
the ExpressionContext is Importable.
if (context == ExpressionContext.Importable) {
pc.AddNamespaceContents(result, String.Empty, pc.Language, true);
CtrlSpaceResolveHelper.AddUsing(result, pc.DefaultImports, pc);
return result;
}
* Custom IExpressionFinder.
This is the only way to set the ExpressionContext to be Importable
or a Namespace. This cannot be done in the resolver.
* Intellisense for built-in modules (e.g. sys).
IronPython does define classes for these built-in types so we
just need to work out a way to get access to them. The standard
methods are available via the BuiltIn class (e.g. dir, print). The
sys module is actually the SystemState class. Most of these classes
have attributes that mark them as PythonTypes or PythonModules. These
could potentially be used. There is also a PythonName property which
could be used to limit the methods returned for a built-in type and
map to the correct name.
* Extend SharpDevelop by providing an IronPython macro window.
Ideally the code should be able to be debugged but this may be
too difficult.
The script should be able to access SharpDevelop and control it.
A macro recorder is out of scope. One way to do this would be
to rewrite SharpDevelop to use Command objects throughout. Otherwise
all calls to objects that are provided to the script needed to be
monitored and all calls recorded.
Intellisense. Could use the same code used in the text editor.
A way to load and run the scripts.
A way to call a script from another script.
* Intelligent completion after a from statement.
Typical statement is "from System import Console". At the moment
code completion after the import is incorrect here. It needs to
show items that are in the System namespace.
* The PythonDesignerGenerator inserts an event handler at the end
of the active document. This is not correct. It should insert it at the
end of the form class. The file could contain multiple classes and
inserting the event handler at the end will not work in that case.
* Python forms designer - default property values are incorrect. They should be based on the parent
control. For example:
ParentControl has BorderStyle = FixedSingle when created.
ChildControl has ParentControl as base class.
BorderStyle set to None in designer for ChildControl. Code should then be generated for BorderStyle since this
is not the default
* Event Handler loading code:
Handle invalid event name.
Check that += operator used.
* ContextMenuStrip
If the context menu is added for the first time and left open and displayed on the form when
switching to the source code you see an OwnerItem property added to the context menu variable:
self._contextMenuStrip1.OwnerItem = ContextMenuStrip
* Look at fixing the compiled exe so it can be run from a different folder.
See http://lists.ironpython.com/pipermail/users-ironpython.com/2009-April/009993.html
* Support for ListViewSubItems - Font, Colors.
* Timer - Honour the GenerateMember setting.
* Look at creating code for non-visual components in the same order as Visual Studio.