Patches item #2001993, was opened at 2008-06-25 05:40
Message generated for change (Comment added) made by mhammond
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&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: Trent Mick (tmick)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch to improve "find_platform_sdk_dir" in setup.py
Initial Comment:
The latest Platform SDK (the "Microsoft Windows Vista SDK") changes the directory and registry keys that identify where it is installed. This updates the method that finds that in "setup.py" to find it.
----------------------------------------------------------------------
>Comment By: Mark Hammond (mhammond)
Date: 2008-06-25 08:22
Message:
Logged In: YES
user_id=14198
Originator: NO
The order is largely arbitrary so I'm happy for you to just go for it if
you are confident it works.
----------------------------------------------------------------------
Comment By: Trent Mick (tmick)
Date: 2008-06-25 07:16
Message:
Logged In: YES
user_id=34892
Originator: YES
I hadn't noticed the addition of "# 4. Vista's SDK" in an earlier change
to setup.py. I guess that match this patch a change to *prefer* using that
SDK if it is installed as well as older ones in the older "C:\Program
Files\Microsoft Platform SDK" or "C:\Program Files\Microsoft SDK"
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2008-06-25 07:16
Message:
Logged In: YES
user_id=14198
Originator: NO
Thanks Trent - please check it in!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&group_id=78018

Patches item #2001993, was opened at 2008-06-24 19:40
Message generated for change (Comment added) made by tmick
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&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: Trent Mick (tmick)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch to improve "find_platform_sdk_dir" in setup.py
Initial Comment:
The latest Platform SDK (the "Microsoft Windows Vista SDK") changes the directory and registry keys that identify where it is installed. This updates the method that finds that in "setup.py" to find it.
----------------------------------------------------------------------
>Comment By: Trent Mick (tmick)
Date: 2008-06-24 21:16
Message:
Logged In: YES
user_id=34892
Originator: YES
I hadn't noticed the addition of "# 4. Vista's SDK" in an earlier change
to setup.py. I guess that match this patch a change to *prefer* using that
SDK if it is installed as well as older ones in the older "C:\Program
Files\Microsoft Platform SDK" or "C:\Program Files\Microsoft SDK"
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2008-06-24 21:16
Message:
Logged In: YES
user_id=14198
Originator: NO
Thanks Trent - please check it in!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&group_id=78018

Patches item #2001993, was opened at 2008-06-25 05:40
Message generated for change (Comment added) made by mhammond
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&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: Trent Mick (tmick)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch to improve "find_platform_sdk_dir" in setup.py
Initial Comment:
The latest Platform SDK (the "Microsoft Windows Vista SDK") changes the directory and registry keys that identify where it is installed. This updates the method that finds that in "setup.py" to find it.
----------------------------------------------------------------------
>Comment By: Mark Hammond (mhammond)
Date: 2008-06-25 07:16
Message:
Logged In: YES
user_id=14198
Originator: NO
Thanks Trent - please check it in!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&group_id=78018

Patches item #2001993, was opened at 2008-06-24 19:40
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=2001993&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: Trent Mick (tmick)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch to improve "find_platform_sdk_dir" in setup.py
Initial Comment:
The latest Platform SDK (the "Microsoft Windows Vista SDK") changes the directory and registry keys that identify where it is installed. This updates the method that finds that in "setup.py" to find it.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&group_id=78018

Feature Requests item #1023985, was opened at 2004-09-07 16:01
Message generated for change (Comment added) made by rupole
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1023985&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
Private: No
Submitted By: nietschy (nietschy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exec code from clipboard
Initial Comment:
In scripts with many lines of codes it would be nice to
test single little functions.
Why not mark them, right click and exec the selection or
copy something into the windows clipboard and run the
code from there.
----------------------------------------------------------------------
>Comment By: Roger Upole (rupole)
Date: 2008-06-18 21:22
Message:
Logged In: YES
user_id=771074
Originator: NO
These have been added in interact.py rev 1.16. The changes
are all local to this file, making the options only available from
the right-click menu in the interactive window.
However, they could be added to the Edit menu or as a toolbar
button if people find them useful enough.
----------------------------------------------------------------------
Comment By: bob gailer (ramrom)
Date: 2004-09-11 11:58
Message:
Logged In: YES
user_id=587593
I second this request. Visual FoxPro has this feature, and I
use it a lot. I would eliminate "single little functions"
since the intent is to execute whatever code is selected. I
would also like the abilty to copy code from the interactive
window into a script and have the >>> and ... prompts and
response lines removed in the process.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1023985&group_id=78018

Bugs item #949887, was opened at 2004-05-07 09:03
Message generated for change (Comment added) made by rupole
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=949887&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: bob gailer (ramrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: Highlighted text not deleted when typing a period.
Initial Comment:
In the interactive window or a script edit window enter a+b
Then select the + (highlight it) and type a period.
The result is a+.b rather than a.b
----------------------------------------------------------------------
>Comment By: Roger Upole (rupole)
Date: 2008-06-18 17:15
Message:
Logged In: YES
user_id=771074
Originator: NO
This has been fixed in view.py r1.27.
----------------------------------------------------------------------
Comment By: Tony Meyer (anadelonbrin)
Date: 2004-05-08 21:18
Message:
Logged In: YES
user_id=552329
I must admit this bugs me, too, and I run into it reasonably
often.
(I guess it doesn't bother me enough to open a bug report, but
does bother me enough to add to one :)
If there isn't some reason for this behaviour, then I'm
definately +1 on changing it. I'm guessing that it's a
reasonably simple change, but if not, I could try and work
up a patch...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=949887&group_id=78018

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

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

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

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