Arrays auf ungleichheit Prüfen

[Zacherl]

Zitat von Glados:

Ich glaube ich habe mich verlesen. Ich dachte hier eher an eine Funktion, der man Parameter übergibt und die Boolean zurückgibt.

So ist es im Grunde auch, nur dass die Funktion als Operator implementiert wurde. Ist halt einfacher/schöner zu verwenden.

[Glados]

Bin ich wirklich so doof?

Delphi-Quellcode:

var
 aA: TArray<string>;
 aB: TArray<string>;
 b: Boolean;
begin
 aA := TArray<string>.Create('1', '2', '3');
 aB := TArray<string>.Create('1', 'B', '3', '4');

 b := '1' in aB;
end;

[himitsu]

Hab's noch nicht selber vollumfänglich ausprobiert ... nur ab und an die Werbetexte und Beispiele in verschiedenen Blogs gesehn.


Ich glaub in 10.2 wurde nochmal was gemacht,
aber in 10.1 fing es damit an.
http://docwiki.embarcadero.com/RADSt...Dynamic_Arrays

String-Like, wobei man es vielleicht besser mit Enum/Set vergleichen könnte, als mit Strings.

[p80286]

Mich würde zunächst einmal interessieren wie die Stör(begin)-Meldung und die Stör(end)-Meldung aussieht.Und wie die entsprechenden Meldungen herein kommen. dementsprechend kann dann die weitere Verarbeitung erfolgen.

Gruß
K-H

P.S.
Auch ich halte ein Array zunächst einmal nicht für die optimale Wahl.

Gruß
K-H

[stahli]

Mal noch ein Versuch, einen geordneten Einstieg zu finden...

Du solltest m.E. mit Klassen arbeiten:

Delphi-Quellcode:

TStoerungStatus = (ssNeu, ssBearbeitung, ssErledigt);

TStoerung = class
  Zeit: TDateTime;
  Bereich: String;
  Meldung: String;
  Status: TStoerungStatus;
end;

Dann hast Du pro Störung ein Objekt. Dieses kannst Du in Listen speichern, verschieben, weitergeben und löschen.

Deine Störungen bekommst Du als HTML-Seite und parst daraus die relevanten Daten. Richtig?
Wie viele solche Meldungen kommen davon in welcher Zeit rein?

Für jeden geparste Störung erzeugst Du ein StörungsObjekt und prüfst, ob dieses schon in der Störungsliste steht.

Hier ist mir unklar, ob die Störungen ggf. mehrfach gemeldet werden und wie Du eigentlich erkennen willst, ob die Störung schon gemeldet wurde.
Eigentlich sollte hier möglichst eine eindeutige ID existieren, damit man die Störungen zuverlässig vergleichen kann.

Wenn sehr viele schnelle Störungen reinkommen sollten, sollte man die Liste sortieren (z.B. eine binäre Suche verwenden), damit die Vergleiche schnell erfolgen können.

Also wenn eine neue Störung reinkommt, erhält sie den Status ssNeu und wird in die Liste gespeichert.

Jetzt können alle neuen Störungen nacheinander bearbeitet werden und erhalten den Status ssBearbeitung.

Wenn diese dann erledigt sind erhalten sie den Status ssErledigt.

Erledigte Störungen können dann in die Datenbank gespeichert und aus der Liste gelöscht werden.


Eine Alternative zu dieser Statuslösung wäre die Verwendung von 3 Listen (Eingang, Bearbeitung, Erledigt) und die Objekte dann von einer in die nächste Liste zu schieben.

Da ich Deinen Ablauf immer noch nicht verstanden habe, ist das vielleicht mal ein kleiner Vorschlag, um sich der Sache anzunähern.

[mensch72]

Mein Ansatz wäre im Prinzip ähnlich dem von Stahli gerade vorgeschlagenem, das mit getrennten Dictionarys zu lösen... und ganz wichtig: eine eigene CompareFunktion, weil man so einfach selbst bestimmt was wie verglichen werden soll... das ist zu 99% viel passender wie ein "zwangsweise 100% binary egual" ArrayVergleich per Operator durch den Compiler

- also alles zunächst wie gewollt im erste "LiveDictionary" zufügen bzw. aktualisieren
- dann z.B. im Timer alles(per "for each") aus dem "LiveDictionary" im ersten "LiveDictionary" auf Vorhandensein prüfen und wenn ja aktualisieren bzw. sonst zufügen und passendes auslösen
- usw...

Das mit dummen Arrays zu machen ist uneffektiv. Dictionarys mit dummen Records wären da sicher schonmal etwas besser und eleganter. Wenn es "schön" werden soll, das das Ganze mit/in eigener Storage-Klasse kapseln und dort auch die zugehörigen internen Comparer mit unterbringen... Mr. Rabe würde gleich noch ein ZugriffsInterface und ein SpeicherInterface designen, dann wird es sogar nebenbei universell erweiterbar/austauschbar.

Auch bei QuickAndDirty würde ich bei uns mindestens ne Kombi aus einer eineindeutigen "globalen/gesamt" TObjectList(oder "=" DB-Tabelle) UND separaten Dictionarys[HASH->"ol"INDEX](oder "=" DB-Zuordnungstabellen) für deine verschiedenen (Zeit)Kategorien und/oder States aller Störungen realsieren und das in einer eindeutig benannten Klasse(hier z.B. "Störungen") kapseln.

Dies entspricht der Tatsache, das dein Problem bei uns unter dem allgemeinem Sichwort "JobList" liefe und per "DesignRule" nach diesem allgemeingültigen internem Grundkonzept gelöst werden würde.