FindItem suchen nach 2ter spalte in CListCtrl (Hashkey)

Nein, kann gar nicht. Es gibt ja viel mehr mögliche Strings als mögliche Hash-Werte.

Aha

Das kommt auf deine Daten an. Vielleicht ein einfacher Index auf deine interne Datenstruktur?

Meine Daten sind einfach. 2 Strings und eine Zeit die ich aktualisieren muss.

Aber wie ich daraus einen Index erzeugen soll? KA. Sorry

MFK

y-vonne schrieb:

Meine Daten sind einfach. 2 Strings und eine Zeit die ich aktualisieren muss.

Diese Daten liegen doch irgendwo im Speicher, in einer Datenstruktur. Array, Vector oder so etwas.

Dann kannst du die Position in dieser Struktur im Listcontrol ablegen.

Wenn sich dann beispielsweise der 3. Eintrag in deiner Datenstruktur ändert, suchst du im Listcontrol die Zeile mit dem lParam-Wert 3.

Hallo

Diese Daten liegen doch irgendwo im Speicher, in einer Datenstruktur. Array, Vector oder so etwas.

Dann kannst du die Position in dieser Struktur im Listcontrol ablegen.

Jo in einer map. Key ist ein pair aus zwei Strings. Hat eine Map auch Positionen?

Wenn sich dann beispielsweise der 3. Eintrag in deiner Datenstruktur ändert, suchst du im Listcontrol die Zeile mit dem lParam-Wert 3.

Dann habe ich aber immer noch das Problem auf das Martin hingedeutet hat.

Und zwar suche ich dann immer noch mit FindItem. Und gehe die Liste durch. Schneller ist es dann auch nicht. Und das Problem wenn während desen sortiert wird besteht auch noch. Darauf hat mich Martin ja hingewiesen. Dass ich nicht das Problem der Eindeutigkeit habe.

MFK

y-vonne schrieb:

Jo in einer map. Key ist ein pair aus zwei Strings. Hat eine Map auch Positionen?

Nicht direkt. Du könntest die Daten in einem Vector ablegen, und in der Map nur die Position im Vector.

y-vonne schrieb:

Dann habe ich aber immer noch das Problem auf das Martin hingedeutet hat.

Und zwar suche ich dann immer noch mit FindItem.

Nein, du kannst mit CListCtrl::GetItemData den lParam-Wert direkt auslesen.

y-vonne schrieb:

Schneller ist es dann auch nicht.

Doch, weil du nicht mit Strings hantieren musst.

y-vonne schrieb:

Und das Problem wenn während desen sortiert wird besteht auch noch. Darauf hat mich Martin ja hingewiesen.

Das Problem, das er meinte, besteht dann, wenn du das Listcontrol nicht durchsuchst, sondern dir merkst, wo welcher Datensatz steht. Wenn du suchst, hast du das nicht.

y-vonne schrieb:

Dass ich nicht das Problem der Eindeutigkeit habe.

Das Eindeutigkeitsproblem ergibt sich aus deinem Hash-Ansatz, weil ein Hash eben nicht eindeutig ist.

Jo in einer map. Key ist ein pair aus zwei Strings. Hat eine Map auch Positionen?
Nicht direkt. Du könntest die Daten in einem Vector ablegen, und in der Map nur die Position im Vector.

Puh, noch mehr Speicherverwaltung. Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position.

Das Problem, das er meinte, besteht dann, wenn du das Listcontrol nicht durchsuchst, sondern dir merkst, wo welcher Datensatz steht. Wenn du suchst, hast du das nicht.

Nein das wollte ich ja nie machen. Habe ja gesagt ich will so was wie eine PID erzeugen und dann immer nach dieser suchen. Immer wenn aktualisiert wird. Und dort hätte ich dann auch nicht mit Strings rumhantiert.

Ich habe das eher so verstanden. Denn wenn ich eine weitere Spalte eingefügt hätte dort einen PID eingefügt hätte (fälschlicherweise war ich der Meinung das sei das selbe wie ein Hashwert) hätte ich auch mit GetItemCount suchen können.

Ließ nochmals den Beitrag von Martin dort wo er auf "O(n)" hingewiesen hat, (was ich im übrigen immer noch nicht verstehe):

Dort sagt er:

Dein Problem bei einer großen Liste ist das lokalisieren des Items...

MFK

y-vonne schrieb:

Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position.

Soll das eine Frage oder eine Aussage sein?

y-vonne schrieb:

Und dort hätte ich dann auch nicht mit Strings rumhantiert.

Wenn du diesen erzeugten Wert, wie auch immer du ihn nennst, in einer zusätzlichen Spalte ablegst, hantierst du mit Strings, denn das Listcontrol speichert diese Werte als Strings. Darum ja das lParam, das wird direkt als Zahlenwert abgelegt.

y-vonne schrieb:

Ließ nochmals den Beitrag von Martin dort wo er auf "O(n)" hingewiesen hat

Brauch ich nicht, ich hab's ja verstanden. Worauf willst du hinaus?

Soll das eine Frage oder eine Aussage sein?

Frage

Wenn du diesen erzeugten Wert, wie auch immer du ihn nennst, in einer zusätzlichen Spalte ablegst, hantierst du mit Strings, denn das Listcontrol speichert diese Werte als Strings. Darum ja das lParam, das wird direkt als Zahlenwert abgelegt. Und dort hätte ich dann auch nicht mit Strings rumhantiert.

Ok. gut danke.

Brauch ich nicht, ich hab's ja verstanden. Worauf willst du hinaus?

Zum ersten erklär mir doch mal jemand bitte was O(n) ist.

Zum zweiten schreibt er doch dass mein Problem nichtdie Eindeutigkeit ist!!! Also was ist dann das Problem.

Also das hier ist irgendwie verzwickt zu erklären. Also so wie ich das verstanden habe löst deine Lösung nicht das Problem auf das Martin hingewiesen hat. Aber das ist halt das was ich rausgelesen habe.

Mag ja sein dass es das Problem ja doch löst. Vieleicht erhalten ich bzw. wir noch ein Statement von Martin.

Dank euch auf jeden Fall für eure hilfe, und dass auch noch trotz dass ich Anfangs so sturr war

Martin Richter

Mit O(n) (sprich O von n) wird die Komplexität eines Algorithmus beschreiben.
Der Aufwand für das Finden eines Elementes ist linear und abhängig von der Anzahl der Elemente n. Hierbei fällt nicht ins gewicht ob Du je Element enen Vergleich oder 2 machst...

Wenn Du also häufige Updates machst, muss Die klar sein, das Du im schlechtesten Fall jedesmal die gesamte Liste durchlaufen musst um Dein dämliches Element zu finden.

Dein Problem ist die Komplexität einer Liste die häufig ein Update erfährt und die zyklisch durchsucht wird.

Evl. solltest Du Dich mal mit den Grundlagen der Informatik beschäftigen.
Insbesondere der Komplexität von Algorithmen.

Danke dir. Jetzt wäre das mit dem O(n) geklärt.

Nun ist aber das andere noch offen. Ob das was MFK beschrieben hat das Problem löst das du angesprochen hast?

MFK

y-vonne schrieb:

Nun ist aber das andere noch offen. Ob das was MFK beschrieben hat das Problem löst das du angesprochen hast?

Das Problem besteht, solange du weiter darauf bestehst, dein Listcontrol linear zu durchsuchen.

Das Problem besteht, solange du weiter darauf bestehst, dein Listcontrol linear zu durchsuchen.

Besteh ich doch gar nicht. Wollte ja nur wissen ob deine Lösung das angesprochene Problem löst. Du meinst ja, was meint Martin?

Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position?

Die Frage wurde nun ganz übersehen. Vieleicht kann darauf auch noch jemand eingehen.

Dann noch zu dem:

Mit O(n) (sprich O von n) wird die Komplexität eines Algorithmus beschreiben.
Der Aufwand für das Finden eines Elementes ist linear und abhängig von der Anzahl der Elemente n. Hierbei fällt nicht ins gewicht ob Du je Element enen Vergleich oder 2 machst...

Da war doch noch was im Hinterkopf. Was ich hier aber noch nicht ganz verstehe. Hier versteh ich nicht warum es keinen Unterschied macht ob ich einen Vergleich mache oder zwei.

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

MFK

y-vonne schrieb:

Besteh ich doch gar nicht.

Doch, tust du. Auf die Hinweise, dass dein Lösungsansatz ineffizient ist, hast du mit

y-vonne schrieb:

Ist ja ok. Ich weiß dass es Zeit braucht. Wollte aber was anderes wissen!!

geantwortet.

y-vonne schrieb:

Wollte ja nur wissen ob deine Lösung das angesprochene Problem löst. Du meinst ja, was meint Martin?

Nein, ich meine nicht ja. Das Problem ist das Suchen im Listcontrol. Da deine Listen recht kurz sind und du außerdem mit einem komplexen benutzerdefinierten Steuerelement arbeitest, dessen Code du vermutlich nicht verstehst, habe ich mich damit abgefunden.

y-vonne schrieb:

Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position?

Die Frage wurde nun ganz übersehen. Vieleicht kann darauf auch noch jemand eingehen.

Es gibt sehr viele Möglichkeiten.

y-vonne schrieb:

DWas ich hier aber noch nicht ganz verstehe. Hier versteh ich nicht warum es keinen Unterschied macht ob ich einen Vergleich mache oder zwei.

Wenn du zwei Strings vergleichst, brauchst du bei der doppelten Anzahl Einträgen die doppelte Zeit.

Wenn du Hash-Werte vergleichst, brauchst du bei der doppelten Anzahl Einträgen die doppelte Zeit.

Wenn du ItemData-Werte vergleichst, brauchst du bei der doppelten Anzahl Einträgen die doppelte Zeit.

y-vonne schrieb:

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

Du kannst dir die ganze Sucherei aber auch komplett sparen, wenn du es richtig anstellst. Aber davon wolltest du nichts hören!

Martin Richter

y-vonne schrieb:

Da war doch noch was im Hinterkopf. Was ich hier aber noch nicht ganz verstehe. Hier versteh ich nicht warum es keinen Unterschied macht ob ich einen Vergleich mache oder zwei.

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

Hör mal eine Vorlesung zu Komplexität von Algorithmen... Das war mal mein Hobby <bg>

Klar fällt es ins Gweicht. Aber das hauptproblem liegt in der Grundkomplexität eben in O(n). Konstante Gaktoren werden weggelassen.

MFK.

Danke für deine Hilfe aber du verdrehst immer komplett alles was ich frage.

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

Du kannst dir die ganze Sucherei aber auch komplett sparen, wenn du es richtig anstellst. Aber davon wolltest du nichts hören!

Weiß nicht was die Antwort hier soll ich wollte hier einfach die Frage der Komplexität klären. Dass ich mir die Suche sparen kann ist mir bereits klar.

Überlass bitte die Fragen die ich an Martin stelle auch Martin. Danke.

dessen Code du vermutlich nicht verstehst...

So wie du meine Anfragen halt nicht verstehst.

Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position?

Die Frage wurde nun ganz übersehen. Vieleicht kann darauf auch noch jemand eingehen.

Es gibt sehr viele Möglichkeiten.

Super das hat mir nun auch sehr viel geholfen

Hör mal eine Vorlesung zu Komplexität von Algorithmen... Das war mal mein Hobby

Tolles Hobby Dank dir Martin für deine Antwort.

MFK

y-vonne schrieb:

Weiß nicht was die Antwort hier soll ich wollte hier einfach die Frage der Komplexität klären

Die Komplexität deiner Lösung in Abhängigkeit von der Listenlänge ist völlig uninteressant, wenn deine Listenlänge begrenzt ist.

Was interessiert es, wie sich die Laufzeit mit wachsendem n entwickelt, wenn dein n nicht wächst?

y-vonne schrieb:

Überlass bitte die Fragen die ich an Martin stelle auch Martin

Du beißt dich an Martins Aussagen fest, die er gemacht hat, bevor du damit rausgerückt bist, dass du maximal 40 Einträge durchsuchen musst.

y-vonne schrieb:

So wie du meine Anfragen halt nicht verstehst.

Ich versuche, dir zu helfen. Ich kann es auch lassen.

y-vonne schrieb:

Super das hat mir nun auch sehr viel geholfen

Deine Frage war, ob es eine andere Möglichkeit gibt. Die habe ich beantwortet. Vielleicht stellst du die falschen Fragen.

Nein, du kannst mit CListCtrl::GetItemData den lParam-Wert direkt auslesen.

Auf den Satz wollte ich auch noch eingehen. Hier kann ich dann den lParam Wert direkt auslesen. Aber das brauche ich ja gar nicht.

Ich habe ja den lParam Wert und möchte mit diesem nun dein Eintrag suchen und aktualisieren.

Und dazu brauche ich doch dann FindItem oder etwa nicht?

MFK

y-vonne schrieb:

Und dazu brauche ich doch dann FindItem oder etwa nicht?

Du brauchst FindItem nicht, aber es ist einfacher und vermutlich schneller, als in einer Schleife GetItemData aufzurufen. Ich wusste nicht, dass man mit FindItem auch nach lParam suchen kann.

Die Komplexität deiner Lösung in Abhängigkeit von der Listenlänge ist völlig uninteressant, wenn deine Listenlänge begrenzt ist.

Ja versteh ich. Ich wollte das mit der Komplexität nur allgemein geklärt haben jetzt nicht im Zusammenhang mit meinem Problem. Und das hat mir Martin auch benatwortet.

Ich versuche, dir zu helfen. Ich kann es auch lassen.

Bin für jede Hilfe dankbar. Aber mit deiner Aussage: "Code den du eh nicht verstehst" greifst du mich an statt zu helfen.

Deine Frage war, ob es eine andere Möglichkeit gibt. Die habe ich beantwortet. Vielleicht stellst du die falschen Fragen.

Das ist genauso wie die folgende Frage mit ja zu beantworten: "Könnten sie mir die Uhrzeit sagen". Klar wenn man den anderen Ärgern will sagt man einfach nur ja.

Also hier nochmals genauer für dich: Welche einfachere Lösung gibt es, als die mit dem Vector?

Du brauchst FindItem nicht, aber es ist einfacher und vermutlich schneller, als in einer Schleife GetItemData aufzurufen. Ich wusste nicht, dass man mit FindItem auch nach lParam suchen kann.

Ja also doch FindItem. Und dann doch die Liste durchgehen. Und vermutlich schneller.

Das ist ja das was ich gesagt habe.

MFK

y-vonne schrieb:

Bin für jede Hilfe dankbar. Aber mit deiner Aussage: "Code den du eh nicht verstehst" greifst du mich an statt zu helfen.

Das ist kein Angriff, sondern eine Feststellung. Eine Lösung, die ohne Suchen auskommt, würde es erfordern, dass du in den Code deines CodeProject-Steuerelements eingreifst. Da das ein Steuerelement mit vielen zusätzlichen Funktionen ist, ist der Code vermutlich recht lang und komplex und damit für jemanden mit deinem Kenntnisstand nicht so ohne weiteres zu durchschauen. Das ist alles.

Also hier nochmals genauer für dich: Welche einfachere Lösung gibt es, als die mit dem Vector?

Erweitere deine Map um einen Zähler, den du beim Einfügen hochzählst, und benutz den für das lParam.