Servus,
stimmt, jetzt fällts mir wieder ein. Ich hatte mir den Kram selbst gebastelt, weil mein 0tes Byte an der letzten Stelle des Arrays steht und nicht an der Ersten. Auf Grund dessen, war ich zu faul gewesen, den Array zu drehen...
Vergesst meine Lösung, das ist Käse für den Normalfall....
gruß
Hellsgore
EDIT:
Btw. zu dem Zeitpunkt kannte ich Array.Reverse noch nicht....
Konrad Rudolph schrieb:
NES-Spieler schrieb:
Ah ja: Wenn man innerhalb des catch-Blocks noch einmal eine Exception wirft, wird der finally-Block ausgeführt, aber das darunter nicht mehr.
'finally' wird *immer* ausgeführt. Nicht nur, wenn man Ausnahmen wirft oder 'return' verwendet, sondern sogar bei so obskuren Dingen wie 'goto' (das wird oft vergessen).
Ja, das meinte ich ja auch: Selbst, wenn man innerhalb des catch-Blocks noch einmal eine Exception wirft, wird der finally-Block ausgeführt, aber das darunter aber nach wie vor nicht mehr. (Das war kein ausschließendes "wenn", sondern ein einschließendes.)
Herb schrieb:
Konrad Rudolph schrieb:
Herb schrieb:
Unix-Tom schrieb:
In C++ kann man auch keine Funktion verwenden ohne sie zu deklarieren.
Natürlich kann man das
Und wie?
int add(int a, int b)
{
return a + b;
}
int main()
{
return add(a,b);
}
Hab die funktion "add" nicht deklariert - die Definition reicht, sie muß nur vor dem Aufruf stehen.
Das da oben ist (auch) eine Deklaration (*jede* Definition ist eine Deklaration). Siehe C++-Standard, Sektion 3 Abs. 5 und 3.1 Abs 2.
Hallo,
schon vor einiger Zeit wurde es angekündigt, jetzt ist es so weit: Benutzer von VS 2008 können den .NET-Framework-Quellcode debuggen.
Genauere Infos dazu, und ein Link zu einer „Gebrauchsanweisung“ sind in Scotts Blog zu finden.
Aber Achtung. Bevor man sich den Quellcode anschaut, sollte man diesen Warnhinweis lesen:
Don't look at the sourcecode of .NET ….
Ich bin zwar nicht 100% mit dem Inhalt einverstanden, aber man sollte diese Warnung wenigstens zur Kenntnis genommen haben.
Jain, ich denke das man nicht davon ausgehen kann, das man einfach Moni installieren muss. Man wird bei der Entwicklung Mono berücksichtigen müssen da (noch) nicht alles umgesetzt ist.
Auch hängt es noch davon ab, ob Nativeaufrufe versteckt sind. (So könnten sicherlich einige GUI Libs von Nativeaufrufen gebrauch machen.)
ich hab ein ziemlich großes Programm, daS auf net basiert. nun das problem ist, das es auf rechnern nicht funktioniert, die entweder kein net framework haben oder eine niedriegere Version haben, als die gebrauchte.
Wenn Du Dein Programm in ein Setup packst werden die Abhängigkeiten (i.d.R.) mit installiert - z.B. das benötigte Framework.
VB is meiner Meinung nach kacke(!)
Du weißt das VB genau so eine voll anerkannte Sprache ist wie C#! Wenn du sagen würdest dir gefällt die Syntax nicht ist das in ordnung aber so eine Aussage ist nicht hinnehmbar ohne einen guten Grund -.-
Herb schrieb:
Stimmit so leider nicht. Im Debugger kannst du problemlos aud private / protected Member einer Klasse zugreifen. Im Code funktioniert das (natürlich) nicht.
Ja das ist richtig, habe aber angenommen, dass es ein public property ist. Aber jetzt hat er ja seine Lösung.
Gast2 schrieb:
Dann werde ich das ganze auf List umstellen. Auch wenn es sehr umständlich sein wird.
Hmm, wieso umständlich? Eigentlich wird dadurch alles einfacher.
Ist ArrayList komplett veraltet? Soll man ArrayList überhaupt nicht mehr verwenden?
Genau das. Die 'ArrayList' bietet gegenüber der generischen 'List<T>' keinerlei Vorteile und einige handfeste Nachteile. Die zwei größten Vorteile der 'List<T>' sind einfach, dass man zum einen klareren Code schreibt weil zum einen das ganze Gecaste wegfällt, was den Code nur aufbläht, zum anderen sind die verwendeten Typen besser ersichtlich.
Der andere große Vorteil ist, dass die 'List<T>' bereits zur Compilezeit viel mehr potentielle Fehler auffängt, weil sie einfach eine wesentlich striktere Typenprüfung ermöglicht.
Hallo,
ich habe folgendes Problem:
Ich habe eine .NET (C#) -dll, welche ein Control enthält. Dieses Control möchte ich jetzt auch in anderen Anwendungen verwenden, welche lediglich die dll referenzieren. Da ich das ganze möglichst leicht (für den Anwender, der in diesem Fall auch Programmieren ist) machen wollte, dachte ich, dass es vielleicht so eine Möglichkeit gibt, wie bei COM-Objekten, diese als Post-Build-Step direkt registrieren zu lassen.
In diesem Sinne habe ich mir einen key generiert und lasse als Post-Build-Step die dll im Global Assembly Cache registrieren. Dort erscheint sie auch wunderbar.
Jetzt dachte ich allerdings, damit wäre das ganze vorbei, da ja das Visual Studio auf der Suche nach Referenzen entsprechende Orte, zum Beispiel bei COM-Objekten die Registry, durchsucht und in der Folge die registrierten dlls anzeigt. Ich dachte, dass die .NET dlls im GAC landen müssen, um in dem Dialog angezeigt zu werden. Allerdings ist das scheinbar nicht so (oder ich habe etwas dabei außer acht gelassen, oder falsch gemacht). Im GAC jedenfalls erscheint meine dll (füge sie als Post-Build-Step mittels "gacutil /I myDll.dll" hinzu) nicht.
Ich hoffe, dass ihr mir irgendwie helfen könntet dabei, habe bislang online noch nicht viele Informationen zu diesem Thema aufgreifen können, vielleicht habe ich nicht richtig (bzw nicht nach den richtigen Keywords) gesucht.
Thxle so far
Danke für die Antwort ich werde mich damit beschäftigen.
Grob sieht der Quelltext so aus.
class Worker
{
/*
+ events und delegates
onFileFound
onFileScanned
onDone
usw..
*/
public Worker()
{
/*
Dictionary initialisieren
*/
}
public void Work()
{
SearchFiles();
/*
Je nach Option
ParseFiles(),
QueryInSQLiteDb() oder
beides.
*/
}
public void SearchFiles()
{
/*
Dateien finden
und im Dictionary speichern
onFileFound aufrufen um Eintrag in die
ListView zu schreiben
*/
}
public void ParseFiles()
{
/*
Dateien nach bestimmten
stellen durchsuchen
onFileScanned aufrufen um Farbe
des Eintrages zu ändern
*/
}
public void QueryInSQLiteDb()
{
/*
Dateien nach bestimmten
stellen durchsuchen
onFileScanned aufrufen um Farbe
des Eintrages zu ändern
*/
}
}