Hi, I have been reading about Dabo with great interest for several months as the framework seems to perfectly address the needs of an in-house project I'm working on right now. I am to the point where I am starting to try to actually use Dabo to start building something, and I am finding it very difficult to make much progress because the class designer tool is so unbelievably slow on my machine.
At first I thought this was simply because my computer was older (it is a dual-processor P3-800), but I have found one or two other posts on the users-group about this running on newer hardware, so I began to suspect it was a bug. However, I have seen no indication that anyone is moving toward finding or fixing it (probably because those who could do so cannot reproduce it). I *am* running the latest Subversion Head of the Dabo system. I obviously am not acquainted enough with Dabo to even know where to start looking, but I assume it has to be in the class designer component, not the core Dabo framework because the demo and the other tools I've run do not exhibit this behavior. I turned on event logging today and suspect I have found at least the general area which is causing the problem. At the times when the class designer seems to hang up, EditorForm.dPanel.dDropdownList1 is firing "Resize" and "Paint" events continuously (with no other events are interspersed within the event log). This appears to be the "Method" drop down in the code editor panel. As an example, according to the event log, when right clicking the main designer form view window and adding a "Code Editor" component, the EditorForm.dPanel.dDropdownList1 fires Resize & Paint events continuously for 32 seconds, a total of 1188 Resize events and 594 Paint events. This was a single block, adding a grid component causes several blocks of these, with other events between them. I have not completely narrowed down the specific instances when this occurs, but it will be triggered often by the main class designer window getting (or sometimes losing) focus. I can cause it by simply using ALT-TAB to change the current window, but ONLY when the class designer window is involved. Just switching between the Editor, Shell & Object Info windows does not seem to cause it. During the time these events are being pumped through, the method box is generally blank white, but will occasionally flash the correct text for a half a second or so. The pattern of events is generally two resize events followed by a paint event, followed by two resize events, etc. This, not the only pattern, just the normal one. Although I can always get it to happen, it does not seem to happen all the time in response to the same actions. For example, I just switched from my E-mail window to the class designer and back, it did not occur. When I did the exact same thing a second time, it happened (when the class designer window got the focus). It will occur when adding controls to the class designer through the main menu bar or the pop-up menu. It will occur when changing the method you are editing using the method drop-down (after you select the new method from the drop down). It will even happen when closing the application (I just used "Close Group" on the windows taskbar to close all of the class designer windows. The buttons for all windows disappeared except the main window which prompted me to save. I answered "No", it removed the taskbar button and then started running a block of Resize/Repaints. I am sure these are not the ONLY actions which cause it to occur, which leads me to believe the bug is in a lower level or often used block of code. A little spelunking in WinPDB shows that the resize / resize / paint block that is chewing up so much time seems to be coming from wxWindows. Tracing through the loop, you end up in dPemMixin.__onWxResize() and dPemMixin.__onWxPaint. The first resize call is sent an evt.Size of 197, 346, the second call is evt.Size 197,21. Then comes a call to __onWxPaint, then rinse & repeat. I have no idea if the Dabo system is somehow causing this loop, or if it is something to do with wx. I am currently running wxPython version 2.8.7.1 wxMSW (Unicode). The appears to be the current release version of wxPython. If anyone is interested in chasing this bug, I would be happy to help in any way possible. I have no problem in reproducing the issue (it occurs anytime I run the class designer, without fail) and I can generate logs, dumps or any other form of information necessary to narrow this down (if someone will tell me how). I also have a machine available which does NOT seem to exhibit these problems (at my work). It is a quad-core (dual-dual processor) Mac Pro running OSX 10.4, and it runs the class designer great. Tomorrow I'll be there and can check if it does not do the Resize/Repaint blocks or if it just runs them fast enough that you don't notice. Without event logging enabled, it takes about 37 seconds between adding a grid, and getting the UI back to a responsive state. That kind of lag makes the class designer effectively un-usable on the computer where I do most of my development, and without the class designer the RAD capability of the system is greatly reduced making it much less useful to me. Anyone game for a little bug hunt? Let me know. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
