Page 1 of 1
[Implemented] Much needed change to DeleteElement()
Posted: Wed Jul 14, 2004 9:58 pm
by PolyVector
There is a serious problem with the way DeleteElement() currently works
Remove the current element from the list. After this call, the new current element is the previous element (the one before the deleted element). If that element does not exist (in other words, you deleted the first element in the list) then the new current element is the next element (the one after the deleted element). If there was only one element in the list when you deleted it then you are left with no current element!
This means that if you want to ForEach through each element and selectivly delete them, you will run into this problem:
Code: Select all
NewList mylist()
For x=1 To 5
AddElement(mylist())
mylist()=x
Next
ForEach mylist()
Debug mylist()
DeleteElement(mylist())
Next
The output of this is:
1
3
4
5
There is no elegant way around this for us poor PB coders
I propose that if you delete the first element in the list, the list should then reset (in the exact same way that ResetList(mylist() works)
This would make DeleteElement() move back one element in
all situations... I believe consistancy in this command is despiratly needed!
Proof of concept:
Code: Select all
NewList mylist()
For x=1 To 5
AddElement(mylist())
mylist()=x
Next
count=0
ForEach mylist()
Debug mylist()
DeleteElement(mylist())
count=count+1
If count=1
ResetList(mylist())
count-1
EndIf
Next
And of course the output of this is:
1
2
3
4
5
Posted: Wed Jul 14, 2004 10:37 pm
by kenmo
Wow, thats really ironic you posted this because I have been having the exact same problem and even made a test similar to yours. Im making a MDI image editor, and when you click close all, it should only close unchanged documents (prompting others) but when you delete SOME but not ALL list elements, it screws it up and different elements point to the wrong gadgets and so on... basically it causes major problems.
Posted: Wed Jul 14, 2004 11:19 pm
by PolyVector
I was having an awefull problem with my skin engine I'm developing for SkunkSoft when I noticed this issue...
The thing is... ForEach is used in conjunciton with DeleteElement() in practially every application you could think of with linked lists... I'd be willing to bet money that the majority of PB coders out there are incorrectly using DeleteElement() in their ForEach loops...
I hope Fred can reslove this issue... It looks to be a fairly simple fix...
Posted: Thu Jul 15, 2004 10:33 am
by Fred
The problem is it will break all the current codes. So I could add a flag to behave like this : DeleteElement(List(), #True)
Posted: Thu Jul 15, 2004 10:34 am
by thefool
i dont know much about lists, but i like flags
Posted: Thu Jul 15, 2004 1:29 pm
by freak
I vote for the flag solution as well.
You see, the current behaviour has it's good side as well, because it ensures that you
always have a "current item" after deleting one (as long as there are any items left of course)
There are cases when having a valid current item is more important than which one it
actually is.
So keep it both please.
Timo
Posted: Thu Jul 15, 2004 9:09 pm
by PolyVector
There are cases when having a valid current item is more important than which one it actually is.
1) I can't think of a single situation where the programmer shouldn't be aware of what element (relativly) is selected...
2) DeleteElement() won't return a valid current item if it deleted the only element... So you have to check for that anyways..
The AllocateMemory() command broke compatibility... but it was a
very good thing...
I can live with the flag solution, but It really should be default method... There is no reason why the direction of the new current element shouldn't be predictable without checking every time.... I've been programming in PB for a long time and I have yet to see any code that is dependant on this feature... I have seen, however, COUNTLESS snippets mis-use the command in the way I've described... Just search the forums and see...
Posted: Fri Jul 16, 2004 12:27 pm
by freak
PolyVector wrote:There are cases when having a valid current item is more important than which one it actually is.
1) I can't think of a single situation where the programmer shouldn't be aware of what element (relativly) is selected...
Just because you can't think of a situation doesn't mean it doesn't exist
I wouldn't have posted this if it wasn't something i use quite frequently.
However..
I have seen, however, COUNTLESS snippets mis-use the command in the way I've described...
I agree here. So the default behaviour should be the new one.
Timo
Posted: Fri Jul 16, 2004 6:50 pm
by PolyVector
Just because you can't think of a situation doesn't mean it doesn't exist
There are some philosophers who might argue with you
Then again, I never thought there would be a clear Port-a-Potty... Live and learn I suppose.
Well anyways, thanks for listenin' to my request