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

[pywin32-bugs] [ pywin32-Patches-1049836 ] makepy and reserved word propertyes

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

Patches item #1049836, was opened at 2004-10-19 08:24
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=1049836&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Niki Spahiev (nikis)
Assigned to: Nobody/Anonymous (nobody)
Summary: makepy and reserved word propertyes

Initial Comment:
Prevent generating of propertyes with names which are
reserved words

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

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

[pywin32-bugs] [ pywin32-Bugs-1037579 ] Often doesn't see absolute identity of path of edited files

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

Bugs item #1037579, was opened at 2004-09-30 10:05
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037579&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Often doesn't see absolute identity of path of edited files

Initial Comment:
Often after some programming session I have multiple
instances of an edited file in the windows list with
little differences in file name: Upper/lower case
differences, "programme/xy..." & "progra~1/xy" differences

somehow PythonWin doesn't see the identity of those
files. PyWin should maybe use
os.path.normcase(os.path.normpath(os.path.abspath(x)))
somewhere in the framework code ?

I rare cases edited code gets lost. But most times the
auto-reload feature prevents more severe losses (unless
I disable auto-reaload !)

Robert


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

>Comment By: Robert Kiendl (kxroberto)
Date: 2004-10-16 17:36

Message:
Logged In: YES 
user_id=972995

Now its seems to be pinned down:

the problem is always with files where the file base name or
one or more folder names are longer than 8 characters and
when the file is opened twice or more by
explorer/right-click/Edit (DDE) . Maybe its a DDE only
problem. Yet opening form explorer is a main method for
opening . Also when explorer opend and then
Menu/File/<history> opened

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

Comment By: Robert Kiendl (kxroberto)
Date: 2004-10-08 11:39

Message:
Logged In: YES 
user_id=972995

I checked to reproduce:
I open a file - exited pywin - re-run - 1: select from
menu/file/history 2: open-context-edit the same file from
explorer  => 2 windows

.py / Edit command in Explorer
C:\PYTHON23\pythonwin.exe "%1" (Uses DDE)

the file path of all the different window instances is
correctly always the same, but multiple windows with
described problem:

>>> a=win32ui.GetApp()
>>>
a.frame.MDIGetActive()[0].GetEditorView().GetDocument().GetPathName()
'C:\devel\TURBOM~1\tea_dscore.py'
#switch to next window
>>>
a.frame.MDIGetActive()[0].GetEditorView().GetDocument().GetPathName()
'C:\devel\TURBOM~1\tea_dscore.py'
#switch to next window
>>>
a.frame.MDIGetActive()[0].GetEditorView().GetDocument().GetPathName()
'C:\devel\TURBOM~1\tea_dscore.py'
>>> 



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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-08 08:30

Message:
Logged In: YES 
user_id=14198

Can you please tell me how to reproduce this - I can not. 
Whatever case I use to open the file, I never get the same
file opened twice.

I can reproduce the problem with "progra~1"

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

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

[pywin32-bugs] [ pywin32-Bugs-1048355 ] PyCWnd.DestroyWindow causes memory access & stack faults

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

Bugs item #1048355, was opened at 2004-10-16 17:30
Message generated for change (Settings changed) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
>Priority: 8
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyCWnd.DestroyWindow causes memory access & stack faults

Initial Comment:
(b203 and all previous builds I know)
win32ui does or causes indirectly something odd with
memory in PyCWnd.DestroyWindow or WM_NCDESTROY handling.

I watch this problem for years with different win32ui
based apps, yet I'm afraid that I cannot manage to
deliver a reproducable minimalistic crashing app,
though I tried. Its a nasty stochastical memory damage
problem I think. I can reproduce the crash here with
different bigger apps in different situations. Now I
have one where I manage to crash it >90% and did 100's
of tests to isolate the problem and track it down. Thus
I found it to be caused (here) by a
PyCWnd.DestroyWindow call, but the actual crash takes
place far later when the operative message handler has
returned to the message loop. Some damage in memory. 

Some users maybe know that PythonWin itself sometimes
crashes over the year at the end of some sessions, when
debug windows were open or complex (own) window
situations or randomly. Maybe there is a connection to
the windows destroying & memory problem here.

I'm quite sure there is a unresolved nasty bug in the
DestroyWindow Process or with WM_NCDESTROY handling in
win32ui. (Think is doesn't have to do with bug 906305 -
in ui_window_destroy_window there is no CEnterLeave..
but GUI_BGN_SAVE/END_SAVE which seem to be correct )

I tell what I know about the bug:

- I use win32ui for some GUI based tools since years. I
get occasional crashes on certain window and non-modal
dialog closings in different situations. memory
problems of other code can be excluded. I traced it
down to certain window destroyings going on

- latest crash traces with registers far below
(b203/py2.3.4), yet that will probably not tell much as
there are indirect memory effects

- the example code snipet below is the final handler of
a autocompletion drop-down SysListCtrl32 in
PyCFrameWnd: Upon certain key events the window has to
be destroyed explicitely and after that some simple
computation/and pasting to clipboard occurs - then
return to message loop When
self.aclstbase.DestroyWindow() is really done then in
certain memory constellations the app crashes. Its very
sensitive and abviously random. E.g. when i start the
app and use it to a certain extent, then the bug will
not show for long etc etc.
Yet when alternative
self.aclstbase.PostMessage(WM_CLOSE) is used in that
case, the app crashes never ever in that situation.

- the memory address of access fault changes in
reproducible cases, when more or less python
computations are done after the .DestroyWindow().

- The crash bug is more often on my Win98 than my WinXP
- maybe because there is less memory ....

- In other apps (mainly on my Win98) similar problems
occur, when progress dialogs (non-modal) are destroyed
or certain othe non-modal dialogs with commctrl childs.

-In other apps (mainly on my Win98) a crash when
multiple modal dialogs have the same parent and one is
closed manually. 

- I think there are always other complex childs
(window.Wnd hooked) inside the window/dialog that shows
the closing crash. If its a simple plain dialog/window
the bug maybe doesn't show at all (but Im not sure)

- Always when the suspicios .DestroyWindow() or manual
window closing methods call can be replaces by
PostMessage(WM_CLOSE) or  PostWM_USER- or 
timer-delayed .DestroyWindow() the crash can be
99%..100% (not completely sure) eliminated.
Unfortunately .DestroyWindow() cannot be replaced always.

Suspicions/Guesses:

- Certain things are going on with the invalid CWnd*
after DestroyWindow - Cannot oversee this

- Problem when WM_NCDESTROY is handled.
 ( not sure if make sens but when I run a certain
bigger app window (lots of childs and toolbars in) and
do on the open mainframe the following
>>> mainframe.SendMessage(wc.WM_DESTROY)
0
>>> mainframe.SendMessage(wc.WM_NCDESTROY)
0
...Window focus change to still existing mainframe ->
crash. Think no matter if it makes sense, win32ui
should not raise a seg fault.?)

- Invalide Message Routing / Calling
  ( the crash is always from win32ui at bottom of the
call stack one or 3 or 2 calls later (randomly going
somewhere into the open memory)  )

- ThreadState Problems
  (Yet I reproduce the bug in apps with no extra
threads or so going on)

-  Py/C AttachObject/Detach Problem 
   ( Yet I played around on CmdTarget._obj_ level. The
problem seems not to be there. )

My debugging knowledge not enough to find out more for
now. I could make suggested tests in the crashing
apps+computers if that helps? The bug is a constant,
rare but unforseable instability problem with many of
my tools.

###########

    def AutoCompleteTake(self,sn=None):
        ....
        #cleanup auto-c window
        ##self.aclstbase.PostMessage(WM_CLOSE)
        self.aclstbase.DestroyWindow()
        ...


##############
(b203/py2.3.4 stack traces memory access errors after
crash)

MFC42! 73d99c2a()
WIN32UI! 1002a268()

MFC42! 73d99c2a()
WIN32UI! 1002a268()

008253dc()
WIN32UI! 0117f7b8()

8801129b()
MFC42! 73d332fe()
WIN32UI! 0117f7b8()

MFC42! 73d332fb()
WIN32UI! 0117f7b8()

 EAX = 00000000 EBX = 007A075A
 ECX = 01499FD8 EDX = 00000000
 ESI = 0012F4CC EDI = 01499FD8
 EIP = 73D332FB ESP = 0012F0C8
 EBP = 0012F0F0 EFL = 00000206 CS = 001B
 DS = 0023 ES = 0023 SS = 0023 FS = 0038
 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=0 AC=0
 PE=1 CY=0

 00000014 = ????????

 ST0 = -0.14695186589127226e+1843
 ST1 = +0.00000000000000000e+0000
 ST2 = +4.30166298621518843e+3581
 ST3 = +0.00000000000000000e+0000
 ST4 = +0.00000000000000000e+0000
 ST5 = +2.10999965667724609e-0001
 ST6 = +0.00000000000000000e+0000
 ST7 = +0.00000000000000000e+0000
 CTRL = 027F STAT = 4020 TAGS = FFFF
 EIP = 1E04B200 CS = 001B DS = 0023
 EDO = 0012E3E0



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

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

[pywin32-bugs] [ pywin32-Bugs-1048355 ] PyCWnd.DestroyWindow causes memory access & stack faults

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

Bugs item #1048355, was opened at 2004-10-16 17:30
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=1048355&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyCWnd.DestroyWindow causes memory access & stack faults

Initial Comment:
(b203 and all previous builds I know)
win32ui does or causes indirectly something odd with
memory in PyCWnd.DestroyWindow or WM_NCDESTROY handling.

I watch this problem for years with different win32ui
based apps, yet I'm afraid that I cannot manage to
deliver a reproducable minimalistic crashing app,
though I tried. Its a nasty stochastical memory damage
problem I think. I can reproduce the crash here with
different bigger apps in different situations. Now I
have one where I manage to crash it >90% and did 100's
of tests to isolate the problem and track it down. Thus
I found it to be caused (here) by a
PyCWnd.DestroyWindow call, but the actual crash takes
place far later when the operative message handler has
returned to the message loop. Some damage in memory. 

Some users maybe know that PythonWin itself sometimes
crashes over the year at the end of some sessions, when
debug windows were open or complex (own) window
situations or randomly. Maybe there is a connection to
the windows destroying & memory problem here.

I'm quite sure there is a unresolved nasty bug in the
DestroyWindow Process or with WM_NCDESTROY handling in
win32ui. (Think is doesn't have to do with bug 906305 -
in ui_window_destroy_window there is no CEnterLeave..
but GUI_BGN_SAVE/END_SAVE which seem to be correct )

I tell what I know about the bug:

- I use win32ui for some GUI based tools since years. I
get occasional crashes on certain window and non-modal
dialog closings in different situations. memory
problems of other code can be excluded. I traced it
down to certain window destroyings going on

- latest crash traces with registers far below
(b203/py2.3.4), yet that will probably not tell much as
there are indirect memory effects

- the example code snipet below is the final handler of
a autocompletion drop-down SysListCtrl32 in
PyCFrameWnd: Upon certain key events the window has to
be destroyed explicitely and after that some simple
computation/and pasting to clipboard occurs - then
return to message loop When
self.aclstbase.DestroyWindow() is really done then in
certain memory constellations the app crashes. Its very
sensitive and abviously random. E.g. when i start the
app and use it to a certain extent, then the bug will
not show for long etc etc.
Yet when alternative
self.aclstbase.PostMessage(WM_CLOSE) is used in that
case, the app crashes never ever in that situation.

- the memory address of access fault changes in
reproducible cases, when more or less python
computations are done after the .DestroyWindow().

- The crash bug is more often on my Win98 than my WinXP
- maybe because there is less memory ....

- In other apps (mainly on my Win98) similar problems
occur, when progress dialogs (non-modal) are destroyed
or certain othe non-modal dialogs with commctrl childs.

-In other apps (mainly on my Win98) a crash when
multiple modal dialogs have the same parent and one is
closed manually. 

- I think there are always other complex childs
(window.Wnd hooked) inside the window/dialog that shows
the closing crash. If its a simple plain dialog/window
the bug maybe doesn't show at all (but Im not sure)

- Always when the suspicios .DestroyWindow() or manual
window closing methods call can be replaces by
PostMessage(WM_CLOSE) or  PostWM_USER- or 
timer-delayed .DestroyWindow() the crash can be
99%..100% (not completely sure) eliminated.
Unfortunately .DestroyWindow() cannot be replaced always.

Suspicions/Guesses:

- Certain things are going on with the invalid CWnd*
after DestroyWindow - Cannot oversee this

- Problem when WM_NCDESTROY is handled.
 ( not sure if make sens but when I run a certain
bigger app window (lots of childs and toolbars in) and
do on the open mainframe the following
>>> mainframe.SendMessage(wc.WM_DESTROY)
0
>>> mainframe.SendMessage(wc.WM_NCDESTROY)
0
...Window focus change to still existing mainframe ->
crash. Think no matter if it makes sense, win32ui
should not raise a seg fault.?)

- Invalide Message Routing / Calling
  ( the crash is always from win32ui at bottom of the
call stack one or 3 or 2 calls later (randomly going
somewhere into the open memory)  )

- ThreadState Problems
  (Yet I reproduce the bug in apps with no extra
threads or so going on)

-  Py/C AttachObject/Detach Problem 
   ( Yet I played around on CmdTarget._obj_ level. The
problem seems not to be there. )

My debugging knowledge not enough to find out more for
now. I could make suggested tests in the crashing
apps+computers if that helps? The bug is a constant,
rare but unforseable instability problem with many of
my tools.

###########

    def AutoCompleteTake(self,sn=None):
        ....
        #cleanup auto-c window
        ##self.aclstbase.PostMessage(WM_CLOSE)
        self.aclstbase.DestroyWindow()
        ...


##############
(b203/py2.3.4 stack traces memory access errors after
crash)

MFC42! 73d99c2a()
WIN32UI! 1002a268()

MFC42! 73d99c2a()
WIN32UI! 1002a268()

008253dc()
WIN32UI! 0117f7b8()

8801129b()
MFC42! 73d332fe()
WIN32UI! 0117f7b8()

MFC42! 73d332fb()
WIN32UI! 0117f7b8()

 EAX = 00000000 EBX = 007A075A
 ECX = 01499FD8 EDX = 00000000
 ESI = 0012F4CC EDI = 01499FD8
 EIP = 73D332FB ESP = 0012F0C8
 EBP = 0012F0F0 EFL = 00000206 CS = 001B
 DS = 0023 ES = 0023 SS = 0023 FS = 0038
 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=0 AC=0
 PE=1 CY=0

 00000014 = ????????

 ST0 = -0.14695186589127226e+1843
 ST1 = +0.00000000000000000e+0000
 ST2 = +4.30166298621518843e+3581
 ST3 = +0.00000000000000000e+0000
 ST4 = +0.00000000000000000e+0000
 ST5 = +2.10999965667724609e-0001
 ST6 = +0.00000000000000000e+0000
 ST7 = +0.00000000000000000e+0000
 CTRL = 027F STAT = 4020 TAGS = FFFF
 EIP = 1E04B200 CS = 001B DS = 0023
 EDO = 0012E3E0



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

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

[pywin32-bugs] [ pywin32-Bugs-1048325 ] Firing event '<<paren-open>>' failed

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

Bugs item #1048325, was opened at 2004-10-16 14:23
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=1048325&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Andersén (erik_andersen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Firing event '<<paren-open>>' failed

Initial Comment:
Try typing a closing parentesis after file.__init__.
__class__

PythonWin 2.4a3 (#56, Sep  2 2004, 20:50:21) 
[MSC v.1310 32 bit (Intel)] on win32.
Portions Copyright 1994-2004 Mark Hammond 
(mha...@sk...) - see 'Help/About 
PythonWin' for further copyright information.
>>> file.__init__.__class__Firing event '<<paren-
open>>' failed.
Traceback (most recent call last):
  File "C:\Python24\Lib\site-
packages\pythonwin\pywin\scintilla\bindings.py", 
line 141, in fire
    rc = apply(binding.handler, args)
  File "C:\Python24\Lib\site-
packages\pythonwin\pywin\idle\CallTips.py", line 
51, in paren_open_event
    arg_text = get_arg_text(self.
get_object_at_cursor())
  File "C:\Python24\Lib\site-
packages\pythonwin\pywin\idle\CallTips.py", line 
147, in get_arg_text
    pos = string.find(ob.__doc__, "\n")
  File "C:\Python24\Lib\string.py", line 293, in find
    return s.find(*args)
AttributeError: 'getset_descriptor' object has no 
attribute 'find'
)


By the way, isn't it strange that we get event 
'<<paren-open>>' when we type a closing 
parentesis?



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

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

[pywin32-bugs] [ pywin32-Feature Requests-1048282 ] win32comext makes many problems (py2exe, zip-packages, etc)

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

Feature Requests item #1048282, was opened at 2004-10-16 13:28
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=1048282&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32comext makes many problems (py2exe, zip-packages, etc)

Initial Comment:
Each time I install a new release of pywin, I first
copy the win32comext folder  contents to win32com.
Otherwise I have a lot of trouble with that module-fake
code in win32com/__init__.py

Is there a true reason for win32comext?
If anybody makes an own extenstion (as I used some)
they don't need to live in win32comext.? If modules
come with pywin they can anyway stay in win32com and
load clean, I think.


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

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

[pywin32-bugs] [ pywin32-Bugs-1042471 ] Pythonwin crashes when exiting.

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

Bugs item #1042471, was opened at 2004-10-07 19:21
Message generated for change (Comment added) made by erik_andersen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1042471&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Andersén (erik_andersen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pythonwin crashes when exiting.

Initial Comment:
Pythonwin crashes when I exit the program.

My operating system is Windows XP.

I had the same problem at installation as in bug  
990048 and I 
followed the instructions, which fixed that problem.

The only information I got from the crash was the 
Windows error popup.
The program worked as expected before ending.

I enclose a screen capture of the Windows error 
popups; this is the only response I got. (You cannot 
copy from these windows.)

Python version:
PythonWin 2.4a3 (#56, Sep  2 2004, 20:50:21) 
[MSC v.1310 32 bit (Intel)] on win32.
Portions Copyright 1994-2004 Mark Hammond 
(mha...@sk...) - see 'Help/About 
PythonWin' for further copyright information.

Pythonwin version:
pywin32-202.win32-py2.4.exe

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

>Comment By: Erik Andersén (erik_andersen)
Date: 2004-10-16 09:33

Message:
Logged In: YES 
user_id=364358

Appears partially "fixed" in build 203 in that I don't get 
the error message when the program ends. Maybe 
"covered is a better word, because the program is still 
not properly closed. 

1. Recent files is not updated.
2. The little snake in the message tray still exists after
   the program exits.

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

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

[pywin32-bugs] [ pywin32-Patches-1043729 ] Fixed double definition of EnumExceptionHandlerAction

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

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

Category: None
Group: None
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixed double definition of EnumExceptionHandlerAction

Initial Comment:
EnumExceptionHandlerAction was defined twice in
win32ui.h. Sorry, my mistake.

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

>Comment By: Adal Chiriliuc (adalx)
Date: 2004-10-14 12:29

Message:
Logged In: YES 
user_id=1067739

Actually, everything was fine.

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

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

[pywin32-bugs] [ pywin32-Bugs-1037629 ] Framework exception on file save after confirmation

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

Bugs item #1037629, was opened at 2004-09-30 12:11
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037629&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: Works For Me
Priority: 9
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Framework exception on file save after confirmation

Initial Comment:
b201 - See the traceback below:

after that the file is saved once, but when editing
more in the editor window, the document-changed-flag is
always OFF (toolbar-icon-disksave grey), thus no more
saving is possible/or requested !! I regularly loose
code by this!

>>> Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py",
line 83, in OnSaveDocument
    self._DocumentStateChanged()
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py",
line 175, in _DocumentStateChanged
   
pywin.debugger.currentDebugger.UpdateDocumentLineStates(self)
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 880, in UpdateDocumentLineStates
    doc.MarkerDeleteAll( MARKER_BREAKPOINT )
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\document.py",
line 117, in MarkerDeleteAll
    self.GetEditorView().SCIMarkerDeleteAll(marker)
AttributeError: SCIMarkerDeleteAll
win32ui: OnSaveDocument() virtual handler (<bound
method SyntEditDocument.OnSaveDocument of
<pywin.framework.editor.color.coloreditor.SyntEditDocument
instance at 0x01333878>>) raised an exception


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

>Comment By: Robert Kiendl (kxroberto)
Date: 2004-10-13 17:25

Message:
Logged In: YES 
user_id=972995

don|t know if b203 solves it meanwhile. 
Yet I reproduce the problem most easyly when simply editing
a file, CtrlF4 to try close, YES => exception  and the
changed flag is no more tracked.

>>> 
>>> Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py",
line 83, in OnSaveDocument
    self._DocumentStateChanged()
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py",
line 175, in _DocumentStateChanged
   
pywin.debugger.currentDebugger.UpdateDocumentLineStates(self)
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 880, in UpdateDocumentLineStates
    doc.MarkerDeleteAll( MARKER_BREAKPOINT )
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\document.py",
line 117, in MarkerDeleteAll
    self.GetEditorView().SCIMarkerDeleteAll(marker)
AttributeError: SCIMarkerDeleteAll
win32ui: OnSaveDocument() virtual handler (<bound method
SyntEditDocument.OnSaveDocument of
<pywin.framework.editor.color.coloreditor.SyntEditDocument
instance at 0x01134A80>>) raised an exception
>>> 

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

Comment By: Robert Kiendl (kxroberto)
Date: 2004-10-08 11:56

Message:
Logged In: YES 
user_id=972995

I found how to reproduce (& getting lots of exception going on):

- open clean pywin
- open a .py file / no more editing (dont set save-request flag)
- set breakpoint somewhere (on top)
- F5-run into breakpoint
- when debugger stops: in that line editi something (e.g. enter 
SPACEs)
- then immediately Ctrl-F4 to try close-window
- on Save-Confirm: Cancel
- ==> exceptions like above going on
- Shift - F5 to stop debugging
- Save file once
- Edit more in the file
- ===> no more change of save-request-flag (grey save
toolbar button)



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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-08 08:26

Message:
Logged In: YES 
user_id=14198

That is very strange, and I certainly can't reproduce it. 
That method does exist (in 'control.py' in that same directory)

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

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

[pywin32-bugs] [ pywin32-Bugs-978096 ] Problem with nested dispatches in build 201

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

Bugs item #978096, was opened at 2004-06-23 09:54
Message generated for change (Comment added) made by gtegos
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=978096&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: George Tegos (gtegos)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with nested dispatches in build 201

Initial Comment:
We have an application which exposes an automation 
object Application. One member of Application is Zip 
which is another automation object which has a 
property Recursive of type BOOL. In a Python script we 
have:
Application.Zip.Recursive = 1
With build 201 we get a COM error saying that we have 
a wrong number of parameters.
The same was working fine with build 200


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

>Comment By: George Tegos (gtegos)
Date: 2004-10-12 09:31

Message:
Logged In: YES 
user_id=464497

I attach a strip down version of the odl file describing 
Application and Zip objects. 
I debugged the code using versions 203 and 200. The 
problem seems to be in CDispatch.__setattr__ 
if self.__LazyMap__(attr):
  # Check the "general" property map.
  if self._olerepr_.propMap.has_key(attr):
    entry = self._olerepr_.propMap[attr]
    invoke_type = _GetDescInvokeType ...
    self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value)
    return

invoke_type has the value of 3 in version 203 instead of 4 
(pythoncom.INVOKE_PROPERTYPUT) in version 200, which 
works.


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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-09 01:48

Message:
Logged In: YES 
user_id=14198

Could you please provide a sample or some way for me to
repro this?

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

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

[pywin32-bugs] [ pywin32-Patches-1043740 ] Added PyCWnd.OnTimer virtual handler

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

Patches item #1043740, was opened at 2004-10-10 00:43
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=1043740&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added PyCWnd.OnTimer virtual handler

Initial Comment:
Added PyCWnd.OnTimer virtual handler so that the Python
WM_TIMER handler will be called even if a modal dialog
box is displayed.


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

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

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

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

Patches item #1043738, was opened at 2004-10-10 00:42
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=1043738&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added SetFloatingFrameClass method to CPythonFrameWnd

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


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

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

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

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

Patches item #1043736, was opened at 2004-10-10 00: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=1043736&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyCControlBar is now exported with PYW_EXPORT

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

I needed this to wrap around the cool CSizingBarControl.


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

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

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

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

Patches item #1043735, was opened at 2004-10-10 00: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=1043735&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added m_pMenu and m_pSubMenu attributes to PyCCmdUI

Initial Comment:
Added m_pMenu and m_pSubMenu attributes to PyCCmdUI.


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

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

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

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

Patches item #1043734, was opened at 2004-10-10 00:38
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=1043734&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixed win32ui.GetRecentFileList

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

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


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

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

[pywin32-bugs] [ pywin32-Patches-1043733 ] Added message map ranges support to CmdTarget

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

Patches item #1043733, was opened at 2004-10-10 00:36
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=1043733&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added message map ranges support to CmdTarget

Initial Comment:
Added HookCommandRange, HookCommandUpdateRange and
HookNotifyRange to CmdTarget.

They have no documentation since AutoDuck doesn't parse
.py files.


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

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

[pywin32-bugs] [ pywin32-Patches-1043732 ] New win32con constants and a bug fix

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

Patches item #1043732, was opened at 2004-10-10 00:35
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=1043732&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: New win32con constants and a bug fix

Initial Comment:
Added some new constants.

BUG: Fixed GetRValue, GetGValue and GetBValue. They
didn't clip the return value to 8 bit integers.
GetRValue(0xffffff) returned 0xffffff.


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

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

[pywin32-bugs] [ pywin32-Patches-1043731 ] New mmsystem.py constants

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

Patches item #1043731, was opened at 2004-10-10 00:32
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=1043731&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: New mmsystem.py constants

Initial Comment:
Added WAVE_MAPPER and WAVE_FORMAT_IEEE_FLOAT constants
to mmsystem.py.

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

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

[pywin32-bugs] [ pywin32-Patches-1043730 ] New afxres.py constants

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

Patches item #1043730, was opened at 2004-10-10 00:28
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=1043730&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: New afxres.py constants

Initial Comment:
Added CBRS_GRIPPER, SBPS_NORMAL, SBPS_NOBORDERS,
SBPS_POPOUT, SBPS_OWNERDRAW, SBPS_DISABLED and
SBPS_STRETCH to afxres.py.
There are two afxres.py files. One in "win32\Lib" and
one in "Pythonwin\pywin\mfc". The first of these
contained the above constants, the other did not. Fixed
that.

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

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

[pywin32-bugs] [ pywin32-Patches-1043729 ] Fixed double definition of EnumExceptionHandlerAction

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

Patches item #1043729, was opened at 2004-10-10 00:26
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=1043729&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixed double definition of EnumExceptionHandlerAction

Initial Comment:
EnumExceptionHandlerAction was defined twice in
win32ui.h. Sorry, my mistake.

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

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

[pywin32-bugs] [ pywin32-Bugs-965610 ] docview.py & COM draw Framework into the machine

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

Bugs item #965610, was opened at 2004-06-03 11:17
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=965610&group_id=78018

Category: pythonwin
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: docview.py & COM draw Framework into the machine

Initial Comment:
docview.py draws the framework into the machine (e.g.
py2exe creates output +1MB in size). Software uses
unnecessary lots of memory.

and: now win32com/server/dispatcher.py also draws the
framework/debugger !

i patched it like this ( but not very elegant because i
don't overview the framework module design well; but
only 2 locations changing ) 
 
# docview.py

 
  self.MakeView=MakeView
  self._SetupSharedMenu_()
 def _SetupSharedMenu_(self):
  pass #to be replaced by framework!
### todo - _SetupSharedMenu_ should be moved to a
framework class.
## def _SetupSharedMenu_(self):
##  sharedMenu = self.GetSharedMenu()
##  from pywin.framework import toolmenu
##  toolmenu.SetToolsMenu(sharedMenu)
##  from pywin.framework import help
##  help.SetHelpMenuOtherHelp(sharedMenu)
 
 def _CreateDocTemplate(self, resourceId):
  return win32ui.CreateDocTemplate(resourceId)
 def __del__(self):




# intpyapp.py


import dbgcommands

lastLocateFileName = ".py" # used in the "File/Locate"
dialog...

# todo - _SetupSharedMenu should be moved to a
framework class.
def _SetupSharedMenu_(self):
        sharedMenu = self.GetSharedMenu()
        from pywin.framework import toolmenu
        toolmenu.SetToolsMenu(sharedMenu)
        from pywin.framework import help
        help.SetHelpMenuOtherHelp(sharedMenu)
from pywin.mfc import docview
docview.DocTemplate._SetupSharedMenu_=_SetupSharedMenu_

class MainFrame(app.MainFrame):
        def OnCreate(self, createStruct):
                self.closing = 0




 

# dispatcher.py

 

  def __init__(self, policyClass, ob):
    exec "import pywin.debugger"
    pywin.debugger.brk()


 


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

>Comment By: Robert Kiendl (kxroberto)
Date: 2004-10-09 15:09

Message:
Logged In: YES 
user_id=972995

The 2 files in attachment. Its a quick hack of the
"SetShared..." hook solution. I didn't understand the
structure and execution flow on the big picture.

in win32com/server/dispatcher.py I didn't do anything.
Thinke there should also be a "SetDebugger" interface to
unravel.


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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-09 08:01

Message:
Logged In: YES 
user_id=14198

You can tell py2exe to exclude them, but if you could turn
your code into either a .patch or the complete files as
"clean" as possible, I'd certainly consider it.  Please
reset the bug status to "open" when you do (or just create a
new "patch")

Thanks

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

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

[pywin32-bugs] [ pywin32-Bugs-733398 ] Can't configuring the tools menu bar

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

Bugs item #733398, was opened at 2003-05-07 02:48
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=733398&group_id=78018

>Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Reginald B. Charney (rcharney)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't configuring the tools menu bar

Initial Comment:
I usually run PythonWin with the debugger tool bar 
present. However, there does not seem to be any way of 
enabling it when PythonWin is loaded. (I.e., the View | 
Toolbars | Debugging can not be selected by default.)

Somewhat related is an inconsistency in the 
documentation that is embedded in the default.cfg file. It 
says that I can define my own .cfg file and using the 
Tools | Options | Editor set PythonWin to start with my 
configuration file. There is no place that I can set the 
startup configuration file in the Editor page.

That said, the product is terrific! Thanks.

Reg. Charney
ch...@ch...

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

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

[pywin32-bugs] [ pywin32-Bugs-770218 ] drag to select in immediate wraps

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

Bugs item #770218, was opened at 2003-07-13 03:33
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=770218&group_id=78018

>Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: bob gailer (ramrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: drag to select in immediate wraps

Initial Comment:
Click in the immediate window, and drag down. Selection
extends until the bottom, then wraps to the top.

It should stop at the bottom.

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

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

[pywin32-bugs] [ pywin32-Bugs-785374 ] Pythonwin startup error.

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

Bugs item #785374, was opened at 2003-08-08 23:13
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=785374&group_id=78018

>Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pythonwin startup error.

Initial Comment:
On an XP Profesional Machine, I upgraded from 
Python23rc1 to Python23 final.  I uninstalled the old 
packages and installed the new ones (Python23, and 
win32all-155) in a different 
location, "D:\Programs\Python23".  It all seemed to 
install correctly, but when trying to start the Pythonwin 
application the following error appeared in window:

<Error getting traceback - cant import 
traceback>exceptions.ImportError: No module named 
pywin.framework.startup

I then decided to start from scratch.  I removed again 
all my python related packages.  I deleted any remnants 
of the installation folder.  I went to the registry and 
deleted the Python23 key.  I rebooted the machine.  I 
installed Python into D:\Programs\Python23, and it 
installed correctly.  I then installed win32all-155.exe.  It 
all seemed to go well, the Start Menu shortcuts were 
created, no errors.  But when I tried to start the 
Pythonwin application it failed again with the same error 
message:

<Error getting traceback - cant import 
traceback>exceptions.ImportError: No module named 
pywin.framework.startup

Interestingly, when I launch the following, the app 
starts fine:
D:\Programs\Python23\Lib\site-
packages\Pythonwin\start_pythonwin.pyw

But, if I launch the following, I get the error:
D:\Programs\Python23\pythonwin.exe

-Ruben

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

Comment By: Ruben Marquez (rrm1)
Date: 2003-09-12 06:35

Message:
Logged In: YES 
user_id=307646

Christopher,
You are correct.  Your workaround is indeed a workaround.  
Thanks.

-Ruben

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

Comment By: Christopher J. Prinos (cprinos)
Date: 2003-09-12 04:11

Message:
Logged In: YES 
user_id=571862

Ruben, see bug #804178 for a workaround (I don't know if it's 
really a fix or not until Mark H. comments)

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

Comment By: Ruben Marquez (rrm1)
Date: 2003-08-14 22:31

Message:
Logged In: YES 
user_id=307646

Problem persists after uninstalling win32all-155 and installing 
win32all-157.  The worst part is that I can not open python 
files from Explorer.  I also notice that some settings are not 
saved, such as the one for showing empty spaces and the 
indentation guidelines.

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

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

[pywin32-bugs] [ pywin32-Bugs-782844 ] Pythonwin/Options/Format Apply-button won't work

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

Bugs item #782844, was opened at 2003-08-05 00:41
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=782844&group_id=78018

>Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond A. St. Marie (rastm2)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pythonwin/Options/Format Apply-button won't work

Initial Comment:
After changeing some font sizes and colors successfully,
I wished to change the "unterminated string" background 
color. While the color changes show up in the example 
window_ I can't Apply them because the Apply button 
will not ungrey itself after making a selection. 
Fortunately, the background color is white and I can 
read the text. More of a feature restriction then a bug. :)
Win 98  (not SE)
win32all - 155
downloaded on the July29th2003 # 46

The Apply button seems to work in other Option 
windows. 

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

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