Laden...

Forenbeiträge von 0815Coder Ingesamt 767 Beiträge

29.10.2007 - 19:04 Uhr

besser, weil sichergestellt ist, dass der stream geschlossen wird.


using (StreamReader reader = new StreamReader(...))
{
  // stuff
}

ist das gleiche wie


StreamReader reader;
try
{
  reader = new StreamReader(...);
  // stuff
}
finally
{
  if (reader != null)
    reader.Dispose();
}

29.10.2007 - 17:09 Uhr

Original von B1rd
Danke dir

Wenn man es aber "normal" macht wäre Dispose die bessere Variante?

ich halte die Variante mit using() für die "normalste" 🙂

es gibt auch nicht viele Fälle, wo man diese nicht verwenden kann, und wenn nicht, kann mans meistens noch anders schreiben, sodass man using() doch wieder verwenden kann. übrig bleiben nur ziemlich wenig ausnahmen (zB wenn man den stream in einer public methode einer dll erzeugt, und der verwender der dll müsste ihn schließen).

26.10.2007 - 22:15 Uhr

Original von talla

Original von brainwave
...ist Firmenpolitik...

Naja, wenn eine Firma eine Technologie nutzen möchte, aber nicht deren technischen Voraussetzungen schaffen möchte - dann würd ich sagen bissle kurz gedacht.

Wir würden gern Computer verwenden, aber bitte ohne Elektronik...

26.10.2007 - 22:03 Uhr

hast du als debug version kompiliert oder als release?

24.10.2007 - 22:24 Uhr

das is sogar ein einzeiler (aus der log4net doku geklaut):


Type callingType = System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.Name;

in deinem Fall würde als "csHelper" rauskommen.

24.10.2007 - 22:20 Uhr

wie herbivore sagt.

wenn du


public static bool operator ==(Eintrag e1, Eintrag e2)
{
  if (e1 == null)
  // irgendwas
}

schreibst rufst du in dem moment den operator== rekursiv auf.

22.10.2007 - 16:47 Uhr

ist zwar wirklich trivial aber das hier ist ja kein mathematik forum 🙂

21% von X ist X mal 0.21

oder

50 EUR brutto sind (50 * 1.20)€ netto 🙂 (für österreich)

22.10.2007 - 12:46 Uhr

Strg-L ists bei mir, dürfte aber auch standard sein. zeile ist danach ebenfalls in der zwischenablage.

19.10.2007 - 15:57 Uhr

Original von Inertia
In einer kleinen Testanwendung habe ich das mit Threads/Sleep/Stopwatch implementiert, [...] aber das Resultat ist +/- 10-20% der gewünschten Framerate. Das Problem hängt wohl mit der Verlässlichkeit der Zeitangaben/Sleep zusammen.

zumindest nicht mit Stopwatch, die ist extrem exakt (irgendwo bei 0.00004 sec auf meinem rechner).

10.10.2007 - 15:52 Uhr

aja das wars... dachte schon "this" wäre ein kandidat für <thread nicht auffindbar> (den mit den überflüssigsten keywords)

ich bin draufgekommen wann ich this wirklich hinschreibe:
in abgeleiteten klassen, wenn ich auf properties der basisklassen zugreife. kA wann ich mir das angewöhnt hab. wahrscheinlich weil die keinen _ am anfang haben, wie meine fields.

10.10.2007 - 15:44 Uhr

hm stimmt, du musst eigentlich komplett durchsuchen, minX, maxX, minY und maxY merken 😦 habs wohl zu tode optimiert

10.10.2007 - 15:41 Uhr

inkrementelle suche?

Strg-I
dann springt er während du was tippst zum nächsten das passt... probier mal, kanns grad nicht gscheit erklären, weil mir der kaffee fehlt.

edit: falsche tastencombo angegeben

10.10.2007 - 00:38 Uhr

Das gibts nicht fertig, musst du selber in von dir zu bestimmenden Zeitintervallen vergleichen.

Dazu merkst du dir das letzte Bild (zB von vor einer Sekunde) und vergleichst Pixelweise von links nach rechts und von oben nach unten.
beim ersten Pixel das nicht gleich ist, hast du die X und Y gefunden.

Dann vergleichst du von rechts unten... und findest somit die rechte unteren X,Y.

siehe auch
800x schneller als GetPixel

09.10.2007 - 21:15 Uhr

Original von Golo
this ist dann zwingend, wenn:

  • Du auf ein Feld zugreifen willst, das genauso heißt wie ein Parameter ... lässt Du this weg, wird der Parameter genommen
  • Um einen Konstruktor zu überladen
  • Um einen Indexer zu definieren

Mehr Fälle fallen mir spontan nicht ein.

Hallo Golo,
zu 1) man kann die Parameter anders nennen um das "this" zu vermeiden (mein Post bezog sich eigentlich nur auf this für fields).

Bei 2) und 3) hätte Microsoft auch genausogut ein anderes Schlüsselwort definieren können (ja, "this" passt ganz gut, das geb ich zu). Wenn mans genau nimmt, IST das sogar ein anderen Schlüsselwort, das nur zufällig auch "this" heisst - genau wie using für "using System.Irgendwas" und "using (Stream s = new ...){}"

09.10.2007 - 15:59 Uhr

wenn man this nicht verwenden sollte, wäre das keyword selbst überflüssig.

ich verwende es wenns den code leichter lesbar macht, was allerdings nicht häufig ist.

09.10.2007 - 13:14 Uhr

ok den teil dass er von mehreren controls erben will, hab ich überlesen. da funktioniert das natürlich nicht.

09.10.2007 - 09:20 Uhr

den code der anderen klasse (von der du nicht erbst) kannst du in eine hilfsklasse geben. die hilfsklasse im abgeleiteten control (wo du von der basis ableitest) zusätzlich instanzieren, und wo du den code brauchst, auf die hilfsklasse zugreifen.

09.10.2007 - 09:18 Uhr

ich hatte mal kurzzeitig sowas in verwendung:


public delegate void ExceptionHandlerDelegate();
public void Handle(ExceptionHandlerDelegate dosomething)
{
  try
  {
    dosomething();
  }
  catch(Exception ex)
  {
    Log(ex);
  }
}

// verwendung:
{
  Handle(delegate
    {
    // code der exception wirft hier
    });
}

vorteil: es gibt nur einen einheitlichen exceptionhandler
nachteil: es gibt nur einen einheitlichen exceptionhandler

in summe überwiegt der nachteil. man will üblicherweise in vielen situationen unterschiedlich reagieren, dann hilft sowas nicht weiter. in summe hats dann dazu geführt, dass in dem catch() auf einmal if (ex is SomeException){} gestanden hat... das war dann auch das unrühmliche ende des Handlers.

07.10.2007 - 23:09 Uhr

auch die events bekommen nur die, die sich dafür angemeldet haben... anmeldung erfolg hier eben mit += und abmeldung mit -=

02.10.2007 - 14:17 Uhr

ein programmierer forum ist wahrscheinlich nicht unbedingt das erfolgversprechendste um grafiker zu finden, obwohls sicher auch hier begabte/interessierte gibt und mir auch klar ist dass du hier zuerst suchst...

aber was is mir blender/photoshop foren? dort gibts sicher mehr begabte leute als hier... ob die alle genauso interessiert wären wie hier, ist leider ein anderes thema.

ich würd mich ja melden, aber die künstlerische gehirnhälfte arbeitet bei mir leider auf sparflamme...

27.09.2007 - 16:08 Uhr

wenn du den shortcut für den smarttag meinst, der ist: Shift-Alt-F10

26.09.2007 - 09:58 Uhr

Original von retnug
Serializable()?
oder SerializableAttribute()?
oder Serializable?
oder SerializableAttribute?
Was sind die Unterschiede bzw. wenn es keine gibt: Was sollte man benutzen?

Die Unterschiede liegen nur in der Schreibweise.

Wenn du [Serializable] schreibst, weiss, der Compiler, dass es sich um ein Attribut der Klasse SerializeableAttribute handelt und erzeugt entsprechend eine Instanz desselben. Eigene Attribute sollen auch "XyzAttribute" genannt sein, damit man kurz [Xyz] schreiben kann. Die Klammern kannst du bei Attributen auch der Einfachheit halber weglassen.

Ich bevorzuge bei Attributen immer [Xyz] ohne Klammern und "Attribute". Die Klammern nur wenn sie aufgrund Parametern nötig sind.

Meine UnitTest Projekte heissen allerdings "XyzProject.Test". Das schlägt sich dann mit dem Namespace und VS färbelt das [Test] Attribute nicht ein, weil es es für einen Namespace hält (auch wenn der Compiler dann weiss, dass es ein Attribute ist). In dem Fall schreibe ich dann [TestAttribute], aber das hat nur optische Gründe.

25.09.2007 - 17:17 Uhr

Original von herbivore
Was den Entwurfsmodus angeht, solltest du einfach Abfragen, ob du im Entwurfsmodus bist.

Damit hab ich (vielleicht andere nicht) ein Problem:
Ich schreib ein UserControl mit Properties, und kann darin wunderbar abfragen ob ich im Entwurfsmodus bin oder nicht.

Dann wirds hart: ich verwende das UserControl im Form (ja auch Entwurfsmodus) aber das UserControl selbst ist dann nicht mehr im Entwurfsmodus -> ergo Mist... kann das wer bestätigen oder bin ich nur für irgendwas zu doof?

24.09.2007 - 16:05 Uhr

privat: den von grisoft (free edition)
rennt ohne belastung, updated automatisch ohne sich wichtig zu machen. manchmal vergess ich schon dass ich den drauf hab, und muss direkt schaun ob er überhaupt rennt. durch den angesprochenen gesunden menschenverstand hat er aber noch nicht anspringen müssen.

21.09.2007 - 15:45 Uhr

da die klasse kein UI oder log hat, kann er mit der ausnahme nichts weiter machen als sie zu a) ignorieren oder b) weiterzuwerfen.

a) schlecht, weil man dann beim verwenden annehmen könnte dass alles geklappt hat, was nicht stimmt.

b) in dem fall braucht man sie gar nicht fangen.

20.09.2007 - 23:42 Uhr

Zeit:


DateTime x = DateTime.Now;  // zB
TimeSpan time = x.TimeOfDay;

mit kombinieren meinst du wahrscheinlich:


            DateTime x1;
            DateTime x2;

            DateTime x3 = new DateTime(x1.Year, x1.Month, x1.Day, x2.Hour, x2.Minute, x2.Second);

20.09.2007 - 13:10 Uhr

Original von svenson
Ich hätte MS empfohlen, bei der Speicheranzeige einfach zu mogeln und aktuellen Cache auf den verfügbaren Speicher draufzuschlagen. Hätte vermutlich keiner gemerkt.

Das wäre nicht mal gemogelt. Wenn benötigt, würde der vom Cache verbrauchte Speicher ja auch zur Verfügung stehen. Was da "verfügbar" heisst, müsste richtigerweise "ungenutzt rumliegend" heissen.

18.09.2007 - 21:16 Uhr

die frage ist wohl: willst du den string wirklich wieder zurückverwandeln können? oder nur nachschauen, ob ein eingegebener string (aus einem registrierungsformular) dem im string entspricht? in dem fall würds reichen, den eingegebenen namen auch zu hashen und beide hashes zu vergleichen.

18.09.2007 - 15:09 Uhr

arr der wars...

18.09.2007 - 14:26 Uhr

Nun, vielleicht bringt dieses Thema aber jemand anderen drauf, der denselben Fehler macht 🙂

sprich, das innere control war wahrscheinlich mit Anchor = Left, Top, Bottom, und hat sich somit nie in der Breite geändert. und auf dessen Resize event hast du reagiert... (?)

18.09.2007 - 00:38 Uhr

Ein Schlückchen Sonnenschein

Die Rotkäppchenverschwörung (qualitativ nicht so hochwertig gerendert, aber trotzdem super)

Und dann noch der eine mit Elijah Wood... fällt mir nicht ein... auf der Verpackung steht er recht teilnahmslos mitten in einem Sonnenblumenfeld... grandioser Film.

14.09.2007 - 23:11 Uhr

cool... vielleicht brauch ichs selber mal 🙂

14.09.2007 - 13:51 Uhr

wäre in bezug auf das enum noch schöner. nur nachdem der aktuelle status aus der datenbank kommt (als int) wärs nicht sehr sinnvoll den zuerst auf das enum zu parsen um dann wieder zurück nach int zu gehen. ausser vielleicht um sicher zu sein, dass der aktuelle überhaupt ein gültiger status ist.

14.09.2007 - 13:46 Uhr

Original von juetho

... ganz abgesehen davon, dass bei Sql-Befehlen sowieso unbedingt **:::

jetzt weiss ich wieder, wieso ich sowenig mit sql mache 🙂

14.09.2007 - 13:43 Uhr

@herbivore

Die Sinnhaftigkeit der Methode zweifle ich gar nicht an.

aber wenn (aktuell + 1 == status) wahr ist, dann muss auch die bedingung drumherum (aktuell < status) wahr sein. kann man sich also sparen. Der Rest ist diskussionswürdig (siehe Anfängerfehler == true / == false

Die Namen hab ich hier fürs Forum geändert... war zu Projektspezifisch

14.09.2007 - 13:11 Uhr

is schon korrigiert...


return status +1 == (int)neu;

wobei man sich sogar die methode schenken kann...
und wobei man sagen muss dass auch ich schon sagenhaften blödsinn geschrieben hab 🙂

14.09.2007 - 12:42 Uhr

Witzig was man so findet, wenn man durch den Code anderer Leute schaut 🙂 (anonymisiert)


private enum Status
{
    Anfang, Mitte, Fertig, Fehler
};
private bool NeuerStatus(Status neu, int aktuell)
{
    int status = (int)neu;
    if (aktuell < status)
    {
        if (aktuell + 1 == status)
        {
            return true;
        }
    }
    return false;
}

14.09.2007 - 11:11 Uhr

am lesbarsten - aber immer die langsamste variante - ist mit string.Format(). verwend ich recht häufig, weil die performance bei den strings nur selten verloren geht. am schnellsten verschwindet die performance bei netzwerkzugriffen (db abfragen an den server...) da zahlt sichs echt nicht aus, das select statement per StringBuilder zusammenzubauen um 0.05ms zu sparen und dann 10ms lang auf die Db zu warten.

14.09.2007 - 11:01 Uhr

wenn man die strings direkt hintereinander hängen kann, wie bei deinem beispiel 1 ist immer der + operator der schnellste. egal wie viele du aneinander hängst.

wenn du strings in einer schleife aufbaust, und bei jedem durchlauf was dazuhängst, ist der StringBuilder zu empfehlen aber auch erst ab minstens 20 durchläufen.

der grund, dass der + operator im ersten fall schneller ist ist der folgende:
der compiler macht draus ein


string.Concat(s1,s2,s3,s4...)

dadurch kann das .net framework zuerst berechnen wie lang der result string in summe sein wird, den speicher einmalig anlegen und dann die strings in den speicher schreiben.

der stringbuilder würde mitwachsen was aber dazu führt, dass jedesmal wenn der speicher vergrößert wird, der bisher erstellte string in den neu angelegten speicher kopiert werden muss.

13.09.2007 - 23:09 Uhr

a) dein lehrer hat keine ahnung.

b) er will wahrscheinlich, dass du einen string in einen double konvertierst, den zu dem zweiten wert addierst und das ergebnis zuwückgibst.

13.09.2007 - 18:45 Uhr

überladen: gleiche methoden mit unterschiedlichen parametern in der gleichen klasse oder einer abgeleiteten klasse.

überschreiben: eine methode in einer abgeleiteten klasse nochmal (mit den gleichen parametern) neu schreiben und (wenn erforderlich) die base.Xyz() aufrufen.

12.09.2007 - 22:51 Uhr

such mal nach "optimistic concurrency"

12.09.2007 - 19:58 Uhr

wenns nur ums speichersparen geht, nimm

int?

. soviel sparst du dir dadurch nicht und es gibt genug gründe, int statt short zu verwenden...

wenns drum geht sicherzustellen, das es keine anderen werte gibt, mach ein enum:


enum sowieso
{
 Eins, Zwei..., Zwölf
}
// und verwende dieses nullable:
private sowieso? mySowieso;

11.09.2007 - 22:31 Uhr

vielleicht nicht static?

11.09.2007 - 17:32 Uhr

irgendwie muss es gehen. ich hatte schon spiele, die sich mit alt-F4 nicht beenden ließen. ist aber auch schon 2-3 jahre her, vielleicht hat MS die "lücke" geschlossen.

11.09.2007 - 10:42 Uhr

ps:
ich hab sowas noch nie gemacht - aber das wäre mein tipp...

10.09.2007 - 23:16 Uhr

Wir haben definitiv Mangel. Dafür können wir uns des Andranges der vielen Projektmanager gar nicht erwehren.

10.09.2007 - 23:13 Uhr

anbei mein Flieger...

10.09.2007 - 21:59 Uhr

Original von JuyJuka

  • ALLES über Streams (RAM-Stream, CPU-Stream, Monitor-Stream, ...)

grundsätzlich guter ansatz, nur brauchts dafür auch hardware, die das unterstützt.

10.09.2007 - 16:52 Uhr

Original von Programmierhans
Ich verwende einen TFT Acer AL2216W also 22-Zoll Wide... hat dieselbe Auflösung wie der Laptop (1680*1050)

Ist nicht nur zum Programmieren genial, sondern auch zum Modellfliegen (Aerofly)...

hätten die dinger mit 1920x240 nicht eine bessere aerodynamik? und... wie oft fliegen die, bevor man sie in den müll schmeissen kann?