C# / VBScript - Wie kann ich verhindern, dass mein Dialog "unantastbar" wird?

Lawyno

Grünschnabel
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:
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:
// (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
 
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
 
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 :)
 
Zuletzt bearbeitet:
Zurück