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

[pywin32-bugs] [ pywin32-Bugs-1027853 ] selected traceback text won't copy

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

Bugs item #1027853, was opened at 2004-09-14 06:57
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1027853&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: Out of Date
Priority: 5
Private: No
Submitted By: bob gailer (ramrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: selected traceback text won't copy

Initial Comment:
Select traceback text in interactive window & do
edit->copy. Clipboard does not change.

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

>Comment By: Roger Upole (rupole)
Date: 2008-06-18 16:51

Message:
Logged In: YES 
user_id=771074
Originator: NO

I can't reproduce this with any recent build.


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

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

[pywin32-bugs] [ pywin32-Bugs-1483482 ] losts assocs

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

Bugs item #1483482, was opened at 2006-05-07 14:31
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&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: 8
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: losts assocs

Initial Comment:
build 208
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.

Get occasionally a trace in the Pythonwin interactive
pane - like this one recently when pressing Ctrl-F
(find tool):


Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of
<pywin.scintilla.find.FindDialog instance at
0x0157FA30>>) raised an exception


I'm noticing this ["win32ui: Internal error - existing
object has type 'PyCWinThread', but 'PyC...' was
requested."] occasionally in very random situations.
Also in other standalone win32ui apps.

This problem may relate to #1475467 (win32ui: Internal
error-existing object is not of same type?). a
"->GetGoodRet()" issue or similar problem?



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

>Comment By: Roger Upole (rupole)
Date: 2008-06-18 16:43

Message:
Logged In: YES 
user_id=771074
Originator: NO

This should finally be fixed in build 211.

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

Comment By: Roger Upole (rupole)
Date: 2008-02-14 14:31

Message:
Logged In: YES 
user_id=771074
Originator: NO

I've added skipLookup=TRUE to several places where I've seen this
most often.  However, when trying to address the underlying issue
with the assocs, it seems as if PyCWinThread's destructor is
not getting called.  Circular references may keep it alive, but I
haven't dug into it that far yet.


There is also another problem with CPythonWinThread::ExitInstance.
	virtual int ExitInstance() {
		CVirtualHelper helper("ExitInstance", this);
		if (helper.HaveHandler() && helper.call()) {
			int ret;
			helper.retval(ret);
			return ret;
		} else
			return CWinThread::ExitInstance();
	}

If there is a python method defined, the base class
ExitInstance is not called.  According to this:

http://msdn2.microsoft.com/en-us/library/1afc1fkh.aspx

CWinThread::ExitInstance should alway be called even
when it is overridden, since this is what actually
deletes the class.


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

Comment By: kxroberto (kxroberto)
Date: 2006-11-21 06:40

Message:
Logged In: YES 
user_id=972995
Originator: YES

I'm reopening this bug. Just got this with build 210 (patch of GIL bug
1590399 already in):

>>> Traceback (most recent call last):
  File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\view.py",
line 430, in OnCmdEditFind
    find.ShowFindDialog()
  File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 36, in ShowFindDialog
    _ShowDialog(FindDialog)
  File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 50, in _ShowDialog
    curDialog = dlgClass()
  File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 162, in __init__
    dialog.Dialog.__init__(self,self._GetDialogTemplate())
  File "C:\Python23\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line
32, in __init__
    dlg=win32ui.CreateDialogIndirect(id)
win32ui: Internal error - existing object has type 'PyCWinThread', but
'PyCDialog' was requested.
win32ui: Error in Command Message handler for command ID 57636, Code 0


Most probable its either still the unaddressed problem with
CPythonWinThread::ExitInstance (destructor not cleaning up its assoc)
problem as described below. Or its another lost object found randomly by
ui_assoc_object::make (within win32ui.CreateDialogIndirect; as most of the
::make calls are not forcing to create objects anew but are likely to pick
up on random sticky assocs to dead objects, which have not cleaned their
assoc accidentally. (Thus big problems arises as consequence of "small"
bug)

-robert

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

Comment By: kxroberto (kxroberto)
Date: 2006-11-18 06:42

Message:
Logged In: YES 
user_id=972995
Originator: YES

bugs as far as concretely visible are solved now with patch of bug
#1590399

The comment regarding the danger of typical ui_assoc_object::make usage
"map lookups are very likely to pick up undeleted
junk objects in the map" still could be interesting to avoid latent bugs
in future.

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

Comment By: kxroberto (kxroberto)
Date: 2006-06-06 12:10

Message:
Logged In: YES 
user_id=972995

Think, I found some of the sources for theses kind of bugs.

I got many other such bugs reported. e.g.:

File "app.pyo", line 2033, in WmSize\\n\', "win32ui: Internal
error - existing object has type \'PyCWnd\', but
\'PyCTabCtrl\' was requested.\\n"]

I have these strong guesses for bugs:

* CPythonWinThread::ExitInstance
the MFC destroys the this pointer, but the assoc is not
deleted! ==> junk items are pickup ==> bug in OP (see
skipLookup problem below)

* ui_propsheet_get_tab_ctrl:
permanent ui_assoc_object::make is called on temporary pTab
= pPS->GetTabControl()  !!
(MFC uses FromHandle !)
PyCWnd::make should be used or something similar to make it
permanent as required for a Python-Object

* (for example!): PyCWinThread::create, PyCFormView::create,
PyCEditView::create, ... (and in most ::create functions)
ui_assoc_object::make( PyCWinThread::type, pThread ) is
called with default skipLookup=FALSE
even if the C object was created brandnew (with 'new' -
which is in done in 95% of cases) !
==> Those map lookups are very likely to pick up undeleted
junk objects in the map !
==> when Objects are created new, skipLookup=TRUE should be
used - or FALSE the default and TRUE only for GetXXX things
- or best a new ui_assoc_object::makenew should be used.
Think this is very important and I attribute many other
strange win32ui - Internal errors to this risky map management.

* ui_assoc_object::GetGoodRet
DODECREF better to be done after DOINCREF !?

-robert


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

Comment By: kxroberto (kxroberto)
Date: 2006-05-07 14:32

Message:
Logged In: YES 
user_id=972995

trace again (as initial posting removes whitespace):


Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog
instance at 0x0157FA30>>) raised an exception

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

Bugs item #1944375, was opened at 2008-04-16 16:11
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1944375&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: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Roger Upole (rupole)
Date: 2008-06-18 16:34

Message:
Logged In: YES 
user_id=771074
Originator: NO

Have you tried build 211 yet to see if you still get this error ?
It's compiled without UNICODE defined, but I can also provide a
compatible win32api compiled for wide-character to see if that
solves the problem.


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-17 20:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Bugger - that's what I get for rushing :(  There is still something wrong
here though (my example doesn't seem to read MBCS that represents the
unicode that we wrote, but that isn't related to the bug being discussed
here.)

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

Comment By: Roger Upole (rupole)
Date: 2008-05-17 04:04

Message:
Logged In: YES 
user_id=771074
Originator: NO

You're calling RegEnumKey which enumerates subkeys,
and there are none.  Note that the error here is
ERROR_NO_MORE_ITEMS, rather than ERROR_MORE_DATA.


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-17 00:33

Message:
Logged In: YES 
user_id=14198
Originator: NO

I've reproduced this (although sadly with a few hacks).  The trick is (a)
to use a character that doesn't fit in 1 MBCS byte and (b) possibly this
value needs to be the longest in the key.

The following code *should* then demonstrate the problem:
---
import win32api, win32con

test_key_name = "SOFTWARE\\Python Registry Test Key - Delete Me"
root_key = win32con.HKEY_CURRENT_USER
key = win32api.RegCreateKey(root_key, test_key_name)
try:
    win32api.RegSetValueEx(key, u"\u0106", 0, win32con.REG_SZ, u"\u0106")
    print win32api.RegEnumKey(key, 0)
finally:
    key.Close()
    win32api.RegDeleteKey(root_key, test_key_name)
---
However, that is not enough - for some reason, using that same character,
I see:

>>> len(u"\u0106".encode("mbcs"))
1

Which seems quite incorrect to me.  So, I just hacked win32apimodule.cpp
to check for a unicode value and call RegSetValueExW() - and as soon as I
did that, I saw:

Traceback (most recent call last):
  File "\temp\delme.py", line 9, in <module>
print win32api.RegEnumKey(key, 0)
pywintypes.error: (259, 'RegEnumKey', 'No more data is available.')

A look in the debugger shows that the max size returned is zero - which we
add 1 to for the terminator!  Hence this return value.  Sadly, my hack to
RegSetValueEx() is incomplete - PyWinObject_AsRegistryValue() can't handle
both unicode and ansi.

Roger (or anyone) - any clue why I can't seem to make
'len(u"\uxxxx".encode("mbcs"))' return >1 for any value of xxxx?


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

Comment By: Roger Upole (rupole)
Date: 2008-05-16 22:35

Message:
Logged In: YES 
user_id=771074
Originator: NO

The size of TCHAR is actually determined at compile time.  It's either 1
or 2
bytes depending solely on whether UNICODE is defined, and does not depend
on
the platform on which it's compiled or run.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-16 08:18

Message:
Logged In: YES 
user_id=13396
Originator: YES

I am attaching a file that contains some changes to the implementations of
RegEnumKey, RegEnumKeyEx, and RegEnumValue - all of which are affected by
this ERROR_MORE_DATA situation.  I have modified the implementation to
expect ERROR_MORE_DATA.

I have looked at the implementation of RegENumValue and friends in the CVS
code.  They still won't work because they presume to know the size of a
TCHAR at compile time, and generally the code is not compiled on an
internationalized box.  I tried a similar implementation that uses the wide
method, and it suffers from the same problem.  I have not tried the link to
the latest version of pywin32, but I will try that today and see if it
resolves the problem.  If it is derived from the code in the latest CVS, it
most likely will not.
File Added: registry_fixes.cpp

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-15 17:35

Message:
Logged In: YES 
user_id=14198
Originator: NO

Hrm - I guess an RDP session might be our last option.  Before that, it
would be nice if you can check the latest pywin32 has the same issue, and
if possible, verify that when you get ERROR_MORE_DATA, the actual buffer
size isn't being returned in one of the pointers - that too would allow us
to avoid any hard-coded limits.

Thanks.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-15 08:55

Message:
Logged In: YES 
user_id=13396
Originator: YES

Ah. The .reg file I attached earlier fails properly on a Korean / Japanese
system.  It seems to work fine on an English system.  I suspect this is due
to some underlying difference in the windows registry handling code.  I
don't think it is possible to reproduce this w/o a version of Windows that
is localized in this way. 

I could probably make an RDP session to such a system available if that
would help you or someone else verify this.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-15 08:25

Message:
Logged In: YES 
user_id=14198
Originator: NO

> The test cases won't fail on Latin character sets because they are
> typically 1-byte granular, so 1 TCHAR ends up being 1 byte.  The
Japanese
> and Korean encodings are not that simple. 

Yeah - I was trying to say that if we could use the native Unicode
registry functions to write Unicode values that can't be represented in
latin1/mbcs, then we would probably be well on the way to reproducing this.
 But best I can see, that's not currently possible with pywin32/_winreg -
although I can't see why win32api and/or _winreg can't be modified to
handle Unicode natively in that case.  In the meantime, maybe a .reg file
could be used to simulate the same thing - as you mention, the key is
probably to end up with characters that can't be represented in 1 byte
inside our English registry for test purposes.

Thanks!

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-15 07:39

Message:
Logged In: YES 
user_id=13396
Originator: YES

The test cases won't fail on Latin character sets because they are
typically 1-byte granular, so 1 TCHAR ends up being 1 byte.  The Japanese
and Korean encodings are not that simple.  I am also unhappy with setting
to a maximum value, so I have revised RegEnumKey and friends to loop when
detecting ERROR_MORE_DATA.  I will also change that for RegEnumValue.

The Windows API seems a bit fuzzy.  However, QueryInfoKey supposedly
returns the maximum size of a key and value name in Unicode characters,
whereas EnumKey/EnumValue say that they return the exact size in TCHARS. 
TCHARS are not necessarily unicode characters, which makes it frustrating
to interpret.  There are a variety of unicode encodings, and they are not
necessarily byte_width * 2.  For example, in the output I pasted below the
key was apparently 8 TCHARS long, but that translated to a buffer of 12
bytes plus a NULL sequence.

I will look at the CVS version and the link you pasted below and see if I
can reproduce the problem with those versions.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-15 07:38

Message:
Logged In: YES 
user_id=13396
Originator: YES

The test cases won't fail on Latin character sets because they are
typically 1-byte granular, so 1 TCHAR ends up being 1 byte.  The Japanese
and Korean encodings are not that simple.  I am also unhappy with setting
to a maximum value, so I have revised RegEnumKey and friends to loop when
detecting ERROR_MORE_DATA.  I will also change that for RegEnumValue.

The Windows API seems a bit fuzzy.  However, QueryInfoKey supposedly
returns the maximum size of a key and value name in Unicode characters,
whereas EnumKey/EnumValue say that they return the exact size in TCHARS. 
TCHARS are not necessarily unicode characters, which makes it frustrating
to interpret.  There are a variety of unicode encodings, and they are not
necessarily byte_width * 2.  For example, in the output I pasted below the
key was apparently 8 TCHARS long, but that translated to a buffer of 12
bytes plus a NULL sequence.

I will look at the CVS version and the link you pasted below and see if I
can reproduce the problem with those versions.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-14 20:03

Message:
Logged In: YES 
user_id=14198
Originator: NO

You might like to try out
starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe and see if
you can still repro it.

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

Comment By: Roger Upole (rupole)
Date: 2008-05-14 19:03

Message:
Logged In: YES 
user_id=771074
Originator: NO

In CVS, win32apimodule.cpp has already been updated to calculate
the name buffer size in TCHARs, and can be compiled with
UNICODE defined to call the wide-character versions of the
API functions.  With the current CVS code (compiled with
or without UNICODE), I don't get an error while reading the
registry data you posted.


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-14 17:42

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks for the update, but I'm afraid I will not have time for a few days,
but a couple of thoughts: does the test case fail on English windows?  If
the issue is simply that the number of bytes returned is sometimes too
small, presumably when multi-byte characters exist, it should be possible
to repro by writing Unicode that has a multi-byte representation and trying
to read it back.  

When you say:
> If you read the documentation for that RegEnumValue closely, you will
> realize that it doesn't actually return what you think.

can you be more specific?  I'd be happy with code that handled the
ERROR_MORE_DATA case, but I'm not happy with setting a hard-coded limit to
either key or value size, and ideally I'd like *some* indication why the
code in question isn't working correctly - as we are discussing the API
itself here, I bet we are not the first people to strike this issue.  Hence
I'm quite keen to see this fail myself (if for no better reason than I can
then submit a patch upstream for Python's _winreg module - they will insist
on a test)

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 14:43

Message:
Logged In: YES 
user_id=13396
Originator: YES

I have attached the .cpp file containing the program I used to generate
these results.
File Added: main.cpp

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 14:42

Message:
Logged In: YES 
user_id=13396
Originator: YES

I believe there are two problems:

(1) MS's registry code works strangely
(2) python and pywin32 assume that the functions are returning sizes in
bytes, whereas the API documentation clearly says unicode characters (or in
some places, TCHARS.)

This happens to work by accident on Latin character set systems b/c they
usually use utf-8 or similar 8-byte systems. Korean and Japanese systems do
not.
The following is output of a C++ program I wrote to examine the
functionality of the registry functions on a 64-bit japanese localized
system:

C:\temp>\\tsclient\dev\registry_test.exe
info:          number of subkeys: 2
   maximum length of subkey name: 8
                number of values: 0
    maximum length of value name: 0
info: read key name:
  size before call: 9
   size after call: 5
     buffer growth: 0
          contents: agent
warn: the buffer allocated was not large enough:
  size before call: 9
   size after call: 9
       resizing to: 10
warn: the buffer allocated was not large enough:
  size before call: 10
   size after call: 10
       resizing to: 12
warn: the buffer allocated was not large enough:
  size before call: 12
   size after call: 12
       resizing to: 15
info: read key name:
  size before call: 15
   size after call: 12
     buffer growth: 3
          contents: \x8c\xc2\x82\xcc\x83t\x83@\x83C\x83\x8b
info: done

== Some explanation:

Size before call is the size of the buffer we allocated in order retrieve
the results of RegEnumKeyEx.
Size after call is what RegEnumKeyEx wrote back INTO the buffer size
parameter after the RegEnumKeyEx call.
Resizing to is the size in bytes of the buffer that has been enlarged to
potentially fit the contents.
buffer growth is the increment over the value returned by RegEnumKeyEx in
the lpcbName buffer.


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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 09:33

Message:
Logged In: YES 
user_id=13396
Originator: YES

I should also clarify - this is a problem with key and value NAMES. Not
the data.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 08:24

Message:
Logged In: YES 
user_id=13396
Originator: YES

I have attached a registry key that causes the failure that I posted below
for your debugging pleasure.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 08:23

Message:
Logged In: YES 
user_id=13396
Originator: YES

File Added: opsware_reg.dat

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 08:22

Message:
Logged In: YES 
user_id=13396
Originator: YES

I have also discovered the same problem in RegEnumKey today.  The error
occurs this way:

Testing:  SOFTWARE\Opsware
=========================
agent
Traceback (most recent call last):
  File "c:\temp\testreg3.py", line 21, in ?
    print win32api.RegEnumKey(r2, index)
pywintypes.error: (234, 'RegEnumKey',
'\x83f\x81[\x83^\x82\xaa\x82\xb3\x82\xe7\x
82\xc9\x82\xa0\x82\xe8\x82\xdc\x82\xb7\x81B')

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 08:12

Message:
Logged In: YES 
user_id=13396
Originator: YES

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 08:09

Message:
Logged In: YES 
user_id=13396
Originator: YES

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 08:04

Message:
Logged In: YES 
user_id=13396
Originator: YES

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 08:03

Message:
Logged In: YES 
user_id=13396
Originator: YES

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 07:59

Message:
Logged In: YES 
user_id=14198
Originator: NO

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size -
so the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 06:07

Message:
Logged In: YES 
user_id=14198
Originator: NO

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1997051 ] win32api, win32com.client

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

Bugs item #1997051, was opened at 2008-06-18 12:08
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1997051&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
Private: No
Submitted By: Peter Botros (peterbotros)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32api, win32com.client

Initial Comment:

downloaded pwin32 from

http://sourceforge.net/project/showfiles.php?group_id=78018&package_id=79063

installed it

then, from a python shell, tried:

>>> import win32com.client
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\Lib\site-packages\win32com\__init__.py", line 5, in ?
    import win32api, sys, os
ImportError: No module named win32api


what can be done ??

Thanks

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

>Comment By: Roger Upole (rupole)
Date: 2008-06-18 16:19

Message:
Logged In: YES 
user_id=771074
Originator: NO

If it was installed over an existing installation, you might want to
check if there are any outdated dll's left over from the previous
build.  It's possible old versions of pythoncom24.dll or pywintypes24.dll
may be left in your system32 directory, or the
\Lib\site-packages\pywin32_system32 dir.


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

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

[pywin32-bugs] [ pywin32-Bugs-1997051 ] win32api, win32com.client

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

Bugs item #1997051, was opened at 2008-06-18 17:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1997051&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
Private: No
Submitted By: Peter Botros (peterbotros)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32api, win32com.client

Initial Comment:

downloaded pwin32 from

http://sourceforge.net/project/showfiles.php?group_id=78018&package_id=79063

installed it

then, from a python shell, tried:

>>> import win32com.client
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\Lib\site-packages\win32com\__init__.py", line 5, in ?
    import win32api, sys, os
ImportError: No module named win32api


what can be done ??

Thanks

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1874046 ] "def" code folding, "class" code folding

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

Feature Requests item #1874046, was opened at 2008-01-17 14:32
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1874046&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jack (gurkesaft)
>Assigned to: Roger Upole (rupole)
Summary: "def" code folding, "class" code folding

Initial Comment:
Hello again,

I think it would also be nice if it were possible to fold all the second-level indents, such as the all the def's inside a class for easy navigation (and the ability to maybe do both class and def folding on startup).

Thanks!
Jack

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

>Comment By: Roger Upole (rupole)
Date: 2008-06-13 16:00

Message:
Logged In: YES 
user_id=771074
Originator: NO

This ability has been added via keyboard shortcuts
(Shift + keypad plus and shift + keypad minus)
The changes should work with any recent release, so
you can grab the latest versions of default.cfg and
coloreditor.py from CVS and try it out to see if this
does what you want.



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

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

[pywin32-bugs] [ pywin32-Feature Requests-1217955 ] Support for RegisterDeviceNotification

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

Feature Requests item #1217955, was opened at 2005-06-09 23:36
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1217955&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
Private: No
Submitted By: Russell (shakes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for RegisterDeviceNotification

Initial Comment:
There doesn't seem to be a way to call the user32.dll
function "RegisterDeviceNotification" to allow a
program to receive notifications from the Device
Management Service.  This allows one to notice if a
device is added to the system and do something
appropriately.

MSDN reference:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/registerdevicenotification.asp

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

>Comment By: Roger Upole (rupole)
Date: 2008-06-12 20:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

This has been added in build 211.


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

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

[pywin32-bugs] [ pywin32-Feature Requests-1798328 ] Restore keypad +-* when folding disabled

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

Feature Requests item #1798328, was opened at 2007-09-19 15:18
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1798328&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
Private: No
Submitted By: Marek Krocak (mkrocak)
Assigned to: Nobody/Anonymous (nobody)
Summary: Restore keypad +-* when folding disabled

Initial Comment:
Keypad '+', '-' and '*' keys are used to control folding in Pythonwin. 

When I disable folding in the "Pythonwin Options" dialog at the "Editor" tab, the keypad keys become inactive and hitting them has no effect. 

I would appreciate if they regain their original meaning of "*", "+" and "-" when folding is disabled.


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

>Comment By: Roger Upole (rupole)
Date: 2008-06-12 20:02

Message:
Logged In: YES 
user_id=771074
Originator: NO

This has been fixed in coloreditor.py r1.12.


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

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

[pywin32-bugs] [ pywin32-Bugs-1984149 ] Feature request (s)

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

Bugs item #1984149, was opened at 2008-06-04 16:47
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1984149&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: Rejected
Priority: 5
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Feature request (s)

Initial Comment:
If feature requests are ignored then ability to file them should be removed. A suitable page should be shown describing why, should be put in place.

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-06-04 18:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Leaving feature requests enabled in no way implies an obligation to
implement them.  Feel free to browse them yourself and implement whatever
you are capable of, but complaining about the lack of attention they get
helps noone.

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

Comment By: Hugh S. Myers (hsmyers)
Date: 2008-06-04 16:49

Message:
Logged In: YES 
user_id=281969
Originator: YES

If this is not the case then please let me know as there appears to be no
activity currently and none since 2006 based on what is visible.

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

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

[pywin32-bugs] [ pywin32-Bugs-1984147 ] Bogus indentation errors

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

Bugs item #1984147, was opened at 2008-06-03 23:45
Message generated for change (Comment added) made by hsmyers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1984147&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
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bogus indentation errors

Initial Comment:
PythonWin under some circumstances is unable to handle multi line docstrings. Yet when they are removed(the offending docstring), there remain bogus indent errors. This further seems to corrupt the file, as apon reload or restart and load, bogus error is still there.

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

>Comment By: Hugh S. Myers (hsmyers)
Date: 2008-06-04 00:03

Message:
Logged In: YES 
user_id=281969
Originator: YES

After some research the bogus errors can be made to go away by block
de-indenting and then re-indenting. Is this the problem fixed with a newer
version of autoindent.py? 

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

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

[pywin32-bugs] [ pywin32-Bugs-1984149 ] Feature request (s)

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

Bugs item #1984149, was opened at 2008-06-03 23:47
Message generated for change (Comment added) made by hsmyers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1984149&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
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Feature request (s)

Initial Comment:
If feature requests are ignored then ability to file them should be removed. A suitable page should be shown describing why, should be put in place.

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

>Comment By: Hugh S. Myers (hsmyers)
Date: 2008-06-03 23:49

Message:
Logged In: YES 
user_id=281969
Originator: YES

If this is not the case then please let me know as there appears to be no
activity currently and none since 2006 based on what is visible.

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

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

[pywin32-bugs] [ pywin32-Bugs-1984149 ] Feature request (s)

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

Bugs item #1984149, was opened at 2008-06-03 23:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1984149&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
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Feature request (s)

Initial Comment:
If feature requests are ignored then ability to file them should be removed. A suitable page should be shown describing why, should be put in place.

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

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

[pywin32-bugs] [ pywin32-Bugs-1984147 ] Bogus indentation errors

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

Bugs item #1984147, was opened at 2008-06-03 23:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1984147&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
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bogus indentation errors

Initial Comment:
PythonWin under some circumstances is unable to handle multi line docstrings. Yet when they are removed(the offending docstring), there remain bogus indent errors. This further seems to corrupt the file, as apon reload or restart and load, bogus error is still there.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1983731 ] Printer font and point size

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

Feature Requests item #1983731, was opened at 2008-06-03 10:14
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=1983731&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
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Printer font and point size

Initial Comment:
The user should have control over what font and what font point size is used to print a listing. While I like a large point size for sitting back and looking at the screen, this same size fits poorly on the printed page.

--hsm

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

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

[pywin32-bugs] [ pywin32-Bugs-1963786 ] MFC71.dll Not packaged

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

Bugs item #1963786, was opened at 2008-05-14 23:25
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1963786&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: installation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: RoadieRich (roadierich)
Assigned to: Nobody/Anonymous (nobody)
Summary: MFC71.dll Not packaged

Initial Comment:
Installer states that a file, MFC71.dll is required for PyWin to function.  File is not included in installer.

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-06-03 21:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Should be fixed in build 211 - please reopen if that is not the case.

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

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

[pywin32-bugs] [ pywin32-Bugs-1983087 ] Package for Python 2.6 is corrupt

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

Bugs item #1983087, was opened at 2008-06-03 16:51
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1983087&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Ali Shah (ragamuffin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Package for Python 2.6 is corrupt

Initial Comment:
Hi,

I just downloaded the exe for installing with Python 2.6 but I can't run the setup. The error message I get is "The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

It seems that the setup available for download is corrupt.

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-06-03 17:02

Message:
Logged In: YES 
user_id=14198
Originator: NO

Does Python 2.6 itself start OK?  If not, the problem is that the vs2008
"redistributables" aren't installed, which both python and pywin32 depend
on.  This is a bug in Python's installer, but once python.exe works,
pywin32 should install and work.

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

Comment By: Muhammad Ali Shah (ragamuffin)
Date: 2008-06-03 16:57

Message:
Logged In: YES 
user_id=584378
Originator: YES

Forgot to mention that this is happening with build 211 only (not with
earlier builds)

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

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

[pywin32-bugs] [ pywin32-Bugs-1983087 ] Package for Python 2.6 is corrupt

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

Bugs item #1983087, was opened at 2008-06-03 08:51
Message generated for change (Comment added) made by ragamuffin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1983087&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Ali Shah (ragamuffin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Package for Python 2.6 is corrupt

Initial Comment:
Hi,

I just downloaded the exe for installing with Python 2.6 but I can't run the setup. The error message I get is "The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

It seems that the setup available for download is corrupt.

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

>Comment By: Muhammad Ali Shah (ragamuffin)
Date: 2008-06-03 08:57

Message:
Logged In: YES 
user_id=584378
Originator: YES

Forgot to mention that this is happening with build 211 only (not with
earlier builds)

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

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

[pywin32-bugs] [ pywin32-Bugs-1983087 ] Package for Python 2.6 is corrupt

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

Bugs item #1983087, was opened at 2008-06-03 08:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1983087&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Muhammad Ali Shah (ragamuffin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Package for Python 2.6 is corrupt

Initial Comment:
Hi,

I just downloaded the exe for installing with Python 2.6 but I can't run the setup. The error message I get is "The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

It seems that the setup available for download is corrupt.

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

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

[pywin32-bugs] [ pywin32-Bugs-1799934 ] easy_install silently fails

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

Bugs item #1799934, was opened at 2007-09-21 20:29
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: easy_install silently fails

Initial Comment:
If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works.

If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this:

$ python -c 'import win32process'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.


I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both.

Regards,

Zooko

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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-06-02 20:31

Message:
Logged In: YES 
user_id=52562
Originator: YES

This is the ticket on the setuptools issue tracker to track the progress
of fixing this in setuptools:

http://bugs.python.org/setuptools/issue18

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 01:30

Message:
Logged In: YES 
user_id=14198
Originator: NO

That installer is quite recent - you may need to get the latest setuptools
rather than the latest pywin32.  Either way, just grab the CVS sources,
install the Vista SDK, and execute "setup.py" - to get some basic
instructions printed.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-03 00:56

Message:
Logged In: YES 
user_id=52562
Originator: YES

Well, I'm afraid that
starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe doesn't
work with the current setuptools -- setuptools v0.6 final.  Could you tell
me how to build pywin32 packages from CVS so I can experiment?  Thanks.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 00:39

Message:
Logged In: YES 
user_id=14198
Originator: NO

Try starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe.  Note
I'm not sure of the status of the bug I referred to - ie, I'm not sure if a
released version of setuptools has the bug fixed (but I assume you are
ontop of that :)

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-02 17:48

Message:
Logged In: YES 
user_id=52562
Originator: YES

Hi, I went to test this so I could definitely close this bug, but it turns
out that pywin32 build 211 isn't downloadable yet.


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

Comment By: SourceForge Robot (sf-robot)
Date: 2008-04-23 02:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Mark Hammond (mhammond)
Date: 2008-04-08 21:20

Message:
Logged In: YES 
user_id=14198
Originator: NO

I believe PJE recently fixed a bug in setuptools that was causing problems
with pywin32 as an egg.  Please try again after build 211 is released.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-01-25 14:17

Message:
Logged In: YES 
user_id=52562
Originator: YES


See also:

http://mail.python.org/pipermail/distutils-sig/2007-July/007823.html


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

Comment By: Mark Hammond (mhammond)
Date: 2007-09-30 23:33

Message:
Logged In: YES 
user_id=14198
Originator: NO

I've no idea - that too is an easy_install question.  I've never used
easy_install to install pywin32, and I've never recommended anyone else do
it either.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2007-09-30 22:57

Message:
Logged In: YES 
user_id=52562
Originator: YES

I will see if I can make the pywin32_postinstall.py stuff get done
automatically upon easy_install.

In the meantime, is there some way to make this failure loud instead of
silent?  How do you tell easy_install: yes, there is a package in the
expected format (.zip) in the expected place (pypi), but it isn't actually
going to work?


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

Comment By: Mark Hammond (mhammond)
Date: 2007-09-21 23:57

Message:
Logged In: YES 
user_id=14198
Originator: NO

After install, pywin32_postinstall.py needs to be run, but ezsetup
apparently does not provide a facility to do that.  You may like to ask
them for such a facility.

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

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

[pywin32-bugs] [ pywin32-Bugs-1976957 ] Column guides cause errors(can)

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

Bugs item #1976957, was opened at 2008-05-28 12:20
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1976957&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Column guides cause errors(can)

Initial Comment:
Use of column guides can cause bogus indentation errors. Pattern yet to
be determined.


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

>Comment By: Roger Upole (rupole)
Date: 2008-05-28 23:20

Message:
Logged In: YES 
user_id=771074
Originator: NO

By indentation errors, do you mean you get a python syntax error
due to whitespace, or are you referring to the red indicator that
the editor displays for inconsistent whitespace ?


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

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

[pywin32-bugs] [ pywin32-Bugs-1976953 ] Whitesace toggle problem

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

Bugs item #1976953, was opened at 2008-05-28 12:18
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1976953&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: Invalid
Priority: 5
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Whitesace toggle problem

Initial Comment:
  View Whitespace started up enabled when file loaded. Had I left it on when I shut down the editor I would understand(somewhat) the persistence. However I turned it off before I left. This now happens every time I load the file. Shouldn't.


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

>Comment By: Roger Upole (rupole)
Date: 2008-05-28 23:13

Message:
Logged In: YES 
user_id=771074
Originator: NO

No problem.

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

Comment By: Hugh S. Myers (hsmyers)
Date: 2008-05-28 22:58

Message:
Logged In: YES 
user_id=281969
Originator: YES

I did and it is. Sorry about that; I don't remember checking the option
but it was checked.

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

Comment By: Roger Upole (rupole)
Date: 2008-05-28 17:39

Message:
Logged In: YES 
user_id=771074
Originator: NO

Check and see if the permanent 'View Whitespace' option is set
under View->Options->Tabs and Whitespace.



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

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

[pywin32-bugs] [ pywin32-Bugs-1976953 ] Whitesace toggle problem

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

Bugs item #1976953, was opened at 2008-05-28 10:18
Message generated for change (Settings changed) made by hsmyers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1976953&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Whitesace toggle problem

Initial Comment:
  View Whitespace started up enabled when file loaded. Had I left it on when I shut down the editor I would understand(somewhat) the persistence. However I turned it off before I left. This now happens every time I load the file. Shouldn't.


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

>Comment By: Hugh S. Myers (hsmyers)
Date: 2008-05-28 20:58

Message:
Logged In: YES 
user_id=281969
Originator: YES

I did and it is. Sorry about that; I don't remember checking the option
but it was checked.

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

Comment By: Roger Upole (rupole)
Date: 2008-05-28 15:39

Message:
Logged In: YES 
user_id=771074
Originator: NO

Check and see if the permanent 'View Whitespace' option is set
under View->Options->Tabs and Whitespace.



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

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

[pywin32-bugs] [ pywin32-Bugs-1976953 ] Whitesace toggle problem

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

Bugs item #1976953, was opened at 2008-05-28 12:18
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1976953&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Whitesace toggle problem

Initial Comment:
  View Whitespace started up enabled when file loaded. Had I left it on when I shut down the editor I would understand(somewhat) the persistence. However I turned it off before I left. This now happens every time I load the file. Shouldn't.


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

>Comment By: Roger Upole (rupole)
Date: 2008-05-28 17:39

Message:
Logged In: YES 
user_id=771074
Originator: NO

Check and see if the permanent 'View Whitespace' option is set
under View->Options->Tabs and Whitespace.



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

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

[pywin32-bugs] [ pywin32-Bugs-1976955 ] Runaway printer

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

Bugs item #1976955, was opened at 2008-05-28 12:19
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1976955&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
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Runaway printer

Initial Comment:
On a 43 line file, printer printed 29 pages, mostly blank(occasional
page and title info across top--- somewhat random). Good news is printer
performance is consistent with print preview!


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

>Comment By: Roger Upole (rupole)
Date: 2008-05-28 17:17

Message:
Logged In: YES 
user_id=771074
Originator: NO

This has been fixed in CVS, see bug #1907148 for more details.


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

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

[pywin32-bugs] [ pywin32-Bugs-1976952 ] printer Error message?

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

Bugs item #1976952, was opened at 2008-05-28 12:16
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1976952&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
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: printer Error message?

Initial Comment:
Just got this:

C:\Python25\Lib\site-packages\pythonwin\pywin\scintilla\view.py:641: DeprecationWarning: 'L' format requires 0 <= number <= 4294967295
  fr = struct.pack('LLIIIIIIIIll', hdcRender, hdcFormat, rc[0], rc[1], rc[2], rc[3], rc[0], rc[1], rc[2], rc[3], pageStart, lengthDoc)

Can't be good...

--hsm


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

>Comment By: Roger Upole (rupole)
Date: 2008-05-28 17:16

Message:
Logged In: YES 
user_id=771074
Originator: NO

This has been fixed in CVS, see bug #1907148 for more details.


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

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