Hi Leute,

ich brauche einen "Progress-Monitor", auf den ich per VBScript aus einer Anwendung heraus zugreifen kann.

Da ich auf COM-Objekte zugreifen kann, bietet sich eine Klassen-Bibliothek mit einem entsprechenden Dialog, bzw. Form an.

So in etwa sollte ich darauf zugreifen können:

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Dim intIndex Dim objDialog Set objDialog = CreateObject("ProgressBar.Dialog")   'setup dialog Call objDialog.SetCaption("Test") Call objDialog.ShowCancelButton(True)   'show dialog Call objDialog.Show()   'do some work in a loop Do While WorkIsAvailable()     Call DoWork()     If objDialog.IsCanceled() Then         Exit Sub     End If     Call objDialog.advanceProgress() Loop   'hide dialog Call objDialog.Hide()

Wir hatten bereits eine VB6.0 Version eines solchen Progress-Monitors, der auch sauber funktionierte. Allerdings will der Kunde (sehr großer, mächtiger Kunde) aus irgendeinem Grund, dass diese Bibliotheken zukünftig in .NET geschrieben werden.

Also habe ich mir mit C# einen solchen "Progress-Monitor" gebastelt:

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

// (C# Code; limitiert auf die Attribute und Methoden die ich für wichtig halte)   public partial class Dialog : Form {     private bool _isCanceled = false;       public void advanceProgress() {         this.progressBar.Increment(1);     }       private void cmdCancel_Click(object sender, EventArgs e) {         this.cmdCancel.Enabled = false;         this._isCanceled = true;     }       public bool isCanceled() {         return this._isCanceled;     } }

Funktioniert auch ganz prächtig - solange man den "Cancel-Button" nicht benötigt.
Denn durch rapides Aufrufen der Methode "advanceProgress()" wird die Form "unantastbar", da der GUI-Thread "busy" ist.

Normal würde man ja zeitintensive Geschichten in einem extra Thread laufen lassen (z. B. mit einem Worker), damit das nicht passiert, aber in dem Fall geht das wohl schlecht.

Hat jemand eine Idee, wie ich das Problem lösen könnte?

Vielen Dank schonmal für's Durchlesen

Mit freundlichen Grüßen

Lawyno

Zitat von Lawyno

Normal würde man ja zeitintensive Geschichten in einem extra Thread laufen lassen (z. B. mit einem Worker), damit das nicht passiert, aber in dem Fall geht das wohl schlecht.

Wieso sollte das denn nicht gehen?

Du kannst nach in der Methode noch Application.DoEvents aufrufen, jedoch ist das Handling im Thread sauberer und sicherer

Zitat von Nico Graichen

Wieso sollte das denn nicht gehen?

Du kannst nach in der Methode noch Application.DoEvents aufrufen, jedoch ist das Handling im Thread sauberer und sicherer

Naja... dadurch, dass die "Arbeit" von dem VBScript verrichtet wird, kann ich ja schlecht die "Arbeit" in einen extra Thread verlagern.

Aber erzähle mir bitte etwas mehr über Deine Theorie mit "Application.DoEvents", das hört sich nämlich interessant an
Allerdings bin ich noch recht unerfahren, was diese .NET-Geschichten angeht

E D I T :
Öhm... sorry, für die blöde Frage... "Application.DoEvents();" wirkt wahre Wunder!

Danke