Hi,
ich habe bislang nur unter Windows mit Visual Studio .net in C# programmiert, aber da ich eigentlich Linux so wie so viel besser leiden kann, wollte ich nun mono und monodevelop mal ausprobieren. Hat vielleicht schon jemand Erfahrung mit mono und der Entwicklungsumgebung monodevelop?
Ich habe mir über Portage mono-1.0.5-r5 runtergeladen und kompiliert, aber ich habe eben auf der mono-Homepage gesehen, dass Version 1.1 nun auch schon stable sein soll (Alledings ist da das Portage-Repository anderer Meinung). Kann mir vielleicht jemand sagen wie stable mono-1.1 wirklich ist? Und stimmt es dass mono-1.1 nun auch Windows.Forms unterstützt? Und gibt es sonnst noch irgend einen Grund für den es sich lohnt mono-1.1 anstatt 1.0 einzusetzen oder andersrum?
monodevelop ist laut Portage ebenfalls unstable, was man allerdings nicht immer so wörtlich nehmen darf. Jedoch hatte ich mit monodevelop 0.7 unter Debian schonmal tatsächlich Probleme. Kann mir vielleicht jemand einen Rat geben mit welcher Version von momonodevelop man am besten arbeiten kann? Welche für mono-1.0 und welche für mono-1.1 am besten geeignet ist?
Danke.
Gruß
Schrankwand
Eigentlich hast du recht, Optimizer, "wirkliche" Schleifen bestehen aus etwas mehr Code als nur einer Addition, sodass der Unterschied zwischen for und foreach nicht mehr so ins Gewicht fällt.
ich denke Du bist ein liebenswürdiger gemütlicher Mensch, nee jetzt wirklich im ernst!
Aber mal was anderes, ich beschäftige mich jetzt seid ca 2 1/2 Monaten mit .NET,
hauptsächlich mit VB und C# wirklich geil dies Teil. Und diese Technologiebeispiele
in der MSDN und in den Microsoft Press - Büchern sind schon echt was feines.
Und der Oberhammer ist meiner Meinung diese Interoperabilität! Die ganze Software
von Microsoft und manche die unter Windows läuft und nicht speziell von Microsoft,
stellt halt über die COM - Technologie Schnittstellen nach aussen bereit.
Man kann somit das gesamte Office - Paket durch nen anderes Programm von aussen steuern etc. sehr nett .
mfg sclearscreen
oh mann, ich sehe schon, keiner weiß bescheid.
Das Problem bestand nun darin, dass die Verbindung zum Server länger als die verwendete Zeit benötigte, dadurch wird ständig eine neue Verbindung geöffnet ohne die alten jemals zu schließen. Das Problem habe ich nun gelöst, indem ich ein TimeOut hinzugefügt habe und wo ich vorher auf einen WebRepsonse verzichtt habe, verwende ich nu diesen, um den Puffer zu leeren und die Infos abzuholen, die sonst erhalten bleiben würden und im Grunde nicht mehr als 5 solche Request offen sein können.
Wenn du mit ILDasm einen Blick auf eine Klasse mit Properties wirfst, dann wirst du sehen, dass eine Get() und eine Set() (wenn nicht readonly) Methode erstellt wurde.
Also ja, Properties sollen Get() und Set() Methoden ersetzen.
In deinem Fall würde ich schreiben:
public string ProxyName {
get { return m_ProxyName; }
}
public int ProxyPort {
get { return m_ProxyPort; }
}
Es ist immer ratsamer keine public Members zu haben.
Informatik hat nicht zwingend viel mit Programmieren zu tun
C# hab ich mir eigentlich im Zuge von 2 Projekten selber beigebracht und mich natürlich hauptsählich um die Dinge gekümmert an denen ich gerade gearbeitet hab.
und wie C# dann im Detail was lädt ist mir bisher verborgen geblieben
Die Idee ist gar nicht schlecht. Ich muss nur mal sehen wie ich die Transition schaffe, da es bereits ein besthendes Albumformat gibt.
Danke für alles!
need_help schrieb:
aber zu meiner fehlerbeschreibung möchte ich hier anfügen:
wenn ich gewusst hätte was fehlerhaft ist dann hätte ich das problem gelöst.
alleine.
Darum geht es nicht.
"irgendwie funzt das nicht" hilft anderen nicht dabei, den Fehler einzugrenzen. Eine gute Fehlerbeschreibung würde hier so aussehen:
"Das Programm wird fehlerfrei kompiliert und stürzt auch nicht ab. Allerdings wird kein Strich gezeichnet. Den Code zum Zeichnen habe ich mir selbst ausgedacht / von xyz.com kopiert / was auch immer"
Fällt dir der Unterschied auf?
und wenn ich wüsste wo der fehler ist dann hätt ich auch nicht hier gepostet
Wenn du gewusst hättest, wo der Fehler ist, dies aber trotzdem verschwiegen hättest, wäre das echt mies. Das wollte ich dir nicht unterstellen. Es ging mir nur darum, dass diese Information auch nichts dazu beigetragen hat, die Fehlersuche zu vereinfachen.
Doch Properties gibt es. In CLI (Common Language Interface) oder so ähnlich. In V1 heisst das Schlüsselwort noch __property ab V2 wohl nur noch property
Danke Schön für deine Antwort!
Ich glaube ich hab das Problem so gelöst: Die einträge werden anstatt so wie oben gezeigt in Context-Anbhängig in ein 3-D Array gespeichert, und von da aus ausgewertet. Das funktioniert ganz gut. Aber Das mit dem XML werde ich mir trotzdem mal anschauen. Scheint ganz Praktisch zu sein....
Aber Danke...