diff --git a/Pywin32/.gitignore b/Pywin32/.gitignore
new file mode 100644
index 0000000..467f152
--- /dev/null
+++ b/Pywin32/.gitignore
@@ -0,0 +1,35 @@
+*.py[co]
+
+# C extensions
+*.so
+
+# Packages
+*.egg
+*.egg-info
+dist
+build
+eggs
+parts
+bin
+var
+sdist
+develop-eggs
+.installed.cfg
+lib64
+__pycache__
+
+# Installer logs
+pip-log.txt
+
+# Unit test / coverage reports
+.coverage
+.tox
+nosetests.xml
+
+# Translations
+*.mo
+
+# Mr Developer
+.mr.developer.cfg
+.project
+.pydevproject
diff --git a/Pywin32/.no-sublime-package b/Pywin32/.no-sublime-package
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/Pywin32/.no-sublime-package
@@ -0,0 +1 @@
+
diff --git a/Pywin32/License.txt b/Pywin32/License.txt
new file mode 100644
index 0000000..237b6c9
--- /dev/null
+++ b/Pywin32/License.txt
@@ -0,0 +1,30 @@
+Unless stated in the specfic source file, this work is
+Copyright (c) 1996-2008, Greg Stein and Mark Hammond.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the distribution.
+
+Neither names of Greg Stein, Mark Hammond nor the name of contributors may be used
+to endorse or promote products derived from this software without
+specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
+IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/Pywin32/README.md b/Pywin32/README.md
new file mode 100644
index 0000000..70968d5
--- /dev/null
+++ b/Pywin32/README.md
@@ -0,0 +1,23 @@
+Pywin32
+=======
+
+Pywin32 support for sublime (win32api etc)
+
+Still evaluating what needs to be included and what doesn't, so if it is missing something important, please let me know.
+
+# Using Pywin32
+Pywin32 modules should be accessible as soon as Sublime loads up the Pywin32 plugin...but since there is no guarunteed way to ensure all plugins are loaded after Pywin32 gets loaded, you should include `Pywin32.setup` before including any pywin32 modules. You can include it once in the top most level file, and all subsequent includes from that file should be guarunteed access. It does not have to be included in all files that call pywin32 modules, just once in the top level file that is the entry point. If I could guaruntee pywin32 to get loaded before all plugins, then even this requriement would not be necessary.
+
+Example (show url path of all open explorer windows):
+
+```python
+import Pywin32.setup
+from win32com.client.gencache import EnsureDispatch
+
+
+def run():
+ for w in EnsureDispatch("Shell.Application").Windows():
+ print(w.LocationName + "=" + w.LocationURL)
+
+run()
+```
diff --git a/Pywin32/lib/x32/pythoncom.py b/Pywin32/lib/x32/pythoncom.py
new file mode 100644
index 0000000..ca7fda4
--- /dev/null
+++ b/Pywin32/lib/x32/pythoncom.py
@@ -0,0 +1,3 @@
+# Magic utility that "redirects" to pythoncomxx.dll
+import pywintypes
+pywintypes.__import_pywin32_system_module__("pythoncom", globals())
diff --git a/Pywin32/lib/x32/win32/_win32sysloader.pyd b/Pywin32/lib/x32/win32/_win32sysloader.pyd
new file mode 100644
index 0000000..b3ae605
Binary files /dev/null and b/Pywin32/lib/x32/win32/_win32sysloader.pyd differ
diff --git a/Pywin32/lib/x32/win32/_winxptheme.pyd b/Pywin32/lib/x32/win32/_winxptheme.pyd
new file mode 100644
index 0000000..8666858
Binary files /dev/null and b/Pywin32/lib/x32/win32/_winxptheme.pyd differ
diff --git a/Pywin32/lib/x32/win32/include/PyWinTypes.h b/Pywin32/lib/x32/win32/include/PyWinTypes.h
new file mode 100644
index 0000000..969ae9f
--- /dev/null
+++ b/Pywin32/lib/x32/win32/include/PyWinTypes.h
@@ -0,0 +1,934 @@
+
+#ifndef __PYWINTYPES_H__
+#define __PYWINTYPES_H__
+
+// If building under a GCC, tweak what we need.
+#if defined(__GNUC__) && defined(_POSIX_C_SOURCE)
+ // python.h complains if _POSIX_C_SOURCE is already defined
+# undef _POSIX_C_SOURCE
+#endif
+
+// early msvc versions complain about pragma #s it doesn't understand
+// C:\mssdk\VC\INCLUDE\string.h(142) : warning C4616: #pragma warning : warning number '6059' out of range, must be between '4001' and '4999'
+// and:
+// C:\mssdk\include\wingdi.h(4340) : warning C4068: unknown pragma
+// I doubt we ever care about that warning, so unconditionally nuke em!
+#pragma warning( disable:4616 4068 )
+// Python.h and Windows.h both protect themselves from multiple
+// includes - so it is safe to do here (and provides a handy
+// choke point for #include vagaries
+
+// Some other warnings generated by MSVC6 which we don't care about
+#if (PY_VERSION_HEX < 0x02060000)
+#pragma warning( disable:4035 )
+#endif
+
+// windows rpc.h defines "small" as "char" which breaks Python's accu.h,
+// so we undefine it before including python.
+#ifdef small
+#undef small
+#endif
+
+#include "Python.h"
+// many many files need python's structmember.h, and its possible people
+// #included windows.h before including us...
+#ifdef WRITE_RESTRICTED
+#undef WRITE_RESTRICTED
+#endif
+#include "structmember.h"
+// and python's structmember.h #defines this, conflicting with windows.h
+#ifdef WRITE_RESTRICTED
+#undef WRITE_RESTRICTED
+#endif
+#include "windows.h"
+#undef WRITE_RESTRICTED // stop anyone using the wrong one accidently...
+
+// Python 2.3 doesn't have Py_CLEAR...
+#if (PY_VERSION_HEX < 0x02040000)
+#ifndef Py_CLEAR
+#define Py_CLEAR(op) \
+ do { \
+ if (op) { \
+ PyObject *_py_tmp = (PyObject *)(op); \
+ (op) = NULL; \
+ Py_DECREF(_py_tmp); \
+ } \
+ } while (0)
+#endif
+// or Py_RETURN_NONE
+#ifndef Py_RETURN_NONE
+/* Macro for returning Py_None from a function */
+#define Py_RETURN_NONE return Py_INCREF(Py_None), Py_None
+#endif
+
+#endif // (PY_VERSION_HEX < 0x02040000)
+
+
+// Helpers for our modules.
+// Some macros to help the pywin32 modules co-exist in py2x and py3k.
+// Creates and initializes local variables called 'module' and 'dict'.
+
+#if (PY_VERSION_HEX < 0x03000000)
+
+// Use to define the function itself (ie, its name, linkage, params)
+#define PYWIN_MODULE_INIT_FUNC(module_name) \
+ extern "C" __declspec(dllexport) void init##module_name(void)
+
+// If the module needs to early-exit on an error condition.
+#define PYWIN_MODULE_INIT_RETURN_ERROR return;
+
+// When the module has successfully initialized.
+#define PYWIN_MODULE_INIT_RETURN_SUCCESS return;
+
+// To setup the module object itself and the module's dictionary.
+#define PYWIN_MODULE_INIT_PREPARE(module_name, functions, docstring) \
+ PyObject *dict, *module; \
+ if (PyWinGlobals_Ensure()==-1) \
+ return; \
+ if (!(module = Py_InitModule(#module_name, functions))) \
+ return; \
+ if (!(dict = PyModule_GetDict(module))) \
+ return;
+
+#else
+// py3k module helpers.
+// Use to define the function itself (ie, its name, linkage, params)
+#define PYWIN_MODULE_INIT_FUNC(module_name) \
+ extern "C" __declspec(dllexport) PyObject *PyInit_##module_name(void)
+
+// If the module needs to early-exit on an error condition.
+#define PYWIN_MODULE_INIT_RETURN_ERROR return NULL;
+
+// When the module has successfully initialized.
+#define PYWIN_MODULE_INIT_RETURN_SUCCESS return module;
+
+// To setup the module object itself and the module's dictionary.
+#define PYWIN_MODULE_INIT_PREPARE(module_name, functions, docstring) \
+ PyObject *dict, *module; \
+ static PyModuleDef module_name##_def = { \
+ PyModuleDef_HEAD_INIT, \
+ #module_name, \
+ docstring , \
+ -1, \
+ functions }; \
+ if (PyWinGlobals_Ensure()==-1) \
+ return NULL; \
+ if (!(module = PyModule_Create(&module_name##_def))) \
+ return NULL; \
+ if (!(dict = PyModule_GetDict(module))) \
+ return NULL;
+#endif // PY_VERSION_HEX
+
+
+// Helpers for our types.
+#if (PY_VERSION_HEX < 0x03000000)
+#define PYWIN_OBJECT_HEAD PyObject_HEAD_INIT(&PyType_Type) 0,
+#define PYWIN_ATTR_CONVERT PyString_AsString
+
+#else // Py3k definitions
+// Macro to handle PyObject layout changes in Py3k
+#define PYWIN_OBJECT_HEAD PyVarObject_HEAD_INIT(NULL, 0)
+
+/* Attribute names are passed as Unicode in Py3k, so use a macro to
+ switch between string and unicode conversion. This function is not
+ documented, but is used extensively in the Python codebase itself,
+ so it's reasonable to assume it won't disappear anytime soon.
+*/
+#define PYWIN_ATTR_CONVERT _PyUnicode_AsString
+
+/* Some API functions changed/removed in python 3.0
+ Definitions for the string functions are in stringobject.h,
+ but comments indicate that this header is likely to go away in 3.1.
+*/
+#define PyString_Check PyBytes_Check
+#define PyString_Size PyBytes_Size
+#define PyString_AsString PyBytes_AsString
+#define PyString_AsStringAndSize PyBytes_AsStringAndSize
+#define PyString_FromString PyBytes_FromString
+#define PyString_FromStringAndSize PyBytes_FromStringAndSize
+#define _PyString_Resize _PyBytes_Resize
+#define PyString_AS_STRING PyBytes_AS_STRING
+#define PyString_GET_SIZE PyBytes_GET_SIZE
+#define PyString_Concat PyBytes_Concat
+#define PyInt_Check PyLong_Check
+#define PyInt_FromLong PyLong_FromLong
+#define PyInt_AsLong PyLong_AsLong
+#define PyInt_AS_LONG PyLong_AS_LONG
+#define PyInt_FromSsize_t PyLong_FromSsize_t
+#define PyInt_AsSsize_t PyLong_AsSsize_t
+#define PyInt_AsUnsignedLongMask PyLong_AsUnsignedLongMask
+#define PyNumber_Int PyNumber_Long
+#endif // (PY_VERSION_HEX < 0x03000000)
+
+// See PEP-353 - this is the "official" test...
+#if PY_VERSION_HEX < 0x02050000 && !defined(PY_SSIZE_T_MIN)
+// 2.3 and before have no Py_ssize_t
+typedef int Py_ssize_t;
+#define PyInt_FromSsize_t PyInt_FromLong
+#define PyInt_AsSsize_t PyInt_AsLong
+#define PY_SSIZE_T_MAX INT_MAX
+#define PY_SSIZE_T_MIN INT_MIN
+#endif
+
+// Py_hash_t was introduced as the size of a pointer in python 3.2 - it
+// was a simple long before that.
+#if PY_VERSION_HEX < 0x03020000
+typedef long Py_hash_t;
+#else
+typedef Py_ssize_t Py_hash_t;
+#endif
+
+#if PY_VERSION_HEX < 0x02030000
+#define PyLong_AsUnsignedLongMask PyLong_AsUnsignedLong
+#endif
+
+// This only enables runtime checks in debug builds - so we use
+// our own so we can enable it always should we desire...
+#define PyWin_SAFE_DOWNCAST Py_SAFE_DOWNCAST
+
+// Lars: for WAVEFORMATEX
+#include "mmsystem.h"
+
+
+// *** NOTE *** FREEZE_PYWINTYPES is deprecated. It used to be used
+// by the 'freeze' tool, but now py2exe etc do a far better job, and
+// don't require a custom built pywintypes DLL.
+#ifdef FREEZE_PYWINTYPES
+ /* The pywintypes module is being included in a frozen .EXE/.DLL */
+# define PYWINTYPES_EXPORT
+#else
+# ifdef BUILD_PYWINTYPES
+ /* We are building pywintypesxx.dll */
+# define PYWINTYPES_EXPORT __declspec(dllexport)
+#else
+ /* This module uses pywintypesxx.dll */
+# define PYWINTYPES_EXPORT __declspec(dllimport)
+# if defined(_MSC_VER)
+# if defined(DEBUG) || defined(_DEBUG)
+# pragma comment(lib,"pywintypes_d.lib")
+# else
+# pragma comment(lib,"pywintypes.lib")
+# endif // DEBUG/_DEBUG
+# endif // _MSC_VER
+# endif // BUILD_PYWINTYPES
+#endif // FREEZE_PYWINTYPES
+
+#if (PY_VERSION_HEX >= 0x03000000)
+// Py3k uses memoryview object in place of buffer
+extern PYWINTYPES_EXPORT PyObject *PyBuffer_New(Py_ssize_t size);
+extern PYWINTYPES_EXPORT PyObject *PyBuffer_FromMemory(void *buf, Py_ssize_t size);
+#endif
+
+// Formats a python traceback into a character string - result must be free()ed
+PYWINTYPES_EXPORT char *GetPythonTraceback(PyObject *exc_type, PyObject *exc_value, PyObject *exc_tb);
+
+#include
This cast, and knowledge of a specific IID_* to type must be simulated in Python.
+Python/COM will therefore maintain a map of UID's to Python type objects. Whenever QueryInterface is called, Python will lookup this map, to determine if the object type is supported. If the object is supported, then an object of that type will be returned. If the object is not supported, then a PyIUnknown object will be returned.
+Note that PyIDispatch will be supported by the core engine. Therefore:
+>>> disp=someobj.QueryInterface(win32com.IID_Dispatch)
+will return a PyIDispatch object, whereas
+>>> unk=someobj.QueryInterface(SomeUnknownIID) # returns PyIUnknown
+>>> disp=unk.QueryInterface(win32com.IID_Dispatch)
+>>> unk.Release() # Clean up now, rather than waiting for unk death.
+Is needed to convert to an IDispatch object.
+The core COM support module will support the IUnknown, IDispatch, ITypeInfo, ITypeLib and IConnectionPointContainer and IConnectionPoint interfaces. This implies the core COM module supports 6 different OLE client object types, mapped to the 6 IID_*'s representing the objects. (The IConnection* objects allow for Python to repsond to COM events)
+A psuedo-inheritance scheme is used. The Python types are all derived from the Python IUnknown type (PyIUnknown). Therefore all IUnknown methods are automatically available to all types, just as it should be. The PyIUnknown type manages all object reference counts and destruction.
+To provide the above functionality, a Python map is provided, which maps from a GUID to a Python type object.
+The advantage of this scheme is an external extension modules can hook into the core support. For example, imagine the following code:
+>>> import myextracom # external .pyd supporting some interface.
+# myextracom.pyd will do the equivilent of
+# pythoncom.mapSupportedTypes(myextracom.IID_Extra, myextracom.ExtraType)
+>>> someobj.QueryInterface(myextracom.IID_Extra)
+Would correctly return an object defined in the extension module.
+A server framework has been put in place which provides the following features:
+All Interfaces provide VTBL support - this means that the Servers exposed by Python are callable from C++ and other compiled languages.
+Supports full "inproc" servers. This means that no external .EXE is needed making Python COM servers available in almost all cases.
+An extensible model which allows for extension modules to provide server support for interfaces defined in that module. A map is provided which maps from a GUID to a function pointer which creates the interface.
+In general, Python and COM are both "type-less". COM is type-less via the VARIANT object, which supports many types, and Python is type-less due to its object model.
+There are a number of areas where Python and OLE clash.
+For simple calls, there are 2 helpers available which will convert to and from PyObjects and VARIANTS. The call to convert a Python object to a VARIANT is simple in that it returns a VARIANT of the most appropriate type for the Python object - ie, the type of the Python object determines the resulting VARIANT type.
+There are also more complex conversion routines available, wrapped in a C++ helper class. Typically, these helpers are used whenever a specific variant type is known (eg, when an ITypeInfo is available for the object being used). In this case, all efforts are made to convert the Python type to the requested variant type - ie, in this situation, the VARIANT type determines how the Python object is coerced. In addition, this code supports the use of "ByRef" and pointer paramaters, providing and freeing any buffers necessary for the call.
+ diff --git a/Pywin32/lib/x32/win32com/HTML/QuickStartClientCom.html b/Pywin32/lib/x32/win32com/HTML/QuickStartClientCom.html new file mode 100644 index 0000000..f3a0274 --- /dev/null +++ b/Pywin32/lib/x32/win32com/HTML/QuickStartClientCom.html @@ -0,0 +1,82 @@ + + + + +This documents how to quickly start using COM from Python. It is not a thorough discussion of the COM system, or of the concepts introduced by COM.
+Other good information on COM can be found in various conference tutorials - please see the collection of Mark's conference tutorials
+For information on implementing COM objects using Python, please see a Quick Start to Server side COM and Python
+In this document we discuss the following topics:
+ +import win32com.client
+o = win32com.client.Dispatch("Object.Name")
+o.Method()
+o.property = "New Value"
+print o.property
+Example
+o = win32com.client.Dispatch("Excel.Application")
+o.Visible = 1
+o.Workbooks.Add() # for office 97 – 95 a bit different!
+o.Cells(1,1).Value = "Hello"
+And we will see the word "Hello" appear in the top cell.
+Good question. This is hard! You need to use the documentation with the products, or possibly a COM browser. Note however that COM browsers typically rely on these objects registering themselves in certain ways, and many objects to not do this. You are just expected to know.
+PythonCOM comes with a basic COM browser that may show you the information you need. Note that this package requires Pythonwin (ie, the MFC GUI environment) to be installed for this to work.
+There are far better COM browsers available - I tend to use the one that comes with MSVC, or this one!
+To run the browser, simply select it from the Pythonwin Tools menu, or double-click on the file win32com\client\combrowse.py
+In the above examples, if we printed the 'repr(o)' object above, it would have resulted in
<COMObject Excel.Application>
+This reflects that the object is a generic COM object that Python has no special knowledge of (other than the name you used to create it!). This is known as a "dynamic dispatch" object, as all knowledge is built dynamically. The win32com package also has the concept of static dispatch objects, which gives Python up-front knowledge about the objects that it is working with (including arguments, argument types, etc)
+In a nutshell, Static Dispatch involves the generation of a .py file that contains support for the specific object. For more overview information, please see the documentation references above.
+The generation and management of the .py files is somewhat automatic, and involves one of 2 steps:
+ +or
+ +The win32com.client.gencache module manages these generated files. This module has some documentation of its own, but you probably don't need to know the gory details!
+You will notice that the generated file name is long and cryptic - obviously not designed for humans to work with! So how do you get at the module object for the generated code?
+Hopefully, the answer is you shouldn't need to. All generated file support is generally available directly via win32com.client.Dispatch and win32com.client.constants. But should you ever really need the Python module object, the win32com.client.gencache module has functions specifically for this. The functions GetModuleForCLSID and GetModuleForProgID both return Python module objects that you can use in your code. See the docstrings in the gencache code for more details.
+Either:
+ +win32com\client\makepy.py' (eg, run it from the command window, or double-click on it) and a list will be presented. Select the Type Library 'Microsoft Word 8.0 Object Library' makepy.py "Microsoft Word 8.0 Object Library"' (include the double quotes). This simply avoids the selection process. 'makepy.py -i "Microsoft Word 8.0 Object Library"' (include the double quotes) to see how to do this.And that is it! Nothing more needed. No special import statements needed! Now, you simply need say
+>>> import win32com.client
+>>> w=win32com.client.Dispatch("Word.Application")
+>>> w.Visible=1
+>>> w
+<win32com.gen_py.Microsoft Word 8.0 Object Library._Application>
+Note that now Python knows the explicit type of the object.
+Makepy automatically installs all generated constants from a type library in an object called win32com.clients.constants. You do not need to do anything special to make these constants work, other than create the object itself (ie, in the example above, the constants relating to Word would automatically be available after the w=win32com.client.Dispatch("Word.Application") statement.
For example, immediately after executing the code above, you could execute the following:
+>>> w.WindowState = win32com.client.constants.wdWindowStateMinimize
+and Word will Minimize.
+ diff --git a/Pywin32/lib/x32/win32com/HTML/QuickStartServerCom.html b/Pywin32/lib/x32/win32com/HTML/QuickStartServerCom.html new file mode 100644 index 0000000..b956daa --- /dev/null +++ b/Pywin32/lib/x32/win32com/HTML/QuickStartServerCom.html @@ -0,0 +1,195 @@ + + + + +This documents how to quickly start implementing COM objects in Python. It is not a thorough discussion of the COM system, or of the concepts introduced by COM.
+For more details information on Python and COM, please see the COM Tutorial given by Greg Stein and Mark Hammond at SPAM 6 (HTML format) or download the same tutorial in PowerPoint format.
+For information on using external COM objects from Python, please see a Quick Start to Client side COM and Python.
+In this document we discuss the core functionality, registering the server, testing the class, debugging the class, exception handling and server policies (phew!)
+class HelloWorld:
+
+
+def __init__(self):
+
+
+self.softspace = 1
+self.noCalls = 0
+
+
+def Hello(self, who):
+
+
+self.noCalls = self.noCalls + 1
+# insert "softspace" number of spaces
+return "Hello" + " " * self.softspace + who
+
+
+
+
+This is obviously a very simple server. In particular, custom error handling would be needed for a production class server. In addition, there are some contrived properties just for demonstration purposes.
+At this stage, Python and Unicode don’t really work well together. All strings which come from COM will actually be Unicode objects rather than string objects.
+To make this code work in a COM environment, the last line of the "Hello" method must become:
return "Hello" + " " * self.softspace + str(who)
Note the conversion of the "who" to "str(who)". This forces the Unicode object into a native Python string object.
+For details on how to debug COM Servers to find this sort of error, please see debugging the class
+This is not a complete list of names, simply a list of properties used by this sample.
+|
+ Property Name |
+
+ Description |
+
|
+ _public_methods_ |
+
+ List of all method names exposed to remote COM clients |
+
|
+ _public_attrs_ |
+
+ List of all attribute names exposed to remote COM clients |
+
|
+ _readonly_attrs_ |
+
+ List of all attributes which can be accessed, but not set. |
+
We change the class header to become:
+class HelloWorld:
+
+
+_public_methods_ = ['Hello']
+_public_attrs_ = ['softspace', 'noCalls']
+_readonly_attrs_ = ['noCalls']
+def __init__(self):
+[Same from here…]
+
+
+COM requires that all objects use a unique CLSID and be registered under a "user friendly" name. This documents the process.
+Microsoft Visual C++ comes with various tools for generating CLSID's, which are quite suitable. Alternatively, the pythoncom module exports the function CreateGuid() to generate these identifiers.
+>>> import pythoncom
+>>> print pythoncom.CreateGuid()
+{7CC9F362-486D-11D1-BB48-0000E838A65F}
+Obviously the GUID that you get will be different than that displayed here.
+The win32com package allows yet more annotations to be applied to a class, allowing registration to be effected with 2 lines in your source file. The registration annotations used by this sample are:
+|
+ Property Name |
+
+ Description |
+
|
+ _reg_clsid_ |
+
+ The CLSID of the COM object |
+
|
+ _reg_progid_ |
+
+ The "program ID", or Name, of the COM Server. This is the name the user usually uses to instantiate the object |
+
|
+ _reg_desc_ |
+
+ Optional: The description of the COM Server. Used primarily for COM browsers. If not specified, the _reg_progid_ is used as the description. |
+
|
+ _reg_class_spec_ |
+
+ Optional: A string which represents how Python can create the class instance. The string is of format The portion up to the class name must be valid for Python to "import", and the class portion must be a valid attribute in the specified class. +This is optional from build 124 of Pythoncom., and has been removed from this sample. |
+
|
+ _reg_remove_keys_ |
+
+ Optional: A list of tuples of extra registry keys to be removed when uninstalling the server. Each tuple is of format ("key", root), where key is a string, and root is one of the win32con.HKEY_* constants (this item is optional, defaulting to HKEY_CLASSES_ROOT) |
+
Note there are quite a few other keys available. Also note that these annotations are not required - they just make registration simple. Helper functions in the module win32com.server.register allow you to explicitly specify each of these attributes without attaching them to the class.
The header of our class now becomes:
+class HelloWorld:
+
+
+_reg_clsid_ = "{7CC9F362-486D-11D1-BB48-0000E838A65F}"
+_reg_desc_ = "Python Test COM Server"
+_reg_progid_ = "Python.TestServer"
+_public_methods_ = ['Hello']
+[same from here]
+
+
+The idiom that most Python COM Servers use is that they register themselves when run as a script (ie, when executed from the command line.) Thus the standard "if __name__=='__main___':" technique works well.
win32com.server.register contains a number of helper functions. The easiest to use is "UseCommandLine".
Registration becomes as simple as:
+if __name__=='__main__':
+ # ni only for 1.4!
+ import ni, win32com.server.register
+ win32com.server.register.UseCommandLine(HelloWorld)
+Running the script will register our test server.
+For the purposes of this demonstration, we will test the class using Visual Basic. This code should run under any version of Visual Basic, including VBA found in Microsoft Office. Any COM compliant package could be used alternatively. VB has been used just to prove there is no "smoke and mirrors. For information on how to test the server using Python, please see the Quick Start to Client side COM documentation.
+This is not a tutorial in VB. The code is just presented! Run it, and it will work!
+When things go wrong in COM Servers, there is often nowhere useful for the Python traceback to go, even if such a traceback is generated.
+Rather than discuss how it works, I will just present the procedure to debug your server:
+To register a debug version of your class, run the script (as above) but pass in a "--debug" parameter. Eg, for the server above, use the command line "testcomserver.py --debug".
To see the debug output generated (and any print statements you may choose to add!) you can simply select the "Remote Debug Trace Collector" from the Pythonwin Tools menu, or run the script "win32traceutil.py" from Windows Explorer or a Command Prompt.
+Servers need to be able to provide exception information to their client. In some cases, it may be a simple return code (such as E_NOTIMPLEMENTED), but often it can contain much richer information, describing the error on detail, and even a help file and topic where more information can be found.
+We use Python class based exceptions to provide this information. The COM framework will examine the exception, and look for certain known attributes. These attributes will be copied across to the COM exception, and passed back to the client.
+The following attributes are supported, and correspond to the equivalent entry in the COM Exception structure:
+scode, code, description, source, helpfile and helpcontext
To make working with exceptions easier, there is a helper module "win32com.server.exception.py", which defines a single class. An example of its usage would be:
+raise COMException(desc="Must be a string",scode=winerror.E_INVALIDARG,helpfile="myhelp.hlp",...)
+(Note the COMException class supports (and translates) "desc" as a shortcut for "description", but the framework requires "description")
This is information about how it all hangs together. The casual COM author need not know this.
+Whenever a Python Server needs to be created, the C++ framework first instantiates a "policy" object. This "policy" object is the gatekeeper for the COM Server - it is responsible for creating the underlying Python object that is the server (ie, your object), and also for translating the underlying COM requests for the object.
+This policy object handles all of the underlying COM functionality. For example, COM requires all methods and properties to have unique numeric ID's associated with them. The policy object manages the creation of these ID's for the underlying Python methods and attributes. Similarly, when the client whishes to call a method with ID 123, the policy object translates this back to the actual method, and makes the call.
+It should be noted that the operation of the "policy" object could be dictated by the Python object - the policy object has many defaults, but the actual Python class can always dictate its operation.
+The default policy object has a few special attributes that define who the object is exposed to COM. The example above shows the _public_methods attribute, but this section describes all such attributes in detail.
+Required list of strings, containing the names of all methods to be exposed to COM. It is possible this will be enhanced in the future (eg, possibly '*' will be recognised to say all methods, or some other ideas…)
+Optional list of strings containing all attribute names to be exposed, both for reading and writing. The attribute names must be valid instance variables.
+Optional list of strings defining the name of attributes exposed read-only.
+Optional list of IIDs exposed by this object. If this attribute is missing, IID_IDispatch is assumed (ie, if not supplied, the COM object will be created as a normal Automation object.
+and actual instance attributes:
+_dynamic_ : optional method
+_value_ : optional attribute
+_query_interface_ : optional method
+_NewEnum : optional method
+_Evaluate : optional method
+ diff --git a/Pywin32/lib/x32/win32com/HTML/docindex.html b/Pywin32/lib/x32/win32com/HTML/docindex.html new file mode 100644 index 0000000..fff74de --- /dev/null +++ b/Pywin32/lib/x32/win32com/HTML/docindex.html @@ -0,0 +1,22 @@ + + + + +
The following documentation is available
+A Quick Start to Client Side COM (including makepy)
+A Quick Start to Server Side COM
+Information on generated Python files (ie, what makepy generates)
+An advanced VARIANT object which can give more control over parameter types
+A brief description of the win32com package structure
+Python COM Implementation documentation
+Misc stuff I don’t know where to put anywhere else
+
Python has an excellent interface to COM (also known variously as OLE2, ActiveX, etc).
+The Python COM package can be used to interface to almost any COM program (such as the MS-Office suite), write servers that can be hosted by any COM client (such as Visual Basic or C++), and has even been used to provide the core ActiveX Scripting Support.
+ + +Preliminary Active Scripting and Debugging documentation is available.
+2 Quick-Start guides have been provided, which also contain other links. See the Quick Start for Client side COM and the Quick Start for Server side COM
+Using win32com.client.Dispatch automatically invokes all the win32com client side "smarts", including automatic usage of generated .py files etc.
+If you wish to avoid that, and use truly "dynamic" objects (ie, there is generated .py support available, but you wish to avoid it), you can use win32com.client.dynamic.Dispatch
+_print_details_() method
+If win32com.client.dynamic.Dispatch is used, the objects have a _print_details_() method available, which prints all relevant knowledge about an object (for example, all methods and properties). For objects that do not expose runtime type information, _print_details_ may not list anything.

This document describes the win32com package in general terms.
+The COM support can be thought of as existing in 2 main portions - the C++ support code (the core PythonCOM module), and helper code, implemented in Python. The total package is known as "win32com".
+The win32com support is stand-alone. It does not require Pythonwin.
+To facilitate an orderly framework, the Python "ni" module has been used, and the entire package is known as "win32com". As is normal for such packages, win32com itself does not provide any functionality. Some of the modules are described below:
+ ++
The pythoncom module is the underlying C++ support for all COM related objects. In general, Python programmers will not use this module directly, but use win32com helper classes and functions.
+This module exposes a C++ like interface to COM - there are objects implemented in pythoncom that have methods "QueryInterface()", "Invoke()", just like the C++ API. If you are using COM in C++, you would not call a method directly, you would use pObject->Invoke( …, MethodId, argArray…). Similarly, if you are using pythoncom directly, you must also use the Invoke method to call an object's exposed method.
+There are some Python wrappers for hiding this raw interface, meaning you should almost never need to use the pythoncom module directly. These helpers translate a "natural" looking interface (eg, obj.SomeMethod()) into the underlying Invoke call.
+ diff --git a/Pywin32/lib/x32/win32com/HTML/variant.html b/Pywin32/lib/x32/win32com/HTML/variant.html new file mode 100644 index 0000000..2631203 --- /dev/null +++ b/Pywin32/lib/x32/win32com/HTML/variant.html @@ -0,0 +1,162 @@ + + ++win32com attempts to provide a seamless COM interface and hide many COM +implementation details, including the use of COM VARIANT structures. This +means that in most cases, you just call a COM object using normal Python +objects as parameters and get back normal Python objects as results. +
+ ++However, in some cases this doesn't work very well, particularly when using +"dynamic" (aka late-bound) objects, or when using "makepy" (aka early-bound) +objects which only declare a parameter is a VARIANT. +
+ +
+The win32com.client.VARIANT object is designed to overcome these
+problems.
+
win32com.client. The constructor
+takes 2 parameters - the 'variant type' and the value. The 'variant type' is
+an integer and can be one or more of the pythoncom.VT_* values,
+possibly or'd together.
+
+For example, to create a VARIANT object which defines a byref array of +32bit integers, you could use: + +
+>>> from win32com.client import VARIANT +>>> import pythoncom +>>> v = VARIANT(pythoncom.VT_BYREF | pythoncom.VT_ARRAY | pythoncom.VT_I4, +... [1,2,3,4]) +>>> v +win32com.client.VARIANT(24579, [1, 2, 3, 4]) +>>> ++ +This variable can then be used whereever a COM VARIANT is expected. + +
PyCOMTest.PyCOMTest. This object defines a method which is
+defined in IDL as:
++HRESULT DoubleInOutString([in,out] BSTR *str); ++ +As you can see, it takes a single string parameter which is also used as +an "out" parameter - the single parameter will be updated after the call. +The implementation of the method simply "doubles" the string. + +
If the object has a type-library, this method works fine with makepy +generated support. For example: + +
+>>> from win32com.client.gencache import EnsureDispatch
+>>> ob = EnsureDispatch("PyCOMTest.PyCOMTest")
+>>> ob.DoubleInOutString("Hello")
+u'HelloHello'
+>>>
+
+
+However, if makepy support is not available the method does not work as
+expected. For the next example we will use DumbDispatch to
+simulate the object not having a type-library.
+
+
+>>> import win32com.client.dynamic
+>>> ob = win32com.client.dynamic.DumbDispatch("PyCOMTest.PyCOMTest")
+>>> ob.DoubleInOutString("Hello")
+>>>
+
+
+As you can see, no result came back from the function. This is because
+win32com has no type information available to use, so doesn't know the
+parameter should be passed as a byref parameter. To work
+around this, we can use the VARIANT object.
+
+The following example explicitly creates a VARIANT object with a +variant type of a byref string and a value 'Hello'. After making the +call with this VARIANT the value is updated. + +
+>>> import win32com.client.dynamic
+>>> from win32com.client import VARIANT
+>>> import pythoncom
+>>> ob = win32com.client.dynamic.DumbDispatch("PyCOMTest.PyCOMTest")
+>>> variant = VARIANT(pythoncom.VT_BYREF | pythoncom.VT_BSTR, "Hello")
+>>> variant.value # check the value before the call.
+'Hello'
+>>> ob.DoubleInOutString(variant)
+>>> variant.value
+u'HelloHello'
+>>>
+
+
++HRESULT DoSomething([in] VARIANT value); ++ +But also imagine that the object has a limitation that if the parameter is an +integer, it must be a 32bit unsigned value - any other integer representation +will fail. + +
If you just pass a regular Python integer to this function, it will
+generally be passed as a 32bit signed integer and given the limitation above,
+will fail. The VARIANT object allows you to work around the limitation - just
+create a variant object VARIANT(pythoncom.VT_UI4, int_value) and
+pass that - the function will then be called with the explicit type you
+specified and will succeed.
+
+
Note that you can not use a VARIANT object to override the types described
+in a type library. If a makepy generated class specifies that a VT_UI2 is
+expected, attempting to pass a VARIANT object will fail. In this case you
+would need to hack around the problem. For example, imagine ob
+was a COM object which a method called foo and you wanted to
+override the type declaration for foo by passing a VARIANT.
+You could do something like:
+
+
+>>> import win32com.client.dynamic +>>> from win32com.client import VARIANT +>>> import pythoncom +>>> dumbob = win32com.client.dynamic.DumbDispatch(ob) +>>> variant = VARIANT(pythoncom.VT_BYREF | pythoncom.VT_BSTR, "Hello") +>>> dumbob.foo(variant) ++ +The code above converts the makepy supported
ob into a
+'dumb' (ie, non-makepy supported) version of the object, which will then
+allow you to use VARIANT objects for the problematic methods.
+
+
+
diff --git a/Pywin32/lib/x32/win32com/License.txt b/Pywin32/lib/x32/win32com/License.txt
new file mode 100644
index 0000000..6c1884e
--- /dev/null
+++ b/Pywin32/lib/x32/win32com/License.txt
@@ -0,0 +1,30 @@
+Unless stated in the specfic source file, this work is
+Copyright (c) 1996-2008, Greg Stein and Mark Hammond.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the distribution.
+
+Neither names of Greg Stein, Mark Hammond nor the name of contributors may be used
+to endorse or promote products derived from this software without
+specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
+IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/Pywin32/lib/x32/win32com/__init__.py b/Pywin32/lib/x32/win32com/__init__.py
new file mode 100644
index 0000000..97b2d39
--- /dev/null
+++ b/Pywin32/lib/x32/win32com/__init__.py
@@ -0,0 +1,120 @@
+#
+# Initialization for the win32com package
+#
+
+import win32api, sys, os
+import pythoncom
+
+# flag if we are in a "frozen" build.
+_frozen = getattr(sys, "frozen", 1==0)
+# pythoncom dumbly defaults this to zero - we believe sys.frozen over it.
+if _frozen and not getattr(pythoncom, "frozen", 0):
+ pythoncom.frozen = sys.frozen
+
+# Add support for an external "COM Extensions" path.
+# Concept is that you can register a seperate path to be used for
+# COM extensions, outside of the win32com directory. These modules, however,
+# look identical to win32com built-in modules.
+# This is the technique that we use for the "standard" COM extensions.
+# eg "win32com.mapi" or "win32com.axscript" both work, even though they do not
+# live under the main win32com directory.
+__gen_path__ = ''
+__build_path__ = None
+### TODO - Load _all_ \\Extensions subkeys - for now, we only read the default
+### Modules will work if loaded into "win32comext" path.
+
+def SetupEnvironment():
+ HKEY_LOCAL_MACHINE = -2147483646 # Avoid pulling in win32con for just these...
+ KEY_QUERY_VALUE = 0x1
+ # Open the root key once, as this is quite slow on NT.
+ try:
+ keyName = "SOFTWARE\\Python\\PythonCore\\%s\\PythonPath\\win32com" % sys.winver
+ key = win32api.RegOpenKey(HKEY_LOCAL_MACHINE , keyName, 0, KEY_QUERY_VALUE)
+ except (win32api.error, AttributeError):
+ key = None
+
+ try:
+ found = 0
+ if key is not None:
+ try:
+ __path__.append( win32api.RegQueryValue(key, "Extensions" ))
+ found = 1
+ except win32api.error:
+ # Nothing registered
+ pass
+ if not found:
+ try:
+ __path__.append( win32api.GetFullPathName( __path__[0] + "\\..\\win32comext") )
+ except win32api.error:
+ # Give up in disgust!
+ pass
+
+ # For the sake of developers, we also look up a "BuildPath" key
+ # If extension modules add support, we can load their .pyd's from a completely
+ # different directory (see the comments below)
+ try:
+ if key is not None:
+ global __build_path__
+ __build_path__ = win32api.RegQueryValue(key, "BuildPath")
+ __path__.append(__build_path__)
+ except win32api.error:
+ # __build_path__ neednt be defined.
+ pass
+ global __gen_path__
+ if key is not None:
+ try:
+ __gen_path__ = win32api.RegQueryValue(key, "GenPath")
+ except win32api.error:
+ pass
+ finally:
+ if key is not None:
+ key.Close()
+
+# A Helper for developers. A sub-package's __init__ can call this help function,
+# which allows the .pyd files for the extension to live in a special "Build" directory
+# (which the win32com developers do!)
+def __PackageSupportBuildPath__(package_path):
+ # See if we have a special directory for the binaries (for developers)
+ if not _frozen and __build_path__:
+ package_path.append(__build_path__)
+
+if not _frozen:
+ SetupEnvironment()
+
+# If we don't have a special __gen_path__, see if we have a gen_py as a
+# normal module and use that (ie, "win32com.gen_py" may already exist as
+# a package.
+if not __gen_path__:
+ try:
+ import win32com.gen_py
+ # hrmph - 3.3 throws: TypeError: '_NamespacePath' object does not support indexing
+ # attempting to get __path__[0] - but I can't quickly repro this stand-alone.
+ # Work around it by using an iterator.
+ __gen_path__ = next(iter(sys.modules["win32com.gen_py"].__path__))
+ except ImportError:
+ # If a win32com\gen_py directory already exists, then we use it
+ # (gencache doesn't insist it have an __init__, but our __import__
+ # above does!
+ __gen_path__ = os.path.abspath(os.path.join(__path__[0], "gen_py"))
+ if not os.path.isdir(__gen_path__):
+ # We used to dynamically create a directory under win32com -
+ # but this sucks. If the dir doesn't already exist, we we
+ # create a version specific directory under the user temp
+ # directory.
+ __gen_path__ = os.path.join(
+ win32api.GetTempPath(), "gen_py",
+ "%d.%d" % (sys.version_info[0], sys.version_info[1]))
+
+# we must have a __gen_path__, but may not have a gen_py module -
+# set that up.
+if "win32com.gen_py" not in sys.modules:
+ # Create a "win32com.gen_py", but with a custom __path__
+ import imp
+ gen_py = imp.new_module("win32com.gen_py")
+ gen_py.__path__ = [ __gen_path__ ]
+ sys.modules[gen_py.__name__]=gen_py
+ del imp
+gen_py = sys.modules["win32com.gen_py"]
+
+# get rid of these for module users
+del os, sys, win32api, pythoncom
diff --git a/Pywin32/lib/x32/win32com/client/CLSIDToClass.py b/Pywin32/lib/x32/win32com/client/CLSIDToClass.py
new file mode 100644
index 0000000..49f0cae
--- /dev/null
+++ b/Pywin32/lib/x32/win32com/client/CLSIDToClass.py
@@ -0,0 +1,53 @@
+"""Manages a dictionary of CLSID strings to Python classes.
+
+Primary use of this module is to allow modules generated by
+makepy.py to share classes. @makepy@ automatically generates code
+which interacts with this module. You should never need to reference
+this module directly.
+
+This module only provides support for modules which have been previously
+been imported. The gencache module provides some support for loading modules
+on demand - once done, this module supports it...
+
+As an example, the MSACCESS.TLB type library makes reference to the
+CLSID of the Database object, as defined in DAO3032.DLL. This
+allows code using the MSAccess wrapper to natively use Databases.
+
+This obviously applies to all cooperating objects, not just DAO and
+Access.
+"""
+mapCLSIDToClass = {}
+
+def RegisterCLSID( clsid, pythonClass ):
+ """Register a class that wraps a CLSID
+
+ This function allows a CLSID to be globally associated with a class.
+ Certain module will automatically convert an IDispatch object to an
+ instance of the associated class.
+ """
+
+ mapCLSIDToClass[str(clsid)] = pythonClass
+
+def RegisterCLSIDsFromDict( dict ):
+ """Register a dictionary of CLSID's and classes.
+
+ This module performs the same function as @RegisterCLSID@, but for
+ an entire dictionary of associations.
+
+ Typically called by makepy generated modules at import time.
+ """
+ mapCLSIDToClass.update(dict)
+
+def GetClass(clsid):
+ """Given a CLSID, return the globally associated class.
+
+ clsid -- a string CLSID representation to check.
+ """
+ return mapCLSIDToClass[clsid]
+
+def HasClass(clsid):
+ """Determines if the CLSID has an associated class.
+
+ clsid -- the string CLSID to check
+ """
+ return clsid in mapCLSIDToClass
diff --git a/Pywin32/lib/x32/win32com/client/__init__.py b/Pywin32/lib/x32/win32com/client/__init__.py
new file mode 100644
index 0000000..0abcd1a
--- /dev/null
+++ b/Pywin32/lib/x32/win32com/client/__init__.py
@@ -0,0 +1,539 @@
+# This module exists to create the "best" dispatch object for a given
+# object. If "makepy" support for a given object is detected, it is
+# used, otherwise a dynamic dispatch object.
+
+# Note that if the unknown dispatch object then returns a known
+# dispatch object, the known class will be used. This contrasts
+# with dynamic.Dispatch behaviour, where dynamic objects are always used.
+
+import pythoncom
+from . import dynamic
+from . import gencache
+import sys
+import pywintypes
+
+_PyIDispatchType = pythoncom.TypeIIDs[pythoncom.IID_IDispatch]
+
+
+def __WrapDispatch(dispatch, userName = None, resultCLSID = None, typeinfo = None, \
+ UnicodeToString=None, clsctx = pythoncom.CLSCTX_SERVER,
+ WrapperClass = None):
+ """
+ Helper function to return a makepy generated class for a CLSID if it exists,
+ otherwise cope by using CDispatch.
+ """
+ assert UnicodeToString is None, "this is deprecated and will go away"
+ if resultCLSID is None:
+ try:
+ typeinfo = dispatch.GetTypeInfo()
+ if typeinfo is not None: # Some objects return NULL, some raise exceptions...
+ resultCLSID = str(typeinfo.GetTypeAttr()[0])
+ except (pythoncom.com_error, AttributeError):
+ pass
+ if resultCLSID is not None:
+ from . import gencache
+ # Attempt to load generated module support
+ # This may load the module, and make it available
+ klass = gencache.GetClassForCLSID(resultCLSID)
+ if klass is not None:
+ return klass(dispatch)
+
+ # Return a "dynamic" object - best we can do!
+ if WrapperClass is None: WrapperClass = CDispatch
+ return dynamic.Dispatch(dispatch, userName, WrapperClass, typeinfo, clsctx=clsctx)
+
+
+def GetObject(Pathname = None, Class = None, clsctx = None):
+ """
+ Mimic VB's GetObject() function.
+
+ ob = GetObject(Class = "ProgID") or GetObject(Class = clsid) will
+ connect to an already running instance of the COM object.
+
+ ob = GetObject(r"c:\blah\blah\foo.xls") (aka the COM moniker syntax)
+ will return a ready to use Python wrapping of the required COM object.
+
+ Note: You must specifiy one or the other of these arguments. I know
+ this isn't pretty, but it is what VB does. Blech. If you don't
+ I'll throw ValueError at you. :)
+
+ This will most likely throw pythoncom.com_error if anything fails.
+ """
+ if clsctx is None:
+ clsctx = pythoncom.CLSCTX_ALL
+
+ if (Pathname is None and Class is None) or \
+ (Pathname is not None and Class is not None):
+ raise ValueError("You must specify a value for Pathname or Class, but not both.")
+
+ if Class is not None:
+ return GetActiveObject(Class, clsctx)
+ else:
+ return Moniker(Pathname, clsctx)
+
+def GetActiveObject(Class, clsctx = pythoncom.CLSCTX_ALL):
+ """
+ Python friendly version of GetObject's ProgID/CLSID functionality.
+ """
+ resultCLSID = pywintypes.IID(Class)
+ dispatch = pythoncom.GetActiveObject(resultCLSID)
+ dispatch = dispatch.QueryInterface(pythoncom.IID_IDispatch)
+ return __WrapDispatch(dispatch, Class, resultCLSID = resultCLSID, clsctx = clsctx)
+
+def Moniker(Pathname, clsctx = pythoncom.CLSCTX_ALL):
+ """
+ Python friendly version of GetObject's moniker functionality.
+ """
+ moniker, i, bindCtx = pythoncom.MkParseDisplayName(Pathname)
+ dispatch = moniker.BindToObject(bindCtx, None, pythoncom.IID_IDispatch)
+ return __WrapDispatch(dispatch, Pathname, clsctx=clsctx)
+
+def Dispatch(dispatch, userName = None, resultCLSID = None, typeinfo = None, UnicodeToString=None, clsctx = pythoncom.CLSCTX_SERVER):
+ """Creates a Dispatch based COM object.
+ """
+ assert UnicodeToString is None, "this is deprecated and will go away"
+ dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,clsctx)
+ return __WrapDispatch(dispatch, userName, resultCLSID, typeinfo, clsctx=clsctx)
+
+def DispatchEx(clsid, machine=None, userName = None, resultCLSID = None, typeinfo = None, UnicodeToString=None, clsctx = None):
+ """Creates a Dispatch based COM object on a specific machine.
+ """
+ assert UnicodeToString is None, "this is deprecated and will go away"
+ # If InProc is registered, DCOM will use it regardless of the machine name
+ # (and regardless of the DCOM config for the object.) So unless the user
+ # specifies otherwise, we exclude inproc apps when a remote machine is used.
+ if clsctx is None:
+ clsctx = pythoncom.CLSCTX_SERVER
+ if machine is not None: clsctx = clsctx & ~pythoncom.CLSCTX_INPROC
+ if machine is None:
+ serverInfo = None
+ else:
+ serverInfo = (machine,)
+ if userName is None: userName = clsid
+ dispatch = pythoncom.CoCreateInstanceEx(clsid, None, clsctx, serverInfo, (pythoncom.IID_IDispatch,))[0]
+ return Dispatch(dispatch, userName, resultCLSID, typeinfo, clsctx=clsctx)
+
+class CDispatch(dynamic.CDispatch):
+ """
+ The dynamic class used as a last resort.
+ The purpose of this overriding of dynamic.CDispatch is to perpetuate the policy
+ of using the makepy generated wrapper Python class instead of dynamic.CDispatch
+ if/when possible.
+ """
+ def _wrap_dispatch_(self, ob, userName = None, returnCLSID = None, UnicodeToString=None):
+ assert UnicodeToString is None, "this is deprecated and will go away"
+ return Dispatch(ob, userName, returnCLSID,None)
+
+def CastTo(ob, target):
+ """'Cast' a COM object to another interface"""
+ # todo - should support target being an IID
+ if hasattr(target, "index"): # string like
+ # for now, we assume makepy for this to work.
+ if "CLSID" not in ob.__class__.__dict__:
+ # Eeek - no makepy support - try and build it.
+ ob = gencache.EnsureDispatch(ob)
+ if "CLSID" not in ob.__class__.__dict__:
+ raise ValueError("Must be a makepy-able object for this to work")
+ clsid = ob.CLSID
+ # Lots of hoops to support "demand-build" - ie, generating
+ # code for an interface first time it is used. We assume the
+ # interface name exists in the same library as the object.
+ # This is generally the case - only referenced typelibs may be
+ # a problem, and we can handle that later. Maybe
This is the readme for win32com. Please check out the win32com documentation index
+ +The win32com/test directory contains some interesting + scripts (and a new readme.txt). Although these + are used for testing, they do show a variety of COM techniques.
+ +win32com.client now has explicit VARIANT objects which can be used in
+situations where you need more control over the argument types passed when
+calling COM methods. See the documentation on
+this object
+
+Important Currency changes
+
+In all builds prior to 204, a COM currency value was returned as a tuple of +integers. Working with 2 integers to represent a currency object was a poor +choice, but the alternative was never clear. Now Python ships with the +decimal +module, the alternative has arrived! +
+
+Up until build 212, code could set pythoncom.__future_currency__ = True
+to force use of the decimal module, with a warning issued otherwise. In
+builds 213 and later, the decimal module is unconditionally used when
+pythoncon returns you a currency value.
+
+Python 2.3 does not ship with a decimal module. For this reason,
+win32com/decimal_23.py is supplied with pywin32. This is a clone of the decimal
+module, but will only be used when import decimal fails. If you
+want to use this functionality in your Python 2.3 programs, you should write
+something similar to:
+
+ try:
+ import decimal
+ except ImportError:
+ import win32com.decimal_23 as decimal
+ val = decimal.Decimal("123.45")
+
+
+
+Python only supports "trusted" execution hosts - thus, it will no longer work +as an engine inside IE (Python itself no longer has a restricted execution environment). +Python continues to work fine as an Active Scripting Engine in all other +applications, including Windows Scripting Host, and ASP. + +
There is also support for Python as an ActiveX Scripting Host.
+ +Active Debugging seems to be fully functional.
+ +| Browser | <%=bc.browser %> + |
| Version | <%=bc.version %> |
| Frames | +<%Response.Write( iif(bc.frames, "TRUE", "FALSE")) %> |
| Tables | +<%Response.Write( iif (bc.tables, "TRUE", "FALSE")) %> |
| BackgroundSounds | +<%Response.Write( iif(bc.BackgroundSounds, "TRUE", "FALSE"))%> |
| VBScript | +<%Response.Write( iif(bc.vbscript, "TRUE", "FALSE"))%> |
| JavaScript | +<%Response.Write( iif(bc.javascript, "TRUE", "FALSE"))%> |
+
+
Python AX Script Engine
+
Demo using the Marquee Control
+
Mark Hammond.
+
+
This is really quite a boring demo, as the Marquee control does everything. However, there is Python code behind the buttons that change the speed. This code is all of 2 lines per button!!! + +
For more information on Python as an ActiveX scripting language, see + +
Python
+
http://www.python.org
+
+
The Python ActiveX Scripting Engine is not currently registered.
+ +
Due to a privacy +concern discovered in the engine, the use of Python inside IE has been disabled.
+ +Before any of the supplied demos will work, the engine must be successfully registered. + +To install a version of the engine, that does work with IE, you can execute the Python program
+win32com\axscript\client\pyscript_rexec.py must be run. You can either do this manually, or follow the instructions below.
If you have read about the privacy +concern and still wish to register the engine, just follow the process outlined below:
+Congratulations on installing the Python ActiveX Scripting Engine
+ +Be warned that there is a privacy +concern with this engine. Please read this information, including how to disable the feature.
+ + +Except as described below, the object module exposed should be similar to that exposed +by Visual Basic, etc. Due to the nature of ActiveX Scripting, the details for each +host are different, but Python should work "correctly". + +
The object model exposed via Python for MSIE is not as seamless as VB. The biggest limitation is
+the concept of a "local" namespace. For example, in VB, you can
+code text="Hi there", but in Python, you must code
+MyForm.ThisButton.Text="Hi There". See the foo2 sample
+for futher details.
+
+
This release seems to have broken Aaron's mouse-trace sample. No idea why, and Im supposed to be looking into it. +
Builtin objects such as MARQUEE are giving me grief. Objects accessed via forms are generally +no problem. +
If you are trying to use Python with the Windows Scripting Host, note that +.pys files are not correct registered - you will need to explicitely +specify either cscript.exe or wscript.exe on the command line. +
An Introduction to the +scripting engine. + +
The Calculator Demo is a very +cool sample written by Aaron Watters. + +
Mouse track is another of +Aaron's samples, and shows how fast the Python engine is! + +
The foo2 sample is mainly used +for debugging and testing, but does show some forms in action. + + diff --git a/Pywin32/lib/x32/win32comext/axscript/Demos/client/ie/docwrite.htm b/Pywin32/lib/x32/win32comext/axscript/Demos/client/ie/docwrite.htm new file mode 100644 index 0000000..c95b790 --- /dev/null +++ b/Pywin32/lib/x32/win32comext/axscript/Demos/client/ie/docwrite.htm @@ -0,0 +1,25 @@ + +
+A page generated by Python + + + + + + + diff --git a/Pywin32/lib/x32/win32comext/axscript/Demos/client/ie/foo2.htm b/Pywin32/lib/x32/win32comext/axscript/Demos/client/ie/foo2.htm new file mode 100644 index 0000000..d5e0c4a --- /dev/null +++ b/Pywin32/lib/x32/win32comext/axscript/Demos/client/ie/foo2.htm @@ -0,0 +1,105 @@ + + + + + + + +The caption on the first button is set by the Window Load code. Clicking +that button changes the text in the first edit box. + +
The second button changes its own text when clicked. + +
The fourth button calls a global function, defined in the global 'script' scope, +rather than the 'MyForm' scope. + +
+And here is a second form +
+