Quelle? Das war vor gefühlten 2-3 Jahren. Das stand so - soweit ich weiß - in einer Ankündigung, IT-News (zum Thema Übernahme durch RedGate). Vielleicht ist dieser Satz mit dem "kostenpflichtig" auch irgendwo anders zwischendurch gefallen.

Es hieß ja schon von Anfang an, als Redgate den Reflector übernommen hat, dass der mal kostenpflichtig wird. Mich wunderts, dass das nicht schon passiert ist.

Wenn dem so ist, dann hat der aber nix innerhalb einer Form zu suchen. Ich würde diesen "Manager" eher statisch in der Anwendung bereitstellen, worauf sich dann jede Form beim Instanziieren registriert.

Wenn du ein Property in deiner Form-Klasse hast, muss es nicht noch mit Form... im Namen beginnen. Das hat eine gewisse Zweideutigkeit. So sehe ich das.

Ich finde es etwas unsinnig, Properties nach ihrem genauen Zweck zu benennen, wenn die Klasse schon einen Teil vorgibt.

Klasse "Form" -> Propety "Manager".

Edit:

Benutze einfach den FullQualifiedName von deinem FormManager

Das Problem liegt hier zwischen Klasse und Propertyname (und nicht Typ).

• Soweit ich mich erinnere (kanns grad nicht testen).

Welche Datei und welcher Code?

Du fügst deine Assembly nicht als Verweis ein, sondern lieferst z.B. ein x86 und x64 Verzeichnis mit, wo die ensprechend kompilierten DLLs liegen.
Eine der beiden lädst du per Assembly.LoadFile.

Ich werfe mal

File.WriteAllText();
File.ReadAllText();

ein. Soweit ich das sehe, kannst du das damit Ersetzen und sparst dir die IO Logik mit dem StreamWriter mit dem Close und Flush.

Dass der Concurrent-Namespace erst ab 4.0 ist, war mir klar. Ich habe aber gerade gesehn, dass ich das missverstanden hatte. Ich hatte das so verstanden, dass Jack meinte, dass die Verwendung dieser Klassen erst seit 4.0 zur Pflicht geworden ist. Wobei die Verwendung Thread-sicherer Collections schon davor ein Thema war. So meinte ich das, aber nun gut, egal 😃

Naja, das ist ja nicht .NET 4.0 Threading-spezifisch, sondern betrifft Threading allgemein, unabhängig vom Framework, oder?

Ich denke, das ist nicht gerade unwichtig zu erwähnen:

The System.Collections.Concurrent namespace provides several thread-safe collection classes that should be used in place of the corresponding types in the System.Collections and System.Collections.Generic namespaces whenever multiple threads are accessing the collection concurrently.

System.Collections.Concurrent Namespace

Oh.. ich sehe gerade, dass ich Programmierhans' Aussage falsch gelesen habe. Hatte das so gelesen, dass man modale Dialog nicht selber disposen sollte, daher meine Verwirrung auch, warum Dispose "schlimm" sein sollte.

Wenn ein Form mit ShowDialog angezeigt wird, dann disposed es sich NICHT selber...

Was spricht denn hiergegen? ->

using (Form form = new Form())
{
    form.Test = Settings.Default.Test;

    if (form.ShowDialog() == DialogResult.OK)
    {
         Settings.Default.Test = form.Test;
    }
}

So ist es möglich, dass der User die Form später einfach wieder öffnen kann und immernoch alles so ist, wie es war, als er sie geschlossen hat.

So etwas geschieht eher optional und je nach Fall. So was wird aber wenn dann normalerweise über Speichern & Laden realisiert. Das hat auch den Vorteil, dass du die Eingabedaten für andere Zwecke zur Vefügung hast.

Da Java IMHO erst ab Windows 2000 unterstützt ist, und .NET ab Windows 98, bleibt nicht viel übrig, als die klassischen nativen Sprachen.

Fenster.Activate();
Fenster.Show();

Googlesuche nach windows messages c#

Falls das nicht hilft, kannst du die Windows Message fürs Minimieren vor dem Scan ignorieren, nach dem Scan wieder tolerieren.

In der Art wie in WPF überhaupt nicht.
Gibt eigentlich nur 2 Möglichkeiten:

• Drittanbieter TreeView verwenden, die das kann (gibt sicherlich was bei Codeproject, o.Ä.)
• DrawNode (beachte DrawMode) Event benutzen, um Gott und die Welt für die Node einzuzeichnen.

allerdings ist diese dann schon bei einfachem Klick zu editieren, und das soll sie erst beim Doppelklick sein. textBox.Enabled bzw. textBox.ReadOnly

Außerdem darf die Textbox selbst nur so hoch sein wie der Text tatsächlich Höhe beansprucht damit nachfolgende Einträge nicht überdeckt werden und überhaupt wissen, wie diese positioniert werden sollen.

das sollte mit BorderStyle=none kein Problem sein, da du die Höhe setzen kannst.

aber wieso genau darf der Text nicht durch die TextBox überlagert werden? Es ist ja nur für die Zeit, in der der Text editiert wird. Dann musst du wahrscheinlich auch nichts von dem Rest sehen, wenn du diesen einen Text bearbeitest.

Mit DayOfWeek hat er doch bereits eindeutige Werte, die ihm sagen, ob es Samstag oder Sonntag ist.

while (zielDatum.ToShortDateString() != tag.ToShortDateString());  

Das ist was für unsere Horror-Code Abteilung 😉

DateTime kannst und solltest du direkt vergleichen, also ohne .ToShortDateString().
oder um die Zeit nicht in den Vergleich miteinzubeziehen:

zielDatum.Date != tag.Date

Wo genau liegt das Problem, die TextBox dynamisch an der Stelle des zu editierenden Labels anzuzeigen? Dass die Texte unterschiedlich gerendert werden, lässt sich nämlich lösen.

Das ist ein Fall für den Timer (System.Windows.Forms.Timer).

Du kannst die Systemeinstellung für die Blinkfrequenz aus der Registry auslesen und diese als Interval für den Timer setzen, der im Event Handler nur Invalidate() auf deinem Control aufruft, in dessen Paint-Event Handler/OnPaint-Überschreibung du wiederum du den Strich zeichnest, wo er sein soll.

Wenn du das TabControl in einen Container (z.B. Panel) legst, kannst du es soweit nach oben positionieren, dass die Tabs aus dem sichtbaren Bereich verschwinden.

Aber wenn du sowas wie in VS machen willst, würd ich dir eher raten, den Content auf der rechten Seite zur Laufzeit hinzuzufügen.

Wenn du also links einen Eintrag anklickst, hast du rechts z.B. ein Panel, auf dem du Controls.Clear() aufrufst, und das entsprechende Control addest (Dock.Fill).

Ein Wunder, dass der Thread noch offen ist...

// Thread
{
    tu was...
    int wert = // berechnung
    UI aktualisieren:

    Action a = () =>
    {
        items.Add(wert);
    };

    if (this.InvokeRequired) // Prüfen, ob wir uns im UI Thread befinden
    {
        this.Invoke(a); // Wenn nein, dann auf die UI invoken
    }
    else // Ansonsten bleiben wo wir sind
    {
        a(); // Methode ganz normal aufrufen
    }
}

Die Abfrage auf InvokeRequired kann wegfallen, wenn man weiß, dass man gerade in einem anderen Thread (-> nicht im Thread des zu aktualisierenden Controls) ist.

Ich verstehe nicht, was an diesem Prinzip nicht begreifbar ist.

Die Zahl der verfügbaren IP-Adressen lässt sich natürlich in der Tat festlegen, das lässt sich mit dem Ölvorrat nun wirklich nicht vergleichen.

Allerdings kann ich mir nicht vorstellen, dass die freien Adressen schon nächstes Jahr dermaßen rar sein sollen. Das Internet müsste eigentlich bislang zu >50% auf IPv6 umgestiegen sein, denn ich glaube kaum, dass das innerhalb eines Jahres geschehen kann, bevor es zum "Super-Gau" kommt.

Das ist meiner Meinung nach nur eine Vorsichtsmaßnahme, um gewappnet zu sein, wenn die Adressen dann in 3-4 Jahren tatsächlich leer sind.

Verpack die TextBox in einem UserControl/Control.

• Ich würde den Namespace Helpers benennen
• Nur weil es in Ordner(n) strukturiert wird, ändert sich der Namespace nicht (so handhabe ich das).

Vielleicht sind Extensions auf den Registry-Klassenobjekten sinnvoll?

Der "Sender" eines Events ist immer die Klasse, die das Event aufruft. Da du die Size des Forms änderst, wirft das Form ein Resize-Event. Von wem die Größenänderung ausgeht, kann die Form ja nicht wissen.
Aber schieben wir diese Grundlage beiseite, das solltest du nämlich auch wissen!

Mir scheint es viel eher so, dass du das zu kompliziert machst. Wo genau ist dein Problem?

public class ButtonX : Button
{
    protected override void OnClick(EventArgs e)
    {
        base.OnClick(e); // <-- Feuert das Click-Event

        Form form = this.TopLevelControl as Form;
        if (form != null)
        {
             form.Size = ...
             form.Location = ...
        }
    }
}

Warum soll der Click-Handler in der Form nochmal die Größe anpassen können? Das sollte doch intern in der Button-Klasse passieren?

Jedenfalls kannst du mit dem base-Aufruf steuern, wann das Event gefeuert werden soll.

Also, wenn ich mich nicht täusche, sollten das mit den 5 Beträgen pro Betrag 9 oder 10 verschiedene Kombinationsmöglichkeiten sein. Und das mal 5 Beträge, also ca. 250 Kombinationen. Mir kam die 3125 so irre hoch vor, dass ich doch selber mal nachschauen wollte 😃

Kann mich auch irren, falls ich da noch was wichtiges vergessen habe.

Wenn es relevant ist, könntest du zum Problem kommen, dass es mehrere Übereinstimmende Kombinationen gibt.

Du weißt wie man die Größe von Fenstern setzt?!
Wie man den Ort (Location) setzt?!

Das kannst du doch selber machen, ob es sowas gibt, weiß ich nicht. Wo genau liegt das Problem, was möchtest du machen?

Viel einfacher und "zuverlässiger" geht das, indem du den String der Parse/TryParse Funktion aus der System.DateTme-Klasse übergibst. Dort hast du dann alles rund um ein Datum bequem im Zugriff.

Das nächste mal bitte dafür Google verwenden!
Das ist absolute Grundlage. Die Lösung/Denkanstoß lässt sich mit einem Suchtext wie "date get month c#" leicht finden.

Edit: ich war noch langsamer

Ein Application.DoEvents() nach Thread.Sleep(x) sollte helfen. Dafür erntest du von mir gleich mal einen virtuellen Schlag auf den Hinterkopf 😃
Woher hast du diese Infos, das mit DoEvents() zu machen?

@ Matze91:
Der Weg geht über Thread/BackgroundWorker und dem Invoke auf die GUI, um die ProgressBar zu aktualisieren. Das sollte eigentlich alles in dem FAQ Artikel drin stehen. Schau bitte nochmal rein! [FAQ] Warum blockiert mein GUI?

Also Finger weg von Sleep und DoEvents.
Alternativ kannst du das auch mit einem Timer umsetzen, was aber an sich nicht viel Sinn macht.

Du kannst auch nochmal speziell nach "Thread Invoke GUI C#" googlen. Du solltest an nützlichen Informationen dann erschlagen werden.

Ich würde das Setzen des wait Cursors sowieso direkt im Event Handler machen, anstatt erst im Thread.
Zudem ersparst du dir das Invoke direkt gleich nach dem Threadwechsel und die theoretische Zeit bis dahin verweilt nicht unnötig mit dem default Cursor.

Hallo,

entweder schaffe ich es nicht, Google zu den passenden Suchergebnissen zu führen oder es gibt wenig Literatur darüber, eine ASP.NET (3.5) Web-Anwendung mit AddIns zu erweitern.
Es sollen auf jeden Fall UserControls und ganze Formulare als AddIn in eine Seite geladen und verwendet werden.

Wie das alles in WinForms funktioniert, ist kein Problem. Aber wie geht man da im Web heran? Ich habe jedenfalls nichts nützliches dazu gefunden.

Edit: Es handelt sich um eine vollständige Web 2.0 Anwendung mit IFrames.

Manchmal drückt Code mehr aus, als 1000 Worte.

Poste mal den fraglichen Code, ich hab momentan nur eine Vermutung was dein Problem sein könnte.

Kannst du deinen JS Code überhaupt debuggen? Du müsstest eher auf sowas wie EndCallback vom UpdatePanel reagieren.

Gibt es kein anderes Feld, dass du für die Scrollposition setzen kannst außer scrollTop?

Noch ein Tipp, um Fehler diesbezüglich auszuschließen: Erstell dir eine getCookie(key) und eine setCookie(key, value) Funktion, um das sauber zu trennen.

Ich bin mir ziemlich sicher, dass du brauchst dafür einen TypConverter brauchst. Den setzt du auf die Klasse von deinem Property oder auf das Property selbst.
Im TypConverter musst du nichts weiter machen, als den String, den du direkt eingeben willst, in deinen Zieltyp zu parsen und umgekehrt.

Dauert es solange bis die Seite an sich geladen ist (Load-Event) oder bleibt er eventuell beim Zugriff auf die Datenbank so lange stecken?

TimeSpan beinhaltet, wie der Name schon sagt, eine Zeitspanne. Daher solltest du in den Konstruktor von Timespan nur die Dauer eingeben (also Arbeitszeit + Pause). Diese Timespan addierst du zu der DateTime arbeitsBeginn.

Wie man mit DateTime und TimeSpan umgeht, diese addiert, kannst du ganz leicht ergooglen. Es gibt einige Add-Methoden auf dem DateTime Objekt, vielleicht kommst du schon alleine drauf.

So sollte der Text des Labels nach außen gewrappt sein:

public string Anzeigetext
{
    get { return this.LabelAnzeigeText.Text; }
    set { this.LabelAnzeigeText.Text = value; }
}

Ich weiß nicht, wie das in WPF genau ist, aber das einfachste ist - da jeder Tab einem Spieltag entspricht - dass du als Key für den Tab die Spieltagnummer setzt. In Windows Forms wäre es das "Name" Property.

Beim Klicken auf den Button brauchst dann nur auf .SelectedTab.Key/Name/Value/wasauchimmer zuzugreifen.

Hab eben mal danach gegooglet und folgenden JavaScript Code gefunden:

function getSelText()
{
    var txt = '';
     if (window.getSelection)
    {
        txt = window.getSelection();
             }
    else if (document.getSelection)
    {
        txt = document.getSelection();
            }
    else if (document.selection)
    {
        txt = document.selection.createRange().text;
            }
    else return;
document.aform.selectedtext.value =  txt;
}

Vielleicht kannst du etwas mit dem selection "Objekt" anfangen. Ich würde in dieser Richtung mal weiterschnüffeln.

Das ist natürlich der beste Weg über ToolStripDropDown, darüber wollte ich hier schonmal einen Artikel schreiben.

Ach komm, die paar bytes

-.-

Für dich als einzelnen User - ja.
Aber bist du der einzige, der die Suche benutzt? 😉
Es ist doch ganz einfach, egal wieviel Traffic die vorher mit den Suchanfragen hatten; Dieser steigt jetzt um das queryString.Length-fache pro Suchanfrage (und wenn nur die erste Ergebnisseite verwertet wird) mit einem Schlag.

Würde es verzögert werden wäre es ja nicht mehr "Instant". Ich rede von Verzögerungen die etwas länger sind, als das Tippen der Tasten, idealer Wert ~300-400 ms.

Ein Delay einer Anfrage ist üblich, um den Server zu schonen. Das scheint Google wohl egal zu sein, da sie die Kapazitäten wohl bieten können.

Was interessiert dich denn, dass 1 Ar = 100 m² sind, wenn du nach Arbeitsagentur suchen wolltest?

Die Methode toString() habe ich überschrieben

Wo? In einer abgeleiteten DataGridViewCell?

Um Werte zu speichern, verwendet man überlicherweise das Tag-Property. Value ist meines Wissens nach dafür da, um den Wert in der Zelle anzuzeigen, wie z.B. Text, Bilder, ...

Dafür würde, wenn dieses Popup die Grenzen der parent Form überschreitet, es dann "abgeschnitten" werden, was bei seinem Weg mit der Form nicht so ist.

Der einzige Vorteil für mich speziell liegt darin, dass ich nicht mehr Enter drücken muss, um die Anfrage abzufeuern.
Ansonsten find ichs relativ penetrant während dem Eintippen. Traffic erzeugt es sowieso ohne Ende, zumindest müsste es eine Verzögerung geben, nach der die Suche erst gestartet wird.