uko - Fr 23.01.09 16:31
Titel: 'Keine Rückmeldung' unter VISTA vermeiden

---

Hallo,

ein Programm von mir benötigt beim Speichern der Daten einiges an Zeit, wo das GUI keine Meldung bekommmt. Unter Vista bedeutet das nun, daß immer die Meldung 'Keine Rückmeldung' im Programmfenster erscheint. :)
So, die Lösung, das Speichern in einen Thread auszulagern, geht nicht, da ich das HauptGUI wirklich sperren muß für jede Art von Eingaben (insbesondere Mausevents). Auch die Variante mit CallBacks scheidet aus, da ich auf die Speicherroutine keinen wirklichen Zugriff habe und dort nichts selbst einbauen kann (und keine Callbacks vorhanden sind).
Frage: gibt es irgendeine Möglichkeit, einen zweiten Thread zu starten, der dann VISTA mitteilt, das das Programm noch aktiv ist?
Bis jetzt hab ich versucht, aus dem zweiten Thread jede Sekunde ein nicht verbrauchendes PeekMessage aufzurufen, aber das hat nicht geholfen (gab's da nicht was mit getrennten Message-Queues?).


Grüße,
Uli

Delete - Fr 23.01.09 16:37

---

uko hat folgendes geschrieben :

da ich das HauptGUI wirklich sperren muß für jede Art von Eingaben

Dann deaktivier doch einfach die Kontollelemente, die nicht benutzt werden dürfen während der Thread arbeitet.

Maweki - Fr 23.01.09 16:37

---

In deiner Hauptschleife

aufzurufen, bringt nichts? (oder gibt das auch die Buttons frei?)

uko - Fr 23.01.09 16:48

---

@Luckie: das geht leider nicht: ich arbeite mit InkOverlays aus Microsofts Ink Komponenten und die reagieren teilweise sehr allergisch mit Hängern, wenn sie nicht aus dem Hauptthread aufgerufen werden bzw. wenn man sie mal eben deaktiviert. :evil:

@Maweki: das würde Callbacks in der Speicherroutine bedeuten die ich nicht einbauen kann.

Grüße,
Uli

BenBE - Fr 23.01.09 18:43

---

uko hat folgendes geschrieben :

@Luckie: das geht leider nicht: ich arbeite mit InkOverlays aus Microsofts Ink Komponenten und die reagieren teilweise sehr allergisch mit Hängern, wenn sie nicht aus dem Hauptthread aufgerufen werden bzw. wenn man sie mal eben deaktiviert. :evil:

Bugreport an Microsoft und andre Komponenten suchen. Komponenten, die nicht stabil laufen, haben nichts in einem Programm zu suchen! Punkt.

uko hat folgendes geschrieben :

@Maweki: das würde Callbacks in der Speicherroutine bedeuten die ich nicht einbauen kann. Grüße, Uli

Du kannst deine gesamte Form deaktivieren (gegen Eingaben) oder mit ShowModal ein Fortschrittsfenster öffnen, was so eine nichtssagende Vista-Fortschritsbalken-Animation abspielt. Das ShowModal verhindert, dass irgendein anderes Formular außer dem aktiven, den Fokus erhalten kann, oder Eingaben erhält. Die Animation läuft dabei im Hauptthread über nen Timer, dein Hauptprogramm bleibt dabei aktiv. Das eigentliche Speichern wird im Hintergrund ausgeführt (von deinem zusätzlichen Thread). Das modale Fenster kannst Du dann über eine Synchronize-Meldung vom Thread am Ende schließen lassen.

jaenicke - Fr 23.01.09 18:45

---

uko hat folgendes geschrieben :

ich arbeite mit InkOverlays aus Microsofts Ink Komponenten und die reagieren teilweise sehr allergisch mit Hängern, wenn sie nicht aus dem Hauptthread aufgerufen werden bzw. wenn man sie mal eben deaktiviert. :evil:

Hast du da vielleicht eine kleine Demo? Vielleicht lässt sich ja herausfinden warum das bei dir so ist.

uko - Fr 23.01.09 22:19

---

Generelles Problem hier: die Fehler bekomme ich von Kunden rein, aber keiner kann davon auf unseren Testsystemen nachvollzugen werden, selbst bei identischer Hardware. Und die Aktionen sind einfach: normales Scrollen oder auch nur das Umschalten in den Vollbildmodus (hier kann man nichts anders bedienen als die Kunden). Die MadExcept-Reports sagen entweder OLEFehler (mit Fehlernummer zu der man nichts findet) oder das Programm stürzt z.T. so komplett ab, daß nicht mal mehr Fehlerreports produziert werden.
Deswegen will ich auch unbedingt im Hauptthread speichern. Nur so kann ich sicher sein, daß mir nichts ins InkOverlay reinfunkt. Auch kein Repaint oder ähnliches.

@BenBE: sagst Du so einfach, die Komponenten zu ersetzen. Es gibt meines Wissens zu den Inks keine Alternative. Und die erste Version des Programms ist eigentlich sehr stabil gelaufen. Das Problem ist mit der neuen Version: hier arbeiten wir sehr viel mehr mit den InkOverlays. Und da gibt es nun anscheinend Probleme.

@jaenicke: Eine wirkliche Demo hab ich nicht. Ich hab mir zwar ein Testprogramm gebastelt, mit dem so ähnliche Fehler wie in der richtigen Anwendung auftreten (d.h. man hat eine reelle Chance, daß sie bei mehreren Versuche wenigstens einmal auftreten), aber selbst hier ist es fast nicht reproduzierbar. Und den eigentlichen Fehler ist bisher nur einmal damit reproduziert worden.

Das Problem ist halt: keiner dieser Fehler ist permanent reproduzierbar. Mal geht's , mal geht's nicht. Das Problem ist vermutlich: InkObverlays senden ihre Events aus einem eigenen Thread heraus. Die Message Handler werden dann aber wiederum im Context des Hauptthreads ausgeführt. Somit hab ich zwei Message Queues die in der Anwendung unter einen Hut zu bringen sind: Problem hier: während z.B. die VCL schon weiter Scroll-Messages abarbeitet, ist vom InkOverlay aber vieleicht noch nicht mal die erste losgeschickt worden. Und wenn diese dann kommt, trifft sie auf einem Zustand der nicht mehr dem ursprünglichen entspricht und das Overlay ist schon in einem Zustand der dem Event widerspricht.

Aber jetzt wird's wohl reichlich OT :) Bei Interesse mach ich eine neue Frage auf.

Grüße,
Uli

Delete - Fr 23.01.09 23:35

---

uko hat folgendes geschrieben :

@Luckie: das geht leider nicht: ich arbeite mit InkOverlays aus Microsofts Ink Komponenten und die reagieren teilweise sehr allergisch mit Hängern, wenn sie nicht aus dem Hauptthread aufgerufen werden bzw. wenn man sie mal eben deaktiviert. :evil:

Dann deaktivier die Steuerelemnete aus dem Hauptthread bevor du den Thread startest, dann startest du den Thread und wenn der fertig ist aktivierst du sie wieder aus dem Hauptthread. Das ist sowieso für mich die übliche Vorgehensweise. Alles, was mit der GUI zu tun hat wird aus dem Thread der GUi gemacht und der Rest aus einem abgespalteten Thread.

BenBE - Sa 24.01.09 01:30

---

Bliebe ein Versuch des ShowModal-Weges, ob der sauber funzt.

@Ersetzen: Manchmal bringt es halt nichts, an Dingen festzuhalten, wenn diese nicht funktionieren ;-)

uko - Sa 24.01.09 08:19

---

Ja, ich werd mir das mit dem modalen Fenster und Helperthread genauer anschauen. Jetzt aber erst mal Wochenende! :party:
@BenBE: Glaub nicht, daß Cheffe da sehr begeistert wäre; mit dem Programm wir dienen wir einen Großteil unseres Gelds. Und es läuft ja bei einem Großteil der Kunden stabil. :D

Grüße,
Uli