bonami Messages: 186 Registered: June 2007 Location: Beijing
Experienced Member
ezcomm/main.cpp line 209
i have a DropList hist_text_in. Its values are received messages and its keys are indexes in a corresponding address list. Thus, different items in the DropList can have same keys to point to same indexes. But when I select an item, if keys are same, I cannot locate the item using GetIndex() + GetValue() or anything.
then i suppose i should have another list/table correlating each address list index to DropList key. in this way, key can be made unique. but when the DropList is full, new items make old items disappear. thus i have no easy way to track items.
bonami Messages: 186 Registered: June 2007 Location: Beijing
Experienced Member
input your IP, port, IP, port from left to right.
keep UDP selected.
write sth.
press "send"
the message is then sent through the network loop and received at the right side.
send multiple messages. then choose one from the DropList on top of the incoming message text field.
whatever you choose, the first message will be shown, because of the location/key problem.
explanation: the incoming message history DropList's key is the peer's index in another std::list. So messages from same peers have same keys and there is no way to differ them by Find() or GetIndex(). The only way is to go through all the items.
simplified
do not spend so long time figuring it out, just ask me to clarify next time. i've already been grateful.
First
GetKey(l.GetIndex())
is (almost) the same as
~l
(but AFAIK, l.GetIndex can return -1, which will crash here).
Second, I start to realize the problem. Yes, "GetIndex" in fact searches for the first key that is equal. Solution is simple - do not put equal keys into DropList
You can solve your problem by adding separate mapping array (keys are then indicies to this array).
bonami Messages: 186 Registered: June 2007 Location: Beijing
Experienced Member
ok. then we've come to the place i first raised the post.
i thought DropList could be full just like WithDropChoice<> and old items might be replaced silently and synchronizing this (old items being deleted) to my "mapping array" would be tough.
but i seemed to be wrong. DropList has no size control, right? so it is all up to me.
ok. then we've come to the place i first raised the post.
i thought DropList could be full just like WithDropChoice<> and old items might be replaced silently and synchronizing this (old items being deleted) to my "mapping array" would be tough.
but i seemed to be wrong.
Yes, usually in cases like this, I "ClearList" and refill (using "Add") after each program state change.
Quote:
DropList has no size control, right? so it is all up to me.