Roger Upole wrote:
"Greg Ewing"<greg.ew...@canterbury.ac.nz> wrote in message
news:4cbfa5e9.7090...@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.
--- C:\usr\src\PyGUI-2.3\GUI\Win32\ScrollableViews.py Fri Nov 13 08:21:50 2009
+++ .\ScrollableViews.py Thu Oct 21 13:12:40 2010
@@ -18,8 +18,31 @@
# and doesn't provide any way of creating a real one without using
# a resource. The following hack creates something that looks enough
# like a CDocument to keep it happy.
-win_dummy_doc = ui.CreateRichEditView().GetDocument()
-#print "ScrollableViews: Created dummy doc"
+
+doctemp = None
+
+def GetDummyDoc():
+ app = ui.GetApp()
+ # we don't really want use MFC doc/view, only want a auto scrollwindow
thing, but
+ # therefore we need a well established c++ doc template + dummy doc object
+ # otherwise pywin32 build 214 crashes
+ global doctemp
+ if not doctemp:
+ # we need a C++ doctemplate and AttachObject() to get a
+ # document to get a scrollwindow .. - oh god
+ from pywin.mfc import object
+ doctemp = ui.CreateDocTemplate(ui.IDR_PYTHONTYPE)
+ doctemp = object.CmdTarget(doctemp) # otherwise we crash at exit
+
+ # alternative, but draws in pythonwin framework
+ # because _SetupShared flaw still in docview (patch still not
accepted!)
+# from pywin.mfc import docview
+# doctemp = docview.DocTemplate()
+
+# app.AddDocTemplate(doctemp)
+
+ dummydoc = doctemp.DoCreateDoc()
+ return dummydoc
class ScrollableView(GScrollableView):
@@ -27,8 +50,8 @@
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))
+ win = ui.CreateView(GetDummyDoc())
+ win.CreateWindow(win_none, ui.AFX_IDW_PANE_FIRST, win_style, (0, 0,
100, 100))
GScrollableView.__init__(self, _win = win)
self.set(**kwds)
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
