Fast New ArrayDisplay with Fast Sort,unlimited columns

[randallc]

Hi,

@Siao,

You can trim some unnecessary operations I left in LVN_GETDISPINFO (such as all the StringLen/StringLetft stuff,

Unfortunately, this is not the time hog

Skipping update of invisible columns somehow

Nor is this...

The problem is the actual WM_NOTIFY is called for every subitem of the array rows, displayed or not, so these issues are not very relevant. [and I need to stop WM_NOTIFY before it even gets to the cache call, so that cannot help me.]

I have tried to interrupt the

Local $wProcOld = Eval('ArrayUDF_wProcOld'), $i, $j, $ii, $jj, $text, $textlen, $maxlen, $a_Rowa2, $iRef ;;$WM_NOTIFY = 0x004E
    If $Msg <> 0x004E Then Return _ArrayUDF_CallWndProcV($wProcOld, $hWnd, $Msg, $wParam, $lParam)
    Local $tNMHDR = DllStructCreate("hwnd hwndfrom;int idfrom;int code", $lParam)
    Local $hWndFrom = DllStructGetData($tNMHDR, "hwndfrom"), $iCode = DllStructGetData($tNMHDR, "code")

part of it, when I can predict it is not going to be necessary, but can speed it up, but not make it foolproof.

I know you don't want to spend the time, but any other ideas?.. I am thinking the main script might be able to send some warning info to save WM_NOTIFY calls or something...

best, randall

Edited February 11, 2008 by randallc

[Siao]

That's a bummer.

No idea right now, will have to look into it... I'll read MSDN and other resources, maybe I missed something and didn't do it properly. Otherwise if the AutoIt code is simply too slow in the core to handle such load, there isn't much that can be done about it.

Edited February 11, 2008 by Siao

[randallc]

That's a bummer.

No idea right now, will have to look into it... I'll read MSDN and other resources, maybe I missed something and didn't do it properly. Otherwise if the AutoIt code is simply too slow in the core to handle such load, there isn't much that can be done about it.

Hi

Don't put in too much;

1. It may be that my implementation is creating a loop which calls it too often anyway; not sure yet.

2. Overall, I wonder if it may be better for me to use the notify message just to trigger my own screen update [not sure if I can do it though...]

Best, Randall

[randallc]

Hi,

Update in post 1!

SuperFast sorting, even compared to before, with Clib Sort from @Siao with thanks.

I am very happy with the workaround for unlimited columns (100,000 etc), using the slider! - though..

Problems still

1. I would rather use Virtual ListView scrolling purely if I can work it out. [any more ideas?...]

2. Scrolling horizontally is fast, but reverts to Row1 on scrolling laterally. [maybe a different way to trigger "updateinfo" than re-sending message of size of ListView!, which I have used here - can we just delete the list view items shown to triger it better?]

3. The Slider is "sticky" on slower machines, so letting go and moving the cursor still moves the columns for a while, and sometimes unpredictable results.... [OK if one carefully waits for full update before moving it; I need to work out how to check when to let that happen.]

4. I would appreciate help with the GUI, buttons, resizing Slider control, if anyone has the time...

Best, Randall

Edited February 16, 2008 by randallc

[Siao]

That's an interesting approach

I've been working on this too. I'm halfway through rewriting the message handler proc in assembly, the plan is to leave autoit with as little work as possible (ideally just to transfer the texts from array to memory) in an attempt to speed things up, but so far the results are less exciting than I have hoped and if this tendency holds, I'll look into your method and those problems you've listed. There are things I've yet to do, and I see some potential in my approach, maybe even the actual use for cache notification, but I'm having serious doubts if the effort is worth it. Because as we agreed, the problem is the sheer quantity of notifications spammed by that damn listview. And that can be worked around in pure AutoIt like you aptly demonstrated; without resorting to mongrel hacks like I'm currently doing.

Btw, there's no need to GuiRegisterMsg WM_HVSCROLL, you can handle it from inside the new windowproc (these _ArrayUDF_WM_NOTIFY... functions), just add some conditional statement for $Msg.

That is, instead of:

If $Msg <> 0x004E Then Return CallWindowProc(old)
;and the rest of it

do

Switch $Msg
    Case 0x004E
;and the rest of it
    Case $WM_HSCROLL
;WM_HSCROLL function
EndSwitch
Return CallWindowProc(old)

Edited February 15, 2008 by Siao

[randallc]

That's an interesting approach

I've been working on this too. I'm halfway through rewriting the message handler proc in assembly, the plan is to leave autoit with as little work as possible (ideally just to transfer the texts from array to memory) in an attempt to speed things up, but so far the results are less exciting than I have hoped and if this tendency holds, I'll look into your method and those problems you've listed. There are things I've yet to do, and I see some potential in my approach, maybe even the actual use for cache notification, but I'm having serious doubts if the effort is worth it. Because as we agreed, the problem is the sheer quantity of notifications spammed by that damn listview. And that can be worked around in pure AutoIt like you aptly demonstrated; without resorting to mongrel hacks like I'm currently doing.

Btw, there's no need to GuiRegisterMsg WM_HVSCROLL, you can handle it from inside the new windowproc (these _ArrayUDF_WM_NOTIFY... functions), just add some conditional statement for $Msg.

That is, instead of:

If $Msg <> 0x004E Then Return CallWindowProc(old)
;and the rest of it

do

Switch $Msg
    Case 0x004E
;and the rest of it
    Case $WM_HSCROLL
;WM_HSCROLL function
EndSwitch
Return CallWindowProc(old)

Hi,

OK, thanks for that.. i have adjusted the Hscroll call. [and put back in the extra includes..]

Best, Randall

Edited February 15, 2008 by randallc