Working example of script with python?

It's true, you are right. It's just that I'm not a seasoned programmer or anything and right now learning a second language might be too soon for me.
I've been meaning to look into javascript for ages thought, I might just do that.

Once you know one you should find it easy to pick up another. They're all very similar and learning the underlying concepts is the hard part, which you're already through.

The only thing I can think of that I has not written earlier is selecting 'Set as default Python' option when installing ActivePython. I was getting 'Script Engine 'Python' could not be opened' right after installation of AP and DO, but right after using pyscript.py to unregister/register it started to work. In the meantime I only checked if demos were working.

Maybe you use @script python without capital P, or omited pyscript.py --unregister, or did not set 'Set as default Python'?

[quote="leo"]You could probably be up to speed in javascript in the time spent trying to get ActivePython to work. :slight_smile:

[/quote]
This is kind of true.. But if you get it to work, you can utilize your earlier knowledge of that language.
Not sure of the advantages with python, but perl's regex engine is just about unbeatable (although PCRE does a pretty good job "imitating"), so
I've used it for those kind of things when the jscript/TR1 wasn't enough, so to speak.

For some reason WSH's "WScript" is directly accessible from pythonscript (when using cscript), but "DOpus" isn't (when using DO11).
It probably is available in a namespace somewhere, but.. (I'm very new with python though).

It's interesting that this (DOpus object visible) apparently worked some time ago:

After running comparison with v10, I must say that things are different in v11 - the global DOpus object was available in v10, but is not anymore in v11 - apparently the problem is on DO side.
Using the script below I can get object type in v10, but "NameError: name 'DOpus' is not defined" in v11.

@script python f = open('c:/temp/out.txt','w') f.write(str(type(DOpus.OpenOutputWindow))) f.close()

Maybe some (new) aspect of the DOpus object is not supported by the Python/ActiveScripting bridge, so object no longer shows up in that environment.

I'm not sure we have any good way to find out what is causing Python to no longer see the object, unless there's good documentation on what is and isn't supported in the language from an ActiveScripting point of view.

From 'Python Programming on Win32' - does it ring any bell?

[Application:]
2. Passes the language engine a series of named items. Each named item is a COM object (that is, an
IDispatch pointer) with a name and attributes. The attributes include whether the item is considered global
and whether the item fires events.
3. Each named item is placed in the namespace by the language engine. Any named items that fire events have
the event-handling mechanism put in place. In addition, any object considered global should have all its
methods and properties made available as global methods and properties.
4. The application then gives the language engine the script code to execute. When the code refers to an object
previously placed in the namespace, the language engine makes a standard COM call on the COM
IDispatch pointer passed for the named item.

That seems to just be describing generic ActiveScripting, or something similar to it.

OK, some difference 10 vs 11 I've found:

  • when calling AddNamedItem for DOpus object in v10, tha value of dwFlags is 6 - and DOpus is available
  • when calling in v11, the value is 2

From activscp.idl:

6 = 4 | 2 = SCRIPTITEM_ISSOURCE | SCRIPTITEM_ISVISIBLE

2 = SCRIPTITEM_ISVISIBLE

Those flags are documented under IActiveScript::AddNamedItem

I don't see why the lack of SCRIPTITEM_ISSOURCE on an object would cause Python to reject it where it didn't before.

Unless there's some basis to the direction you're looking in, it feels like we're just shooting in the dark, which will probably be a waste of time.

Even if we work out how to get the object to appear in Python, I don't see much point in trying to get an ActiveScripting language to work when there is no community and no resources around it to help when the next set of problems emerge. You'll always be at a severe disadvantage using it, and switching to another language/syntax is trivial in comparison to that effort when all the scripting languages on offer are so similar.

Wouldn't it be rather somewhat straightforward to check (although it would still takes a bit of time)?
I mean, compare the source for the D11 DOpus object with the one for D10, and see if something is off between those two (including interface definitions and AddNamedItem's).

It isn't only python that has this issue with DO11, PerlScript apparently has the same (iow, probably anything but VB/JScript), although scripting
still works with it as long as you don't need the DOpus object for anything.

SCRIPTITEM_ISSOURCE is (apparently) used for items providing events, so if it doesn't, it (usually) shouldn't need it.

If you ever get some free time it would be nice if it was available in those languages as those have uses JS and VB doesn't.

No, that would not be straightforward as the scripting interface is almost all new in Opus 11, not just some small changes from Opus 10, and we also do not know what we are looking for.

Even if we find it, these languages have no tutorials, support or community around them for this kind of use, so we would just be doing work that led to even more work when the next question about them comes up, I fear.

JScript and VBScript are trivial to learn if you know Python.

Support (in the sense 'it works with' at least) for Python is claimed in documentation (Other common languages like Perlscript and Python can be obtained from third-party providers.)
It looks to me that it has never been verified to any extent (happens from time to time in software world, unfortunately - or am I wrong?), nevertheless I am trying to put the pieces together.
JScript and VBScript are no options for me at this time. Learning another language so that I can be productive (as opposed to quick hacks) is neither quick nor easy for me.

BTW 1: it looks like python in Script Add-ins is not recognized in any way? If I create *.py file in script add-ins folder, I get syntax error in Other logs at DO start.
BTW 2: dwFlags is not the reason, as Windows Scripting Host creates WScript with SCRIPTITEM_ISVISIBLE only and is visible.

1 Like

The docs were written assuming it would work without needing special & unknowable changes for Python, which is obviously wrong now.

If you spent the time used in this thread on learning the minor differences in syntax etc., you'd be writing JScript by now. Seriously. It's not that hard to switch if you know one language. Getting Python to work is harder.

We have a fix now for the Python issue, which will be available in the next update.

(but JScript is still better :slight_smile: )

1 Like

Nice!! If it works for Python, then it should work for perl too (seeing as Perl already works, only the DOpus object wasn't available).
Well, it is a matter of what you intend to do.
A hammer is not always the right tool for a job, neither is a tweezer.

I guess the same applies when having .pl files in the script folder though.

thanks very much for this!

[quote="jon"]We have a fix now for the Python issue, which will be available in the next update.
[/quote]

Wow, Christmas is early this year! Is there something that could be fixed/improved on pywin32 side (the component that interfaces python and Windows) - I've done some preliminary debugging with its author?

Please remember about Script object and supporting .py as Script add-ons.

And no, JScript is awful, and has no references to Monty Python :slight_smile: