#2836: GUI modeller: errors when changing order of commands (indexation of items
seems wrong)
-------------------------+---------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.3
Component: wxGUI | Version: svn-releasebranch70
Keywords: modeller | CPU: Unspecified
Platform: Unspecified |
-------------------------+---------------------------------
Using the GUI modeller in trunk and release70 I observe the following
issues:
1. first issue:
* Add a command to the modeller
* Add a second command to the modeller
* Go to the items tab, select the first item and push on down (if you have
more than two items this always works with the second to last item).
Result:
{{{
Traceback (most recent call last):
File
"/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
-unknown-linux-gnu/gui/wxpython/gmodeler/frame.py", line
1662, in OnMoveItemsDown
self.list.MoveItems(items, up = False)
File
"/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
-unknown-linux-gnu/gui/wxpython/gmodeler/dialogs.py", line
972, in MoveItems
model.ReorderItems(idxList)
File
"/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
-unknown-linux-gnu/gui/wxpython/gmodeler/model.py", line
123, in ReorderItems
nextItem = self.items[newIdx+1]
IndexError
:
list index out of range
}}}
2. Second (related) issue:
* Add a loop
* Add two commands and check the relevant boxes in 'List of items in loop'
* Go to the Items tab
* Select the second (lowest) item and push 'Up'
Result: both commands now have the label of the second command (the one
that was moved up), even if the command behind that name is the command
that was first before. When you move the top one 'Up' then it is the loop
(item number 1, but hidden in the item list) that gets renamed.
Replying to [comment:5 martinl]:
> Fixed in r68198 (trunk) and backported in r68199. Please close after
testing.
I am still able to reproduce the second issue from time to time, but it
seems to occur randomly. I haven't been able to create a systematically
reproducible test case, yet.
So, I'm closing this for now and will open a new bug if the issue
continues to appear.