Hab das Problem gefunden. Man muss da wohl immer ein VertexElement.VertexDeclarationEnd hinzufügen:

VertexElement[] elements = new VertexElement[3]
{
    new VertexElement(0, 0, DeclarationType.Float3, DeclarationMethod.Default, DeclarationUsage.Position, 0),
    new VertexElement(0, 12, DeclarationType.Color, DeclarationMethod.Default, DeclarationUsage.Color,0),
    VertexElement.VertexDeclarationEnd
};
m_vertexDecl = new VertexDeclaration(m_device, elements);

Gruß
Roland

Ne, passt schon. In dem Fall würd ich den Remotedebugger empfehlen, falls das möglich ist.

Hi Dux,

schau dir mal die Methode Assembly.GetReferencedAssemblies an

Gruß
Roland

Hi Toast,

schau dir mal von dieser Exception die Eigennschaft LoaderExceptions an. Da stehen dann direkt die Typen drinne, bei denen Probleme aufgetreten sind.

Gruß
Roland

Hi,

hm.. rein mit dem XmlSerializer wirst da nicht weit kommen. Den musst du ja den Typ des zu deserialisierenden Objekt direkt schon im Konstruktor übergeben.

Du könntest höchstens versuchen, die erste Node bereits vorher mit einem XmlReader zu Lesen und anhand des Namens (Name des Nodes ist i. d. R. der Name der Klasse) zu entscheiden, mit welchem Typ das XmlSerializer Objekt erzeugt werden soll. Danach könntest ganz normal deserialisieren.

Wär zwar ein kleiner Umweg, sollte aber für dein Ziel reichen.

Gruß
Roland

Diese Fehlermeldung kommt nur im Debugger, und da kannst du siese auch ohne schlechtes Gewissen ignorieren.

Einfach im VisualStudio im Menü Debug auf die Schaltfläche Excetions klicken (ich hab die Englische Version). Dann findest du bei Managed Debugging Assistants einen Eintrag namens LoaderLock. Da musst den Hacken raus machen.

Ich weiß, ist nicht schön, aber sind mir zumindest keine praktischen Probleme bekannt, die an der Stelle auftreten können.

Gruß
Roland

Hi,

bei folgendem Coding hänge ich grad ein bissl:

VertexElement[] elements = new VertexElement[2]
{
    new VertexElement(0, 0, DeclarationType.Float3, DeclarationMethod.Default, DeclarationUsage.Position, 0),
    new VertexElement(0, 12, DeclarationType.Color, DeclarationMethod.Default, DeclarationUsage.Color,0)
};
m_vertexDecl = new VertexDeclaration(m_device, elements);

Und zwar stürzt der immer ab (mit einer Direct3D9Exception), sobald in der hier letzten Zeile das VertexDeclaration Objekt erstellt werden soll. Irgendwie fällt mir aber kein Grund ein, warum das nicht funktionieren sollte.

Fällt euch ein Grund ein, warum das schief läuft?

Gruß
Roland

Ne, ich selbst habe das schon öfters so gemacht. Und ich kenne auch viele, die das auch auf die Art gelöst haben. Und von Problemen hab ich da bis jetzt noch nix gehört.

Schön ist dieser Weg halt net, das ist klar. Deswegen sollte dieser Weg auch eine absolute Notlösung sein.

Hi,

doch, den .Net Connector kannst du schon in höheren .Net Versionen nutzen, aber nur umständlich. Du musst da separat noch VS 2003 installiert haben, um den Designer des Connectors nutzen zu können. Sobald dieser die benötigten Klassen erstellt hat, kann man diese einfach in das aktuelle VS 2008 und damit auch zur aktuellen .Net Version rüberschieben.

Ob das aber für dich der richtige Weg ist, hängt davon ab, was du tun willst. Beim .Net Connector läuft die Verbindung per RFC - was eigentlich das schnellste Protokoll ist, mit dem du dich mit SAP verbinden kannst. RFC-Connectoren gibt es viele. Für C# fallen mir da spontan der eben schon erwähnte .Net Connector von SAP ein, aber auch das kostenpflichtige ERPConnect. Gibt sicher noch ein paar andere an der Stelle. Für C++ und Java, Ruby, ... gibts dann auch noch ein paar - wobei man sagen muss, dass im Endeffekt alles entweder die librfc32 oder schon die neue NetWeafer RFC-Bibliothek von SAP nutzt.

So, eine andere gängige Möglichkeit sind dann auch Webservices. Du kannst quasie im SAP einen Webservice anlegen und direkt mit dem Kommunizieren - ohne jetzt irgendwelche andere Fremdbibliotheken nutzen zu müssen. Ist zwar etwas langsamer (unterschied liegt im 2-Stelligen millisekunden Bereich 😉), aber sollte auch ein vernünftiger Weg sein.

Am Markt gibt es daneben noch jede Menge anderer Tools und Frameworks, die auch genau das selbe machen, wie die zwei oben genannten Möglichkeiten.

Ich würde mich an deiner Stelle einfach mal ein paar Tage Zeit nehmen und einfach mal mit dem Zeug rumspielen. Dann merkst du schnell, welches der bessere Weg ist.

Ich hoffe, ich konnte dir hier mal einen kurzen Überblick geben.

Gruß
Roland

Hi

Ne, SlimDX automatisiert im Gegensatz zu ManagedDirectX garnix - die wollen ja auch nur einen Wrapper für die DirectX-Funktionen bieten und keine extra logiken wie MDX es getan hat.

Das Handling selbst ist eigentlich recht Simpel. Ich mach eigentlich immer um das komplette Rendern ein Try-Catch und fang somit die DeviceLostException ab. Sobald diese aufgetreten ist, müssen alle geladenen Resourcen Disposed werden. Anschließend kannst du immer wieder versuchen, ob du das Device resetten kanst - Irgendwas von wegen CheckCooperativeLeven oder sowas (fällt mir jetzt zumindest spontan dazu ein). Und sobald diese Methode das OK gibt, kannst du Device.Reset aufrufen und wenn diese erfolgreich war, alle Resourcen neu laden.

Solltest bei dir das Rendern in der OnPaint Methode eines Controls stattfinden, hasst dus da eigentlich recht einfach. Weil diese wird sowieso nur dann aufgerufen, wenn das Device auch gerade Verfügbar sein kann. So kann es dir dann bloß passieren, dass du nach dem Verlust des Bildschirms (z. B. bei STRG+ALT+ENTF) nur einmal kurz Resourcen disposen, Device resetten und dann direkt die Resourcen neu laden musst und fertig.

Gruß
Roland

Danke für die Antworten, genau sowas hab ich gesucht

hm... genau, an sowas hab ich auch schonmal gedacht.
Was mir an der Lösung net gefällt, ist, dass man dafür die komplette Assembly laden muss - Obwohl man ja eigentlich bloß diese eine Eigenschaft auslesen will.

Hi,

ich hab Momentan folgendes Problem: Ich will von einer Exe-Datei die Eigenschaft "Produktname" auslesen. Über den Windowsexplorer findet man diese per Rechtsklick -> Eigenschaften -> Version -> Produktname. Die Frage ist jetzt, wie kann ich diese Eigenschaft per C# abfragen. Mit FileInfo und dem Zeugs komm ich da irgendwie net weiter.

Gruß
Roland

Hi,

ne List<object> ist nicht wirklich sinnvoll. Ich würde deine Methode SelectObjects generisch machen, so dass rauskommt List<MeinTyp> liste = SelectObjects<MeinTyp>(queryString).

Mehr zum Thema findest du hier

Gruß
Roland

Hi mogli73,

zufällig hab ich genau sowas auch vor ein paar Tagen gebraucht. Ich habs aber auch, wie von Adi vorgeschlagen, dann selber programmiert. Das Coding sieht bei mir dann so aus:

        /// <summary>
        /// Deletes the given directory
        /// </summary>
        public static void DeleteDirectory(string directory)
        {
            DeleteAllFiles(directory, true);
            Directory.Delete(directory, true);
        }

        /// <summary>
        /// Deletes all files in the given directory
        /// </summary>
        public static void DeleteAllFiles(string directory, bool alsoForSubfolders)
        {
            foreach (string actFile in Directory.GetFiles(directory))
            {
                File.SetAttributes(actFile, FileAttributes.Normal);
                File.Delete(actFile);
            }

            if (alsoForSubfolders)
            {
                foreach(string actDirectory in Directory.GetDirectories(directory))
                {
                    DeleteAllFiles(actDirectory, alsoForSubfolders);
                }
            }
        }

Um damit ein Verzeichnis zu löschen, brauchst du bloß die Methode DeleteDirectory([Pfad]) aufrufen.

Gruß
Roland

Hi HelixX23,

Ich kenn mich jetzt zwar mit Access und dem VBA Zeugs net so aus, aber ich schätz mal, dass das Control ein ActiveX Control sein muss, damit sowas geht. Und genau hier wärs schwierig. Man kann zwar .Net UserControl als ActiveX Controls verfügbar machen, aber soweit ich weiß, kann dann nur der InternetExplorer mit diesen Controls umgehen.

Ich würd mir mal an deiner Stelle das neue VSTO Zeugs anschaun, vielleicht ist da was dabei, was du brauchst.

Gruß
Roland

So braucht man nicht sämtliche Filme anspielen sondern kann schon auf den Screenshots erkennen was in dem Film enthalten ist.

Das macht doch der Explorer von Vista und XP schon von Haus aus, oder versteh ich dich falsch?

Sollte mit SlimDX kein großes Problem darstellen.

Aber wenn du das ganze in XNA schon richtig anzeigen kannst, würd ich an deiner Stelle aber auch in XNA weitermachen. Denn was Shader und Animationen angeht, hast du in XNA die selben Möglichkeiten, wie in SlimDX (DirectX 9) oder C++ auch. Außer du willst einen Effekt umsetzen, welcher auf DirectX 10 ausgelegt ist, aber ich schätz mal, so weit willst du garnet gehn, oder?

Hallo Peter

du meinst wohl djatsunrise.
Ich hab keine Frage gestellt 😉

Gruß
Roland

Ne, würd ich jetzt nicht zwingend sagen. Kommt drauf an, was du machen willst. Wenn du schnell mal ein Spiel entwickeln möchtest, ist XNA ideal. Das bringt so grundsätzliche Sachen wie DeviceHandling von vorneherein mit.

Wenn du mehr etwas in Richtung Windows-Applikation machen willst, ist SlimDX ideal. Selbst für Spiel ist SlimDX mehr als gut. Wie gesagt, es ist quasie die DirectX API fasst 1 zu 1 in C#.

C++ geht natürlich auch, überhaupt keine Frage. Diese Weg ist allerdings der Aufwändigste von allen.

Zu dem DirectShow.Net kann ich net viel sagen, davon les ich zum ersten mal.

edit: Nachteile von XNA kommen vorallem daher, weil es parallel auch auf der XBox laufen muss. So wirst du es im Bereich Tool-Entwicklung schwieriger haben, weil diese ganzen Game-Componenten auf Einen Bildschirm ausgelegt sind. Sprich, wenn du mehere Fenster verwenden möchtest, musst du wieder den langwierigeren Weg gehen, wie etwa mit SlimDX auch. Das nächste ist die DirectX Version an sich. XNA bietet bei DirectX 9 keinen Zugriff auf die Fixed Function Pipeline und DirectX 10 steht auch außen vor.

Ich würde das ganze in einem BackgroundWorker laufen lassen, und am Ende den Gui-Thread per Control.BeginInvoke informieren, dass das Konvertieren abgeschlossen ist.

Hi djatsunrise,

Generell kannst du von C# aus nicht direkt auf DirectX zugreifen, du benötigst also einen Wrapper. Davon gibts es aber mehrere, und zwar XNA, SlimDX und Managed DirectX (MDX). Um mal zu jedem ein paar kurze Worte zu sagen:

XNA: Mehr ein Framework zur Spieleentwicklung, als nur ein Wrapper. Diese Platform dient dazu, um als hobby schnell Spiele zu entwickeln.

SlimDX: Dieser Wrapper hat es sich zum Ziel gesetzt, die DirectX API komplett und originalgeträu umzusetzen. Hiermit ist es kein Problem, das wissen aus c Programmen in .Net zu verwenden. Dies ist auch die einzige API mit der du per .Net DirectX 10 verwenden kannst.

MDX: Solltest du nichtmehr nehmen. Wird schon seit ner ganzen Weile nichtmehr weiterentwickelt, ist .Net 1.1 und der Support ist auch eingestellt. XNA ist der inoffiyizielle Nachfolger davon

Gruß
Roland

Hallo Stu42,

schau dir mal die Methode Vector3.Project an. Das müsste genau das sein, was du suchst.
Siehe auch hier

Kann es sein, dass bei dir die Projekteigenschaften im Release Modus anders eingestellt sind. Denn die unterscheiden sich in Debug- und Relase Build

Ich hatte so ein Problem auch mal. Am Ende fand ich raus, dass der im Releasemodus lediglich eine Dll zuwenig ins Verzeichnis kopiert hat.

Hi,

Versuchs mal mit Environment.CurrentDirectory (gibt dir das aktuelle Verzeichnis der Anwendung zurück) oder Assembly.GetExecutingAssembly.Location (Gibt die den Speicherort der gerade ausgeführten Assembly zurück)

Gruß

Hi,

schau dir mal das Property FieldName an. Mit dem kannst du ein Feld aus deiner Datenquelle direkt an eine Spalte binden. Damit sollte es dann auch funktionieren

Gruß

Hi,

ein Zugriff auf SelectedValue sollte dieses Event aber nicht auslösen können. Kann das sein, dass du an irgendeiner anderen Stelle den SelectedIndex setzt? Schau dir mal den StackTrace genau an.

Ich habs hier eben bei mir auch mal so probiert, wie du das geschrieben hast. Funktioniert alles einwandfrei.

Gruß

Hi,

also ich würd da Spontan XmlDocument oder XmlReader verwenden

Hi,

also ich persönlich rate dir davon ab, jetzt noch mit MDX anzufangen, da es bereits seit mehr als einem Jahr nicht mehr weiterentwickelt wird. Kurz gesagt, es ist veraltet.

XNA ist auch nicht wirklich komplizierter als MDX, ganz im Gegenteil. Erste Ergebnisse bringt man mit XNA schneller hin.

Eine weitere Möglichkeit ist da noch SlimDX, siehe hier.

Hi,

dein Mesh wird ansich korrekt gezeichnet, du hast bloß vergessen, einen DepthBuffer zu setzen:

Einmal oben bei InitializeDirectX hinzufügen:

        presentParams.AutoDepthStencilFormat = DepthFormat.D16;
        presentParams.EnableAutoDepthStencil = true;

Und noch bei OnPaint diese Zeile Ändern:

        device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, Color.White, 1.0f, 0);

Mehr zum Thema DepthBuffer findest du hier (Ist zwar DirectX 10, aber der Sinn ist der gleiche).

Gruß

Das hat mit der Reihenfolge des Ladens nix zu tun.

Wenn du deine Objekte undurchsichtig zeichnen willst, ist das überhaupt kein Problem: Einfach im RenderState AlphaBlendEnable und BlendEnable auf false setzten (sind sie standardmäßig sowieso), und es sollte gehn.
Ein Mesh wird also nur transparent gezeichnet, wenn während des Aufrufens von Mesh.DrawSubset auch die RenderStates so eingestellt sind.

danke euch beiden für die schnelle Hilfe

@schabe: Ja, hat funktioniert. der Designer lädt wieder - wenn auch noch genauso absturzanfällig wie vorher, aber immerhin.
@MagicAndre1981: Die Datei find ich garnicht, brauchts aber wohl auch nichtmehr

Ich hab den Hotfix hier bei mir mal ausprobiert und ich bin wirklich verblüft, wie Microsoft die Probleme mit dem WPF-Designer gelöst hat. Jetzt gibts den bei mir gleich gar nicht mehr. Wenn ich jetzt auf eine xaml-Datei Doppelklicke, kommt nur ein ganz normales Textfenster - ohne Highlighting, ohne alles.

Habt ihr da auch ähnliche Probleme?

Hi,

bei deinem Device-Objekt gibt es die Events DeviceLost und DeviceReset. Generell musst du immer im DeviceLost event alle deine auf die Grafikkarte geladenen Resourcen freigeben, so auch deine Sprites / Texturen oder sonstige Models (ganz einfach durch einen Aufruf von Dispose am jeweiligen Objekt). Im DeviceReset musst du die Objekte schließlich neu erzeugen.

Das war jetzt mal so der prinzipielle Ablauf, die Erfahrung zeigt allerdings, dass das reale Leben dann doch net so einfach ist. Über Sprites kann ich da nix spezielles sagen, die Dinger hab ich bisher noch nie verwendet.

Am besten du suchst dir ein Beispielprogramm, in welchem das schon gemacht wird, und programmierst das nach. Ich hätt da sogar ein gutes im Kopf, nur weiß ich im Moment nicht genau, wo man das findet ?(
Wenns mir wieder einfällt werd ichs hier posten

Gruß
Roland

Hi,

hast du die C-Dll im Debug-Modus kompiliert? Wenn ja, dann braucht diese dll die Debug-Version der C Runtime Bibliotheken. Diese ist aber blos bei VisualStudio dabei.

Ansonsten muss auf jedenfall die C++ Redist 200X installiert sein (X je nach VisualStudio Version).

Gruß
Roland

Gut, ich teste das immer mittels VirtualPC und einer englischen Version von Windows. Im MSDN Packet is ja alles dabei 😉

ansonsten wüsst ich allerdings auch keine Möglichkeit, wie man das Testen kann, sorry.

Hi,

setzt mal Thread.CurrentThread.CurrentCulture und CurrentUICulture auf die Cultur, die du testen möchtest. Dann sollte es gehen.

Gruß
Roland

Hi,

ich vermute mal, dass der Designer die dll einfach nicht findet. Dlls werden standardmäßig innerhalb des Ausführungsverzeichnisses und dem System32 Ordner (und evtl. noch ein paar andere) gesucht. Das Ausführungsverzeichnis im Designer ist allerdings ein anderes als bei deiner Anwendung. Du musst also deine Dll beispielsweise in den System32 Ordner kopieren, damit es geht.

Gruß
Roland

Schau dir mal die Eigenschaft Anchor an

hi,

Problem gelöst. Ich hab jetzt einfach mal alles was mit VisualStudio zu tun hat von meinem Rechner deinstalliert und anschließend VisualStudio 2008 und danach das SP1 davon wieder installeert. Und jetzt gehts perfekt.

Da scheint vorher etwas nicht korrekt installiert gewesen zu sein

Gruß
Roland

Der Fehler kommt immer.
Egal, ob in einem vorhandenen oder in einem neuen Projekt.

Erstellen und ausführen kann ich allerdings ohne Probleme.

edit: Ich finde das irgendwie komisch. Jetzt hab ich das auch auf meinen Laptop ausprobiert und da kommt der gleiche Fehler. Da ist Vista 32Bit drauf. Für die Installation habe ich die Iso-Datei verwendet, die man bei Microsoft runterladen kann. Vorher war bei beiden VisualStudio 2008 und VistualStudio 2005 drauf.

Hi,

ich habe bei mir privat das ServicePack 1 von VisualStudio 2008 installiert und bekomm seitdem im WPF Designer immer eine Fehlermeldung (Screenshot ist im Anhang).

Ich benutze Vista x64, UAC ist deaktiviert. Bei der Installation gabs auch keinerlei Fehlermeldungen. Hat außer mir noch wer dieses Problem? Gibts ne Lösung?

Gruß
Roland

Hi,

bis jetzt sind das eigentlich blos die Standardtutorials, so wie man sie aktuell für DX 9 beispielsweise zu hauf findet. Wenn die fertig sind, wollte ich mal ein paar speziellere Themen angehen, wie z. B. Instancing, Cellshading oder allgemein mal ein gescheites HLSL Tutorial.

Hier auf mycsharp kann ich diese Einführungstutorials gerne veröffentlichen. Mal schaun, wie lange ich mit dem Zeugs noch brauche.

Gruß
Roland

Hallo Jack_AI,

ich weiß jetzt zwar nicht wie MrSparkle die Sache sieht, aber das erste und größte Problem ist die Abhängigkeit. Im Setup von XNA steht ganz groß was von GameStudio, XBox und so weiter. Wirkt jetzt nicht ganz so Professionell, finde ich.

Technisch gibt es allerding auch ein paar Probleme. Da XNA auf der XBox laufen soll, implementiert es den kleinsten gemeinsamen Nenner. Was heist, es gibt beispielsweise keine Multi-Monitor Unterstützung, welche in prof. Anwendung in der Regel benötigt wird. Das nächste Problem ist, dass z. B. das Game Framework ansich nutzlos ist, da es auf ein eigenständiges Fenster aufbaut, die Maus versteckt, usw.. Du musst also auch in XNA das ganze Device-Managment zeugs selber machen. Mehr will ich hier mal nicht aufführen. Aber das sind alles Gründe, weshalb ich mich gegen XNA entschieden habe.

Gruß
Roland

Hi,

genau das gleiche Problem hatte ich auch in einem ActiveX-Control. Meine Lösung war das OnHandleDestroyed Ereignis der System.Windows.Forms.Control Klasse. Ich glaub aber, dass es dir nicht sonderlich viel hilft, oder? Du hast ja kein ActiveX Control sondern nur ein normales Objekt.

Gruß
Roland

Dann laß uns doch mal was gemeinsam auf die Beine stellen, daß hier auch mal was in Sachen DirectX vorwärtsgeht

Genau das wollte ich hören (hm.. blöde Redewendung, eigentlich wäre hier lesen richtig). Ich hab in den letzten Wochen scho ziemlich viel in der Richtung gemacht. Den aktuellen Stand findest du hier. Das ganze ist noch lange nicht fertig (so wie die restliche Seite auch), und Zeit hab ich auch nicht oft, von daher ist mir Hilfe sehr willkommen. Kannst mich ja mal im icq drauf anschreiben.

Tja, ich hatte heut erst das Problem, daß mein NVidia-Treiber das Device geresetet hatte, es gab eine DXGI_ERROR_DEVICE_REMOVED Exception, die man nun leider nicht mehr anders behandeln kann, als die ganze Engine neu zu starten. Jedenfalls hab ich noch keine bessere Lösung dafür gefunden...

hmm.. wäre jetzt für mich einer der großen Vorteile gewesen. Schaumer mal, hoffentlich liegts am Treiber. Aber die Engine neuladen wie du es schreibst muss man doch sowieso. Zumindest alles was nur im Grafikspeicher liegt.

Gruß
Roland

Hallo MrSparkle,

ich experimentiere mit SlimDX jetzt auch schon seit ner ganzen Weile. DirectX 10 ist da noch nicht ganz vollständig umgesetzt, oder? Gut, kann ich jetzt auch nicht wirklich beurteilen, da ich nur so kleine Spielereien wie Objekt anzeigen usw. mit SlimDX gemacht habe.

Was mir an der API gefällt ist, dass es scheinbar kein DeviceLost / DeviceReset Zeugs mehr gibt. Eine gewaltige Erleichterung für prof. Anwendungen.

Eine kurze Einführung für DirectX 10 währe schon mal sehr gut. Ich selbst spiel auch seit ner Weile mit dem Gedanken, da was zu machen.

Gruß
Roland

Hallo,

es gibt auch schon Gerüchte, dass Microsoft die nächsten DirectX Versionen auch für Mac und eventuell Linux veröffentlichen möchte... Spricht also für eine lange Zukunft.

Auf C# Seite ists komplexer. Wie vorher schon gesagt wurde, ist MDX gestorben. Aktuell gibt es hier XNA (von Microsoft, eher Richtung Spiele) und SlimDX (Community Projekt) und so wies aussieht, wirds diese auch noch eine ganze Zeit lang geben.

selbstverständlich.

ja, können durchaus mehrere von der Sorte sein. Beispiele sind bytearrays und Memorystreams. Seit der Fehler das erste mal aufgetreten ist, hab ich an der Stelle etwas optimiert, sprich ein byte array mehrmals verwenden usw.. Es ist dadurch auch erstmal besser gworden, doch hat das mein Problem nur etwas verzögert.

Was kann man tun, wenn es ein LOH Problem ist?