PyScripter v2.5.3 released

PyScripter version 2.5.3 was released at http://pyscripter.googlecode.com.  This is another bug-fix release.  It fixes two issues in version 2.5.

• Unit test discovery was broken 
• Find in files was broken in the x64 version.

See previous post for the new features and bug fixes in version 2.5

PyScripter v2.5.2 released

PyScripter version 2.5.2 was released at http://pyscripter.googlecode.com.  This just a bug-fix release.  It fixes a regression in version 2.5 due to which GUI scripts would not show up. (Issue 625).

PyScripter v2.5.1 released

PyScripter version 2.5.1 was released at http://pyscripter.googlecode.com.  This just a bug-fix release.  It fixes two issues in version 2.5.

• Word-wrap in the editor caused problems
• Navigation with the Code Explorer was broken.

See previous post for the new features and bug fixes in version 2.5.

PyScripter v2.5 released

PyScripter version 2.5 was released at http://pyscripter.googlecode.com. 

• New features:
• This is the first joint 32-bit and 64-bit version release
• Python 3.3 support added
• Recent Projects menu item added
• Expandable lists and tuples in the Variables window ( Issue 583 )
• Expandable watches as in the Variables window ( Issue 523 )
• Basic support for Cython files added ( Issue 542 )
• New interpreter command Paste & Execute ( Issue 500 ) Replaces Paste with Prompt
• New PyIDE option "Display package names in editor tabs" default True ( Issue 115 )
• New search option "Auto Case Sensitive" (case insensitive when search text is lower case)
• The Abort command raises a KeyboardInterrupt at the Remote Engine ( Issue 618 )
• Incremental search in the Project Explorer matches any part of a filename (Issue 623)
• New IDE option "File line limit for syntax check as you type" default 1000
• Issues addressed:
• Issue 516 , Issue 348 , Issue 549 , Issue 563 , Issue 564 , Issue 568 , Issue 576 , Issue 587 , Issue 591 , Issue 592 , Issue 594 , Issue 597 , Issue 598 , Issue 599 , Issue 612 , Issue 613 , Issue 615

Please let me interrupt you

The standard way of interrupting a long running script in a Python shell is to press Ctrl+C which signals a keyboard interrupt and the interpreter raises a KeyboardInterrupt exception.  I was trying for a while to find a way to raise a KeyboardInterrupt execption at the remote python engine without much success.  The way IDLE handles this, is by running a separate thread in the server, which waits for such a signal to arrive from IDLE and then uses the interrupt_main function of the threading module.  I thought that having a separate thread just for this purpose would slow down the execution of scripts and the PyScripter solution of reinitializing the engine was good enough.

Resently, a user has posted an issue about this at PyScripter’s bug tracker and I had another look at the problem.  So I found a solution using Windows API and avoiding run overheads,  For the benefit of Windows hackers I show the code below:

function CtrlHandler( fdwCtrlType : dword): LongBool; stdcall;
begin
  Result := True;
end;

AttachConsole := GetProcAddress (GetModuleHandle ('kernel32.dll'), 'AttachConsole');
if Assigned(AttachConsole) then
try
  OSCheck(AttachConsole(fRemotePython.ServerProcess.ProcessInfo.dwProcessId));
  OSCheck(SetConsoleCtrlHandler(@CtrlHandler, True));
  try
    OSCheck(GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0));
    Sleep(100);
  finally
    OSCheck(SetConsoleCtrlHandler(@CtrlHandler, False));
    OSCheck(FreeConsole);
  end;
except
end;

Note that the CtrlHandler is needed to avoid killing PyScripter itself.  It took me a while to work out this piece of code since, I could not find such code sample (only pieces of the puzzle) in the Internet.  The only solution I found involved injecting code into the server process.

So starting from the forthcoming version 2.5, the Abort command will result in a KeyboardInterrupt exeption in script is run or debugged.  So there is no need to reinitialize the engine to stop a script.  After the script stops you can enter the Post-Mortem mode to see what the script was doing when it received the Keyboard interrupt.

I could have added a shortcut Ctrl+C to the interpreter for raising a Keyboard interrupt, but the Ctrl-C shortcut in GUI applications is associated with the copy command.  So the Abort command will achieve the same thing as pressing Ctrl+C in Python Shell.  When a scrip is stopped at a breakpoint, the Abort command will work as before.