Laden...
Avatar #avatar-3234.gif
JunkyXL myCSharp.de - Experte
Software Developer Ein paar Bytes südlich von string Dabei seit 02.05.2006 1.665 Beiträge
Benutzerbeschreibung
Code-Junky

Forenbeiträge von JunkyXL Ingesamt 1.665 Beiträge

21.03.2009 - 12:50 Uhr

Naja

ich glaube, der IE wird nie einen Grund haben, mich ihn zum Benutzen zu bringen.
Ich bin mit Firefox absolut zufrieden.

PS:

19.03.2009 - 17:24 Uhr

BeginInvoke ist übrigens oft günstiger, weil bei Invoke wartet der NebenThread, bis der Gui-Thread fertig ist.

Genau deswegen benutze ich immer Invoke, weil es sonst zu Überschneidungen führen kann.

19.03.2009 - 12:21 Uhr

Von dort kann der Fehler aber nicht kommen..
Poste doch mal den umliegenden Code von dieser Zeile. Ich denke, dort liegt wohl der Fehler.

19.03.2009 - 08:42 Uhr

Ich verwende jeweils die kleingeschriebene Variante der Typen string, int, float, ...
So kenn ich das aus C, wo die primitiven Datentypen auch klein geschrieben sind.
Die Großgeschriebene Variante ist für mich die jeweilige Helferklasse für den primitiven Typ und daher verwende ich für Methoden davon die großgeschriebene Variante.

18.03.2009 - 00:55 Uhr

Wir arbeiten ganz primitiv mit folgenden Benennungsschemas:

TextBox textBoxName;
TextBox textBoxFirstname;
ListView listViewAppointments;
Button buttonOK;

//
this.textBoxFirstname.Text = ...

ohne Abkürzung, ohne nix. Lediglich UserControl stellt die Ausnahme mit "uc" als Präfix dar (=> "ucEditor"). Man sollte ja eigentlich wissen, mit welchen Typen von Controls man auf der UI arbeitet. So hat man mit dem ausgeschriebenen und leserlichen Typnamen eine logische Gruppierung. Ich bekomme da oft Magenschmerzen wenn ich txtXYZ oder btnCancel lese.

Letztendlich kann es jeder frei entscheiden. Manche meinen, den Unterstrich in Variablennamen immer noch verwenden zu müssen oder z.B. auch Ordnernamen mit Unterstrichen zu versehen, weil sie in den alten Zeiten zu sehr stecken geblieben sind (soll sich jetzt keiner beleidigt fühlen, ich finde das einfach nur humbug in der heutigen Zeit). Kann jeder für sich entscheiden, ich stehe da mehr zu Leserlichkeit.

17.03.2009 - 12:26 Uhr

Hast du einen Empfänger, der AllowDrop auf true gesetzt hat?

17.03.2009 - 12:22 Uhr

Was ist dein Problem? Wo hängts? Ich sehe auch nichts von einer ListView.

17.03.2009 - 12:13 Uhr

Hast du dir die Beschreibung von OptimizedDoubleBuffer angeschaut? Da steht drin, welche Styles du noch brauchst.

17.03.2009 - 11:45 Uhr

Prüfe Rectangle.Size auf Size.Empty. Eine Größe von null macht ohnehin keinen Sinn zu zeichnen.

Evtl. SetStyle(OptimizedDoubleBuffer, true); falls es beim Resizen immer noch flackert.

12.03.2009 - 20:08 Uhr

Hast du schon GetTypes() anstatt GetExportedTypes() probiert?

Erklär mir mal diese mysteriöse Codezeile:

string toolConnector = typeof(ICoreToolConnector).ToString().Substring(typeof(ICoreToolConnector).ToString().LastIndexOf(".") + 1);

was soll da im Optimalfall zurückkommen?

12.03.2009 - 16:18 Uhr

Jetzt bleibt mal bitte ruhig und vor allem sachlich.
Dieses Gestachel ist total unnötig. Wäre also sinnvoller, wenn ihr euch auf das Wesentliche konzentriert. Soll es halt unmöglich sein, das muss man demjenigen aber nicht dauernd einreden/klarstellen.

Ich finde es eine Schande für dieses doch sonst so saubere und freundliche Forum.
Also wenn, antwortet konstruktiv anstatt destruktiv.

Danke!

12.03.2009 - 12:23 Uhr

Ich gehe davon aus, dass es auch mit Serializable geht. Vielleicht findest du einen Weg?!

12.03.2009 - 11:36 Uhr

Natürlich, im Prinzip ist in der Programmierung nichts unmöglich. Ob es passt, ist aber eine andere Frage 😃

12.03.2009 - 11:33 Uhr

in dem Fall werd ich mich auch mal mehr mit dem using beschäftigen...

... was nichts anderes ist als:

IDisposable disposable;
try
{
    // Code
}
finally
{
    disposable.Dispose();
}
12.03.2009 - 11:28 Uhr

Ist deine blubb Klasse Serializable? Wenn ja, entfern das mal. Dann sollte er den Code auch wieder generieren.

12.03.2009 - 00:39 Uhr

Ja, ich konnte es mir auch nicht vorstellen, dass sie den Fokus verliert. Woher denn auch? Selbst wenn diese eine Zeile den Unterschied macht, so richtig kann ich mir das nicht erklären. Hast du schon versucht, nach dieser Zeile Form.Activate() auszuführen?

11.03.2009 - 16:51 Uhr

Ich verstehe zwar nicht genau was du meinst, aber viel ist mit der ProgressBar nicht möglich. Welcher zusammenhängender Bereich? Evtl. mal an einer Zeichnung darstellen?!

11.03.2009 - 16:34 Uhr

Ja weil erstens sieht der auf jedem System anders aus. Das hat auch so seine Berechtigung bei jeder Windows Version anders auszusehen. So ist das mit jedem Programm. Oder passen z.B. Vista oder XP-Buttons mit einer ≤ Win 2000 Oberfläche zusammen?

11.03.2009 - 16:31 Uhr

@JunkyXL

Der Code vom Designer macht das auch so, siehe hier:

  
this.btnArchivloeschen.Click += new System.EventHandler(this.btnArchivloeschen_Click);  

Das ist kein Event von this, sondern von einem Button.
this.Click, this.Load wären Events von this.

Aber wenn man Events der Klasse innerhalb dieser registriert und es egal sein sollte, ob man sie abhängen muss oder nicht, dann kann es dir auch egal sein ob du sie registrierst oder die Methode überschreibst.
Ich nehm halt immer die Methode, weil das viel schneller geht und auch sauberer aussieht. Zudem sind Events für mich etwas für die Welt da draußen, außerhalb der Klasse.

11.03.2009 - 12:05 Uhr

Wer verliert den genau den Fokus? Deine main TestForm oder die modale Form mit dem Progress?
Wenn es die Anwendung ist, dann ist es logisch, weil du ja mit ShowDialog() die Progress Form nach vorne holst bzw. sie muss auch vorne sein, da sie modal ist.

11.03.2009 - 11:59 Uhr

Zudem würde ich nicht Events von this registrieren, wie bei dir das Load-Event, sondern die entsprechenden virtuellen Methoden überschreiben (OnLoad). Somit sparst du dir auch das deregistrieren des Handlers.

Edit: Klassen-, Property- und Methodennamen sollte man der Namenskonvention wegen groß schreiben.

11.03.2009 - 11:43 Uhr

Ein Background-Worker führt im Hintergrund eine Operation aus und updatet das Progress-Fenster entsprechend. Wenn die Operation fertig ist (hier durch einen Timer simuliert), soll das Progress-Fenster geschlossen werden...

Die Operation sollte das Fenster nicht kennen. Ich würde die Operation in einer eigenen Klasse abkapseln und den Fortschrittsverlauf und das Ende der Operation über ein Event anbieten, an welches sich dann deine Form registriert.
Mit anderen Worten: Die Opertation sollte das GUI nicht kennen und unabhängig verwendbar sein.
So lassen sich sicherlich auch einige Probleme eingrenzen.

11.03.2009 - 11:38 Uhr

Ich bin zwar sicher, dass der Marketinghype den Nutzen um Potenzen übersteigt, aber es ist schon mal gut zu wissen:

There is no risk of Wolfram Alpha becoming too smart, or taking over the world.

Sag niemals nie.. Bei entsprechendem Erfolg ist sicherlich nichts mehr ausgeschlossen.

11.03.2009 - 10:48 Uhr

Um das besser zu kontrollieren, empfehle ich dir bei UserControls z.B. eine Initialize() und Uninitialize() Methode zu verwenden, die du von außen Aufrufst. Diese registriert/deregistriert Events von verschachtelten Controls z.B.
Uninitialize() rufst du anstelle von Dispose auf, da du das ebenfalls in die Uninitialize() Methode packen kannst.
Wie Programmierhans sagt, denke ich auch, dass es ziemlich wahrscheinlich mit den Events zu tun hat, die die Instanz festhalten.

11.03.2009 - 10:39 Uhr

Du solltest vor dem Disposen und Nullsetzen Form.Close aufrufen.

Oder, wenn du auch Form.Show() benutzt, kannst du anschließend Form.Activate() aufrufen.

09.03.2009 - 11:33 Uhr

Editier bitte deinen Post und füge noch den entsprechenden Code hinzu.

Jack hat bereits alles dazu gesagt, ansonsten sollte das mit der Ellipsengröße anhand vom Scrollwert an sich funktionieren.

06.03.2009 - 10:15 Uhr

Hast du es schon mit LostFocus anstatt Leave probiert?

05.03.2009 - 13:29 Uhr

PS:

IsKeyAlphbeticCharacter(e.KeyCode)

dafür gibt es char.IsLetter(); Die Überprüfung auf zulässige Zeichen solltest du besser mit :::

04.03.2009 - 17:08 Uhr

Ein Label kann so etwas nicht. Es zeichnet lediglich den vorgegebenen Text.

Welches Control soll so etwas können? Ich kann es mir nur schwer vorstellen, da 7/10 oder (Wurzel)16 individuelle Zeichen sind. Also musst du das alles selbst machen.
Natürlich nicht gerade einfach aus dem Ärmel geschüttelt, aber machbar auf jeden Fall.

Mein Ansatz wäre:

class Wurzel
{
    public int Value { get; set; }
}
Wurzel wurzel = new Wurzel(16);

Instanz von Wurzel im Zeichenvorgang:
// Zeichne Wurzelzeichen
// Zeichne String innerhalb des Wurzelzeichens (DrawString(wurzel.Value.ToString()))
04.03.2009 - 15:54 Uhr

Das Berechnen der Abstände ist nicht schwer.

// Startposition
Point currentLocation = Point.Empty;

for (int i = 0; i < formel.Length; i++)
{
    // zeichne bei currentLocation

    SizeF size = Graphics.MeasureString(formel[i]);
    currentLocation.X += size.Width;
}
04.03.2009 - 14:43 Uhr

Codeproject: TreeListView

Wenn du Lust hast, kannst du dich auch in die Control-Programmierung einarbeiten und dieses Control selbst machen.

04.03.2009 - 12:44 Uhr

Ich wusste doch, dass das mal ging. Habe den Browser Cache geleert, nun gehts wieder.

04.03.2009 - 11:24 Uhr

Hallo,

ich meine mal, dass man nach dem Login wieder auf die zuletzt besuchte Seite "zurückgeleitet" wurde.
Jedenfalls finde ich es störend, wenn ich zu einem Thread eine Antwort verfassen möchte, ich aber nach dem Login (falls nicht eingeloggt, wird man ja auf die Login Seite erst weitergeleitet) auf http://www.mycsharp.de/wbb2/index.php weitergeleitet werde, anstatt zum Thread.

Ist das gewollt oder bisher nur unter den Tisch gefallen?

04.03.2009 - 00:16 Uhr

this.BackColor = Color.Transparent;

SetStyle(SupportsTransparentBackColor) "sagt" ja nur aus, dass auch Transparenz unterstützt wird. Die Farbe muss noch nur gesetzt werden.

Du kannst das auch manuell machen:

OnPaintBackground()
{
    // Hintergrund zeichnen
    e.Graphics.FillRectangle(Brushes.Transparent, this.ClientRectangle);
}
03.03.2009 - 17:36 Uhr

Hallo m0rius,

selbst zeichnen.
Wenn du versuchst, die abgerundeten Ecken zu zeichnen, dann bemüh google mit Rounded Rectangle. Auf codeproject gibt es dazu auch etwas entsprechendes.
Den Rahmen zeichnest du gerendert (Graphics.SmoothinMode = AntiAlias) damit das ordentlich aussieht.
Erfordert zwar etwas Geduld, aber machbar ist das.

03.03.2009 - 15:19 Uhr

Im Falle von var sehe ich es ein.

Dann verstehe ich es also richtig, dass wenn der zweite Audruck ausgewertet wird, dieser in den Typ des ersten Ausdrucks konvertiert wird? Den Grund zu dieser Entscheidung konnte ich da jetzt nicht rauslesen 😐

Ich möchte den Thread nicht zerstören und unnötig aufblähen, deswegen belass ich es hierbei 😃

03.03.2009 - 15:03 Uhr

Der Typ, der auf der linken Seite der Zuweisung steht. Denn ohne den lässt sich das nicht kompilieren.

03.03.2009 - 14:46 Uhr

Deswegen meinte ich ja, dass die linke Seite den Typ des Ausdrucks vorgibt, der ja dann auch zur Compilezeit bekannt wäre.
Also wäre an object obj = str ?? DBNull.Value; eigentlich nichts auszusetzen?!

Dann müsstest du irgend einen Typ direkt im Ausdruck nach object casten, wenn es sich bspw. um eine Wertetyp handelt.

Dass das hier geht object obj = str ?? (object)DBNull.Value; war mir bewusst, ich habe es halt hingenommen, wenn ich so einen Fall hatte. Aber warum funktioniert das erst mit dem Casten? DBNull ist ja auf jeden Fall ein System.Object. Daher kann ich die Lösung mit dem Casten nach object nicht ganz verstehen.

03.03.2009 - 14:17 Uhr

JunkyXL und Golo haben die Begründung genannt

Golo. Es scheitert wirklich schon vorher. Was mich jetzt aber zum Nachdenken anregt, da doch eigentlich (firstName ?? DBNull.Value) ein Ausdruck ist, der je nach Bedingung den entsprechenden Wert zurückgibt. Also ist doch die linke Seite spannend, die einen Typ erwartet und nicht der Typ der Bedingung (firstName, string)?
Ich finde gerade auch nichts konkretes dazu, wieso beide Typen übereinstimmen müssen. Es könnte ja sein, dass ich auf der linken Seite einen Typ System.Object habe, der dann beide Werte entgegennehmen kann.

03.03.2009 - 13:59 Uhr

Ich muss es jetzt einfach sagen: Da ist jemand von sich sehr eingenommen.
Außerdem sind die genannten Beispiele quatsch. Das hat nichts mit Microsoft zu tun.

03.03.2009 - 13:02 Uhr

Die Methode AddWithValue() erwartet mit Sicherheit einen String, laut Fehlermeldung.
Da kannst du nicht einfach string = DBNull zuweisen.

03.03.2009 - 12:55 Uhr

Da die .NET Controls standardmäßig kein festes Kontextmenü haben, kannst du bei jedem Control MouseClick (MouseButtons.Right) abfangen und das userControl.ContextMenu/Strip.Show() aufrufen.

03.03.2009 - 08:54 Uhr

Gemeint war aber sicherlich, dass WPF schon vor VS 2010 eingesetzt werden kann und nicht zur Oberflächengestaltung genutzt wird. So hab ich das zumindest auch verstanden.

03.03.2009 - 08:24 Uhr

Deswegen wär ich dafür, den Thread jetzt zu schließen.
Wenn er ein konkretes Problem hat, soll er sich nochmal richtig anstellen. Seine Eingangsfragen (wenn wirklich ernst gemeint) sollten bis dato größtenteils geklärt sein.

02.03.2009 - 18:15 Uhr
// Form
foreach (Control control in plugin.Controls)
{
    this.Controls.Add(control);
}

wozu hantierst du mit parent? Schreibe doch mal den betreffenden Codeschnipsel. So wird dir besser weitergeholfen werden.

01.03.2009 - 20:45 Uhr

Den sehe ich bei Vista nicht...

01.03.2009 - 19:32 Uhr

Wenn du genau das gleiche Verhalten haben willst, wozu setzt du dann die anderen Sachen wie TRANSPARENTSHADOWTEXT oder TRANSPARENTBKGND?

01.03.2009 - 19:28 Uhr

Bis jetzt habe ich diese Thematik meistens mit dem Casten von ColumnHeader nach MyColumnHeader gelöst und dabei die ListView so belassen wie sie ist.