Laden...
65 Antworten
6,839 Aufrufe
Letzter Beitrag: vor 19 Jahren

@ FIl:

und warum?

gleich rutscht mir wieder das aufbauende Microsoft-Zitat raus g

der marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

Soweit ich mich erinnere hatte das was mit automatischen casts zu tun, die der compiler bei der einen schreibweise macht und bei der anderen nicht. Genau weiß ich das aber nciht mehr.

Ja, aber wenn es auf meinem System funktioniert, dann müsste es doch auch auf seinem funktionieren...

Hab jetzt gesehen, dass lowrider VisualStudio 2003 verwendet, also Net 1.1. Das von uns beschriebene funktioniert nur unter .Net 2.0 also #Develop2 oder VS 2005! 🙂

der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

Original von lowrider
Eine Frage habe ich noch...

Wieso Akzeptiert der Compiler diese Zeile nicht...

System.Threading.Thread t = new System.Threading.Thread( delegate() { listBox1.Items.Add( text );} );  

und meldet beim ausdruck delegate, dass dies kein gültiger Ausdruck sei....???

mfg
low

Des geht auch erst ab 2.0 wo anonyme Delegate erlaubt sind. Benutzt du evtl. 1.1?

Baka wa shinanakya naoranai.

Mein XING Profil.

Ja, er benutzt 1.1 ... 🙂

Ja ich benutze 1.1; Bin ich wohl ehr der einzige hier 😛....Aber naja es hat seine Gründe.

Also neben dem Problem das ich immer noch hab mit der listbox habe ich noch ein neues Festgestellt...

Wie in meinem Code beschribe öffne ich ja eine Process und lasse ein Patch installieren...

Irgendwie wartet dieser aber bei der Zeile

p.WaitForExit();

nicht sondern geht weiter....
So erhalte ich nun ständig eine Meldung das Bereits ein Reader (für Datenbankzugriff) geöffnet sei und deshalb kein neuer geöffnet werden kann... obwohl ich am Ende der while(myReader.Read()) Schlaufe

ein myReader.Close() platziert habe...
hmmm es ist zum Mäusemelken 😉

kennt einer dieses Problem??

mfg
low

myReader.Close() reicht nicht.

Ich setze ihn immer auf null und erzeuge dann einen neuen ...

Zum ersten Problem:
Der Thread wartet schon beim WaitForExit. Aber (da asynchron) der Aufrufer nicht auf den Thread ... (war ja auch sinnn der sache , wenn ich mich recht erinnere).

Ja klar macht das mit den Threads wahr ja auch so 😉....

Aber das mit dem Reader, macht mir noch recht kopfzerbrechen.....

Hier den Aktuellsten Code nochmals....

btn_Klick_Methode


		btn_Install.Enabled = false;
			Hide();
			dlg_install.countItem((listPatches_Standart.CheckedItems.Count + listPatches_Erweitert.CheckedItems.Count));
			if(check_dlgHintergrund.Checked == true)
			{
				dlg_install.Hide();
				dlg_hintergrundmodus();
			}
			dlg_install.Show();
			MyDelegate d = new MyDelegate(dlg_install.install_XP_Standart);
			for (int i = 0; i < listPatches_Standart.CheckedItems.Count; i++)
			{
				string Source_Pfade = listPatches_Standart.CheckedItems[i].SubItems[0].Text;
				d.BeginInvoke(Source_Pfade, null, null);		
			}
}
			

install_XP_Standart Methode


		public void install_XP_Standart(string Source_Pfad)
		{
			try
			{
				prcBar_Install.Value += 1;

				if(db.TryToConnectBD() == false)
				{
					MessageBox.Show("Keine Datenbank --> Der Vorgang wird abgebrochen");
					return;
				}
				OleDbCommand ac = new OleDbCommand();
				ac.CommandText = "Select * from Windows_Update_XP";
				ac.Connection = db.m_cnnWinUpdateVerw;
				OleDbDataReader myReader = ac.ExecuteReader();
				while(myReader.Read())
				{
					string dbSource_Pfade = myReader["Source Pfad"].ToString();
					if(dbSource_Pfade == Source_Pfad)
					{
						if((Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Updates\Windows XP\SP3\" + myReader["KB-Nr"].ToString()))== null)
						{
							Process p = new Process();
							p.StartInfo.Arguments = myReader["Source Pfad Parameters"].ToString();
							p.StartInfo.FileName = @"Data\winxp_standart\"+ myReader["Source Pfad"].ToString();
							p.Start();
							p.WaitForExit();
							listBox1.Items.Add(Source_Pfad + ": \t wurde Installiert");
							//listBox1_AddItem(Source_Pfad + ": \t \t wurde Installiert");
	
						}
						else
						{
							listBox1.Items.Add(Source_Pfad + ": \t war bereits Installiert");
							//listBox1_AddItem(Source_Pfad + ": \t \t war bereits Installiert");	
						}
					}
				}
				myReader.Close();
			}
			catch(InvalidOperationException e2) //Fehlerbehandlung falls Verbindung nicht steht
			{
				MessageBox.Show(e2.Message);
			}
			catch(Exception e2)//Allg.  Fehlerbehandlung
			{
				MessageBox.Show(e2.Message);
			}
	
		}

Ich weiss das wegen den listboxen....muss noch geändert werden..😜

Also erstmal kannst Du nicht über die BeginInvokes iterieren! Zumindest nicht so, wie Du es machst ...

Dann ergibt sich das andere problem auch ... evtl.

Hi Fil!

Ich setze ihn immer auf null und erzeuge dann einen neuen ...

Weshalb? Mit null entfernst du ja im prinzip den objektverweis und schreibst dann einen neuen verweis auf den heap in den stack. Genauso kannst du auch gleich den alten mit dem neuen überschreiben und das null weglassen.
Hoffe, ich hab richtig verstanden.

der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

ja, hast du. Ist so eine angewohnheit. Wenn ich mal das neusetzen vergesse, kann ich gegen null abprüfen ...
natürlich hast Du recht, man braucht es nciht unbedingt machen ...

Wie müsste ich dann Richtig Iterieren?

Erstmal hören, was die anderen dazu sagen. Bin mir grad unschlüssig, ob das stimmt, was ich geschrieben hab.

//Nachtrag alles ohne Gewähr, ich lehn mich jetzt mal ordentlich aus dem Window:
Also die Sache ist die: Ich glaube (!= wissen) , daß mehrere Installationsvorgänge gleichzeitig wenig Sinn machen, richtig ? Die können m.W. nach ja auch voneinander abhängen, auch richtig ?
Also, würde ich die Sache zweiteilen:

  1. Funktion startet EINE installation (mit BeginInvoke) und übergibt dem BeginInvoke einen CallBack.

  2. Der CallBack
    -Prüft die korrekte Installation (wenn gewünscht)
    -Ist noch mehr zu tun ? Ja -> goto 1. ; Nein -> Fertig

So in der Art.
Dann hast Du die einzelnen Installationen nacheinander. Jeweils während der Installation bleibt aber Deine GUI nicht "eingefroren" ...

Man mag mich bitte berichtigen, wenn das Schwachfug ist! Ich will ihm nicht mehr arbeit machen, als das Projekt es fordert.

Hi!

Ich würde noch radikaler vorgehen und alles in wirklich nur 2 Threads laufen lassen. der eine ist der GUI-Thread, welchen du zur Nutzer-Belustigung brauchst. Ab dem Moment, in dem der Benutzer auf den Startbutton drückt, würde ich den 2. Threads starten, welche jegliche Arbeit erledigt und sich beim GUI-Thread per Events und BeginInvoke meldet. Zudem soll er sich durch selbtsständiges auslaufen beenden und nicht durch Thread.Abort(). gestoppt werden. Auch eine Abbrechen-Funktion sollte über Events und einem selbstständigen Auslaufen des 2. Threads geschehen.

@Fil: So wie ich dich verstanden habe, möchtest du jeden einzelnen Vorgang (hier meinetwegen pro Update) immer wieder in einem eigenen Thread laufen lassen. Das halte ich aber für unnötig und macht die Sache komplizierter, wie ich finde. Er sollte eine Methode im 2. Thread starten, welche alle einzelnen Arbeitsmethoden (wenn er mehrere hat) aufruft.

der Marcel

:] 😄Der größte Fehler eines modernen Computers sitzt meist davor 😁 :]

Ok, ist natürlich auch eine Überlegung ... und wenn ich so überlege ... so hätt ich es wahrscheinlich von vorne herein gemacht ...