Rekursion.

Du brauchst eine eigene Methode, die einen Ordnerpfad als Parameter entgegennimmt und die Anzahl der enthaltenen Dateien zurückgibt. Sollte der Pfad weitere Ordner enthalten, lässt du die gleiche Methode mit dem neuen Ordner aufrufen. Das umschließt du mit einen try-Block und fängst die Ausnahme ab, damit solche System-Ordner übersprungen werden.

Du findest sicherlich genug Beispiele dazu im Internet.

Das ToolStripMenuItem in der obersten Ebene (also das Stammelement des MenuStrip, häufig "Datei", "Bearbeiten", "Hilfe", etc.) kann zwar auch "Checked" sein, wird allerdings nicht durch einen Haken visuell dargestellt. Möglicherweise hast du dadurch den Eindruck, dass nichts passiert.

Versuche, ob das Problem bei einem untergeordneten ToolStripMenuItem ebenfalls auftritt.

Du könntest den Text zerlegen (Trennzeichen wäre der Zeilenumbruch) und das Ergebnis in einem Array speichern. Mit einer Schleife durch jedes Element iterieren und mit deinem gesuchten Wort vergleichen.

Wenn du eine For-Schleife nimmst, dann kannst du über die Laufvariable den Index der Zeile herausfinden.

Was hat dir an meiner Antwort in der vorherigen Frage nicht gepasst? Du hättest es ja auch kommentieren können, wenn es nicht deiner Erwartung entspricht.

So genau habe ich die Verbindung zur Datenbank nicht verstanden. Aber wenn du für jede Zeile die 5. Spalte anpassen willst, dann geht das mit folgendem Code:

For Each row As ListViewItem In ListView1.Items
    ' Für jede Zeile wird der Text aus der fünften 
    ' Spalte mit "Neuer Text" ersetzt.
    row.SubItems(4).Text = "Neuer Text"
Next

Vielleicht kannst du das Problem aber nochmal genauer erläutern. Wann kommen welche Daten? Wann soll unter welcher Vorraussetzung was geändert werden?

In der Reference Source zur Replace-Methode der String-Klasse des .NET Frameworks steht als Kommentar:

// This method contains the same functionality as StringBuilder Replace. The only difference is that
// a new String has to be allocated since Strings are immutable

Die Replace-Methode der StringBuilder-Klasse sieht dann folgendermaßen aus: http://referencesource.microsoft.com/#mscorlib/system/text/stringbuilder.cs,99b1a99cf6684774

Fizzbuzz ist ein beliebter Algorithmus bei Bewerbungsgesprächen in der IT-Branche (wenn auch nicht zwingend in Deutschland).

Da gäbe es zum Beispiel diese Möglichkeiten für die unterschiedlichsten Programmiersprachen: https://discourse.codinghorror.com/t/fizzbuzz-solution-dumping-ground/1752

Für die etwas anspruchsvolleren Entwickler: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

Obwohl ich in der Enterprise-Edition nicht verstehe, wieso ein vordefiniertes Array verwendet wurde, anstatt der Rechenvorschrift. Na ja, wie dem auch sei. Viel Spaß.

Irgendwie so:

ListView1.Items(5).SubItems(4).Text = "Modified"

ObjShell.Popup "Beispiel", 3, "Beispiel"

Das Usercontrol ist in Sachen Fokus eine seltsame Geschichte.

Am einfachsten wäre es, die Enabled-Eigenschaft auf False zu setzen. Dabei werden automatisch alle Child-Controls auch auf Enabled = False gesetzt und ist über den Tab nicht mehr zu erreichen.

this.SetStyle(ControlStyles.Selectable, false) wäre auch eine Möglichkeit, aber dann kannst du nicht mehr von einer TextBox des UserControls in eine andere TextBox eines anderen UserControls mit Tab springen.

Gibt sicher noch andere Möglichkeiten, da wird es dann aber etwas komplizierter.

"Visual Basic" ist nicht eindeutig. Es gibt verschiedene Sprachen, die "Visual Basic" im Namen haben, darauf aufbauen, sich aber dennoch (sehr) unterscheiden.

VBS - Visual Basic Script. Damit könnten dynamische Webseiten oder kleinere Skripte erstellt werden. Im Grunde ist das aber eine tote Sprache und hat einige Nachfolger bzw. bessere Alternativen.

VBA - Visual Basic for Applications. Damit kannst du Makros für Microsoft Office Produkte schreiben, typischerweise Word und Excel. Die Anwendungen lassen sich mit solchen Makros annähernd fernsteuern und automatisieren.

VB - Visual Basic. Allgemein ist VB eine objektorientierte Programmiersprache und wird meist in Zusammenhang mit der Version benannt, also z.B. VB6 oder VB7, VB8 und so weiter. VB6 ist dabei eine ältere Version, die eine andere Laufzeitumgebung nutzt, als VB7. VB7 ist die erste Version, die auf dem .NET Framework basiert und daher auch VB.NET genannt wird. Die Unterschiede zu VB6 sind enorm. Das .NET Framework ist eine riesige Ansammlung diverser Programmbibliotheken, die für die unterschiedlichsten Aufgaben konzipiert sind. Im Grunde kannst du damit jede typische Desktop-Anwendung erstellen. Wie in den meisten Programmiersprachen kannst du die Windows API direkt nutzen oder andere nicht auf dem Framework basierten Bibliotheken einbinden und nutzen, wodurch du mehr Möglichkeiten zur Verfügung hast.

Ich selbst arbeite zu Hause und im Beruf mit VB.NET (in der aktuellsten Version) und bin sehr zufrieden. Aufgrund der geringen Symbolik und dem vemehrten Einsatz grammatikalischer Aspekte, lässt sich die Sprache sehr leicht lernen und flüssig programmieren. Der große Funktionsumfang erleichtert ebenfalls die Umsetzung diverser Aufgaben.

Ein Vorteil ist auch die Konvertierung zwischen VB.NET und C# Anwendungen (da beide auf .NET beruhen).

Die beiden Schleifen bilden im Grunde das Kleine/Große/Mittlere (welches auch immer) 1x1 ab.

Die äußere Schleife ist der erste Faktor i von 2 bis 50. Die innere Schleife ist der zweite Faktor j von 2 bis Größtes-Produkt-Kleiner-Gleich-MAX. Ich habe das mal in einer Excel-Tabelle dargestellt. Vertikal ist i, horizontal ist j. Die Zahlen mit dem roten Hintergrund sind jene Produkte, die sich aus den Schleifendurchläufen ergeben. Diese Produkte sind keine Primzahlen und werden deswegen mit

aByte(i * j) = 0 

gesetzt. (Offensichtlich steht 1 für "ist Primzahl" und 0 für "ist keine Primzahl".)

Zahl1 ist der Inhalt, bevor du auf eine Rechenoperation klickst. Zahl2 ist der Inhalt, bevor zu auf das Gleichheitszeichen klickst. Das Ergebnis wird dann in Zahl1 zusammengefasst und angezeigt.

Wenn man programmieren möchte, hilft es häufig sich das Problem auf Papier klar zu machen - oder in einem Textverarbeitungsprogramm am PC - oder ... je nachdem, was einem lieber ist.

Zuerst zu deinem Problem: Application.DoEvents steht an der falschen Stelle. Wenn dich die Erklärung für das Verhalten interessiert, dann lies weiter, ansonsten springe zum nächsten Absatz nach der Liste. Schritt für Schritt sieht der Ablauf so aus:

• Erster Durchlauf: Du setzt den Wert auf 10 und weist diesen Wert dem Label zu. Das Label hat nun von Windows eine Anforderung zum Neuzeichnen erhalten und wird diese ausführen, sobald die MessageQueue verarbeitet wird. (Das passiert noch nicht, weil der aktuelle Thread noch in der For-Schleife arbeitet.)
  
• Im zweiten Durchlauf setzt du den Wert auf 10 und erlaubst die Abarbeitung der MessageQueue durch Application.DoEvents. Das Label darf nun seinen Inhalt aktualisieren und zeigt den Wert 10 an. Erst dann weist du dem Label den neuen Wert 20 zu. Gleiches Spiel: die Anforderung zum Neuzeichnen landet in der MessageQueue und wird bei der nächsten Abarbeitung ausgeführt. Aber auch das passiert erst im nächsten Durchlauf.
• Im vorletzten Durchlauf ist der Wert der ProgressBar 90 und das Label darf dann erst seine 80 aus der vorherigen Anforderung zeichnen.
• Im letzten Durchlauf passiert das gleiche. Allerdings ist der Thread danach frei (kein Thread.Sleep) und kann sofort die MessageQueue erneut abarbeiten und somit die 100 anzeigen. Die 90 wird also vorher angezeigt, aber nur für den Bruchteil einer Sekunde (wenn überhaupt).
  

Wenn du Application.DoEvents nach der Wertzuweisung des Labels schreibst, funktioniert es wie gewollt.

Nun zum anderen Problem: Nichts ist nerviger als ein simulierter Fortschritt. Eine ProgressBar, die ihren Wert in Abhängigkeit einer (zur Entwurfszeit) definierten Zeit verändert hält den gesamten Programmablauf auf und hat ohne Multithreading wenig Sinn.

Typischerweise (sofern nichts geändert wurde) wird die Anwendung beendet, wenn die Startform geschlossen wird.

Es kann sein, dass das Startformular versteckt wurde (Hide) und somit nicht geschlossen werden kann. Dadurch bleibt die Anwendung aktiv.

Du könntest zum Test einfach mal schauen, was dir "My.Application.OpenForms" so ausgibt, wenn dein Fenster geschlossen wird. Damit lässt du dir alle geöffneten Fenster anzeigen.

Wo kommst du nicht weiter? Beim Ermitteln der Position, an der der Benutzer auf der ProgressBar geklickt hat? Beim Umrechnen der Position in die Zeit? Beim Abspielen der Musik ab dieser Zeit?

Ein paar mehr Informationen wären hilfreich.

Die zweite If-Abfrage ist unnötig, wenn du eine Ausnahmebehandlung verwendest. Das sollte man grundsätzlich beim Zugriff auf das Dateisystem.

try
{
    if (!System.IO.Directory.Exists(sPath))
        System.IO.Directory.CreateDirectory(sPath);

    System.IO.File.WriteAllText(sPath + "Datei.txt", "Inhalt");

}
catch (Exception ex)
{
    // Ausnahme beim Erstellen des Verzeichnisses oder Schreiben der Datei.
}

In dem Beispiel sollte der Catch-Block für eine spezielle Ausnahme angepasst und die gesamte Anweisung um weitere relevante Catch-Blöcke erweitert werden. Denkbar wäre auch eine geschachtelte Try-Anweisung, um das Erstellen des Verzeichnisses und Schreiben der Datei zu trennen. (Das wäre die bessere Variante.)

Das Lesen der Datei kannst du dann über die ReadAllText-Methode der File-Klasse realisieren. Was da wo entschlüsselt werden muss ist mir nicht klar, weil nirgends in deinem Code eine Verschlüsselung zu sehen ist.

ILSpy.

Der dekompilierte Code ist aber an einigen Stellen sehr kurios, wenn auch gleich funktionell wie der ursprüngliche Code.

Bei Kryptographie ist es immer sehr gefährlich, wenn man selbst wenig Einblicke hat. Wenn man dann gefundenen Programmcode nicht versteht, kommt es unweigerlich früher oder später zu solchen Problemen.

Deine Encrypt- und Decrypt-Methode mit jeweils einem Parameter können nicht funktionieren, weil du bei jedem Aufruf einen neuen Key erzeugst. Dann ist es natürlich klar, dass du eine Ausnahme erhälst, wenn du eine Datei mit einem Key entschlüsseln willst, der nicht für die Verschlüsselung verwendet wurde.

In dem verlinkten Beispiel wird jeweils der selbe Key verwendet für die Ver- und Entschlüsselung. Das solltest du auch tun.

Entweder das, was PWolff erwähnt (mit hoher Wahrscheinlichkeit) oder der auszuführende Programmcode nimmt zu viel Zeit in Anspruch (geringere Wahrscheinlichkeit für das genannte Problem).

Eine leere Form mit einer Picturebox, die bei einem Klick und einem Doppelklick einen Zähler inkrementiert, schafft bei mir 1000 Klicks innerhalb der nachfolgenden Zeiten:

01. Durchlauf: 305 ms
02. Durchlauf: 300 ms
03. Durchlauf: 299 ms
04. Durchlauf: 302 ms
05. Durchlauf: 313 ms
06. Durchlauf: 300 ms
07. Durchlauf: 306 ms
08. Durchlauf: 300 ms
09. Durchlauf: 240 ms
10. Durchlauf: 304 ms
11. Durchlauf: 301 ms
12. Durchlauf: 303 ms
13. Durchlauf: 298 ms

Realistisch ist der Test zwar nicht, wenn nur ein Zähler inkrementiert wird, zeigt aber das Potenzial. Für den "typischen" Entwickler reichen die .NET Methoden bestens aus. Da gibt es keinen Grund eigene Methoden mit direktem API Aufruf zu schreiben.

Irgendwie so:

MsgBox("Inhalt", vbDefaultButton2 Or vbApplicationModal, "Titel")

Natürlich müssen den Konstanten die richtigen Werte zugewiesen werden.