mach mal nicht den Umweg über String.Format, sondern nimm gleich Convert.ToString, oder alternativ auch direkt (value).ToString("0.000000e+00")

Automatische Listenkonvertierung in dieser Art kann gar nicht funktionieren. Was wäre zum Beispiel wenn fooListDerived Objekte enthält, die IModelObject, aber nicht IArticle implementieren? Andersrum wäre die Sache schon eher denkbar, da jedes IArticle-Objekt zwingender Weise auch IModelObject implementiert. Aber in die Richtung wird dir nichts anderes übrig bleiben, als das ganze händisch zu machen.

Meine Aussage, OnPaint nie direkt aufzurufen bezog sich auch nur auf den Aufruf in anderen Methoden. Das Methode ihre Basismethode, die sie überschreibt, aufruft ist immer legitim (die würde ja sonst auch aufgerufen werden)

private void LöseLabyrinth()
        {
            // Hier den Lösungsalgorythmus unterbringen
            // Am besten mit einem Timer
            // Nach jedem "Schritt" OnPaint aufrufen;
        }

bullshit, sorry, wenn ich mich drastisch ausdrücke, aber NIEMALS OnPaint aufrufen!!!! Was du aber machen kannst, ist Invalidate aufrufen und am besten noch berechnen, welchen Bereich du neu zeichnen willst.

mir ist aber nichts desto trotz noch etwas am Code von JuyJuka aufgefallen:

dataPoints.Remove(point);

ist unklug, wenn du schon den Index des Eintrags kennst, dann lieber doch

dataPoints.RemoveAt(index);

Ich glaub nicht, dass das in dieses Forum gehört. Ich meine, wir können hier gerne über die Wahl von Programmiersprachen reden, aber nicht mit dem Titel "Irgendwie bin ich grade frustriert"!

Normalerweise macht man es so, dass sämtlicher Initialisierungscode in die Form.Load-Ereignisprozedur gepackt wird, die am Anfang einen Splashscreen öffnet und diesen am Ende schließt...

dann schieb die Datei doch via MemoryStream in ein Byte-Array und stell das dann ins ClipBoard. Aber warum? Andere Programme werden damit höchstwahrscheinlich nichts anfangen können...

Kopierschutz, der einfach und gleichzeitig unüberwindbar ist? Was meinst du, warum MS sowas wie Produktaktivierung macht? Du wirst Kompromisse machen müssen.

Ein Dictionary (ich nehme an, du benutzt Dictionary<T>) ist ein ReferenceType, wird also als Referenz übergeben.

Gib mal nicht nur den StackTrace, sondern auch die Fehlermeldung, das hilft ungemein...

Es gibt ja die Methode Array.Copy, aber ich kenne die Aufrufregeln nicht ausreichend gut, um sie dafür zu nutzen, aber vllt gehts damit.

Letzten Endes ist #Dev ja auch ein Programm, was man mit VS vergleichen kann und komplett in C# geschrieben...

Eine gute und eine schlechte Nachricht:
Erst die gute: Ja, es geht
Jetzt die schlechte: Es ist verdammt schwer und du wirst nur wenige finden, die sich damit auskennen (ich gehöre nicht dazu). Du musst einen Designer-Host bereitstellen, es gab mal auch einen Artikel im Forum dazu... Ansonsten schau dir mal den Quelltext von #Dev an, sollte dir weiterhelfen...

Ja, das Ganze soll ein Programm für die PM Logikpuzzle werden. Die Anzeige von 2D-Puzzlen ist als Steuerelement schon realisiert, aber jetzt hab ich mir gedacht, man kann ja mit nem Computer viele schöne Sachen machen und das ganze um eine Dimension erweitern...

Der 2D-Part ist aber wie gesagt schon komplett mit GDI gemacht...

Ich glaub ehrlich gesagt noch nicht dran, dass ich das irgendwann portiere. Fehlt einfach die Zeit. Ich mein, wär schon schön, wenn's auf Mac und Linux läuft, aber der Preis ist glaub ich zu hoch...

Anwendung setzt auch bis jetzt schon massiv GDI ein (2D), wär ja auch wieder für die Katz'

ist sie nicht 🙂

int[,] mehr = new int[2, 2] { { 1, 2 }, { 3, 4 } };
int[] tmp = new int[mehr.Length];

int zeile=0;

for(int i=0; i<mehr.GetUpperBound(1))
tmp[i]=mehr[zeile,i];

Danke erstmal!

Anwendung soll in der Tat unter Windows laufen (vllt kommt später auch eine Portierung für andere Systeme, aber das hat Zeit). Mit GDI wollte ich gar nicht erst anfangen, hab mein 2D-Kram damit jetzt gemacht, aber für 3D werd ichs nich benutzen.

Wollte nur den prinzipiellen Ansatz wissen, die Technologie, die man in diesem Fall verwenden sollte und das wird bei mir jetzt wahrscheinlich Direct X sein...

Danke für den Link!

Hallo,

ich möchte gerne in einem abgegrenzten Bereich auf einem Formular eine 3D-Engine laufen lassen. In diesem Bereich soll ein Raster (ca. max. 40x40x40) angezeigt werden, wobei in jeder Zelle ein Würfel einer bestimmten Farbe sein soll (oder eben halt gar kein Würfel). Die Würfel an sich sollen einfarbig sein, wobei die Farbe variierbar sein muss. Zusätzlich hätt ich gerne Licht und Schatteneffekte, wenn es die Performance zulässt (muss also abschaltbar sein, die Abschaltung an sich wird aber das wohl geringste Problem sein). Die Sicht soll mit der Maus drehbar sein, ansonsten ist alles statisch.

Nun meine Frage: Womit kann man das erreichen? XNA? Irrlicht? Hab von 3D mit .NET (bislang) keine Ahnung...

Danke schon mal im vorraus!

dann wende die Formel doch für Rückwärtsfahren an 🙂, geht das nicht? Normalerweise fahren ja die Hinterräder wenn man es so will immer geradeaus...

ich bin mir mit dem Code nicht 100%ig sicher (programmier normalerweise in VB.NET und hab auch grad keine IDE vor mir), aber in etwa so müsste es aussehen:

public class QuickBar
{

private QuickBarItemCollection mItems

public QuickBar()
{
mItems=new QuickBarItemCollection(this);
}

public QuickBarItemCollection Items
{
get{return mItems;}
}

public class QuickBarItemCollection:thumbsup:bjectModel.Collection<QuickBarItem>
{

private QuickBar mOwner

public QuickBarItemCollection(QuickBar owner)
{
mOwner=owner
}

override void InsertItem()
{
...
}

}


}

public class QuickBarItem
{

private QuickBar mOwner
private Int32 mID

internal QuickBar OwnerInternal
{
get{return mOwner<}
set{mOwner=value:}
}

internal Int32 IDInternal
{
get{return mID;}
set{mID=value;}
}

public QuickBar Owner
{
get{return mOwner}
}

public Int32 ID
{
get{return mID;}
}
}

Mach dir eine Klasse QuickBarItemCollection, in der du den Eigentümer der Auflistung speicherst (am besten von ObjectModel.Collection<QuickBarItem> ableiten), überschreibe die Insert/Remove Methoden und mach in die QuickBarItem eine internal-Eigenschaft mit der IBar. Dann solte es gehen. Im Insert kannst du auch automatisch deine IDs vergeben...

im Editor unter Ansicht den Zeilenumbruch einschalten 🙂

Wenn du das Passwort im Programmcode hinterlegen willst ist die einzige Variante, dass man es nicht (d.h., ohne viel Aufwand) rauskriegen kann, zwingend das SupressIldasm-Attribut.

Naja das ist ja nu keine Lösung, sondern nur ein Workaround. Aber wenn es mit Schnittstelle geht liegt es definitiv nicht an der Assemblyversion und die Deserialisierung an sich ist auch i.O....

Ich versteh nur nicht ganz den Sinn dieser Schnittstelle (Entschuldigung, wenn ich da direkt bin). Du willst eine Schnittstelle haben für Klassen, die Elemente sortieren können, bei denen die Elemente die Sortierung vorgeben (und nur die), so dass die Klassen, die diese Schnittstelle erfüllen, die Sortierung nur ausführen, die Reihenfolge, in der die Elemente sortiert werden, aber nicht beeinflussen. Die Aufgabe ist immer die selbe und daher gibt es im Schnitt eine Klasse, die die Aufgabe am besten löst. Dann kann man diese Klasse auch direkt benutzen.

Viel sinnvoller wäre es doch aber, Sortierer für Elementtypen bereit zu stellen, die sich nicht von Haus aus vergleichen (und damit sortieren) können, um benutzerdefinierte Sortierungen zu zu lassen. Dann brauchst du die Einschränkung mit IComparable<T> aber nicht mehr.

Die Antwort von dem MSDN-Typen erklärt, warum es bei int nicht geklappt hat, aber warum hat es bei string geklappt?

Wenn due deine ItemCollection von ObjectModel.Collection<(Itemklasse)> ableitest und bei der Itemklasse einen parameterlosen Konstruktor implementierst, dann ein readonly property auf die ItemCollection mit dem Attribut DesignerSerializationVisibility auf Content stellst, dann hast du die Designerunterstützung.
Wie du das Zeichnen dann gestaltest musst du selber wissen (je nachdem wie es aussehen soll)

Zumindest ist das ein Punkt, den FxCop immer ankreidet. Und auf der Seite zu der Collection<T> steht auch der Hinweis, diese vorzugsweise zu gebrauchen. Aber du hast Recht, serialisierbar ist die nicht (nicht standardmäßig). Aber man kann sie ziemlich einfach serialisierbar machen (ISerializable implementieren), intern basiert das Ding (standardmäßig) ja auch nur auf einer List<T>, wobei man auch beliebige andere IList<T> als Grundlage benutzen kann.

Anmerkung:
Microsoft hält es offiziell nicht für günstig, die generische List<T> Klasse nach außen zu geben, sondern einen Wrapper zu schreiben. Damit kannst du dann auch sowas machen, dass eine Etage immer weiß, in welchem Haus sie sich befindet (was ja wohl eine ziemlich nützliche Information ist, wenn du die Etage suchst!!!). Mittel der Wahl dafür ist die System.Collections.Generic.ObjectModel.Collection<T>, bzw. (wie ich es immer mache), eine Ableitung davon (die Suchfunktion von besagter Klasse sind sch....).

public class Haus
{

private EtagenCollection etagen

public Haus()
{
etagen=new EtagenCollection();
}

public class EtagenCollection:thumbsup:bjectModel.Collection<Etage>
{
...
}
}

Eigentlich Alle Soundtracks von John Williams oder James Horner sind zu empfehlen (z.B. Star Wars, Shrek, Zorro, Harry Potter, u.v.m.)

Und die Musik von Webber-Musicals (Phantom der Oper, Cats, ect.)...

Hm, das erste, was mir jetzt so ganz spontan einfällt wäre Neue Button-Klasse und OnClick überschreiben. Dann hast du selber die Kontrolle, wann das Ereignis ausgelöst wird und wann nicht. Aber eigentlich sollte der normale Button das auch von selber tun (Click-Ereignis unterdrücken, meine ich). Aber "Das sollte eigentlich nicht passieren" ist natürlich keine Lösung...

oder du benutzt für die ganze Sache MS SQL Server Compact Edition. Der müsste in VS integriert sein (Ich hab Orcas Beta 1, da funzts leider nicht)

Original von herbivore
wobei die erste Variante von dN!3L eindeutig vorziehen ist.

Warum? Nur mal so ganz blöde gefragt...

Ich meine, in gewissem Sinne hast du Recht, die erste Variante verletzt den Gedanken der Objektorientierung. Aber wenn du einen Mittelweg gehst, nämlich beide Events auf den gleichen Handler registrierst, der dann wiederum dann die Methode DoStuff aufruft, hast du eine Methode weniger geschrieben und trotzdem das selbe erreicht, ersparst dir also Methodenmüll. Ich meine, zwei einzelne Methoden wird wegen der Unterstützung von VS wahrscheinlich schneller gehen, aber von der Theorie her...

Arbeit Anfang des Jahres:

Centrino 1,6 Ghz
512Mb RAM
30GB Festplatte
15,1 Zoll Display

Jetzt in Irland:

Pentium III 1200Mhz
256Mb RAM
30GB Festplatte, davon 10 für Linux
14 Zoll Display

Beides Laptops

Mit dem Centrino kann man auch ganz gut arbeiten, hat zwar eine geschlagene Viertelstunde gedauert, bis alle 14 Projekte dann mal geladen waren, aber es geht. Der jetzige hat definitiv zu wenig (RAM und CPU)

Von der Festplatte kommt man aber mit 20Gb hin (keine Musik drauf)

Coheed&Cambria
Ghinzu

Panels sind auch nur Container, haben aber ganz andere Designer. Wenn du ein Panel im Designer öffnest, dann kannst du da wesentlich weniger machen, als wenn du ein Formular änderst.

Bei EventHandlern sollte (und bei allem, was Microsoft fabriziert ist das auch so) das Objekt der Sender sein, der das Ereignis auslöst, ansonsten kommt man in Teufels Küche. Das ist auch der Grund, weshalb die ganzen Methoden der Steuerelemente á la OnClick oder so nie einen Sender haben wollen, sondern immer nur die Ereignisdaten (EventArgs eben)

Naja, du kannst ja mit Assembly.GetResourceNames die Assembly auswerten, oder?

Ich wüsste nicht, dass der in der Asembly gespeichert sein sollte. Warum auch?

Ich würde beides kombinieren: Eine Schnittstelle IVirtualFile und eine Schnittstelle IVirtualFileSystem, wobei IVirtualFile ein readonly property FileSystem mit dem Typ IVirtualFileSystem hat.

Die Implementierung des Windows-Dateisystems:
Eine Singleton-Klasse WindowsFileSystem, die IVirtualFileSystem implementiert und eine Klasse WindowsFile, die IVirtual implementiert und als FileSystem zwingend die Singleton-Instanz von WindowsFileSystem.

Bei eingebetteten Ressourcen (und dazu zähle ich Archive jetzt einfach mal dazu) müsste die Implementierung von IVirtualFileSystem dann so aussehen, dass die Klasse dann auch weis, wo sich das Archiv befindet etc...

D.h., theoretisch kann man es machen, wenn man InitializeEditingControl und DetachEditingControl der DatagridViewCell überschreibt und dort eigenhängig die EventHandler registriert und wieder deregistriert, aber das steht m.E. in keinem Verhältnis zum Aufwand.

Gar nicht.

Aber du kannst DatagridView.CellContentClick behandeln und dann gucken, ob in die Spalte mit den Bildern geclickt wurde.

Naja, eine Konsolenanwendung endet doch dann, wenn die Prozedur aus der sie besteht endet, also könnte man doch einfach die Prozedur beenden. Beispielsweise mit einer eigenen Exception, die dann einfach nur in der äußersten Schleife gefangen wird.

Plan B: Der große Holzhammer: Environment.Exit

Funktioniert

Control c=...
Bitmap btm=new Bitmap(c.Width,c.Height);
Rectangle rect=new Rectangle(0,0,c.Width,c.Height);
c.DrawToBitmap(btm,rect);

nicht?

Wenn du nur die brauchst, die in IVBlock festgelegt sind gibt es zwei Möglichkeiten:

1. Setze bei allen anderen Eigenschaften per Attribut Browsable auf False
   (geht bei Steuerelementen schlecht, weil du an viele Eigenschaften nicht rankommst)

2. Bau deinen eigenen TypeConverter (der von der Klasse TypeConverter oder ExpandableTypeConverter abgeleitet ist) und überschreibe GetProperties

Was die Sache mit dem Editor angeht: Du hast glaub ich nicht verstanden, was ein Editor ist (im Sinne des ComponentModels) ist. Es ist eine Klasse, die ein Objekt verändern kann, also zum Beispiel das Auswahlfeld, dass du bei Enumerationen siehst, oder der Dialog beim Auswählen von Farben, oder auch der Dialog zum Editieren von TabPages oder DataGridViewColumns. Alle diese Editoren lassen sich mit Klassen darstellen, die von System.Drawing.UITypeEditor abgeleitet sind (und sein müssen).

Theoretisch ist es auch möglich, andere Basisklassen zu nehmen (hab aber keine Ahnung, welche das sein sollten).

Editor bringt deshalb nichts, weil du es komplett falsch einsetzt.

1. Doch, das PropertyGrid kennt die Struktur von IVBlock (Reflection)

2. 'Unter'Grid:

[TypeConverter(typeof(ExpandableObjectConverter))]

3. Editor:

[Editor(typeof(<<EditorTyp>>),typeof(Drawing.Design.UITypeEditor))]

<<EditorType>> ist dabei ein Typ, der einen Wert bearbeiten kann. Am einfachsten implementierst du den, in dem du dir mal bei http://www.codeproject.com ein Tutorial und vor allem eine sehr gute Basisklasse (ich weiß nicht mehr wie die heißt, den Autor kenn ich auch nicht, aber der Code war in VB.NET, musst also übersetzen) suchst, es kann auch gut sein, dass ich den Link hier im Forum irgendwann mal gepostet habe...

Lass mich raten: Der Forms-Designer erscheint nicht, so wie du dir das vorgestellt hast, sondern stattdessen nur der Designer, den du von der Komponentenerstellung kennst. Du kannst zwar Komponenten zu deiner Form hinzufügen, aber keine Steuerelemente.

Soll ich dir sagen warum?

Weil der Designer im innern seines Herzens auch nichts weiter ist, als ein schnöder ControlDesigner, von dem man keine Fähigkeiten erwarten kann, die ein FormDocumentDesigner beherrscht.

Einzige Lösung: FormDocumentDesigner abschreiben und dann vererben. Wenn es da Probleme geben sollte von wegen, manche Sachen sind halt internal, tja, Pech gehabt, Microsoft hat wahrscheinlich verhindern wollen, dass die Leute vorschnell irgendwelche Designer für Steuerelemente verwenden, für die sie nicht gedacht waren, und die Massen an Fehlermeldungen die dann entstehen auf den Windows.Forms-Designer schieben, der für diese Blödheit aber nichts dafür kann. Das ist mir jetzt schon bei einigen Steuerelementen aufgefallen, dass die so implementiert sind, dass man da an sehr wichtigen Stellen nichts erweitern kann. Die Steuerelemente sind offenbar alle samt ausschließlich zum und nicht zum Weiterentwickeln gedacht.

Nein. Was in meinem Fall nicht besonders schlimm ist, da ich ASP.NET eh nur als HTML-Editor für die Doku benutze... 🙂, aber ansonsten würde es mich wirklich ankotzen 🙂. Ne aber mal im Ernst, eine Lösung dafür hab ich bis jetzt auch noch nicht gefunden.

Da jedesmal wenn du auf den Buttun klickst wieder eine neue Forminstanz aufgerufen wird. Du mußt erst prüfen ob sie schon auf ist. Ich habe das so gelöst.

Wenn du mit sowas anfängst musst du aber aufpassen, teilweise sehr gute fertige Lösungen für VB.NET (My.Application.Forms) werden extrem oft missbraucht, weil die Einsatzgebiete überschritten werden. Ich will nur sagen, so eine Lösung kann man machen, aber man muss sich ganz genau im klaren sein, wann und wie man die fertige Lösung einsetzt, um sich nicht in der Welt der .NET-Programmierer stark unbeliebt zu machen (wie auch der Ansatz von My.Application.Forms ja sehr stark verpönt ist)

Naja, wenn man kein Datum angibt nimmt DateTime m.E. immer das aktuelle Datum, 23:00 würde also interpretiert als heute, 23:00 und 7:00 dementsprechend als heute, 7:00. Es sollte aber eine Methode geben DateTime.AddDays

DateTime theDate1 = DateTime.Parse("23:00")
DateTime theDate2 = DateTime.Parse("7:00")
theDate2=theDate2.AddDays(1)

Ansonsten so wie Mystique das schon gesagt hat...