[python-win32] and PyGUI notes - Re: PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems

[Robert]

Roger Upole wrote:
>
> "Greg Ewing"<greg.ewing at canterbury.ac.nz>  wrote in message
> news:4CBFA5E9.7090100 at canterbury.ac.nz...
>> On 21/10/10 14:02, Roger Upole wrote:
>>
>>> 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.
>>
>> Actually, the problem is that it *won't* allow a view to be
>> created without a document, even though it should. If I remember
>> correctly, at the MFC level, the constructor for the view object
>> I'm using doesn't even take a Document as an argument -- you set
>> it later if you want one. Win32ui goes out of its way to accept
>> one at construction time.
>>
>> This wouldn't be such a serious problem, except that win32ui
>> doesn't seem to provide any way of creating a Document without
>> a resource -- hence the above kludge.
>
> You instantiate the MFC view object without a document, but in order
> to actually create a window and do anything useful with it, it needs
> a valid document.  For some reason, the win32ui framework
> chooses to accept a document when the view is initially created
> instead of when its window is created.  (That's where MFC
> accepts the associated document object.)
>
> I have yet to be able to determine where the dummy document is
> actually coming from in build 212.  When I try to run it in a
> debug build, so many asserts are triggered that it would take
> forever to step thru it.
>
>>> 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()
>>
>> That may work if you run the program using the pythonwin
>> executable, which contains the referenced resource. But I want
>> pygui programs to be runnable using the standard Python
>> interpreter, which means I can't rely on resources at all.
>
> The resource is actually in win32ui.pyd, rather than in Pythonwin
> itself.  I've just verified that this method works from plain python.exe.
> The scrollable view test runs with this change.
>

I should have written yesterday as I already found/worked on the doctemp problem yesterday, just I didn't completely solve (or better "workaround"), so I shifted ..

(py2.6.5 / pywin32-214)

A)

in ScrollableViews.py globals:

##win_dummy_doc = ui.CreateRichEditView().GetDocument()
doctemp = ui.CreateDocTemplate(ui.IDR_PYTHONTYPE)
win_dummy_doc = doctemp.DoCreateDoc()
#print "ScrollableViews: Created dummy doc"


This lets start the blobedit.py / my test app. but at the exit hard crash.
TestScrollableViews.py / 12-scroll.py crashes hard even at start (runtime to terminate in unusual...)


B)

in ScrollableViews.py globals:

##win_dummy_doc = ui.CreateRichEditView().GetDocument()
#print "ScrollableViews: Created dummy doc"
doctemp = ui.CreateDocTemplate(ui.IDR_PYTHONTYPE)
import pywin.mfc.object
doctemp = pywin.mfc.object.CmdTarget(doctemp)  # otherwise we crash at exit
win_dummy_doc = doctemp.DoCreateDoc()


blobedit.py & 12-scroll.py now start, work and exit correct from commandline.
(well the 12-scroll.py displays/user-interacts mostly buggy but thats not the problem here)

However when I make multiple starts / close of the app-window in IDE/one process, or when in an app the total number of ScrollView's counts down to zero and then up 
again, then still a hard crash (somehow the doc is too smart and gets corrupt at zero count)



C)

the attached .patch :

blobedit.py & 12-scroll.py now start, work and exit, and multi-boot, views count to zero and up again .. correct from commandline, python.exe & pythonw.exe & frozone 
with py2exe.


D)


But 39-text_editor.py with CRichEdit's (nothing to do with scrollview) and may test app with (scrollview +) richedits still crashes hard at exit when run with 
pythonw.exe  (but not with python.exe !).

I tried feeding in no-None RichEditDoc(templates) similar to scrollview .patch in dozends of ways, plus terminating, .close()ing docs/doctemps in various ways, but it 
didn't solve. I failed terribly.
Maybe for such and similar reasons many apps crash at exit with 214.
The (damn) Document/Template stuff in win32ui somehow seems to have become more instable in 214 (213?). danging pointers or so.

(I often use ScrollViews, SplitterViews, RichEdits,  etc. in win32ui apps  - not wanting to use the damn MFC doc/view mechansim (pure Python is much better for this), 
just to exploit the Window features ... before in infinite time I rewrite the behavior of the MFC-goodies in pure win32gui ;-) )


Robert


PS: PyGUI notes

PyGUI is/seems a nice plan. rather direct on platform libs ( theorically - still damn MFC on Win ;-) ). If combined with a slim Mingw/msvcrt.dll complied Python ...
But perhaps long time and debugging to get real world usability (Win).
One could use the (bugfixed) existing behaviour, plus __getattr__ on the ._win Component member etc for first and hope for platform independent behavior later (some 
90%+x auto-translate code).

As of now the frame windows open somehow randomly in background or foreground or somewhere (questionable win32 parent window management?), many tests like above show 
ill display behavior, no default Win-Keys like Alt-F4, Alt-<letter>-Menu Keys etc ... few controls. image Resources rarely found / hardly freezable.
py2exe and cxfreeze don't find the PyGUI autoloader stuff, one has to collect&pull some 80+ paths by extra function.
will try and go into it a little more.

Further notes so far: currently no pythonic speedy late import is done for expensive stuff throughout the library to exploit the dynamic binding (like e.g. done in 
above .patch in GetDummyDoc). A simple app pre-imports almost the whole mess, 80+ GUI mods plus pywin fully 1:1, even win32com.shell things before you see anything 
(and rarely use all these things), problems for freezer excludes. (the __init__.py autoloader thus doesn't save a lot) like a fully statically linked C 
program/library (e.g. wx). 1s and more boot time on laptops on 2nd load, though it shall be a very thin direct library.

Principally (=more) disturbs me (original sin) that the method/function names throughout the lib are in abc_def style - exactly the same as variables and properties. 
Not even Java'ish "abcDef" for Functions. So upon autocompletion and rather new to the lib one is very very disturbed:   xy.changed   ..  its a function! ;-)
By experience there is no trouble mistaking classes for functions (one doesn't even need a C in front of CDocument or so) , but much trouble: confusing functions, 
vars and properties. No one should write a new GUI-lib which does not use AbcDef for method names.

The menus seem to be a litte too automatic, but have to go into it further, if things can be avoided, menu icons etc things can principally be extended ...
The string style constants/events etc. ... may disapear without trace if a letter is typed wrong (difficult for auto-completers, pychecker, ...).
Didn't come to the new auto layout features (like wx / glade) so far .. which would be a key thing.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: .patch
URL: <http://mail.python.org/pipermail/python-win32/attachments/20101021/5060b4c1/attachment.ksh>