pywin32-bugs — Automated tracker notifications (not for bug reports!)

[pywin32-bugs] [ pywin32-Bugs-1273738 ] atexit not called for pythonservice (win32)

[SourceForge.net <no...@so...>]

Bugs item #1273738, was opened at 2005-08-25 21:52
Message generated for change (Comment added) made by woodsplitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1273738&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hari Krishna Dara (haridsv)
Assigned to: Nobody/Anonymous (nobody)
Summary: atexit not called for pythonservice (win32)

Initial Comment:
I have a couple of functions registered with atexit
which work fine when the program is executed on
command-line. But when I run the same as a windows
service, and stop the service using service interface,
these hooks never get call backs. The service does exit
normally (at least my program doesn't do os._exit() and
there are no exceptions).

I am using ActiveState's distribution of python, but I
would imagine this is non-specific. Here is the version
information:

ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on
Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310
32 bit (Intel)] on win32

As a workaround I am calling the
atexit._run_exitfuncs() manually before returning from
SvcDoRun() for now.

----------------------------------------------------------------------

Comment By: David S. Rushby (woodsplitter)
Date: 2006-01-12 13:50

Message:
Logged In: YES 
user_id=414645

I wonder if this bug is related to the following issue?
http://groups.google.com/group/comp.lang.python/browse_thread/thread/fe9e426650764ed9/972ecadc2d6fcf5b#972ecadc2d6fcf5b

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1273738&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1404103 ] patch to setup.py for adsi build

[SourceForge.net <no...@so...>]

Patches item #1404103, was opened at 2006-01-12 18:29
Message generated for change (Settings changed) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Trent Mick (tmick)
>Assigned to: Mark Hammond (mhammond)
Summary: patch to setup.py for adsi build

Initial Comment:
Mark,

I've found that the pywin32 build always fails while
building the 'adsi' extension with the following error
unless I add user32.lib and advapi32.lib to the setup
of libraries for it (patch attached).

-----------------------------------------------------
  Creating library
build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.l
ib and object
build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.exp
PyADSIUtil.obj : error LNK2019: unresolved external
symbol __imp__wsprintfA refe
renced in function "struct _object * __cdecl
PyADSIObject_FromADSVALUE(struct _a
dsvalue &)"
(?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_adsvalue@@@Z)
PyADSIUtil.obj : error LNK2019: unresolved external
symbol __imp__GetSecurityDes
criptorLength@4 referenced in function "struct _object
* __cdecl PyADSIObject_Fr
omADSVALUE(struct _adsvalue &)"
(?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_a
dsvalue@@@Z)
build\lib.win32-2.4\win32comext/adsi\adsi.pyd : fatal
error LNK1120: 2 unresolve
d externals
error: command '"C:\Program Files\Microsoft Visual
Studio .NET 2003\Vc7\bin\link
.exe"' failed with exit status 1120
-----------------------------------------------------

My build is on Win2k with the "Windows Server 2003 SP1
SDK" (the latest according to
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/).

I presume you (and Roger and others) don't have the
same local patch in your setup.py so I'm not sure what
the difference is that you can build and I cannot.

Thoughts on add this patch?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1404103 ] patch to setup.py for adsi build

[SourceForge.net <no...@so...>]

Patches item #1404103, was opened at 2006-01-12 18:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch to setup.py for adsi build

Initial Comment:
Mark,

I've found that the pywin32 build always fails while
building the 'adsi' extension with the following error
unless I add user32.lib and advapi32.lib to the setup
of libraries for it (patch attached).

-----------------------------------------------------
  Creating library
build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.l
ib and object
build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.exp
PyADSIUtil.obj : error LNK2019: unresolved external
symbol __imp__wsprintfA refe
renced in function "struct _object * __cdecl
PyADSIObject_FromADSVALUE(struct _a
dsvalue &)"
(?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_adsvalue@@@Z)
PyADSIUtil.obj : error LNK2019: unresolved external
symbol __imp__GetSecurityDes
criptorLength@4 referenced in function "struct _object
* __cdecl PyADSIObject_Fr
omADSVALUE(struct _adsvalue &)"
(?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_a
dsvalue@@@Z)
build\lib.win32-2.4\win32comext/adsi\adsi.pyd : fatal
error LNK1120: 2 unresolve
d externals
error: command '"C:\Program Files\Microsoft Visual
Studio .NET 2003\Vc7\bin\link
.exe"' failed with exit status 1120
-----------------------------------------------------

My build is on Win2k with the "Windows Server 2003 SP1
SDK" (the latest according to
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/).

I presume you (and Roger and others) don't have the
same local patch in your setup.py so I'm not sure what
the difference is that you can build and I cannot.

Thoughts on add this patch?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1361822 ] crash when or after importing scipy - Build 205

[SourceForge.net <no...@so...>]

Bugs item #1361822, was opened at 2005-11-19 19:36
Message generated for change (Comment added) made by cjwhrh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash when or after importing scipy - Build 205

Initial Comment:
This has happened a number of times but I haven't been
able to pin it down to more than the fact it occurs
when attempting to debug a program using scipy.

If the code is executed first, then one can step
through it.  In this case a crash often occurs eventually.

The crash report is the instruction "0x7c168f1d" could
not read "0x0000001c"

Colin W.

----------------------------------------------------------------------

>Comment By: Colin J. Williams (cjwhrh)
Date: 2006-01-11 20:09

Message:
Logged In: YES 
user_id=285587

Mark,

Attached is the script ugh1.py
If I Run, the results are as expected.
If I Step into, 
stepover (the print command)
Step into the import command and continue stepping into, we
crash on the umath reference.

I've had similar problems with Boa-Contructor and PyScripter.

I hope that this helps.

Best wishes,

Colin W.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 00:07

Message:
Logged In: YES 
user_id=14198

Can you please provide instructions on how I can reproduce it?

Cheers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1397932 ] SHFileOperation - support sequence of names

[SourceForge.net <no...@so...>]

Feature Requests item #1397932, was opened at 2006-01-06 04:47
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1397932&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Klinik (brudermarkus)
>Assigned to: Roger Upole (rupole)
Summary: SHFileOperation - support sequence of names

Initial Comment:
Actually, replace the line 

PyErr_Format(PyExc_RuntimeError, "Sequences of names
not yet supported");

in com/win32comext/shell/src/shell.cpp
with useful code.

:)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-12 10:49

Message:
Logged In: YES 
user_id=14198

Thanks Roger - they both sound fine to me!

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-01-12 02:40

Message:
Logged In: YES 
user_id=771074

It might actually be easier to just let callers construct 
their own string with filenames separated by NULL's.
Interestingly, this would work right now except for the 
fact that _tcscpy is used which stops copying characters 
when it finds a NULL byte.  So basically, replace tcscpy
with memcpy and remove the sequence check altogether.  
It'll take longer to put together a test case than it will 
to change the C++ code.  Mark, if you're okay with this 
I'll go ahead and do it.

Alternately, win32api already has code to create a double-
null terminated sequence of strings for REG_MULTI_SZ.  We 
could move it into pywintypes so it's available for 
anyplace else this type of string is used.

         Roger


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1397932&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-716708 ] pythonwin editor does strange things with non-english chars

[SourceForge.net <no...@so...>]

Bugs item #716708, was opened at 2003-04-07 14:43
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=716708&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: pythonwin editor does strange things with non-english chars

Initial Comment:
Reported by a few people, but to repro:
* Paste "# ça ne va pas" into pywin (or any other
string with extended char)
* Move to the ç
* Press Backspace

Some other character appears.  This will be related to
pywin.idle not being mult-character aware.

----------------------------------------------------------------------

Comment By: Robert Kiendl (kxroberto)
Date: 2006-01-11 17:31

Message:
Logged In: YES 
user_id=972995

pywin build 203
From News Message-ID:
<113...@g4...>

Neil Hodgson schrieb:
> Robert:
>     PythonWin did have some Unicode support but I think
Mark Hammond was
> discouraged by bugs. In pythonwin/__init__.py there is a
setting
> is_platform_unicode = 0 with a commented out real test for
Unicode on
> the next line. Change this to 1 and restart and you may see
>
>  >>> x = u'sytest3\\\u041f\u043e\u0448\u0443\u043a.txt'
>  >>> print x
> sytest3\Пошук.txt
>  >>>

thanks for that hint. But found that it is still not
consistent or even
buggy:

After "is_platform_unicode = <auto>", scintilla displays
some unicode
as you showed. but the win32-functions (e.g. MessageBox)
still do not
pass through wide unicode. And pasting/inserting/parsing in
scintilla
doesn't work correct:

PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC v.1200 32 bit
(Intel)] on win32.
Portions Copyright 1994-2004 Mark Hammond
(mha...@sk...) -
see 'Help/About PythonWin' for further copyright information.
>>> x = u'sytest3\\\u041f\u043e\u0448\u0443\u043a.txt'
>>> print x
sytest3\Пошук.txt
>>> print "sytest3\Пошук.txt"
sytest3\?????.txt

!!!

--------

Then tried in __init__.py to do more uft-8:

default_platform_encoding = "utf-8"  #"mbcs" # Will it ever
...this?
default_scintilla_encoding = "utf-8" # Scintilla _only_
supports this
ATM

Pasting around in scintilla then works correct. But
MessageBox then
shows plain utf-8 encoded chars. Even german umlauts are not
displayable any more on my machine and when opening document
files with
above-128 chars, Pythonwin breaks (because files are not
valid utf-8
streams, I guess):

>>> Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\document.py",
line 27, in OnOpenDocument
    text = f.read()
  File "C:\Python23\lib\codecs.py", line 380, in read
    return self.reader.read(size)
  File "C:\Python23\lib\codecs.py", line 253, in read
    return self.decode(self.stream.read(), self.errors)[0]
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa9 in
position
19983: unexpected code byte
win32ui: OnOpenDocument() virtual handler (<bound method
SyntEditDocument.OnOpenDocument of
<pywin.framework.editor.color.coloreditor.SyntEditDocument
instance at
0x00E356E8>>) raised an exception


Thus the result is: no combination provides a real
improvement so far.
wide unicode in win32-functions is obviously not possible at
all.  I
switch back to the original setup.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 10:48

Message:
Logged In: YES 
user_id=14198

Had a couple of reports that this is fixed in build 200 :)

----------------------------------------------------------------------

Comment By: Kanich Vladimir (kanich)
Date: 2004-02-26 08:13

Message:
Logged In: YES 
user_id=304670

With the solution described by oleg_noga (replacing of 
scintilla.dll) I tried to edit full string of special Slovak and 
Czech characters (codepage Cp1250) in PythonWin editor 
with full success. Thank you for the solution. N.B. Backspace 
operation in this arragement needs twice to push BACKSPACE 
key.

----------------------------------------------------------------------

Comment By: Oleg Noga (oleg_noga)
Date: 2004-02-25 16:02

Message:
Logged In: YES 
user_id=551440

view.py, KeyDotEvent() allways generates "." but it can be 
non-english character instead of "."!

----------------------------------------------------------------------

Comment By: Oleg Noga (oleg_noga)
Date: 2004-02-25 15:32

Message:
Logged In: YES 
user_id=551440

Bug has a solution: editor does not display characters after 
non-english (see followup by anadelonbrin, 2003-05-09 10:38)

Solution is to replase scintilla.dll with latest version. Just 
download scintilla src from sourcefourge, build it and replase 
scintilla.dll with SciLexer.dll (rename SciLexer.dll to 
scintilla.dll). 

It do not solves bugs with clipboard, backspace and Cyrillic 
small "u" ("&#1102;") letter.


----------------------------------------------------------------------

Comment By: Kanich Vladimir (kanich)
Date: 2004-01-22 09:33

Message:
Logged In: YES 
user_id=304670

I have same problem with encoding 'cp1250' (default encoding 
in sk/cz). Without changing __init__.py file (as recommended 
by hweber) the editor is swallowing the half of characters 
with char-code above 127. It seems that the used editor 
routine is byte-oriented and not UNICODE.
Setting the variable is_platform_unicode = 0 helps also for 
encoding 'cp1250'.

----------------------------------------------------------------------

Comment By: Henrik Weber (hweber)
Date: 2004-01-07 12:17

Message:
Logged In: YES 
user_id=121229

This behaviour can be worked around by switching off unicode 
support. The easiest way to do this is in the __init__.py file.

Replace the line beginning with is_platform_unicode by this:
is_platform_unicode = 0

With this pythonwin works normally at least with the german 
umlauts (I haven't tried the other ones).

----------------------------------------------------------------------

Comment By: Henrik Weber (hweber)
Date: 2004-01-07 12:16

Message:
Logged In: YES 
user_id=121229

This behaviour can be worked around by switching off unicode 
support. The easiest way to do this is in the __init__.py file.

Replace the line beginning with is_platform_unicode by this:
is_platform_unicode = 0

With this pythonwin works normally at least with the german 
umlauts (I haven't tried the other ones).

----------------------------------------------------------------------

Comment By: Gilles Lenfant (glenfant)
Date: 2003-11-28 15:53

Message:
Logged In: YES 
user_id=122383

Same strange charset behaviour when copying text (with non
ASCCI chars) from pythonwin to a regular text editor
(notepad or any other).

It seems that pythonwin copies utf-8 to the clipboard rather
than &quot;natural&quot; default encoding (cp1252 for western european
languages).


----------------------------------------------------------------------

Comment By: Oleg Noga (oleg_noga)
Date: 2003-08-18 16:08

Message:
Logged In: YES 
user_id=551440

So there are 3 bugs:
------------
First bug (this report, 716708):

Incorrect work of backspace. (Del works ok). I must press 
backspace two times to remove non-english character. This 
bug presents in every version of pythonwin from 1.46, and 
very probably, in the earlier versions.
------------

Second bug (see followup by anadelonbrin, 2003-05-09 10:38
):

Editor does not display characters after non-english.
Another reproduces: 
- open py file with non-english strings, encoded with system 
default encoding. Look at non-english strings in editor: editor 
does not display string ends! Now move cursor at the begin of 
string and move it with right arrow button. Cursor stucks at 
the end of string, and lefts there for click count that equals 
invisible characters count. Move cursor to the inwisible end of 
string. Now type english characters: qwertyu... Invisible end 
of string will apear, but newly typed characters (qwertyu...) 
still not visible. Save file. Look in notepad. Document data is 
ok.
  So this bug is how pythonwin displays strings in editor, it 
does not affect document data.

There was no bug like this in version 1.48, we still use it. But 
it present in earlier versions (1.50 ... 1.55).
--------------

Third bug (seems unreported yet): 

Can't type \xFE character in editor. It is &quot;&amp;#1102;&quot; (Cyrillic small &quot;u&quot;) 
letter. Dot typed instead of this character. Interesting that 
dot in at the same keybord button as Cyrillic small &quot;u&quot; letter.  
Editor opens files with this character, displays them correctly, 
and removes and copies them ok.
This bug presents in every version of pythonwin from 1.46, 
and very probably, in the earlier versions.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-05-09 09:38

Message:
Logged In: YES 
user_id=552329

As another example:

In IDLE (0.8):
&gt;&gt;&gt; u = u'questa \xe8 bella'
&gt;&gt;&gt; u
u'questa \xe8 bella'
&gt;&gt;&gt; print u
questa è bella

In PythonWin (152):
&gt;&gt;&gt; u = u'questa \xe8 bella'
&gt;&gt;&gt; u
u'questa \xe8 bella'
&gt;&gt;&gt; print u
questa è bell

(note that if you copy the result of the 'print u', or type 
something after it, the a appears.  *very* confusing!)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=716708&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1397932 ] SHFileOperation - support sequence of names

[SourceForge.net <no...@so...>]

Feature Requests item #1397932, was opened at 2006-01-05 12:47
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1397932&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Klinik (brudermarkus)
Assigned to: Nobody/Anonymous (nobody)
Summary: SHFileOperation - support sequence of names

Initial Comment:
Actually, replace the line 

PyErr_Format(PyExc_RuntimeError, "Sequences of names
not yet supported");

in com/win32comext/shell/src/shell.cpp
with useful code.

:)

----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2006-01-11 10:40

Message:
Logged In: YES 
user_id=771074

It might actually be easier to just let callers construct 
their own string with filenames separated by NULL's.
Interestingly, this would work right now except for the 
fact that _tcscpy is used which stops copying characters 
when it finds a NULL byte.  So basically, replace tcscpy
with memcpy and remove the sequence check altogether.  
It'll take longer to put together a test case than it will 
to change the C++ code.  Mark, if you're okay with this 
I'll go ahead and do it.

Alternately, win32api already has code to create a double-
null terminated sequence of strings for REG_MULTI_SZ.  We 
could move it into pywintypes so it's available for 
anyplace else this type of string is used.

         Roger


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1397932&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1377153 ] Improved Windows CE support

[SourceForge.net <no...@so...>]

Patches item #1377153, was opened at 2005-12-10 01:26
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Luke Dunstan (infidel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improved Windows CE support

Initial Comment:
Some changes to allow pywintypes, win32gui, 
win32event and win32process to compile for Windows 
CE. Tested with MS eMbedded Visual C++ 4.0 with the 
Pocket PC 2003 SDK.

This is still a work in progress.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-11 22:46

Message:
Logged In: YES 
user_id=14198

Your patch (appears to have :) changed CreateDC from a
'native' method to a SWIG one:

< // @pyswig int|CreateDC|Creates a device context for a
printer or display device
< %native (CreateDC) PyCreateDC;
...
> HDC CreateDC(TCHAR *INPUT_NULLOK, TCHAR *INPUT_NULLOK,
TCHAR *INPUT, DEVMODE *INPUT);

This created an extra param (that arguably should have been
included in the first place :)  I take responsibility for
this though - I should have applied it just after a release,
not just before one :) :(

----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2006-01-11 22:29

Message:
Logged In: YES 
user_id=30442

Can you tell me what the bug was with CreateDC() so I can 
avoid making the same mistake again?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 14:45

Message:
Logged In: YES 
user_id=14198

All checked in - thanks!

----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2005-12-16 02:48

Message:
Logged In: YES 
user_id=30442

Probably not soon.

I have a set of makefiles for building the parts of 
pywin32 I mentioned for WinCE (using MS eVC 4): would that 
be appropriate for submission? They are based on makefiles 
from the PythonCE project because pywin32 is distributed 
with it. I hope to eventually look at modifying distutils 
to eliminate the need for these makefiles but I have no 
idea how hard that will be. Failing that I would try 
writing a Python script (from scratch) to do it.

I also created a small module wince.pyd containing a bunch 
of WinCE-specific functions (actually mostly Pocket PC-
specific I think), but now that I have also finished 
porting ctypes to ARM-WinCE that module may be less 
necessary.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-12-14 08:49

Message:
Logged In: YES 
user_id=14198

Thanks for that.  When you submitted the patch, you
mentioned "This is still a work in progress."  Do you think
you will have an update any time soon?

----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2005-12-14 00:43

Message:
Logged In: YES 
user_id=30442

Yes, I tried to explain but not clearly enough. That 
particular #ifdef is incorrect, it should be like:

#ifndef MS_WINCE
    if (index==-1) {
        nicons = (int)ExtractIconEx(fname, index, NULL, 
NULL, 0);
        PyWinObject_FreeTCHAR(fname);
        return PyInt_FromLong(nicons);
    }
#endif

because -1 does not have this special meaning.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-12-13 08:39

Message:
Logged In: YES 
user_id=14198

I'm still not quite with you on the handling of the "-1,
NULL, NULL" case.  I agree that the docs are not
particularly clear, but I see nothing in the docs that means
you should force the result to 1 in that case - the way I
read it, your code will *always* return 1 in the "-1, NULL,
NULL" case, regardless of what Windows actually returned. 
Further, the comment appears incorrect - if the API actually
returns a HICON but your implementation always returns 1,
then presumably the hicon returned has been lost?

+#ifdef MS_WINCE
+        /* On WinCE >= 2.1 the API actually returns a HICON */
+        nicons = 1;
+#endif
+        PyWinObject_FreeTCHAR(fname);
         return PyInt_FromLong(nicons);


----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2005-12-13 02:19

Message:
Logged In: YES 
user_id=30442

* You are correct about the format string

* Regarding the return value:

"For Windows CE versions 2.10 and later, this function 
returns the handle to an icon. If both phiconLarge and 
phiconSmall are not NULL, the return value defaults to the 
large icon.

For Windows CE versions 1.0 through 2.01, this function 
returns a UINT data type. If the nIconIndex parameter is –
1, the phiconLarge parameter is NULL, and the phiconSmall 
parameter is NULL, then the return value is the number of 
icons contained in the specified file. Otherwise, the 
return value is the number of icons successfully extracted 
from the file."

My reading is that the whole of the second paragraph only 
applies to WinCE <= 2.01. The earlier description of 
nIconIndex supports this:

"For Windows CE versions 2.10 and later, the nIconIndex 
parameter must be zero or –N, where N is a specified 
resource identifier."

This implies that -1 means "the resource ID 1" for WinCE 
>= 2.10. This probably also means that my patch should 
have excluded the whole if(index==-1) { ... } block for 
MS_WINCE. Also, it would not make much sense to return the 
number of icons since nIcons must be 1.

In theory we could use #if to check the WinCE version but 
I prefer to leave that to someone who actually develops 
for old versions of WinCE.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-12-12 16:15

Message:
Logged In: YES 
user_id=14198

This looks quite good - thanks!  A few questions about
ExtractIconEx:
* It appears first char of the format string passed to
PyArg_ParseTuple should be changed from "s" to "O"?

* The block:
    if (index==-1) {
        nicons = (int)ExtractIconEx(fname, index, NULL,
NULL, 0);
#ifdef MS_WINCE
        /* On WinCE >= 2.1 the API actually returns a HICON */
        nicons = 1;
#endif

Isn't clear to me.  My reading of the MSDN documentation for
CE says that the (-1, NULL, NULL case does correctly return
the number of icons in the DLL.

Can you please clarify?

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1377153 ] Improved Windows CE support

[SourceForge.net <no...@so...>]

Patches item #1377153, was opened at 2005-12-09 22:26
Message generated for change (Comment added) made by infidel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Luke Dunstan (infidel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improved Windows CE support

Initial Comment:
Some changes to allow pywintypes, win32gui, 
win32event and win32process to compile for Windows 
CE. Tested with MS eMbedded Visual C++ 4.0 with the 
Pocket PC 2003 SDK.

This is still a work in progress.


----------------------------------------------------------------------

>Comment By: Luke Dunstan (infidel)
Date: 2006-01-11 19:29

Message:
Logged In: YES 
user_id=30442

Can you tell me what the bug was with CreateDC() so I can 
avoid making the same mistake again?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 11:45

Message:
Logged In: YES 
user_id=14198

All checked in - thanks!

----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2005-12-15 23:48

Message:
Logged In: YES 
user_id=30442

Probably not soon.

I have a set of makefiles for building the parts of 
pywin32 I mentioned for WinCE (using MS eVC 4): would that 
be appropriate for submission? They are based on makefiles 
from the PythonCE project because pywin32 is distributed 
with it. I hope to eventually look at modifying distutils 
to eliminate the need for these makefiles but I have no 
idea how hard that will be. Failing that I would try 
writing a Python script (from scratch) to do it.

I also created a small module wince.pyd containing a bunch 
of WinCE-specific functions (actually mostly Pocket PC-
specific I think), but now that I have also finished 
porting ctypes to ARM-WinCE that module may be less 
necessary.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-12-14 05:49

Message:
Logged In: YES 
user_id=14198

Thanks for that.  When you submitted the patch, you
mentioned "This is still a work in progress."  Do you think
you will have an update any time soon?

----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2005-12-13 21:43

Message:
Logged In: YES 
user_id=30442

Yes, I tried to explain but not clearly enough. That 
particular #ifdef is incorrect, it should be like:

#ifndef MS_WINCE
    if (index==-1) {
        nicons = (int)ExtractIconEx(fname, index, NULL, 
NULL, 0);
        PyWinObject_FreeTCHAR(fname);
        return PyInt_FromLong(nicons);
    }
#endif

because -1 does not have this special meaning.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-12-13 05:39

Message:
Logged In: YES 
user_id=14198

I'm still not quite with you on the handling of the "-1,
NULL, NULL" case.  I agree that the docs are not
particularly clear, but I see nothing in the docs that means
you should force the result to 1 in that case - the way I
read it, your code will *always* return 1 in the "-1, NULL,
NULL" case, regardless of what Windows actually returned. 
Further, the comment appears incorrect - if the API actually
returns a HICON but your implementation always returns 1,
then presumably the hicon returned has been lost?

+#ifdef MS_WINCE
+        /* On WinCE >= 2.1 the API actually returns a HICON */
+        nicons = 1;
+#endif
+        PyWinObject_FreeTCHAR(fname);
         return PyInt_FromLong(nicons);


----------------------------------------------------------------------

Comment By: Luke Dunstan (infidel)
Date: 2005-12-12 23:19

Message:
Logged In: YES 
user_id=30442

* You are correct about the format string

* Regarding the return value:

"For Windows CE versions 2.10 and later, this function 
returns the handle to an icon. If both phiconLarge and 
phiconSmall are not NULL, the return value defaults to the 
large icon.

For Windows CE versions 1.0 through 2.01, this function 
returns a UINT data type. If the nIconIndex parameter is –
1, the phiconLarge parameter is NULL, and the phiconSmall 
parameter is NULL, then the return value is the number of 
icons contained in the specified file. Otherwise, the 
return value is the number of icons successfully extracted 
from the file."

My reading is that the whole of the second paragraph only 
applies to WinCE <= 2.01. The earlier description of 
nIconIndex supports this:

"For Windows CE versions 2.10 and later, the nIconIndex 
parameter must be zero or –N, where N is a specified 
resource identifier."

This implies that -1 means "the resource ID 1" for WinCE 
>= 2.10. This probably also means that my patch should 
have excluded the whole if(index==-1) { ... } block for 
MS_WINCE. Also, it would not make much sense to return the 
number of icons since nIcons must be 1.

In theory we could use #if to check the WinCE version but 
I prefer to leave that to someone who actually develops 
for old versions of WinCE.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-12-12 13:15

Message:
Logged In: YES 
user_id=14198

This looks quite good - thanks!  A few questions about
ExtractIconEx:
* It appears first char of the format string passed to
PyArg_ParseTuple should be changed from "s" to "O"?

* The block:
    if (index==-1) {
        nicons = (int)ExtractIconEx(fname, index, NULL,
NULL, 0);
#ifdef MS_WINCE
        /* On WinCE >= 2.1 the API actually returns a HICON */
        nicons = 1;
#endif

Isn't clear to me.  My reading of the MSDN documentation for
CE says that the (-1, NULL, NULL case does correctly return
the number of icons in the DLL.

Can you please clarify?

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1398756 ] ReadFile returns trash when using overlapped io on namedpipe

[SourceForge.net <no...@so...>]

Bugs item #1398756, was opened at 2006-01-07 05:47
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: ReadFile returns trash when using overlapped io on namedpipe

Initial Comment:
This bug demonstration probably looks familiar if you 
read svcbug.py - however it is a different bug.

win32file.ReadFile seems to be returning as much data 
as is requested (only when using overlapped io) even 
if that much data is not actually available. The extra 
data is random trash. This same operation in C does 
not act this way.

running "ovbug.py s" starts a correct server 
and "ovbug.py s bug" starts a buggy server.
running "ovbug.py c" starts a client

You'll also notice that PeekNamedPipe seems to 
indicate the correct situation.



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-11 09:22

Message:
Logged In: YES 
user_id=14198

It appears that sample uses strlen() to determine how much
to write.

I'm not sure what you are asking for.  ReadFile simply
returns the exact same buffer that was passed to it.  If you
were writing this in C and passing (say) an 8k buffer to the
function, there must be *some* way to determine how much of
that is valid.  My choice was to put that in the hands of
the programmer.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2006-01-11 04:55

Message:
Logged In: YES 
user_id=731668

Why does this work differently form the native win32 api? 
This example doesn't use the overlapped api to retrieve the 
size of the valid data:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/ipc/base/named_pipe_server_using_overlapped_i_o.asp

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 16:16

Message:
Logged In: YES 
user_id=14198

This is the documented behaviour.  From the pywin32 docs for
ReadFile:

While the operation is in progress, you can use the slice
operations (object[:end]) to obtain the data read so far.
You must use the OVERLAPPED API functions to determine how
much of the data is valid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1401843 ] win32 icmp support

[SourceForge.net <no...@so...>]

Feature Requests item #1401843, was opened at 2006-01-10 18:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1401843&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 icmp support

Initial Comment:
There are a handful of functions:

IcmpCreateFile
IcmpSendEcho
...etc...

defined in:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7
\PlatformSDK\Misc\Icmp\IcmpAPI.h

and implemented in:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7
\PlatformSDK\Misc\Icmp\Lib\Icmp.Lib

which it would be nice to have in "win32icmp" or some 
such python module.

Later versions of windows supposedly use "Icmpapi.h" 
and "Iphlpapi.lib" respectively, but they appear to be 
the same functions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1401843&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1398756 ] ReadFile returns trash when using overlapped io on namedpipe

[SourceForge.net <no...@so...>]

Bugs item #1398756, was opened at 2006-01-06 18:47
Message generated for change (Comment added) made by ghazel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: ReadFile returns trash when using overlapped io on namedpipe

Initial Comment:
This bug demonstration probably looks familiar if you 
read svcbug.py - however it is a different bug.

win32file.ReadFile seems to be returning as much data 
as is requested (only when using overlapped io) even 
if that much data is not actually available. The extra 
data is random trash. This same operation in C does 
not act this way.

running "ovbug.py s" starts a correct server 
and "ovbug.py s bug" starts a buggy server.
running "ovbug.py c" starts a client

You'll also notice that PeekNamedPipe seems to 
indicate the correct situation.



----------------------------------------------------------------------

>Comment By: Greg Hazel (ghazel)
Date: 2006-01-10 17:55

Message:
Logged In: YES 
user_id=731668

Why does this work differently form the native win32 api? 
This example doesn't use the overlapped api to retrieve the 
size of the valid data:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/ipc/base/named_pipe_server_using_overlapped_i_o.asp

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 05:16

Message:
Logged In: YES 
user_id=14198

This is the documented behaviour.  From the pywin32 docs for
ReadFile:

While the operation is in progress, you can use the slice
operations (object[:end]) to obtain the data read so far.
You must use the OVERLAPPED API functions to determine how
much of the data is valid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1064568 ] Added GlobalInterface Table and more Safearray Variant Types

[SourceForge.net <no...@so...>]

Patches item #1064568, was opened at 2004-11-12 02:51
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1064568&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stefan Schukat (sschukat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added GlobalInterface Table and more Safearray Variant Types

Initial Comment:
Until now only IStream marshalling was supported by
pythoncom. This is not sufficient for all marshalling
tasks. 
Therefore I patched the pythoncom DLL which allows now
to create a Global Interface Table Object and access
the IGlobalInterfaceTable interface.
Secondly some VARIANT types where missing in the
SafeArray support.  This list was now extended.

The new and changed files and a GIT test are attached.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 21:07

Message:
Logged In: YES 
user_id=14198

excellent!  Thanks for the clarification.

----------------------------------------------------------------------

Comment By: Stefan Schukat (sschukat)
Date: 2006-01-10 20:48

Message:
Logged In: YES 
user_id=977439

The change you are unsure about is already included in 
another way, see
line 519 Oleargs.cpp
if (lObjectSize==0)
     return lReturnDimension+1;


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 15:07

Message:
Logged In: YES 
user_id=14198

Very sorry about the delay in getting to this.  The
SafeArray ones are out of date, but I have checked in the
GIT ones (without pythoncom.CreateGIT() - see testGIT for
how this should be done.

However, I'm a little unsure about the change in oleargs.cpp:

		else {
			// Just an empty list so increase Dimension
			lReturnDimension += 1;
		}

Is a test case possible for this?

Thanks,

Mark

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1064568&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1195096 ] Native access to SAFEARRAY with wrapper class

[SourceForge.net <no...@so...>]

Patches item #1195096, was opened at 2005-05-04 20:19
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Schukat (sschukat)
Assigned to: Mark Hammond (mhammond)
Summary: Native access to SAFEARRAY with wrapper class

Initial Comment:
The conversion to/from SAFEARRAYs to tuples takes up a
lot of time if the SAFEARRAYs are really big. Therefore
I created a wrapper class which does not copy any data
and just wraps the access to the underlying SAFEARRAY
data. 
In addition to the performance improvements thes
classes could be created for specific dimensions and
data types if the automatic calculation of the
dimension does not work or a specific data type is
requested by the COM server.
The new object does support, comparision, sequence
protocol, printing and representation. 
The changed files a test client and script are attached.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 21:04

Message:
Logged In: YES 
user_id=14198

Thanks.  Sorry I wasn't more clear - my idea ends up with
the same end result, although also provides a transition
plan to the New World Order! :)  I don't think we do want to
give the user a choice, as the user may be using libraries
they have no control over, but which have made a different
choice - like the "currency" issue, its important there is
only one 'correct' thing we return.  As mentioned, there is
already existing __future_ related code dealing with
currencies - if you could adopt your patch to something
similar, it reduces any adaptation I need to make to the patch.

Cheers

----------------------------------------------------------------------

Comment By: Stefan Schukat (sschukat)
Date: 2006-01-10 19:53

Message:
Logged In: YES 
user_id=977439

I already saw that problem and included therefore included
pythoncom.SetSafeArrayType(bool) to set the flag
programmatically. Your suggestion would lead to the same
result. So I have no objections, but as long as the
PySafeArrayType does successfully pass the tuple test suite
I would give the user the choice.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 15:20

Message:
Logged In: YES 
user_id=14198

I like the idea of this, but I'm not that happy with the
global used to change the behaviour.  My main concern is for
an application using one lib that wants SafeArrays, and the
other wanting tuples, and no clear answer about who is "correct"

I assume that the new SafeArray type will operate exactly
like a tuple in every way - but that the "type()" will
obviously be different - so that the vast majority of
programs will see no change. 

I'd prefer an approach like I am taking for the "Decimal"
objects.  Specifically:

* create a pythoncom.__future_safearray_ flag - default is
False, but ppl can set it to true to get the new behaviour
(globally) now.
* A few/many builds in the future, we start issuing
deprecation warnings whenever SafeArrays are used without
this flag being set.
* A few/many builds after that the new behaviour becomes the
default.

Would that work for you?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-10-24 09:32

Message:
Logged In: YES 
user_id=14198

Sorry for the delay here - I'll check this out after I
release the next pywin32 build - in the next few days.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1064568 ] Added GlobalInterface Table and more Safearray Variant Types

[SourceForge.net <no...@so...>]

Patches item #1064568, was opened at 2004-11-11 16:51
Message generated for change (Comment added) made by sschukat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1064568&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stefan Schukat (sschukat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added GlobalInterface Table and more Safearray Variant Types

Initial Comment:
Until now only IStream marshalling was supported by
pythoncom. This is not sufficient for all marshalling
tasks. 
Therefore I patched the pythoncom DLL which allows now
to create a Global Interface Table Object and access
the IGlobalInterfaceTable interface.
Secondly some VARIANT types where missing in the
SafeArray support.  This list was now extended.

The new and changed files and a GIT test are attached.

----------------------------------------------------------------------

>Comment By: Stefan Schukat (sschukat)
Date: 2006-01-10 10:48

Message:
Logged In: YES 
user_id=977439

The change you are unsure about is already included in 
another way, see
line 519 Oleargs.cpp
if (lObjectSize==0)
     return lReturnDimension+1;


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 05:07

Message:
Logged In: YES 
user_id=14198

Very sorry about the delay in getting to this.  The
SafeArray ones are out of date, but I have checked in the
GIT ones (without pythoncom.CreateGIT() - see testGIT for
how this should be done.

However, I'm a little unsure about the change in oleargs.cpp:

		else {
			// Just an empty list so increase Dimension
			lReturnDimension += 1;
		}

Is a test case possible for this?

Thanks,

Mark

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1064568&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1195096 ] Native access to SAFEARRAY with wrapper class

[SourceForge.net <no...@so...>]

Patches item #1195096, was opened at 2005-05-04 12:19
Message generated for change (Comment added) made by sschukat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Schukat (sschukat)
Assigned to: Mark Hammond (mhammond)
Summary: Native access to SAFEARRAY with wrapper class

Initial Comment:
The conversion to/from SAFEARRAYs to tuples takes up a
lot of time if the SAFEARRAYs are really big. Therefore
I created a wrapper class which does not copy any data
and just wraps the access to the underlying SAFEARRAY
data. 
In addition to the performance improvements thes
classes could be created for specific dimensions and
data types if the automatic calculation of the
dimension does not work or a specific data type is
requested by the COM server.
The new object does support, comparision, sequence
protocol, printing and representation. 
The changed files a test client and script are attached.

----------------------------------------------------------------------

>Comment By: Stefan Schukat (sschukat)
Date: 2006-01-10 09:53

Message:
Logged In: YES 
user_id=977439

I already saw that problem and included therefore included
pythoncom.SetSafeArrayType(bool) to set the flag
programmatically. Your suggestion would lead to the same
result. So I have no objections, but as long as the
PySafeArrayType does successfully pass the tuple test suite
I would give the user the choice.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 05:20

Message:
Logged In: YES 
user_id=14198

I like the idea of this, but I'm not that happy with the
global used to change the behaviour.  My main concern is for
an application using one lib that wants SafeArrays, and the
other wanting tuples, and no clear answer about who is "correct"

I assume that the new SafeArray type will operate exactly
like a tuple in every way - but that the "type()" will
obviously be different - so that the vast majority of
programs will see no change. 

I'd prefer an approach like I am taking for the "Decimal"
objects.  Specifically:

* create a pythoncom.__future_safearray_ flag - default is
False, but ppl can set it to true to get the new behaviour
(globally) now.
* A few/many builds in the future, we start issuing
deprecation warnings whenever SafeArrays are used without
this flag being set.
* A few/many builds after that the new behaviour becomes the
default.

Would that work for you?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-10-24 01:32

Message:
Logged In: YES 
user_id=14198

Sorry for the delay here - I'll check this out after I
release the next pywin32 build - in the next few days.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1400633 ] GetVersionEx does not return everything

[SourceForge.net <no...@so...>]

Bugs item #1400633, was opened at 2006-01-10 06:13
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1400633&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetVersionEx does not return everything

Initial Comment:
win32api.GetVersionEx() returns:
(5, 1, 2600, 2, 'Service Pack 2')
when it should return:
(5, 1, 2600, 2, 'Service Pack 2', 2, 0, 256, 1, 0)

sys.getwindowsversion() returns the short version as 
well, so I was hoping to use win32api to retrieve more 
detailed information.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 16:36

Message:
Logged In: YES 
user_id=14198

You can now specify 1 for a new optional param, and the
function will return the extra info.

Checking in win32apimodule.cpp;
new revision: 1.52; previous revision: 1.51

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1400633&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1398756 ] ReadFile returns trash when using overlapped io on namedpipe

[SourceForge.net <no...@so...>]

Bugs item #1398756, was opened at 2006-01-07 05:47
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody/Anonymous (nobody)
Summary: ReadFile returns trash when using overlapped io on namedpipe

Initial Comment:
This bug demonstration probably looks familiar if you 
read svcbug.py - however it is a different bug.

win32file.ReadFile seems to be returning as much data 
as is requested (only when using overlapped io) even 
if that much data is not actually available. The extra 
data is random trash. This same operation in C does 
not act this way.

running "ovbug.py s" starts a correct server 
and "ovbug.py s bug" starts a buggy server.
running "ovbug.py c" starts a client

You'll also notice that PeekNamedPipe seems to 
indicate the correct situation.



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 16:16

Message:
Logged In: YES 
user_id=14198

This is the documented behaviour.  From the pywin32 docs for
ReadFile:

While the operation is in progress, you can use the slice
operations (object[:end]) to obtain the data read so far.
You must use the OVERLAPPED API functions to determine how
much of the data is valid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1361822 ] crash when or after importing scipy - Build 205

[SourceForge.net <no...@so...>]

Bugs item #1361822, was opened at 2005-11-20 11:36
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash when or after importing scipy - Build 205

Initial Comment:
This has happened a number of times but I haven't been
able to pin it down to more than the fact it occurs
when attempting to debug a program using scipy.

If the code is executed first, then one can step
through it.  In this case a crash often occurs eventually.

The crash report is the instruction "0x7c168f1d" could
not read "0x0000001c"

Colin W.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 16:07

Message:
Logged In: YES 
user_id=14198

Can you please provide instructions on how I can reproduce it?

Cheers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1379557 ] problem with pywin32 and unicode

[SourceForge.net <no...@so...>]

Bugs item #1379557, was opened at 2005-12-14 01:56
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1379557&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dieter Verfaillie (halon)
Assigned to: Mark Hammond (mhammond)
Summary: problem with pywin32 and unicode

Initial Comment:
I had a problem with the following code,
pywin32 Build 205 and unicode.

The following:

<code, without error handling for easy reading...>
  # active_directory.find_user() eventualy
  # calls GetObject('LDAP://...') and
  # returns the result.
  account_in_ad = active_directory.find_user('DNFtest')

  # init canonicalName field
  account_in_ad.GetInfoEx(['canonicalName'], 0)
  # print canonicalName field
  print '[found]', account_in_ad.GetEx("canonicalName")[0]
</code>

sometimes resulted in the following:

<trace>
  Traceback (most recent call last):
    File
"C:\Python24\lib\site-packages\win32com\client\dynamic.py",
line 293, in
  _make_method_
      codeObject = compile(methodCode, "<COMObject %s>"
% self._username_,"exec")
  UnicodeEncodeError: 'ascii' codec can't encode
character u'\xf6' in position 66:
   ordinal not in range(128)
</trace>

Playing around with print statements showed
that the call to GetInfoEx() triggered the
backtrace.
Looking deeper, self._username_ on line 293
in the file win32com/client/dynamic.py
contained the unicode value:
  LDAP://CN=DNFtest,OU=16 H-Coördinatie
  & Veiligheid,OU=Unit 
  Placeholder,DC=workplace,DC=be
Note the o with the trema. That together with
pythons compile() builtin used on that
same line not liking unicode at all for the
filename parameter caused the backtrace.
As the second parameter (filename) to the
compile builtin doesn't really matter when
the code to compile does not come from a file,
changing line 293 from:

codeObject = compile(methodCode, "<COMObject %s>" %
self._username_,"exec")

to:

codeObject = compile(methodCode, "<COMObject %s>" %
self._username_.encode('ascii','replace'),"exec")

solves this problem. Testing this change
does not seem to have negative effects
to other(older) code, so, eeerhm, whoohoo?

I haven't looked if there are any other
places where compile() is used yet, and if
there are, maybe it would be a good idea
to do this everywere, as long as the code
to compile does not come from a file?

with kind regards,
Dieter Verfaillie

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 16:06

Message:
Logged In: YES 
user_id=14198

This fix was recently checked in.

----------------------------------------------------------------------

Comment By: Dieter Verfaillie (halon)
Date: 2005-12-14 20:54

Message:
Logged In: YES 
user_id=894731

I reverted my change and tried again with
your function, but it didn't work (same traceback
occuring on the same place as my original report).

After some debugging I found out that
the userName value sometimes contains
the LDAP:// querystring. So the function you
gave me never encodes userName. It only does
that if userName is None, calculating userName
from IDispatch.

So taking that in account and adding
an else to the if "userName is None:" part
works. Like so:

def _GetGoodDispatchAndUserName(IDispatch,userName,clsctx):
  #print userName
  if userName is None:
    if type(IDispatch) == StringType:
      userName = IDispatch
    elif type(IDispatch) == UnicodeType:
      # We always want the name displayed to the user to be
a string
      userName = IDispatch.encode("ascii", "replace") 
    else:
      userName = "<unknown>"
  else:
    if type(userName) == UnicodeType:
      userName = userName.encode("ascii", "replace")
  return (_GetGoodDispatch(IDispatch, clsctx), userName)

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-12-14 09:10

Message:
Logged In: YES 
user_id=14198

Could you please try a different fix for me?  Try reverting
your change, and change the following function:

def _GetGoodDispatchAndUserName(IDispatch,userName,clsctx):
	if userName is None:
		if type(IDispatch) == StringType:
			userName = IDispatch
                elif type(IDispatch) == UnicodeType:
                        # We always want the name displayed
to the user to be a string
                        userName = IDispatch.encode("ascii",
"replace") 
		else:
			userName = "<unknown>"
	return (_GetGoodDispatch(IDispatch, clsctx), userName)


Note the special handling of Unicode that will not exist in
your version.

This change should have the same affect, but should prevent
you seeing other edge cases with the similar error, as this
should ensure _username_ is *always* a string (not only when
passed to compile)

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1379557&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1186128 ] Adding dynamic dispatch methods to AutoComplete list

[SourceForge.net <no...@so...>]

Patches item #1186128, was opened at 2005-04-20 03:16
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1186128&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jerry Gamache (sfjerry)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adding dynamic dispatch methods to AutoComplete list

Initial Comment:
The autocomplete in the PyWin interactive shell can be
pretty bare for pure COM dynamic dispatch objects. It
does not need to be that way since the typelib can be
explored for function and attribute names. This patch
adds the names to the dict of functions.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 16:04

Message:
Logged In: YES 
user_id=14198

Thanks!

Checking in view.py;
new revision: 1.24; previous revision: 1.23

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1186128&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1043734 ] Fixed win32ui.GetRecentFileList

[SourceForge.net <no...@so...>]

Patches item #1043734, was opened at 2004-10-10 07:38
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043734&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixed win32ui.GetRecentFileList

Initial Comment:
Added CProtectedWinApp::GetRecentCount which calls the
underlying m_pRecentFileList->GetSize to get the MRU
item count.

Modified
ui_get_recent_file_list(win32ui.GetRecentFileList) to
use CProtectedWinApp::GetRecentCount instead of reading
the MRU file count from the registry to avoid problems
when the application modifies that count.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 15:40

Message:
Logged In: YES 
user_id=14198

Checking in win32app.cpp;
new revision: 1.5; previous revision: 1.4
Checking in Win32app.h;
new revision: 1.4; previous revision: 1.3
Checking in win32uimodule.cpp;
new revision: 1.30; previous revision: 1.29


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043734&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1043738 ] Added SetFloatingFrameClass method to CPythonFrameWnd

[SourceForge.net <no...@so...>]

Patches item #1043738, was opened at 2004-10-10 07:42
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043738&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added SetFloatingFrameClass method to CPythonFrameWnd

Initial Comment:
Added CPythonFrameWnd::SetFloatingFrameClass to be able
to use some advanced features of CSizingControlBar.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 15:58

Message:
Logged In: YES 
user_id=14198

That is the last of the "simple" patches - thanks, and sorry
for the delay!

Checking in pythonframe.h;
new revision: 1.2; previous revision: 1.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043738&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1043736 ] PyCControlBar is now exported with PYW_EXPORT

[SourceForge.net <no...@so...>]

Patches item #1043736, was opened at 2004-10-10 07:40
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043736&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyCControlBar is now exported with PYW_EXPORT

Initial Comment:
Added PYW_EXPORT to PyCControlBar class definition to
solve linking errors when subclassing from another DLL.

I needed this to wrap around the cool CSizingBarControl.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 15:54

Message:
Logged In: YES 
user_id=14198

Checking in win32toolbar.h;
new revision: 1.2; previous revision: 1.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043736&group_id=78018

[pywin32-bugs] [ pywin32-Patches-1043735 ] Added m_pMenu and m_pSubMenu attributes to PyCCmdUI

[SourceForge.net <no...@so...>]

Patches item #1043735, was opened at 2004-10-10 07:40
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043735&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added m_pMenu and m_pSubMenu attributes to PyCCmdUI

Initial Comment:
Added m_pMenu and m_pSubMenu attributes to PyCCmdUI.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-01-10 15:52

Message:
Logged In: YES 
user_id=14198

Checking in win32cmdui.cpp;
new revision: 1.6; previous revision: 1.5

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043735&group_id=78018