[Pygui] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems

[Roger Upole]

"Robert" <kxroberto at googlemail.com> wrote in message 
news:i9kmoi$clm$1 at dough.gmane.org...
> A)
>
> What could be the cause for this exception of PyGUI with 
> pywin32-build214 - but not with build 212 :?
>
> Traceback (most recent call last):
>   File "blobedit.py", line 131, in <module>
>     BlobApp().run()
>   File "C:\Python26\lib\site-packages\GUI\GenericGApplications.py", line 
> 122, in run
>     self.process_args(sys.argv[1:])
>   File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line 
> 251, in process_args
>     self.open_app()
>   File "blobedit.py", line 32, in open_app
>     self.new_cmd()
>   File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line 
> 219, in new_cmd
>     self.make_window(doc)
>   File "blobedit.py", line 40, in make_window
>     cursor = self.blob_cursor)
>   File "C:\Python26\lib\site-packages\GUI\Win32\ScrollableViews.py", line 
> 32, in __init__
>     GScrollableView.__init__(self, _win = win)
> win32ui.error: The object has been destroyed.
>
>
>
>
> class ScrollableView(GScrollableView):
>
>     _line_scroll_amount = default_line_scroll_amount
>
>     def __init__(self, **kwds):
>         kwds.setdefault('extent', default_extent)
>         win = ui.CreateView(win_dummy_doc)
>         win.CreateWindow(win_none, 0, win_style, (0, 0, 100, 100))
>         GScrollableView.__init__(self, _win = win)
>         self.set(**kwds)
>
>     def get_hscrolling(self):
>
>
>
> ( both from commandline and inside PythonwinIDE )
>

The problem stems from these 2 lines in ScrollableViews.py:

rev = ui.CreateRichEditView()
win_dummy_doc = rev.GetDocument()

The win32ui framework really should not allow a view to be created
without a valid document.  In win32view.cpp, there's a C++ class that
allows some protected members of an MFC class to be set which
makes this possible.
Essentially this is a hack on top of a hack, and I'm not sure why it ever
worked.  A while back I thought I had a solution to allow it to work again,
but it only caused unpredictable results and crashes further down the road.

The PyGUI framework can probably create a valid MFC document to use
as a dummy with a little work.
Something like:
dt=win32ui.CreateDocTemplate(win32ui.IDR_PYTHONTYPE)
win_dummy_doc=dt.DoCreateDoc()
may do the trick.

Also, the win32ui framework needs to disallow the current behaviour
altogether.  I think it was originally allowed because it was attempting
to instantiate MFC objects in the wrong order.


> B) a oneliner with just "import wx" crashes hard with F5 in Pythonwin IDE 
> build 214/py2.6 - but not in build 212   (ntdll.dll)
>
> AppName: pythonwin.exe AppVer: 2.6.214.0 ModName: ntdll.dll
> ModVer: 5.1.2600.3520 Offset: 00044872
> Code: 0xc015000f
> Address: 0x7c954872
> (wxpython 2.8.11.0 (msw-unicode))
>
> Only after this patch below (passing the SendMessage by a direct python 
> call) it works again.  (But with importing this oneliner file with Ctrl-I 
> the IDE still
> crashes the same.)
>
> --- scintilla/bindings.py Sun Jan 04 15:01:18 2009
> +++ scintilla/bindings.py Tue Oct 19 18:53:49 2010
> @@ -33,7 +33,11 @@
>  def __init__(self, cmd):
>  self.cmd = cmd
>  def __call__(self, *args):
> - win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd)
> + # F5-run on simple "import wx" (wx2.8.11.0 (msw-unicode)) crashed in 
> ntdll.dll:
> + ##win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd)
> + win32ui.GetMainFrame().OnCommand(self.cmd, 0)
> + #note: Ctrl-I/import still crashes because of WM_COMMAND in the line
> +

Trying to run one GUI framework inside of another is a sure recipe for
disaster.  Both will be trying to process messages, with race conditions
and memory conflicts galore. The short answer is "don't do that".


> C) all standalone win32ui GUI apps here crash hard with 
> py2.3/pywin32-build214 at the very end/exit when they are executed from 
> commandline "python
> somewin32uiapp.py".  not with 212 and before.  (they may crash as well as 
> .pyw / win-apps  - or even PythonWin.exe may crash at the end but nobody 
> sees without a
> shell win)
>

Can you post a small script that exhibits this ?

        Roger