IronPython 2.6 : Automation API

[kdart]

Would anyone at Ranorex forsee any problems if I changed the path to IronPython in the Options setting to point to an installation of IronPython 2.6 instead of the shipped one?

[Support Team]

We don't know of any issues, but we have not tested Ranorex Studio with IronPython 2.6 (it's still a release candidate). Please, report any issues to this thread.

Regards,
Alex
Ranorex Support Team

[kdart]

One issue I have already sent a support email about is that IronPython does now properly support the source file character encoding. But your generated files don't specify that the source has non-ascii string literals (which it does), and fails.

PS Y:\shared> & 'C:\Program Files\IronPython 2.0.1\ipy.exe' manualRepository.py
PS Y:\shared> & 'C:\Program Files\IronPython 2.6\ipy.exe' manualRepository.py
File "manualRepository.py", line
SyntaxError: Non-ASCII character '\xa0' in file manualRepository.py on line 176, but no encoding declared; see http://ww
w.python.org/peps/pep-0263.html for details

The fix is to put the encoding line at the top of the source file, just as in CPython:

# -*- encoding: iso-8859-1 -*-

Your file actually has that charset in the generated string literals.

[Support Team]

Thank you for reporting this issue. We try to fix that issue for the next Ranorex maintenance release, even if Ranorex Studio won't be shipped with IronPython 2.6 in that release.

Until then, you can try to change the encoding of the file by opening the "Repository.py" file in Ranorex Studio and right click into the source code editor. In the opening context menu click on "Buffer Options" and in the "General" tab page select "US-Ascii" from the "File Encoding" list.

Regards,
Alex
Ranorex Support Team

[kdart]

IronPython 2.6 has now been officially released. When do you expect to ship (and generate) IronPython code? Would that be 2.2.2?

Thanks,
Keith

[Support Team]

Currently, the fix for this issue is scheduled for the next Ranorex minor release, i.e. Ranorex 2.3. That's because the fix could involve substantial changes in the code generation algorithm, since the file encoding needs to influence the content of the generated code (this is usually not the case). As the bug has not been fixed by our development team, yet, we don't know right now how substantial these changes will be. I flagged the issue in our bug database, so after fixing the bug the development team will decide whether the bug fix can be included in a maintenance release (e.g. V2.2.2) or if it needs to go in the next minor release (V2.3).

Sorry, but at the moment I can't give you an exact date for that bug fix

Regards,
Alex
Ranorex Support Team

[Support Team]

We did some research on this topic and found out that IronPython correctly detects the encoding of a code file if there is a UTF-8 BOM (Byte Order Mark), even without an encoding-hint at the top of the file. That is true for both IronPython 2.0.3 (currently used in Ranorex Studio) and IronPython 2.6 (most current version), so we use that feature to be compatible with both versions.

In the upcoming service release Ranorex 2.2.2, all Ranorex tools will generate code files in UTF-8 encoding with BOM. Ranorex Studio will correctly create code files in the default encoding set in the Ranorex Studio options (Tools -> Options -> Text Editor -> General -> File Encoding), so be sure to use "Unicode (UTF-8)" there. Note though, that only newly created files will have that encoding, already created files will not change. So you might need to change the encoding of already created Python code files, e.g. by a text editor like Notepad++.

Regards,
Alex
Ranorex Support Team