[Implemented] Much needed change to DeleteElement()

[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

[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.

[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...

[Fred]

The problem is it will break all the current codes. So I could add a flag to behave like this : DeleteElement(List(), #True)

[thefool]

i dont know much about lists, but i like flags

[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

[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...

[freak]

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

[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