TMS TDBAdvGrid und regelm. Refresh

[Medium]

Ich bin heute endlich wieder dazu gekommen mich darum zu kümmern. Leider mit keinem Erfolg auf ganzer Linie. Ich habe alle Vorschläge hier ausprobiert, aber das Grid bleibt felsenfest bei deinem Rumgezuckel. Before/AfterScroll waren auch meine Favoriten, leider bezieht sich das aber auch nur auf das DataSet - heisst: Wenn ich im Grid den Scrollbalken noch "in der Hand" habe, wird dennoch das Refresh durchgeführt, da der Zeitraum zwischen den Events ja leider nur das gaaanz kurze Stück genau beim Wechsel des aktiven Datensatzes ist.

Auch der TMS Support konnte mir keinen Lösungsweg aufzeigen. (Sind Refreshes in Grids mit Scrollbalken so exotisch!?)

Meine bisher letzte Idee war es OnMouseDown/Up meinen Timer zu schalten, nur leiiider wird das Event nur bei Klicks im Clientbereich des Grids ausgelöst, nicht auf dem Scrollbalken. Wie könnte ich denn da evtl. dran kommen?

[shmia]

Zitat von Medium:

Sind Refreshes in Grids mit Scrollbalken so exotisch!?

Eigentlich schon!
Wenn du alle 2 Sekunden ein Dataset refreshst und damit alle 2 Sekunden die immer gleiche SQL-Query absendest missbrauchst du die Datenbank für einen Zweck für die sie nicht konstruiert wurde.

Eine Datenbank ist kein Subsystem dass man im Pollingbetrieb ständig abfragen sollte.
Dein Problem ist also nicht das Grid, sondern die Ursache liegt viel tiefer am Design deiner Anwendung.

[Medium]

Ich wüsste nicht wirklich, wie ich die folgende Situation ohne jetzt Mannwochen in ein eigens dafür entwickeltes Subsystem sonst sinnvoll abbilden sollte:

Teilnehmer: Eine bzw. mehrere S7 SPS, ein Server, N Clients

Unser Serversprogramm pollt ständig Informationen aus der SPS, und speichert Werte in die SQL DB. (Welche Werte wann wo in welche Tabellen sollen ist wiederum in einer Tabelle hinterlegt.) Unter diesen Daten befinden sich alle möglichen Dinge: Anlagenzustände, Behälterfüllstände, Rezept-Daten, Analogmesswerte (z.B: Temperaturen, Drücke), Wägedaten, einfach alles, was in einer industriellen Produktionsanlage so anfällt.
Die Clients haben die Aufgabe, diese Daten in eine für die Bediener sinnvolle Form zu bringen und darzustellen. Darunter sind visuelle Komponenten zur Anzeige von Zuständen, und auch eine ganze Latte an Tabellen. Konkret geht es mir hier besonders um die Behälter-Tabelle, in der alle Behälter gelistet sind, mitsamt ihren Füllständen, aktuellen Stoffen und anderen ihnen zugehörigen Randdaten, von denen sich einige stets ändern.
Wenn der Bediener jetzt diese Tabelle offen hat, und etwas im Prozess passiert, oder ein anderer Client ändert etwas, so muss auch ein gerade woanders betrachtetes Grid diese Änderungen unbedingt wiederspiegeln. Die einzige Stelle, an der die Änderung passiert ist, ist die Datenbank, und diese muss Maßgeblich bleiben, weil sich auch Routinen im Server darauf beziehen. Und MySQL bietet imho kein Eventsystem, also muss ich das, so glaube ich zu wissen, doch pollen. Und selbst mit Eventsystem: Die Änderungen würden ebenfalls oft genug (öfter sogar) statt finden, und beim Refresh wieder das Problem beim scrollen verursachen.

Ein ähnliches Eventsystem habe ich im Server für die visuellen Komponenten gebaut: Es wird nur bei Änderungen in die DB geschrieben, und an die Clients via TCP mitgeteilt in welcher Tabelle sich bei welchen SatzIDs etwas geändert hat. Nur das hilft mir ja auch nicht weiter, da ich im Grid ja nicht nur einzelne Zeilen updaten kann.

[stahli]

Bleibt denn die Anzahl und Reihenfolge der "Messstände" i.d.R. gleich?
Oder ändern die sich oft?
Die Daten werden nur angezeigt - oder?

Vielleicht wäre es günstiger, die Daten in einem Stringgrid oder ListBox oder in Panels innerhalb einer Scrollbox (jedes Panel könnte eine Id erhalten und den zugehörigen Datensatz repräsentieren) darzustellen.
Du musst zwar die Darstellung dann von Hand veranlassen, hast aber mehr Kontrolle.

(Wurde, glaube ich, schon mal empfohlen.)

[Medium]

In dieser Tabelle bleibt das alles gleich, ja. Leider ist das für andere Tabellen nicht der Fall: Dort ändert sich die Zeilenanzahl. Das Problem welches ich mit einer komplett neuen Darstellungsmethode habe ist, wie oben schon mal angedeutet, dass ich dann eine ziemliche Fülle von Features des TMS Grids "from scratch" neu implementieren müsste, und das einheitliche Design den Bach runter wäre, wenn ich dann nicht alle Grids im Projekt dahingehend ändere. Und das wären schon ein paar... Wir reden hier von geschätzten Wochen, die ich a) nicht habe, und b) mir keiner bezahlt, und c) für dessen Einsparung wir ja u.a. TMS gekauft hatten . Das ist eine alles andere als machbare Lösung, und steht irgendwie auch in keinem Verhältnis zum eigentlichen Problem: Scrollen!

Aber mir kommt gerade noch eine doofe Idee: Das Grid in eine Scrollbox hauen. Jetzt hoffe ich nur, dass das doofe Ding eine Möglichkeit bietet seine Höhe an die Datensatzanzahl anzupassen. Im Zweifel muss ich dann eben Filter bieten, damit das nicht zu viele werden an 2-3 Stellen.