das GUI meiner Anwendung wurde mit WPF und dem Caliburn.Micro Framework entwickelt. Die Hilfe innerhalb der Anwendung soll kontextsensitiv gestaltet werden. Es gibt einen globalen Button in einer Art Ribbon Bar, der, bei Betätigen, die Hilfe aufruft. Neben den Controls sollen Texte erscheinen, die deren Funktionalität erklären. Es sollen in einem View, das gerade aktiv ist, alle Texte gleichzeitig erscheinen und auch gleichzeitig wieder ausgeblendet werden. Bei Verschieben des Hauptfensters sollen sich die Container der Texte gleichermaßen mit verschieben. Bei aktiver Hilfe soll das aktuelle View leicht verschwommen im Hintergrund dargestellt werden, die Texte und deren Container on top, natürlich nicht verschwommen.
Die Anforderungen stehen also, nur ist die Wahl der Technologie noch nicht klar. Wie würdet ihr das machen? Die Idee ist, die Tooltips der Controls zu verwenden und entsprechend zu verwalten. Ist das mit den Anforderungen vereinbar? Welche Alternative Technologien gibt es? Allgemein mit AdornedControls?
ich habe natürlich zuvor gegoogelt und herausgefunden, dass man [Flags] setzen muss, wenn man mit Kombinationen arbeitet. Leider hilft das nicht beim Deserialisieren.
Nun ergibt sich aber die Problematik, dass ich Kombinationen derart ( Monday | Wednesday o.ä.) deserialisieren möchte. Ich erhalte eine Exception, dass der Wert nicht vorhanden ist.
Ich möchte natürlich unbedingt verhindern, dass ich alle Kombinationen explizit definieren muss. Wie kann ich das umgehen?
danke für deine Antwort. Ich habe das gleich ausprobiert! Das Problem vor dem ich nun stehe, ist, dass die Information als ein String vorliegt. Wie kann ich dem Serializer das "beibringen"?
ich möchte ein Array der Größe n ab einschließlich dem Index 1 (Position 2) mit einem Array der Größe n-2 überschreiben. Wie geht das ohne eine Schleife?
wie gestalte ich die Kommunikation zwischen zwei .NET Anwendungen A und B? Es geht um Datenaustausch und Steuerung der Anwendung B durch die Anwendung A über ein Netzwerk.
Eine Datenbank spielt dabei erstmal keine Rolle? Wäre WCF Data Services etwas für mich? Was ich dazu bisher recherchiert habe, überzeugt mich allerdings nicht.
Der Thread ist wirklich sehr interessant. Ich habe mich auch mit der Thematik beschäftigt, und ich werde letztlich die Vorteile beider Sprachen verwenden, indem ich zeitkritische Berechnungen auslagere und damit Fortran-DLLs "beauftrage".
Erste Tests haben gezeigt, dass die Performancevorteile sehr groß sind. Nachteil: Man muss einen teuren Compiler kaufen...
Ja, natürlich befinden sich EXE und DLL im selben Ordner. Ich vermute, dass es daran liegt, dass ich eine Demoversion verwende und die Software daher systemgebunden ist.
Edit: An der Demoversion liegt es auch nicht. Eine Test-EXE läuft auch auf anderen Systemen.
Danke für deine Antwort! Das Ausgangsproblem habe ich gelöst. Allerdings stellt sich nun das Problem, dass meine DLL nicht gefunden werden kann, wenn ich die Exe und DLL auf einem anderen System teste. Ich habe den Pfad relativ angeben. Auf meinem System läuft das auch prima.
ich fühle mich ein wenig gescholten, aber nichts für ungut...
So einfach und klar ist die Sache nicht, weil
1. ich die Fortran.exe und Fortran-DLL (so wie ich sie in der C#-Anwendung aufrufe) unter denselben Bedingungen bzw. mit denselben Einstellungen kompiliert habe.
2. ich die DLL so konzipiert habe, dass diese nur EINMAL aufgerufen wird, so dass Overhead durch zu häufige Aufrufe ausgeschlossen werden kann. Der Subroutine "permut" wird indes mit O(n!) sehr häufig aufgerufen, das allerdings innerhalb des nativen Codes. Wie ich gemessen habe, wird doch aus meinen Codebeispielen heraus klar.
Mir ist unterm Strich noch überhaupt nicht klar, woher diese Laufzeitunterschiede kommen.
Welche Sprünge sollen das sein? Hat jemand vielleicht irgendwelche Referenzen von Microsoft selbst, wo ich etwas über den Performanceverlust beim Aufrufen von nativem Code nachlesen kann?
Was bedeutet dann, dass P-Invokes gejittet werden?
nein, der kompilierte Fortram-Code wird nicht nochmal übersetzt. Sonst würden ja auch Systemaufrufe (z.B. für Windows-Messages, Paint-Aufforderung etc.) immer decompiliert.
Gut, aber warum läuft die FORTAN-DLL dann so viel langsamer?
Also gut, ich werde höchstwahrscheinlich reinen Fortran-Code schreiben. Dann muss man eben die Schnittstelle zur Hauptanwendung an einer anderen Stelle geschaffen werden.
Aber noch einmal die konkrete Frage: Warum genau läuft der native Code langsamer, wenn eine .NET-Anwendung diese Bibliothek aufruft?
Danke nochmal für eure Antworten. F# wäre eine Alternative. Da dies aber ebenfalls auf dem CLR-Konzept aufsetzt, sehe ich da keine Performancevorteile.
@Siassei: Meine Anwendung ist extrem zeitkritisch. Das ist eine wichtige a priori Erkenntnis. Daher versuche ich Berechnungen auszulagern, um die Laufzeit zu optimieren.
Es sei aber nochmal betont, dass C# auch auf mein Beispiel bezogen nicht schneller ist. Programmiere ich eine reine FORTRAN-Anwendung, ist diese mit derselben DLL rund zweimal schneller. Der Flaschenhals entsteht beim Aufrufen der DLL innerhalb der C#-Anwendung.
Hier einmal der C#-Code zum Aufrufen der DLL:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
using CSharpDllTest;
namespace FortranDllCallTest
{
class Program
{
static void Main(string[] args)
{
int[] arr = {1,2,3,4,5,6,7,8,9,10,11};
int arraySize = arr.Length;
//************Aufruf der CSharp DLL****************
PERMUTATIONUD csharpdll = new PERMUTATIONUD();
csharpdll.PERMUTATIONUDMAIN(arr, arr.Length);
//************Aufruf der Fortan DLL****************
FortranDllWrap.FPERMUTATIONUD(arr, ref arraySize);
//FortranDllWrap.FPERMUTATIONUD();
Console.ReadKey();
}
}
public class FortranDllWrap
{
// CallingConvention.Cdecl must be used since the stack is
// cleaned up by the caller in Intel Fortran by default
[DllImport("D:/Algorithmen/Fortran/Testcode/DllTest/DllTest/Debug/DllTest.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern void FPERMUTATIONUD(int[] arr, ref int arraySize);
//public static extern void FPERMUTATIONUD();
}
}
OK, ich formuliere einmal meine Zielstellung. Ich programmiere ein Planungstool in C#. Zu Optimierungszwecken möchte ich (numerische) Berechnungen nach Fortran-DLLen auslagern. Denn, kurzum, möchte man Rechnen und gigantische numerische Objekte "wälzen" ist Fortran schneller.
Die Frage ist nun, wie ich das praktisch umsetzen kann. Ich habe also eine kleine Beispiel-DLL in Fortran erstellt und rufe diese aus meiner C#-Anwendung heraus auf. Jetzt muss ich aber feststellen, dass das ganze dann langsamer wird.
Rufe ich dieselbe DLL aus einer Fortran-Anwendung heraus auf, benötigt der Durchlauf für n=11 1,2 Sekunden, aus C# heraus jedoch 5 Sekunden.
Woran liegt das? Ist es ein zusätzlicher Verwaltungsaufwand des .NET Frameworks? Wenn ja, was kann ich optimieren?
Die Hauptfrage ist aber, lohnt sich das Auslagern nach Fortran-Bibliotheken überhaupt? Mein bisherigen Versuche haben gezeigt, dass dies nicht der Fall ist.