GUIListViewEx - Deprecated Version

[Melba23]

jandings,

Welcome to the AutoIt forums.

That scheme looks fine. If you wanted to be really picky you should prevent the UDF from initially registering the WM_NOTIFY handler by using:

_GUIListViewEx_MsgRegister(False) ; The other 2 handlers will still be registered by default

But as the messages will immediately be re-registered by the following GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY") it does not really matter.

And there is no need to "close" the ListView if all you are doing is exiting the script - that function is designed to save memory if you destroy a ListView but keep the overall script running.

Do come back if you run into any problems integrating the UDF - always happy to help.

M23

Edit: Sorry, missed a bit. You will need to pass the same parameters to the UDF handler as you received in your WM_NOTIFY handler:

_GUIListViewEx_WM_NOTIFY_Handler($hWnd, $iMsg, $wParam, $lParam)

obviously adjusted to match the actual parameter names you use in your handler definition line.

Edited August 27, 2015 by Melba23

[jandings]

Melba,

thank you very much for your quick and detailed response!

:-)

[JanZoudlik]

Hi Melba23,

I do like your work however I do have to report a more than likely a bug which is stopping me from using this UDF. I have to be able to cycle through entries in one column and where user types in the value and confirms it using enter, next item on the list becomes active for entering value(hope this make sense). Basically I cannot use arrows or tab key, I need to use <enter>. When I tried simply:

_GUIListViewEx_EditItem($hListViewEx,1,4)
_GUIListViewEx_EditItem($hListViewEx,2,4)
_GUIListViewEx_EditItem($hListViewEx,3,4)
_GUIListViewEx_EditItem($hListViewEx,4,4)
_GUIListViewEx_EditItem($hListViewEx,5,4)

it is doing all source of weird things if entered value confirmed by <enter>.  When I add sleep in between each command it seems to partially sort it out however it keeps "selected" listview item 1 above the edit box.

I thought it might be worth to report this behavior...

Regards

Jan

 

[Melba23]

JanZoudlik,

Very strange behaviour indeed! Thanks for the report - I will look into it.

I have to be able to cycle through entries in one column and where user types in the value and confirms it using enter, next item on the list becomes active for entering value(hope this make sense). Basically I cannot use arrows or tab key, I need to use <enter>

And why can the user not use tab or an arrow key to cycle through the items? Why must it be <enter>?

M23

[JanZoudlik]

JanZoudlik,

Very strange behaviour indeed! Thanks for the report - I will look into it.

And why can the user not use tab or an arrow key to cycle through the items? Why must it be <enter>?

M23

They will use barcode scanner which needs to be set to <enter> after scanned barcode due to another app it is used in...

Anyway, thanks for looking into it...

[JanZoudlik]

Also further more, it cannot simply cycle through as it might have to skip some items therefore it has to use exact coordinates during each edit item call as follow:

_GUIListViewEx_EditItem($hListViewEx,1,4)
_GUIListViewEx_EditItem($hListViewEx,2,4)
_GUIListViewEx_EditItem($hListViewEx,4,4)
_GUIListViewEx_EditItem($hListViewEx,7,4)

Of course coordinates(item numbers) won't be hard-coded but calculated...

[Melba23]

JanZoudlik,

I have found the problem - the ListView was reacting to the {ENTER} key if it was still pressed after the edit ended. I have added code to wait for whatever key was pressed to end the edit to be released before the function returns - that way the ListView never sees it. And as an added bonus I have added the keycode for the "edit ended" key to the returned array so that you can react accordingly and prevent additional edits if the function was being looped.

Here are the modified UDF and a sample script to show it working in both loop (your original request) and random (your new request) modes:

 

It works fine for me - can you let me know if it is working for you too.

M23

Edited June 2, 2016 by Melba23
Beta code removed

[JanZoudlik]

JanZoudlik,

I have found the problem - the ListView was reacting to the {ENTER} key if it was still pressed after the edit ended. I have added code to wait for whatever key was pressed to end the edit to be released before the function returns - that way the ListView never sees it. And as an added bonus I have added the keycode for the "edit ended" key to the returned array so that you can react accordingly and prevent additional edits if the function was being looped.

Here are the modified UDF and a sample script to show it working in both loop (your original request) and random (your new request) modes:

 GLVEx_Mod24.zip

It works fine for me - can you let me know if it is working for you too.

M23

Vow,

I am impressed... May I just ask, do you actually have a life?  Such a quick response on Saturday...

Anyway thanks a lot for this, I am getting back to the original idea of using your UDF...

5 stars for your great work!!!

[Melba23]

JanZoudlik,

May I just ask, do you actually have a life?  Such a quick response on Saturday...

Indeed I do! But it is extremely rainy here today and so I have time to look at the code - no golf or flying possible. Delighted I could solve the problem so quickly - I will look to releasing a new version of the UDF soon.

M23

[Melba23]

[NEW VERSION] - 24 Oct 15

Added: _GUIListViewEx_ChangeItem now waits for the "end edit" key ({ENTER} or {ESC}) to be released before returning to prevent problems when used in a loop. The function also now returns True in @‌extended if the {ENTER} key was used to end the edit and False in all other cases to allow for post-edit decision-making.

New UDF in the first post.

M23

[JanZoudlik]

[NEW VERSION] - 24 Oct 15

Added: _GUIListViewEx_ChangeItem now waits for the "end edit" key ({ENTER} or {ESC}) to be released before returning to prevent problems when used in a loop. The function also now returns True in @‌extended if the {ENTER} key was used to end the edit and False in all other cases to allow for post-edit decision-making.

New UDF in the first post.

M23

Hi M23,

I found yet again strange behavior if in "loop mode" especially when edit initialized by a button.

This is nothing what would stop me from using your UDF however as a bug it should be looked as it can cause troubles to somebody else.

Incomplete bit of code, how I managed to replicate an issue is placed below... All you need to do is somehow fill $aTemp 2d array with random data to get it to work.

I actually load it from SQL database so I removed that bit of code as it would not work for you anyway.

#include <GuiConstantsEx.au3>
#include <WindowsConstants.au3>
#include <GUIListViewEx.au3>

Local $hGUI = GUICreate("TEST", 1000, 500)
Local $iOKButton = GUICtrlCreateButton("Edit", 70, 50, 60)
Local $hListView = GUICtrlCreateListView("A|B|C|D|E",100,100,500,300)

For $i = 1 To UBound($aTemp) - 1
    GUICtrlCreateListViewItem($aTemp[$i][0] & "|" & $aTemp[$i][1] & "|" & $aTemp[$i][2] & "|" & $aTemp[$i][3] & "|"& $aTemp[$i][4], $hListView)
Next

$aTemp4listView=_GUIListViewEx_ReadToArray
Local $hListViewEx=_GUIListViewEx_Init($hListView,$aTemp4listView,0,0,false,0+ 1+ 2 + 8+ 16+ 128+256,"4")

_GUIListViewEx_MsgRegister(); required for listViewEx
_GUICtrlListView_SetColumnWidth($hListView,0,0) ;hide Link code column
GUISetState(@SW_SHOW, $hGUI)
Local $iMsg = 0
While 1
   $iMsg = GUIGetMsg()
   Switch $iMsg
      Case $iOKButton
         _GUIListViewEx_EditItem($hListViewEx,2,4)
         _GUIListViewEx_EditItem($hListViewEx,3,4)
         _GUIListViewEx_EditItem($hListViewEx,4,4)
         _GUIListViewEx_EditItem($hListViewEx,5,4)
         _GUIListViewEx_EditItem($hListViewEx,6,4)
      Case $GUI_EVENT_CLOSE
         ExitLoop
   EndSwitch
   _GUIListViewEx_EditOnClick() ; Required by listViewEx
WEnd
_GUIListViewEx_Close($hListViewEx)
GUIDelete($hGUI)

yet again this bit of script was used for testing so it is hardcoded.

What happens is that if you actually try to edit items with use of button, it does always works for first time however after several cycles through the edit it occasionally skips the first edited line(3rd line within listview).

Please note that there is a _GUIListViewEx_EditOnClick() within main loop as I need to allow user to be able to edit others if needed.

As you made it so it passes true or false within extended depends on key pressed, I can test for it and stop going through predefined loop if escaped... Also predefined loop will be always executed only once and therefore this bug is irrelevant to me as only one pass which always works...

Let me know if you need further info in replicating this issue.

Regards

Jan

Edited October 30, 2015 by JanZoudlik

[Melba23]

JanZoudlik,

I have just run this automated version of your script for 500 cycles and it always started editing at the correct row:

expandcollapse popup

#include <GuiConstantsEx.au3>
#include <WindowsConstants.au3>
#include <MsgBoxConstants.au3>
#include <GUIListViewEx.au3>

Global $aTemp[][] = [[1, 2, 3, 4, 5], [1, 2, 3, 4, 5], [1, 2, 3, 4, 5], [1, 2, 3, 4, 5], [1, 2, 3, 4, 5], [1, 2, 3, 4, 5], [1, 2, 3, 4, 5]]

Local $hGUI = GUICreate("TEST", 550, 400)
Local $iOKButton = GUICtrlCreateButton("Edit", 10, 10, 80, 30)
Local $hListView = GUICtrlCreateListView("A|B|C|D|E", 10, 50, 500, 300)

For $i = 0 To UBound($aTemp) - 1
    GUICtrlCreateListViewItem($aTemp[$i][0] & "|" & $aTemp[$i][1] & "|" & $aTemp[$i][2] & "|" & $aTemp[$i][3] & "|" & $aTemp[$i][4], $hListView)
Next

$cDummy = GUICtrlCreateDummy()

$aTemp4listView = _GUIListViewEx_ReadToArray

Local $hListViewEx = _GUIListViewEx_Init($hListView, $aTemp4listView, 0, 0, False, 2, "4")

_GUIListViewEx_MsgRegister(); required for listViewEx



_GUICtrlListView_SetColumnWidth($hListView, 0, 0) ;hide Link code column

GUISetState(@SW_SHOW, $hGUI)

Global $iCount = 1
$nBegin = TimerInit()

While 1
    $iMsg = GUIGetMsg()
    Switch $iMsg

        Case $iOKButton, $cDummy

            GUICtrlSetState($iOKButton, $GUI_DISABLE)

            AdlibRegister("_AutoClick", 250)

            _GUIListViewEx_EditItem($hListViewEx, 2, 4)
            _GUIListViewEx_EditItem($hListViewEx, 3, 4)
            _GUIListViewEx_EditItem($hListViewEx, 4, 4)
            _GUIListViewEx_EditItem($hListViewEx, 5, 4)
            _GUIListViewEx_EditItem($hListViewEx, 6, 4)

            AdlibUnRegister("_AutoClick")
            $iCount += 1

            $sLine_2 = _GUICtrlListView_GetItemTextString($hListView, 2)
            $sLine_6 = _GUICtrlListView_GetItemTextString($hListView, 6)

            If $sLine_2 <> $sLine_6 Then
                MsgBox($MB_SYSTEMMODAL, "Error on pass " & $iCount, "ListView lines do not match")
            EndIf



            GUICtrlSetState($iOKButton, $GUI_ENABLE)
        Case $GUI_EVENT_CLOSE
            ExitLoop

    EndSwitch



    _GUIListViewEx_EditOnClick() ; Required by listViewEx



    If TimerDiff($nBegin) > 3 * 1000 Then
        GUICtrlSendToDummy($cDummy)
        $nBegin = TimerInit()
    EndIf

WEnd



Func _AutoClick()
    Send($iCount & "{ENTER}")
EndFunc

Are you doing anything particular with the ListView when or shortly before the problem occurs?

M23

[JanZoudlik]

Hi there,

nothing particular, just clicking the button using mouse and then clicking enter escape etc...

Anyway, if you click enter at some point while your script runs it will do it also. It is like if value is hanging in keyboard buffer waiting to be read out...

 

Edited November 2, 2015 by Melba23
Removed quote!

[Melba23]

JanZoudlik,

Of course pressing {ENTER} will affect the script - the code looks for certain keys (including {ENTER}) to determine what to do next. As you correctly surmised, pressing {ENTER} places that keystroke in the buffer and so it short-circuits the UDF code.

You could use BlockInput to prevent the user pressing {ENTER} while the edit loop is running - but that would not prevent any keystrokes made outside the loop from entering the buffer. You could perhaps flush the buffer before entering the loop - that would entail using _WinAPI_SetWindowsHookEx which is getting a bit complex. Do you actually need any user input at all?

M23

P.S. When you reply, please use the "Reply to this topic" button at the top of the thread or the "Reply to this topic" editor at the bottom rather than the "Quote" button - I know what I posted and it just pads the thread unnecessarily.

 

[JanZoudlik]

Hi Melba,

yeah I realized that...

anyway, easiest way to clear a buffer is still assembly code:

mov ah,08h              
int 21h

which should work in conjunction with https://www.autoitscript.com/forum/topic/86672-autoit-inline-assembly-udf/ (I did not tested this...)

I went through so many programming and scripting languages that it is all mixed up... If I recall it correctly some of them actually used to clear buffer automatically when command initiating keyboard input was called.

But hey, this is autoIt and therefore my bad...  Sorry about that...

And yet again thanks for you quick response

Regards

Jan

[Melba23]

JanZoudlik,

easiest way to clear a buffer is still assembly code

I used to code a lot in Assembler (using A86/D86) - already working on it!

M23

[JanZoudlik]

I kind of miss that...

Used to have a lot of fun back at school while programming intel 8086 microproccesor family. It was at the time code actually had to be optimized for performance due to very limited power  

Bring also memories about Borland Pascal in conjunction with assembler, I used to love that programming language...

[JanZoudlik]

Hi Melba,

using your UDF and it works great, however I found a minor limitation which causing user inconvenience...

I would suggest to overcome it as it will make your UDF even better

Within GUI I have created(message loop mode) I have also created several buttons as well as list view and once I call _GUIListViewEx_EditItem all the buttons will stop responding as function is stuck within it's own loop. I can think of two options how to overcome this limitation:

1. split internally function down into a 3 sections. Something like init, loop and final, where function will internally ensures that init is run first time it goes through, after that loop section is being launched each time it is called until appropriate keys hit and then it launches final section which will keep returning result until actioned. Or actually physically break it down into separate functions... This way the main script loop will be used for this and therefore everything else will work as well. 

2. pull GUIGetMsg() inside functions loop and if changed exit editing and return it so it can be processed within main script loop

I will likely go for the 2nd option as it makes it significantly easier for me to modify your UDF, however 1st option will likely have more sense for others...

Or do you have any other suggestion? for example how can I actually set GUI message (something like GUISetMsg as it would be the best option for everyone > exit editing and fake GUI message so it is picked up automatically in next loop without need of another variable)

I will hopefully have a time to look into it tomorrow. I will post modified UDF once done

Thanks

Jan

[Melba23]

JanZoudlik,

My concept was that the user starts and finishes the ListView edit before doing anything else - doing as you suggest would, in my opinion, massively complicate the code (which is already more complex than I would like) for very little gain.  Why does the user need to action these buttons during the course of a ListView edit? What is so pressing that it cannot wait?

if you are determined to proceed, the second of the 2 options you suggest would seem the easier, but even then I am not at all sure that it would be easy to code - you might like to look at the Interrupting a running function tutorial in the Wiki to see how it might be implemented. Good luck.

M23

 

[JanZoudlik]

Hi Melba,

are you ever away from PC?  Always so quick in replies... 

I am aware of suggested concepts of interrupting running functions and AutoIt limitations, yet still I don't think it will complicate the code that much(using 2. suggested option; 1. suggested option would be of course complex and complicated). As I a mentioned before I will post modified UDF version where I will clearly mark all the changes I will do, it will be up to you if you like it or not...

To your question why does user need an immediate response? Well simply, because if buttons won't respond on first click then it is a bug. It can be fixed by temporary disabling them which I considered as first option, however it is not option I like as I believe that software should be always as user friendly as possible, which is prime! This applies even if it adds extra thousand lines into the code!

I hope I will have chance to look into it tomorrow...

Regards

Jan