Ist mir auch schon aufgefallen, selbst bei ziemlich Primitiven Sachen wie Dokumenttiteln...
Und wenn du dann die List<T> erbst (oder besser eine ObjectModel.Collection<T> nimmst), dann kannst du +- und --Operator überladen uns hast deine "Event-Funktionalität"
Von NDoc gibts aber auch eine (inoffzielle) Version für .NET 2.0, funktioniert einwandfrei.
Wenn du mal mt dem Reflector in die Bibliothek System.Design.dll reinschaust, da sind haufenweise Designer, aber so gut wie alle nicht Public (sondern Internal). Mit anderen Worten: Ja, es gibt ihn, nützen tuts dir aber nix...
Wenn man einfach den ControlDesigner nimmt dann geht eine ganze Menge an Entwurfszeitunterstützung verloren.
Naja, aber die meisten SQL-Befehle sind doch Datenbanksystemabhängig, oder? Schon durch die Tatsache, dass Oracle alle Primary Keys aus einer Sequence auslesen will und es aber im SQL Server nichts vergleichbares gibt (außer im weitesten Sinn IDENTITY). Alle sind so ein bisschen SQL92-konform, aber die Unterschiede sind doch gewaltig...
verwendetes Datenbanksystem: SQL Server 2005
Hallo,
ich versuche gerade eine Kreuztabelle im SQL Server zu erstellen, die mit zwei Spalten ausgestattet ist, die jeweils einen Fremdschlüssel auf die Primärspalte haben, bis dahin ist alles OK, aber wenn ich jetzt die Trigger ON DELETE bei beiden Fremdschlüsseln auf CASCADE setze, dann sagt er mir das geht nicht, weil 'eventuell Schleifen oder längere Kaskadepfade' entstehen würden. Kann man da irgendwoe was konfigurieren, dass das trotzdem geht? Es muss doch möglich sein, dass ein Datenbanksystem wie der SQL Server Kaskaden unterstützt...
Außerdem ist ein solcher Versionssprung wie von 1.1 auf 2.0 in Zukunft erstmal nicht mehr zu erwarten, weil die CLR 2.0 eigentlich schon ziemlich alles umsetzen kann, was man sich so wünschen kann (bis 3.5 läuft ja alles unter CLR 2.0). So ein Problem kommt erst wieder mit der Einführung von dynamischen Sprachen, aber das kann dauern...
Das ist eine Konfigurationsfrage des .NET-Frameworks. Frag mich aber nicht, wo man das einstellen kann (Aber bei #dev oder VS brauchst erst gar nicht anfangen zu suchen)
Ich hab vor kurzem bei der langen Nacht der Wissenschaft einen Vortrag über Supercomputing gehört, wo u.a. ein solches Programm (ich glaube es wurde sogar unter .NET realisiert) vorgestellt wurde, also möglich ist es (Das waren Studenten, die das gemacht haben). Mittlerweile wurde die Firma dann von Intel aufgekauft, soviel hab ich auc noch aus dem Vortrag mitgenommen, aber ansonsten...
Von der Umsetzung her wäre CPU-Auslastung, Speicherverbrauch und Netzwerkakitivität wahrscheinlich nicht so das Problem, die Methodenaufrufe dürften da schon schwieriger werden, aber VS macht das ja letztendlich auch (Debug-Modus)...
Die CLR kann den Typ 'string' nicht finden, weil es den ja auch nicht gibt.
prop.Type = new CodeTypeReference(typeof(string));
sollte dagegen funktionieren...
Die Instanzierung m.E. zu dem Zeitpunkt statt, in dem die Form aufgerufen wird.
Die NullReferenceExceptions treten m.E. auf, weil das Formular beim Schließen aus dem Speicher genommen wird. Wenn du das Fenster nicht mit Close (bzw. Dispose) schließt, sondern mit Hide, dann sollte das Problem nicht mehr auftreten. Mach das aber nur bei Formularen, die auch wirklich nochmal kommen, ansonsten kriegst du über kurz oder lang Speicherprobleme...
Naja, man könnte implizite Konvertierungsoperatoren implementieren, aber wie herbivore schon sagt, das sollte man vermeiden.
Gemeinsame Basisklasse, oder wenn das nicht geht Schnittstellen sind die Lösungen
Das VB-Konstrukt
Public Class A
Private WithEvents b As Button
Private Sub C(ByVal sender As Object, ByVal e As EventArgs) Handles b.Click
...
End Sub
End Class
entspricht
public class A
private Button _b
private Button b
{get{return _b;}
set{if(_b!=value){
if(_b!=null) _b.Click-=new EventHandler(C)
_b=value
if(value!=null) value.Click+=new EventHandler(C)
}}}
private void C(Object sender, EventArgs e)
{
...
}
}
//edit: Abschließenden C#-Tag vergessen
Naja, mindestens bei WinForms ist es schon ein recht deutlicher Unterschied, ob man Ereignisse benutzt, oder die Ereignis-auslösende Methode überschreibt, weil die Ereignisse im DesignMode nicht aufgerufen werden, die entsprechenden Methoden aber schon...
Die VB-Konstrukte WithEvents Variablendeklaration und Handles-Klauseln kann man einfach mit Eigenschaften nachstellen, die im Setter die entsprechenden EventHandler deregistrieren bzw. registrieren (genau das generiert VB intern auch)
(ungeordnet)
-I, Robot
-eXistenZ
-Vanilla Sky
-Herr der Ringe (SE)
-Star Wars komplett
-Donnie Darko
-Matrix 1
-WiXXer
-Fluch der Karibik 1 (2 nicht so, 3 k.A.)
-Shrek 1&2
-Spider Man 1&2
-The Day after Tomorrow
-Spiel mir das Lied vom Tod
...
because it's definition query is too simple
Manche Leute haben Probleme... 🙂
@herbivore
Type.IsAssignableFrom hab ich schon probiert, klappt aber nicht
@svenson
Try&Error wollt ich ja grade vermeiden, aber warscheinlich ist das das beste. Auf IConvertible zu casten ist schon mal ne gute Idee.
Danke euch beiden
Um das mal klarzustellen: Ich kenne den Typ zur Compilezeit noch nicht.
@svenson:
Ist der Begriff 'Parsen' nicht ausschließlich mit der Interpretation von Zeichenketten belegt?
Ich schreibe eine Formatierungsklasse, die z.B. Objekte als Fließkommazahlen formatiert. Sie soll eine Funktion bereitstellen, die angibt ob ein Objekt mit dieser Formatierung formatiert werden kann und das Objekt gegebenenfalls dementsprechend formatieren. Nun kann eine Fließkommazahl aber nicht nur in decimal, float oder real gespeichert sein, sondern auch in int, int64 oder sonstwo (womöglich noch in selbst definierten Datentypen)
Es gibt eine weitere .cs-Datei, in der zum Formular gehöriger Quellcode hinterlegt ist. VS2005 findet also mehrmals den Eintrag:
C#-Code:
public partial class Form1 : Form
Das sollte eigentlich kein Problem sein, VS merkt sich die CodeDatei, in der die InitializeComponent() liegt, und davon gibt es zwangsläufig nur eine...
Was es sonst noch an CodeDateien gibt ist VS i.d.R. egal
Nein, der ist es auch nicht. Nicht wirklich. Nach der Ausführung des EventHandlers für das Form.Load-Ereignis wird das Layout offenbar nochmal neu, und zwar in diesem Fall ganz offensichtlich falsch berechnet, ganz so, als ob das anfangs erwähnte Steuerelement größer wäre. Aber das ist es ja nicht. Wenn man das einmal manuell ändert (im Debug ja kein Problem), dann funktioniert alles wie gewünscht...
Ich hab in dem UserControl aber auch kein InitLayout überschrieben oder so...
Naja, meint ich ja, am Ende der InitializeComponent() sind die Eigenschaften noch so, wie ich sie erwarten würde...
Dann wird's wohl doch der Code im Load-Handler sein... 🙁
Nein, am vom Designer erzeugten Code liegt's nicht, der funktioniert korrekt. Aber wenn man die Anwendung zur Laufzeit ausführt, dann haut da was nich hin...
Ich habe ein benutzerdefiniertes Steuerelement gebaut, funktioniert einwandfrei, bis auf die Anchor-Eigenschaft der darin enthaltenen Steuerelemente. Wenn man Anchor auf einem Steuerelement, was sich auf besagtem Steuerelement befindet, einstellt, dann funktioniert zwar zur Designzeit weiterhin alles wie es soll, zur Laufzeit aber werden die Steuerelemente einfach nicht angezeigt.
Bei dem Steuerelement handelt es sich um ein Panel.
Danke schon mal im Voraus
Mit den Grundlagen von Windows Forms würd ich auch erstmal ne Weile warten. Erstmal nochmal kurz OOP, damit das auf jeden Fall sitzt...
Nagut, dachte es gibt da vllt noch was, was ich noch nicht kenne...
Trotzdem Danke!
Hallo @all,
Wie kriegt man raus, ob eine Klasse eine implizite Konvertierung in eine andere Klasse unterstützt?
Bsp.: Ich hab ein Wert, dessen Typ ich nicht kenne. Diesen möchte ich nun, falls möglich, implizit in Int64 konvertieren, Try&Error is klar, aber gehts auch besser?
Also bei mir hab ich das so:
Main (bei mir heißt's FrameSet) hat einen Designer (FrameSetDesigner), bei dem die DesignerVerbs überschrieben sind, wodurch zwei Verbs ('Frame hinzufügen' und 'Frame entfernen') bereitgestellt werden. Dieser Designer ist von ControlDesigner abgeleitet, da man dem FrameSet eigenhändig keine Controls hinzufügen können soll, außerdem wird GetHitTest überschrieben, damit man zwischen den einzelnen Frames hin- und herschalten kann und das FrameSet ausgewählt wird, wenn man auf das Auswahlfeld clickt.
Frame hat ebenfalls einen eigenen Designer, der von ScrollableControlDesigner abgeleitet ist und damit schon mal bewirkt, dass neue Steuerelemente den Frames zugeordnet werden, außerdem bewirkt dieser, dass Frames nur FrameSets hinzugefügt werden können.
Jetzt funktioniert alles wie gewünscht, mit der Ausnahme, dass beim Auswählen des FrameSets immer mal eine NullReferenceException geworfen wird, wo ich aber leider keine Ahnung hab, woher die kommen könnte (und man kann den Designer ja leider sehr schlecht Debuggen...)
Hast du nur für das TabControl einen Designer oder auch für die TabPages?
Einfach: GetHitTest überschreiben. Aber denk nach, was du machst, wenn du einfach nur True zurückgibst, dan kann's dir passieren, dass Dinge geschehen, die du nicht haben willst....
Naja, hat er doch gesagt: 🙂
Das kann aber auch heißen, TabControl abgeleitet und erweitert...
Ja, der Designer fängt sämtliche Mausereignisse ab, allerdings nur genau dann, wenn die GetHitTest-Methode für die angegebene (Bildschirm(!)-)Position False ergibt.
Benutz mal die Forumsuche, wir hatten das Thema schon mal, ich weiß aber nicht mehr wo...
@HansDampf:
...mit denen aber schwer umzugehen ist, da ist CodeDOM noch einfacher zu verstehen...
Nein, jedenfalls nicht kostenlos.
Aber es gibt kostenlose Alternativen:
die Boxen, die sich am Bildschirmrand einklappen und automatisch aufgehen, wenn man mit der Maus darüber fährt
->http://www.codeproject.com->Weifen Luo DockingSuite
die ToolBox (zum Gruppieren von Elementen)
schau mal nach dem Extender für die DockingSuite von Danillo Corallo (auch bei CodeProject.com), da ist in den Samples sowas umgesetzt...
Wenn ich mal raten darf: Das was du uns hier als TabControl anbietest ist in Wahrheit eine komplette Eigenentwicklung, deren Struktur aber ähnlich eines TabControls ist. Die Steuerelemente, die den TabPages entsprechen würden, hast du auch mit einem eigenen Designer ausgestattet, damit sie nur auf dein TabControl (oder wie auch immer es in Wahrheit heißen mag) passen und nirgendwo anders draufgehen, und du ein paar Eigenschaften von Panel verstecken kannst. Genau wie die Orginal-TabPages sind deine von Panel abgeleitet. Den Designer hast du von System.Windows.Forms.Design.ControlDesigner abgeleitet.
(deine Problembeschreibung passt so haargenau auf das, womit ich mich in den letzten Tagen auch rumgeschlagen hab)
Lösung: Der Designer ist nicht von ParentDesigner abgeleitet, und unterstützt standardmäßig kein Einfügen von Komponenten. Du kannst das selber probieren (theoretisch), aber das ist ein Overkill, da ParentDesigner diese Funktionalität zur Verfügung stellt und öffentlich verfügbar ist. Wenn du aber den Designer von ParentControlDesigner ableitest, dann ist die Unterstützung der Scrollbalken in den TabPages (so du welche zulässt) noch nicht gegeben. Leite den Designer deshalb nicht von ControlDesigner, sondern von ScrollableControlDesigner ab. Leider ist der PanelDesigner nicht verfügbar, aber das kann man nu mal nicht ändern, aber es geht auch so.
Operatorüberladung (Speziell die Castingoperatoren) für Schnittstellen hätt ich gern noch... 🙂
Mmhh, ich fürchte ich war ein wenig neben mir, hab gedacht, dass Problem besteht darin, dass erstmal überall try-catch-konstrukte her müssen. Hab wohl etwas flüchtig gelesen...
Wenn man aber wie man das sollte immer nur die Exceptions fängt, die man erwartet gehen alle unerwarteten durch und werden dann erst im AppDomain.UnhandledException-Ereignis abgehandelt...
nicht mit .NET-Mitteln.
Und was ist, wenn du einfach das AppDomain.UnhandledException-Ereignis behandelst?
Ich finde den Begriff dynamische Methode eigentlich selbst erklärend, es handelt sich dabei um eine Methode, die dynamisch - also zur Laufzeit - erzeugt wird. Aus diesem Grund kann eine solche Methode auch nur als Delegate aufgerufen werden, weil man sie ja zur Compilezeit noch nicht kennt.
Aber das ist jetzt eigentlich was das Thema betrifft ja nur noch Hintergrundwissen. Das komplette Thema dynamische Methoden hiere in einem Thread abzuhandeln, aus dessen Titel man nie erahnen würde, dass da dynamische Methoden drinstecken (weil's eigentlich Blödsinn ist, sowas mit dynamischen Methoden machen zu wollen, die Musterlösung ist die, die im letzten Beitrag von VizOne steht), fänd ich blödsinnig, weil es dem Grundgedanken eines Forums (neue Themen in neue Threads) m.E. widerspricht (ehrlich gesagt würd ich mich nicht wundern, wenn demnächst einer der Admins die letzten Beiträge abtrennt)
Alles neu macht der Mai halt 🙂 in diesem Fall halt der Mai08 🙂
Tut mir Leid, mit WPF hab ich meich (leider) noch nicht beschäftigt...
außerdem fehlt ein () nach GetProperties
Naja, ich programmier im Normalfall VB.NET und da geht das 🙂
Ich kenn die Syntax der Reflection-Methoden (noch) nicht auswendig, und wie gesagt, der Code war halt ungetestet...
-> Grundlagen
Man erstellt die Klasse genau wie Int, Char & Co. als struct, dass ist dann von ValueType abgeleitet und damit wird (im Normalfall) eine Kopie der Daten übergeben.
String ist was ganz anderes, das ist eine Klasse, die als Immutable markiert ist und sich deshalb in manchen Situationen ähnlich wie ein Wertetyp verhält...
Das Zauberwort lautet Reflection:
foreach (PropertyInfo pi in typeof(SystemColors).GetProperties)
{
String name=pi.Name
Color c=(Color)pi.GetValue(null)
}
(ungetestet)
//Edit: Drei Beiträge innerhalb einer Minute is nich schlecht...
Da gibt es mehrere Wege:
Bei Variante 1 und 2 brauchst du einen Compiler, vorzugsweise den Microsoft.CSharp.CSharpCodeProvider.
Variante 3 verfolgst du am besten gar nicht, was kleines wie ein paar Methoden kann man damit mal machen, mehr wird aber höllisch schwierig (geht aber)
Was die dynamischen Methoden angeht, da findest du bei http://www.codeproject.com ein paar nützliche Artikel.
Prinzipiell sehe ich das aber genauso wie VizOne (auch wenn der Weg über dynamische Methoden kaum Performanceverluste bedeuten würde). Ja, da entstehen Redudanzen, aber die entstehen in jedem Fall, weil selbst wenn du alles in eine supertolle Methode auslagern kannst, musst du immernoch irgendwie sagen, auf welches Feld du zugreifen willst und die Zeichenkette muss natürlich auch mit übergeben werden.
Naja, Exceptions im Fehlerfall und der Einsatz von Reflection machen die Sache aber ziemlich unperformant...
Wenn überhaupt mit Reflection, dann spar dir wenigstens die Exceptions im Fehlerfall:
public static void SetOrForget(object pTarget, string pPropertyName, double pOldValue, string pValueToParse)
{
double newValue
if (double.TryParse(pValueToParse, out newValue)
{
if (newValue!=pOldValue)
{
try
{
PropertyInfo pi=pTarget.GetType().GetProperty(pPropertyName);
pi.SetValue(pTarget,newValue,new object[]{});
}
catch{}
}
}
}
Wenn du's über Reflection lösen willst, dann wären aber warscheinlich eher dynamische Methoden das Mittel der Wahl...
Da ich das nicht ausnahmslos Sicherstellen kann, ist die Variante nicht machbar.
Naja, wenn du Mist verarbeitest kommt selten mehr als Mist raus...
Wenn du nicht an die Felder selber rankommst, dann geht das was du willst so nicht, aus dem einfachen Grund, weil der Getter der Eigenschaft ja schon mal gleich den Wert kopiert und du dann nur noch die Kopie referenzieren kannst...
System.Security.AllowPartiallyTrustedCallersAttribute, einfach irgendwo im Code (vorzugsweise in der AssemblyInfo.cs soweit vorhanden) einfügen