On Mon, Jan 21, 2013 at 5:15 AM, Staffan Tylen <staffan.ty...@gmail.com>wrote:
> I've tried to implement the CustomDraw class in order to achieve colouring
> of every second row in a listview report, but I'm facing what seems to be
> sporadic or intermittent problems. In one case the onCustomDraw never gets
> called (proved by tracing), unless more than one listview is created after
> each other (see the loop below). In another case only the first portion of
> the listview gets coloured, like the 10 first lines. In other cases it
> seems to work fine. I suspect it has to do with multiple threads being at
> work, but can't pinpoint what it is. The general implementation is as
> follows (this is not a working example):
>
CustomDraw shows the limitations of trying to do something in an
interpreted language that is meant to be done in a low-level language. In
the case you are describing, in custom draw, the operating system sends so
many messages, so fast, that the interpreter can not keep up.
This is exacerbated during dialog creation, and in your case you have a
very tight loop creating multiple dialogs at once.
>From the native C++ code, every time the code needs to invoke a method in a
Rexx object, it needs to get a lock on the interpreter kernel. Every time
a custom draw message is sent by the operating system to the window
processing loop, the native code needs to get the kernel lock, invoke your
Rexx method, parse the reply, and pass the information back to the
operating system. Before the next custom draw message can be processed.
For a list-view, the number of messages sent when the list-view is first
displayed is huge because it is asking how to color every row that is shown.
You're trying to display multiple list-views at the same time. plus doing
the work of populating the list-view items, all at the same time. It is
too much to do at once, the interpreter can't process the custom draw
messages fast enough.
Trying to trace this will compound the problem. Writing text to the
console slows things down even more, making it even less likely that the
custom draw messages will be processed fast enough.
The operating system has various strategies that it uses when it detects
that a window is not processing it's messages fast enough. This can be
seen with mouse messages, which can also come very fast. If a window is
not processing the messages fast enough, the operating system drops some of
them.
I believe that custom draw will work fine, in ooRexx, with one dialog.
Trying to do multiple dialogs with list-views at the same time, is not
going to work well. To do that, you would need to write the application in
C / C++.
> loop report over reports~allitems
> .testcustomdraw~generate(report)
> end
>
> The above is a simplified picture of how the process works. I've tested
> without resizingadmin but with the same results. I'm out of ideas...
>
Create only one dialog, show it to the user, let the user interact with it.
Have the user ask for the next report to view.
Maybe use some other strategy that doesn't involve creating all the report
dialogs at once.
--
Mark Miesfeld
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
