Laden...

Forenbeiträge von s-sharp Ingesamt 162 Beiträge

24.05.2008 - 12:41 Uhr

Hallo,

ein derartiges Tool kenne ich nicht. Hast Du denn die gängigen Bildbearbeitungsprogramme a la 'XnView', 'Irfan View' und 'ACDSee' schon auf Deine Wünsche hin geprüft?

Ich persönlich nutze als Bildbetrachter XnView, und das hat für Batchbetrieb einen ganzen Ar... voll Funktionen, mit denen ich mich aber noch nicht näher auseinander gesetzt habe.
Und für Irfan View gibt es meines Wissens nach jede Menge PlugIns - vielleicht ist da ja etwas dabei.

Nochetwas - Du bringst als Argument gegen JPEG die Verlustbehaftung.
Das steht irgendwie im Widersprich dazu, dass Du GIFs einsetzen willst.
Bei Grafiken, die als GIF mit seinen 256 Farben annehmbar aussehen, dürften die durch JPEG-Konvertierung enstehenden Verluste nicht so ins Gewicht fallen 😉

23.05.2008 - 18:50 Uhr

Ich kenne kaum eine andere Branche in der der Frauenanteil so erschreckend gering ist. *Dachdecker *Maurer *Straßenbauer

😁

im Big Brother haus[...]

Gibt es tatsächlich noch Leute, die diesen .... anschauen 😭

22.05.2008 - 11:25 Uhr

Es wäre schön, wenn es eine Möglichkeit gäbe, eine zweite Konsole zu öffnen.
Das permanente hoch- und runterscrollen, gerade im ersten Teil des Spiels, ist etwas nervig (wo war jetzt nochmal die eMail meiner Frau? =) )

21.05.2008 - 20:46 Uhr

Weis grad net genau was du meinst , hier der code der abfrage:

 switch (eingabe)  
            {  
                case "*****":   
                    output.AppendText("Passwort Aktzeptiert!" + "\r\n");  
                    output.AppendText("" + "\r\n");  
                    output.AppendText("Verbinde nun mit Remote Server ..." + "\r\n");  
                 output.AppendText("" + "\r\n");  
                 output.Clear();  
                 timer3.Enabled = !timer3.Enabled;   
               
                break;  
               default:output.AppendText("Falsches Passwort,Verbindung wird getrennt!" + "\r\n");  
                   PW=false;  
                   output.AppendText("" + "\r\n");  
                   break;  
           }  

Hmm, dann wurde das bestimmt vom Reflector nur so dargestellt, dort stand


if ((eingabe != null) && (eingabe == "*****")){}

Frage an die anderen: warum macht die IDE das intern?

21.05.2008 - 20:12 Uhr

Moin,

nettes Spielchen.

Eine Frage habe ich nur zu folgender Abfrage (bin selber noch Anfänger in C#):
In Deiner Passwortabfrage prüfst Du zuerst die Eingabe auf null, bevor Du das Passwort prüfst. Wieso? Hat das einen Sinn?

Soll keine Kritik sein; ich möchte es nur wissen - vielleicht weißt Du etwas, was ich nicht weiß 😉

20.05.2008 - 17:55 Uhr

[...]

Und was willst Du uns damit sagen? 🤔

19.05.2008 - 22:17 Uhr

Okay, danke für die Erläuterung, und tschuldigung.

Hätte vielleicht doch alle Threads zum Thema lesen sollen 😉

19.05.2008 - 17:22 Uhr

[EDIT]Abgeteilt von myCSharp.de hat jetzt seine eigene Stadt und hier eingefügt[EDIT]

Hallo zusammen.

Ich weiß, es steht mir nicht zu, mich zu beschweren. Dennoch möchte ich folgendes loswerden:

Es ist heute bereits das zweite Mal, dass die Seite nicht erreichbar ist.

Ich weiß nicht, wie es anderen geht. Aber ich persönlich finde es sehr sehr ärgerlich, wenn ich gerade Hilfe benötige, und dann eine meiner Lieblingsressourcen, nämlich dieses Forum, nicht erreichbar ist.

Da ich dieses von den Communities anderer Programmiersprachen (die meiner Meinung nach dazu noch stärker frequentiert sind) nicht kenne, finde ich es natürlich besonders ärgerlich.

Anscheinend gibt es diesbezüglich ja schon mehrere Threads, die ich aber nicht alle gelesen habe.
Dennoch meine ich herausgelesen zu haben, dass die Ursache in dieser Mini-City liegt.

Die Frage, die sich mir nun stellt, ist die, ob es eine Spielerei wie diese Mini-City wirklich wert ist, Teil dieser Community zu sein, wenn sie derart viele Ausfälle beschert.

Ich hoffe, hier fühlt sich nun niemand auf den Schlips getreten.
Möchte lediglich zum Ausdruck bringen, was mir nicht so gut gefällt.

19.05.2008 - 15:36 Uhr

Ok, mißverstanden - sorry.

19.05.2008 - 15:25 Uhr

@JAck30lena: danke.
Vielleicht hätte ich darauf hinweisen sollen, dass ich das Ganze gerne kostenfrei hätte 😉

@Bionic:

ich könnte eines gebrauchen, dass mir aus den von mir markierten Membervariablen Properties erstellt 😁 Variable einstellbar sind Zugriffsmodifier für get und set

Das kann die VS2008-IDE (Pro) doch schon: schau mal unter den Refactoring-Optionen bei 'Feld kapseln' 😉

19.05.2008 - 14:56 Uhr

Hallo,

ich hätte gerne ein AddIn für VisualStudio 2008, mit dessen Hilfe ich im Quelltext eine Methode löschen kann, und gleichzeitig auch sämtliche Verweise auf diese Methode entfernt werden. Thema: hier

Desweiteren benötige ich ein AddIn, mit dem es mir möglich ist, diverse Fensterlayouts der IDE abzuspeichern, zwischen denen ich dann flexibel umschalten kann. Ideal wäre es, wenn ich mir ein Debug- und ein Designlayout speichern könnte, zu denen dann automatisch umgeschaltet wird, wenn ich in den Debugmodus wechsle, bzw. wieder zurück (das automatische Umschalten auf ein Debuglayout funktioniert bereits, nur dass z.Zt. noch auf die letzte bekannte Konfiguration gewechselt wird). Thema: hier

Wann kann ich damit rechnen? 😁

18.05.2008 - 18:15 Uhr

Okay, danke Dir.

Dann mache ich es wie bisher; erst die Methode löschen, und dann durch Doppelklick auf die Fehlerliste zu den entsprechenden Verweisen hüpfen.

18.05.2008 - 17:26 Uhr

Hallo zusammen,

schmerzlich vermisse ich im VS2008 eine Möglichkeit, Methoden und andere aus dem Quelltext zu löschen, derart, dass auch alle Verweise darauf entfernt werden.

Beispiel:
Ich fülle das Click-Event eines Buttons mit Leben.
Irgendwann überlege ich mir, dieses Event doch nicht mehr behandeln lassen zu wollen und lösche die button1_Click-Methode aus dem Quelltext.

Wenn ich das Projekt nun kompilieren will, funktioniert das natürlich nicht, da die Zuweisung des Events noch immer im Designer-Quelltext steht.


this.button1.Click += new System.EventHandler(this.button1_Click);

Gibt es da keine automatisierte Möglichkeit?

18.05.2008 - 11:57 Uhr

Ihr werdet OT 😉

es geht nicht darum, das Schließen des Fensters zu verhindern, sondern die Eingaben zuprüfen und wenn sie falsch sind, das Verlassen des Feldes, in dem sich die Fehleingaben befinden zu verhindern, damit der Benutzer sie leicht korrigieren kann, aber auch muss.

Ich glaube, es ist noch immer nicht klar geworden, worauf ich hinaus möchte X(

Dass Sinn und Zweck des Validierens nicht das Unterbinden der Anwendungsbeendigung ist, sondern bspw. die Überprüfung von Eingaben, ist mir klar.

Mir ist nur aufgefallen, dass sich so aber auch das Beenden der Anwendung verhindern lässt.
Da ich das Verhalten, dass ein Control die Freigabe des Fokus 'ablehnen' kann, aus Delphi nicht kenne (nur über abfangen der WindowMessages), wollte ich wissen, ob es hinsichtlich des Beendens einer Anwendung irgendwelche sinnvollen Einsatzmöglichkeiten geben kann; aber dem scheint ja nicht so zu sein 😉

17.05.2008 - 18:00 Uhr

Das mit der Textbox war nur ein Beispiel.

Es geht mir vielmehr darum, ob es eine sinnvolle Einsatzmöglichkeit gibt, das Beenden der Anwendung dadurch zu verhindern, dass irgendein Control den Focus nicht abgibt?

Denn eigentlich wäre dafür doch das Abfangen im FormClosing-Event zuständig.

17.05.2008 - 17:21 Uhr

Hallo zusammen,

beim rumspielen ist mir gerade aufgefallen, dass ich mit dem Setzen von e.Cancel = True im Validating-Event verhindern kann, dass die Anwendung auf natürlichem Weg geschlossen wird, da das Control den Fokus einfach nicht loslässt g.

Diese Zeilen bewirken bspw., dass sich die Anwendung nicht beenden lässt, solange das Textfeld leer ist:


		private void textBox1_Validating(object sender, CancelEventArgs e)
		{
			if (textBox1.Text == String.Empty)
				e.Cancel = true;
		}

Ursprünglich wohl kaum dafür gedacht, das Schließen der Anwendung zu verhindern, finde ich dieses Verhalten grundsätzlich sehr interessant, sehe derzeit aber noch keine sinnvolle Verwendung dafür.

Hat jemand von Euch dieses Verhalten schonmal für diesen Zweck eingesetzt?

17.05.2008 - 10:51 Uhr

Danke für die Ergänzung!

Und Glückwunsch zum 3000sten Mal 'Nullen' 😉

16.05.2008 - 23:51 Uhr

Okay, danke Euch allen.

Fassen wir also zusammen:

Bei einem Single-Core-System ist der Einsatz mehrerer Threads dafür geeignet, mehrere visuell ablaufende Prozesse scheinbar parallel ausführen zu können. Hier geht es, auf gut deutsch gesagt, ausschließlich um die Zufriedenstellung des Anwenders (ein wenig mehr steckt schon dahinter, aber prinzipiell trifft es das schon).

In einem Dual-Core-System (gibt es schon mehr als zwei?) ist dann reelles Multithreading angesagt, d.h., dass die Zweigleisigkeit nicht nur visuell stattfindet, sondern unter der Haube tatsächlich zwei Sachen gleichzeitig ablaufen.

16.05.2008 - 23:30 Uhr

einkernsystem trifft es wohl eher aber im prinzip hast du recht.

Ja klar, 'tschuldigung 🙂

16.05.2008 - 23:28 Uhr

...macht es doch keinen Unterschied, ob nun fünf Threads 'nacheinander' ihre vier Dateien abarbeiten,

In dem Fall würden die Threads ja die Dateien gleichzeitig (parallel) abarbeiten und nicht nacheinander (squenziell). Das setzt natürlich einen PC mit mehreren Kernen oder CPUs vorraus.

Ähm, ja, aber ich sprach ja von einem Ein-Prozessor-System 😉

16.05.2008 - 23:19 Uhr

Hallo zusammen,

es leuchtet mir vollkommen ein, wenn man einen Sekundärthread nutzt, um bspw. bei länger andauernden Operationen den Primärthread und somit ggf. das GUI nicht zu blockieren.

Was bringt es mir aber, wenn ich bspw. ein Konvertierungsprogramm schreibe, welches threadbasiert eine bestimmte Anzahl von Dateien abarbeitet? Sagen wir mal, ein Thread kümmert sich um fünf Dateien. Bei 20 Dateien wären das somit vier Threads.

Alle Dateien müssen abgearbeitet werden. Da bei einem Ein-Prozessor-System aber nur ein Thread gleichzeitig arbeiten kann, macht es doch keinen Unterschied, ob nun fünf Threads 'nacheinander' ihre vier Dateien abarbeiten, oder ein Thread seine 20. Oder sehe ich da etwas falsch? Wäre die Multithreadlösung in diesem Fall nicht sogar eher kontraproduktiv, da die Threads ja auch noch verwaltet werden müssen?

07.05.2008 - 13:45 Uhr

Für die einmalige Verwendung genügt auch


            if (args.Contains<string>("some text"))
                //do something

06.05.2008 - 08:40 Uhr

Ich persönlich versuche Funktionen und Methoden so smart wie möglich zu halten (lieber 20 einzel Funktionen, als 2000 Zeilen Code). Jede Funktion mit sprechendem Namen und Kommentare für die Funktion selbst sowie die Argumente.

(Smart != kurz) zumindest nicht pauschal.
Natürlich versuche auch ich, kompakte Funktionen zu erstellen.
Hast Du aber eine Methode mit komplizierten Berechnungen, wäre die Aufsplittung oftmals kontraproduktiv.

Bei mir ist es eher andersrum, ich überlese meist Kommentare und versuche den Code selbst zu lesen und zu verstehen. Das klappt nicht immer Zeilenweise aber doch Blockweise

Du hast weiter oben das Argument 'Zeitverschwendung' gebracht. Im Hinblick auf diesen Kommentar widersprüchlich.
Wenn ich einen Defect im Code eines Kollegen beheben muss, dann möchte ich die Stelle an der es hakt auf Anhieb finden, und nicht erst lange danach suchen müssen - das ist Zeitverschwendung 😉

Eine generelle Aussage lässt sich hier aber sowieso nicht treffen. Der eine mag es so, der andere so 😉

Ich möchte jetzt auch ehrlich gesagt keine Grundsatzdiskussion zum Thema 'Wie kommentiere ich richtig' führen 😉

05.05.2008 - 22:45 Uhr

Hallo,

  
//aktuellen Index auf 0 setzen  
int styleIndex = 0;  
  

ist nicht böse gemeint, aber solche Kommentare sind unnötig. Wenn man sich nur den Quellcode anschaut sieht man, das der Index (wahrscheinlich von einer Auflistung Styles) auf 0 gesetzt wird.

mit 'böse' hat das nichts zu tun. Bin für jedes (!) Feedback dankbar.
Ich gebe Dir hier natürlich vollkommen recht; der Kommentar ist hier - normalerweise - absolut nicht notwendig.
Es ist nur so, dass ich gerade erst anfange, mich mit C#, generell mit C-basierten Sprachen, zu beschäftigen.
Bei mir dauert es zugegebenermaßen immer etwas länger, bis es 'klick' macht, und daher habe ich für mich beschlossen, zu Beginn alles zu kommentieren, um ggf. einen ganzen Programmabschnitt nur durch lesen der Kommentare nachvollziehen zu können - das hat mir in der Vergangenheit sehr geholfen, und ich hoffe, dass es das auch bei C# tut 😉

Das zu dokumentieren halte ich eher für Zeitverschwendung.

Nun, Zeitverschwendung würde ich es nicht nennen - es ist einfach nur unnötig und trägt nicht gerade zur guten Lesbarkeit des Codes bei 😉

Es reicht in vielen Fällen aus, nur die Funktion und derren Argumente zu Kommentieren - am besten über ///

In dem Punkt, muss ich Dir leider widersprechen - zumindest dann, wenn Du mit 'vielen' nahezu 'alle' meinst.
Ich entwickle hauptberuflich im Team (mit Delphi) an einer modularen Anwendung, die einige Millionen Zeilen Code umfasst (nur im Client-Bereich).
Da bei solchen Dimensionen nicht jeder jeden Bereich kennen kann, ist eine ausführliche Dokumentation sämtlicher Funktionalitäten unabdingbar, gerade deshalb, weil es sich um eine branchenspezifische Software aus dem Finanzwesen handelt.
Muss jemand für einen Kollegen einspringen, wäre es ziemlich aua, wenn der über eine schlecht, oder gar unkommentierte Funktion stolpern würde.

Und ich muss auch für mich selber sagen, dass es mir im Nachhinein oftmals hilft, Sachen schneller ins Gedächtnis zuück zu rufen, wenn ich mir gut kommentierte Methoden anschaue, gerade aus den Bereichen, an denen man nicht tagtäglich herumwerkelt.

05.05.2008 - 15:50 Uhr

Hallo,

wenn

font = new Font(name, size, (FontStyle)styles[styleIndex]);  

funktioniert, ist es dann keine Endlos-Schleife?

nein, da sie ja nur solange ausgeführt wird, solange mein font-Objekt gleich null ist.
Wenn die Instanziierung erfolgreich war, ist es das logischerweise nicht mehr 😉

05.05.2008 - 15:36 Uhr

So, ich habe nun den Weg über 'goto' durch eine entsprechende Schleife ersetzt.


        /// <summary>
        /// Erzeugt eine neue Schriftart unter Berücksichtigung, ob die Schriftart den zu setzenden Schriftschnitt unterstützt
        /// </summary>
        /// <param name="name">Schriftname</param>
        /// <param name="size">Schriftgröße</param>
        void CreateFont(string name, int size)
        {
            //ggf. bereits vorhandene Schriftart zerstören
            if (font != null)
                font.Dispose();

            //ein Array mit sämtlichen Werten der FontStyles-Enum anlegen
            int[] styles = new int[] { 0, 1, 2, 4, 8 };

            //aktuellen Index auf 0 setzen
            int styleIndex = 0;

            //solange die Schriftart nicht mit dem Style instanziiert werden kann, Style wechseln und neu versuchen
            do
            {
                try
                {
                    //versuchen, Font mit Style hinter aktuellem Styleindex zu erzeugen
                    font = new Font(name, size, (FontStyle)styles[styleIndex]);
                }
                //sollte es knallen
                catch (ArgumentException)
                {
                    //setzen wir den Styleindex um eins hoch
                    styleIndex++;

                    //und das vorhandene Objekt auf null
                    font = null;
                }
            } while (font == null);
        }

Schöner wäre es natürlich in der Tat, wenn man vorher wüsste, ob die zu erzeugende Schriftart den entsprechenden Schriftschnitt unterstützt, oder nicht.
Leider bin ich diesbezüglich noch immer nicht fündig geworden 🙁

04.05.2008 - 22:41 Uhr

Hallo, auch Dir vielen Dank für das Feedback!

Öffentliche Felder sollten nicht verwendet werden. Ersetze diese durch Eigenschaften.

Okay, habe die beiden Felder nun gekapselt.

1.) Goto sollte man nicht verwenden. (while-Schleife wenn möglich)
2.) Hier wird IMHO try/catch zum steuern des Programmflusses eingesetzt.
Versuche den "Knall" vorher auszuschließen. Dass selbe gilt für Zeile 76 bis 92 in
sfx.ASCIIChart.Connect. Hier sollte versucht werden eine andere Lösung zu finden.

Tja, an der Stelle stand ich vor einem Problemchen.
Ich habe dynamisch Font-Objekte erzeugt, und im Konstruktor den Regular-Schriftschnitt übergeben. Leider unterstützen den nicht alle Schriftarten, so dass es unter Umständen geknallt hat. Ich weiß nicht, wie ich im Voraus überprüfen soll, ob die Schriftart den Schnitt unterstützt, so dass ich es über die Exceptions geregelt habe.

Dass selbe gilt für Zeile 76 bis 92 in sfx.ASCIIChart.Connect.

Die Connect.cs-Datei wird automatisch von der IDE angelegt 😉

04.05.2008 - 21:18 Uhr

Hallo und vielen Dank für Deine Antwort!

Auch dokumentierst du bereits sehr viel, allerdings solltest du wenn möglich immer die XML-Dokumentation verwenden (3x /) und nur im eigentlichen Code // verwenden.

Habe ich nachgeholt.

Visual Studio belohnt dies damit, dir diese Dokumentation bei Verwendung des jeweiligen Elements anzuzeigen.

Tolle Sache 👍

Als hilfreiches Werkzeug zur Dokumentation kann ich nur GhostDoc empfehlen, damit macht dokumentieren richtig Spaß.

Habe ich bereits im Einsatz, und nimmt einem wirklich einiges an Tipparbeit ab =)

Ansonsten finde ich den Stil schon ganz OK.

Das freut mich.

Aber es muss doch noch mehr geben, was nicht optimal gelöst ist 🤔

Ich hoffe auf weiteres Feedback. 🙂

04.05.2008 - 14:21 Uhr

Hallo zusammen,

ich habe gerade mein erstes kleines 'Projekt' in C# begonnen; es handelt sich um eine ASCII-Tabelle. Wer die GExperts für Delphi kennt, dem wird die Tabelle vielleicht bekannt vorkommen.

Da ich vermeiden möchte, mir von Anfang an einen schlechten Stil oder ähnliches anzueignen, würde ich mich freuen, wenn versierte Leute sich meine Sourcen einmal anschauen, und sich dazu äußern würden.

Dabei bitte ich darum, das Augenmerk nicht auf designtechnische Aspekte wie Schriftgröße, Farbe etc. zu legen, sondern ausschließlich auf den Code. Auch, wie man die Source-Dateien besser in Ordnern strukturiert verwalten kann etc.

Vielen Dank für Eure Unterstützung.

(Sourcecode ist im Zip enthalten)

04.05.2008 - 11:56 Uhr

Guten Morgen,

ich habe mir nun die Mühe gemacht, und das Ganze nochmal neu augesetzt, so wie ich es schon beim ersten Mal gemacht habe (neues AddIn, vorhandene Sourcen importiert).

Nun wollte ich den Fehler zum dritten Mal reproduzieren; man glaubt es kaum, aber es geht nicht.
Ich kompiliere im Release-Modus und das AddIn lässt sich ohne zu murren laden.

Woran liegt das? Kann es sein, dass durch den Neustart des Rechners irgendetwas wieder gerade gebogen worden ist? Irgendwelche Verweise vielleicht?

Hatte noch nie jemand ein derartiges Problem?

04.05.2008 - 01:21 Uhr

Hallo zusammen,

ich kämpfe seit Stunden mit einem ziemlich blöden Problem, und zwar:

Es geht um ein AddIn für VS2008.
Irgendwann hatte ich für das Projekt einen Namespace umbenannt. Ab dem Zeitpunkt ließ sich das AddIn nicht mehr von der IDE laden - Fehler: 80131522.
Grund: In der*.addin-Datei musste ich ebenfalls noch den Namespace ändern.

Gesagt getan. Start der IDE: ein neuer Fehler: '80004002 Schnittstelle nicht unterstützt'

Ich habe sämtliche Dateien des Projektes untersucht, ob ich vielleicht an weiterer Stelle den Namespace noch ändern muss - aber es war alles korrekt.

Dann dachte ich mir, erzeuge ich einfach ein neues AddIn und importiere dort hinein einfach die beiden *.cs-Dateien, von denen ich wusste, dass das Problem dort nicht liegen kann.

Gesagt getan. Start der IDE: Juhuuu, das AddIn funktioniert wieder.

So, jetzt gehts los: ich stelle die Konfiguration von Debug auf Release und kompiliere das Projekt.

Start der IDE: '80004002 Schnittstelle nicht unterstützt'.

Ab dem Zeitpunkt war mir klar, dass es sich nur um die Umstellung Debug <-> Release handeln kann, die ich beim ersten Auftreten dieses Fehlers auch schon gemacht habe. Das schlimme ist aber, dass ich jetzt die Konfiguration wieder auf Debug stellen kann, das AddIn aber noch immer mit der gleichen Fehlermeldung nicht geladen werden kann.
Kopiere ich jedoch die zuvor im Debug-Modus erzeugte DLL (habe ich mir vorher weggesichert) funktioniert das AddIn wieder.

Da ich sämtliche Quellcode-Dateien (außer obj, bin und *.suo) mittels SVN verwalte, kann ich sehen, dass sich an den Dateien nichts geändert hat, nachdem ich auf Release umgestellt habe.

Ich habe auch mal die Ordner 'bin' und 'obj' komplett gelöscht, das Build bereinigt und neu erstellt, ohne Erfolg. Ich habe auch sämtliche Verweise einmal entfernt, und neu hinzugefügt. Auch den Test, die Verweise als lokale Datei einzubinden habe ich gemacht.

Ich weiß einfach nicht mehr weiter 🙁 Es kann doch nicht sein, dass soetwas die ganze Arbeit zunichte machen kann.

Also nochmal als Fazit:
Nachdem ich von Debug auf Release gestellt habe, lassen sich erzeugte AddIn-DLLs nicht mehr in die IDE laden; egal, ob im Debug- oder Release Modus. Fehler: '80004002 Schnittstelle nicht unterstützt'.
Laut SVN hat sich an den Quellcode-Dateien nach dieser Umstellung nichts geändert.

Klar könnte ich nun wieder ein neues AddIn erzeugen, und die beiden Dateien wieder einbinden, Das kann aber doch nicht Sinn der Sache sein - irgendwann stelle ich vielleicht aus Versehen wieder die Konfiguration um, und das Theater geht von vorne los.

Ich hoffe, mir kann hier jemand helfen. Danke.

//
Visual Studio 2008 Professional EDU

03.05.2008 - 11:08 Uhr

Danke für den weiterführenden Hinweis.

Kann man also allgemein sagen, dass der so hochgelobte GarbageCollector doch nicht das Wahre ist?

Ich meine, in Delphi lief es nicht anders ab. Ich erzeuge mir ein Objekt, und zerstöre es irgendwann wieder. Tue ich das nicht, läuft zwar irgendwann der Speicher voll, eine Ausnahme wird aber nicht geschmissen.

Das Verhalten Delphi <> C# ist also in diesem Punkt gleich.

Wieso wird dann immer, gerade im Bereich der Speicherverwaltung, C# vor Delphi gestellt?

02.05.2008 - 22:08 Uhr

Aber wahrscheinlich geht es ihm nur darum zu wissen ob es vorteilhaft ist die Dispose()-Methode aufzurufen.

Ganz genau das war es, was ich wissen wollte. Probiert habe ich es natürlich, und es hat nicht geknallt 😉
Da ich aber gerade erst vom Delphi-Lager nach C# übergelaufen bin, bin ich noch etwas unsicher, was Speicherverwaltung betrifft.

Danke Euch beiden.

Mache es jetzt so:


            if (font != null)
                font.Dispose();
02.05.2008 - 21:29 Uhr

Hallo,

ich weiß, dass ich ein komplett neues Font-Objekt erzeugen muss, wenn ich die Schriftgröße ändern möchte.

Nehmen wir mal an, ich habe beim Programmstart ein Font-Objekt namens 'font' erzeugt und möchte nun irgendwann ein neues Font-Objekt namens 'font' mit einer anderen Schriftgröße erzeugen.

Muss ich dann font.Dispose() aufrufen, bevor ich Font font = new font() aufrufe, oder ist das nicht notwendig?

01.05.2008 - 20:41 Uhr

Refresh erzwingt, dass die durch Invalidate angeforderten Aktionen unmittelbar durchgeführt werden. Das ist in der Regel unnötig und daher nicht angemessen.

Vielen Dank für die ausführliche Erläuterung 👍

01.05.2008 - 14:09 Uhr

Hallo und danke!

Im Zweifel im Resize-Event Invalidate aufrufen.

Gibt es einen Nachteil von Refresh() im Gegensatz zu Invalidate()?
Damit hatte ich es nämlich zuerst probiert.

01.05.2008 - 13:19 Uhr

Hallo,

ich möchte ein Grid auf ein Panel zeichnen.
Beim Resizen des Panels soll sich das Grid bzgl. Spaltenbreite und Zeilenhöhe automatisch anpassen.

Dazu rufe ich in der Paint-Methode des Panels die Methode auf, die das Zeichnen erledigt.

Das sieht so aus:


        const int Rows = 16; //Anzahl der Zeilen
        const int Cols = 8; //Anzahl der Spalten;

        private void panel1_Paint(object sender, PaintEventArgs e)
        {
            PaintGrid(e);
        }


        void PaintGrid(PaintEventArgs e)
        {
            Pen pen = new Pen(new SolidBrush(Color.Gray));

            //Berechnen, in welchem Abstand die Linien gezeichnet werden sollen
            int height = panel1.Height;
            int width = panel1.Width;

            int yPos = height / rowcount;
            int xPos = width / colcount;

            //Zeilen zeichnen
            for (int i = yPos; i < height; i += yPos)
            {
                e.Graphics.DrawLine(pen, new Point(0, i), new Point(width, i));
            }

            //Spalten zeichnen
            for (int i = xPos; i < width; i += xPos)
            {
                e.Graphics.DrawLine(pen, new Point(i, 0), new Point(i, height));
            }

            pen.Dispose();
        }

Das Zeichnen funktioniert auch soweit. Wenn ich nun aber die Größe der Form ändere, wird das Zeichnen nicht neu ausgeführt, und somit sieht das Ganze etwas merkwürdig aus.
Erst wenn ich die Form im Hintergund verschwinden lasse, und wieder hervor hole, erfolgt das Neuzeichnen.

Was mich wundert, ist, dass das Ganze mit einer TabPage anstelle des Panels ordentlich funktioniert.
Wo liegt hier der Unterschied, und wie komme ich mit dem Panel zu dem gewünschten Ergebnis?

01.05.2008 - 09:57 Uhr

Hallo,

also bei mir verstellt sich die Spracheinstellung nicht von alleine.

also besteht noch Hoffnung; danke =)

30.04.2008 - 22:53 Uhr

Hallo zusammen,

die in VS2008 integrierte Hilfe (Microsoft Document Explorer) finde ich sehr gelungen.

Was mich allerdings stört, ist die Tatsache, dass bei einer Suchanfrage - unter bisher nicht eindeutigen Umständen - der von mir definierte Sprachfilter wieder zurückgesetzt wird.

Ich möchte mir bspw. zu der Brush-Klasse ausschließlich die Syntax von C# anzeigen lassen; J#, C++... interessieren mich nicht. Also stelle ich das unter 'Sprache' ein und gut ist.

Irgendwann passiert es dann, dass sich der Sprachfilter von alleine wieder zurücksetzt - das finde ich etwas nervig.

Weiß jemand, wie sich die Sprachauswahl dauerhaft festlegen lässt?

30.04.2008 - 16:05 Uhr

Achso, tust du ja schon 😉

Ja, tue ich schon, aber leider schreibt er es eine Zeile tiefer. Gebe ich also fünf mal etwas falsches ein, habe ich dort fünf mal untereinander 'Pixel Breite: ' stehen 🙁

30.04.2008 - 15:50 Uhr

Hallo,

dass es knallt, hatte ich gemerkt 8)

Das 'TryParse' hatte ich gesucht - danke 👍

Habe es nun so: (Int in Double geändert)


            do
            {
                Console.Write("Pixel Breite: ");
            } while (!Double.TryParse(Console.ReadLine(), out pxBreite));

Gibt es noch eine elegantere Möglichkeit, eine erneute Eingabe zu erzwingen, als das 'Pixel Breite: ' einfach nochmal darunter zu schreiben?

30.04.2008 - 15:19 Uhr

Hallo,

ich möchte fünf Werte vom Typ Int32 über die Konsole abfragen. Sollte anstelle der Eingabe eines Wertes einfach die Enter-Taste gedrückt werden, soll den Variablen defaultmässig ein Wert 0 bzw. 72 zugewiesen werden.
Ich nutze dafür folgenden Code:


            Console.Write("Pixel Breite: ");
            temp = Console.ReadLine();
            pxBreite = (temp == "") ? 0 : Convert.ToInt32(temp);

            Console.Write("Pixel Höhe: ");
            temp = Console.ReadLine();
            pxHoehe = (temp == "") ? 0 : Convert.ToInt32(temp);

            Console.Write("mm Breite: ");
            temp = Console.ReadLine();
            mmBreite = (temp == "") ? 0 : Convert.ToInt32(temp);

            Console.Write("mm Höhe: ");
            temp = Console.ReadLine();
            mmHoehe = (temp == "") ? 0 : Convert.ToInt32(temp);

            Console.Write("dpi: ");
            temp = Console.ReadLine();
            dpi = (temp == "") ? 72 : Convert.ToInt32(temp);

Geht das nicht auch schöner als über die temporäre Variable?
Und was ist, wenn man einen Buchstaben anstelle der Zahl eingibt?

Muss das Ganze mittels Exceptions abgefangen werden, oder gibt es da einen Trick? Eingabebeschränkung oder soetwas?

30.04.2008 - 08:39 Uhr

Ich war schonmal in einer ähnlichen Situation.

Lösung: Callback seitens des Autors nach vorheriger Anfrage und Weiterleitung des Anliegens durch den Verlag.

Sollte also kein Problem darstellen.

29.04.2008 - 17:01 Uhr

Hallo,

er hat 2002 auch für den Heyne-Verlag geschrieben; Kannst da ja mal anfragen.

29.04.2008 - 06:45 Uhr

Schau mal da:

>

Oh je, wie blöd muss man (hier: ich) sein.

Ich depp habe knapp zwei Stunden vorher das Gleiche für Delphi verfasst, und komme dann hier net auf die Lösung...

Das tut doch schon weh, oder?! X(

27.04.2008 - 14:22 Uhr

Hallo,

in dem openbook 'Visual C# 2005', welches Du bei Galileo-Computing findest, gibt es irgendwo innerhalb der ersten Kapitel ein Beispiel für einen Objektzähler, der auch das automatische Dekrementieren im Destruktor etc. vorsieht.

Meine, der stünde irgendwo in Kapitel 4-6 in dem Circle-Beispiel.

Edit: Kapitel 5.1.1 war's

Hier der Link

Edit 2: Hinweis: diese Beispielanwendung baut sich Stück für STück auf. Kann sein, dass die Besprechung des Konstruktors in diesem Fall auch erst später kommt. Da beginnt auf jeden Fall die Implementierung des Objektzählers.

27.04.2008 - 14:15 Uhr

Hallo Mandy,

also bei mir gibt es das von Dir genannte Verzeichnis 'Dokumente' unterhalb von 'All Users' nicht.

WinXP SP2

Meinst Du vielleicht 'Gemeinsame Dateien' innerhalb des Program-Folders?
Das wäre dann 'CommonProgramFiles'.

Ansonsten könntest Du den gewünschten Pfad auch auf Basis von 'CommonApplicationData' das Dich nach 'C:\Dokumente und Einstellungen\All Users\Anwendungsdaten' führt, ermitteln.