Grüße Euch

Ich habe über mehrere Jahre eine umfangreiche Excel-Software für den Bausektor entwickelt, ca. 60.000 Zeilen mit ca. 20 Spalten, die vermarktet werden soll und deshalb nicht in Excel bleiben kann.

Nun suche ich nach einer Lösung, diesen Excel-Rohling "irgendwie" in C# und WPF neu aufzusetzen.
Bei meinem nicht vorhandenen Fachwissen brauche ich dazu einen Profi.
Ich würde das aber gerne vom Prinzip her verstehen.
Man kann Excel-Dateien ja in C# einlesen, denke aber, dass es besser ist, das ganz neu aufzusetzen.

Eigentlich ist Excel für meine Software perfekt, denn es gibt zahllose Zellformatierungen, ca. 1 Mio. Formeln mit teilweise sperrigen Rechnungen, Zeilen müssen automatisch aus- und eingeblendet werden. Aber eine Software in Excel zu verkaufen kommt eben irgendwie laienhaft, auch ist die Sicherheit nicht gegeben und jeder Kunde müsste Excel in einer bestimmten Version haben. Auch muss man die Software immer wieder updaten, also wäre eine webbasierte Lösung vermutlich besser.

Wie legt man das in C# an, das fast genauso funktioniert wie Excel, aber kein Excel ist?
Also eine endlos lange Maske aus Zeilen und Spalten, eingebunden in eine WPF-Form mit der üblichen Seitenaufteilung, links Menü, oben Kopf, usw.
Wie gesagt, es geht mir darum, das vom Prinzip her zu verstehen, zum Programmieren bräuchte dann schon professionelle Hilfe, also jemandem aus dem Raum München, der sich mit mir hinsetzt und das entwickelt.

Ich verstehe das so:
Excel ist vorkonfiguriert, in C# muss ich mit jeder Zelle "reden" wie mit einem Kleinkind, ihr erklären, dass sie eine Zelle ist, zu einer Klasse gehört, gewisse Eigenschaften hat und nun dieses und jenes machen soll. Das wird bei ca. 1 Mio. Zellen ein Riesenaufwand, auch wenn man das sicher intelligent gruppieren kann. In meiner Software gibt es keine langen Datenbanktabellen, dafür aber Hunderte kleiner Tabellen, Dropdowns, usw. Zumindest darf würde ich gern in Excel bzw. XML lassen, sonst wird es uferlos.

Ich bin für alle Vorschläge offen und möchte nur das Prinzip verstehen,brauche keine Codes, usw.
Wer mag mir das erklären, wie man es eben einem Laien erklärt? Ohne die typischen Fachbegriffe.

- Excel in C# und WPF nachbilden, ohne dafür Excel zu brauchen.
- dynamische Zellformatierungen
- Ein- und Ausblenden von Zeilen, wenn (bei Excel) in Spalte A eine Null oder Eins steht
- bedingte Dropdowns (bei Excel =indirekt(...))

Wenn jemand aus München Zeit und Interesse daran hat, das mit mir zusammen aufzusetzen (anhand des bereits vorhandenen Excel-Rohlings),wäre das eine feine Sache, denn ich kann es nicht, das würde nur Murks werden, wenn überhaupt ...

Hallo ariba,
erstmal Willkommen in der Entwickler-Ecke.

Erst kürzlich habe ich eine Excel-Anwendung komplett nach Delphi umgebaut (inklusive Import aller vorhandenen Daten und Auswahl- und Prüflisten). Daher kann ich dir erstmal sagen, dass das grundsätzlich möglich ist.
In C# dürfte es noch "einfacher" sein.

Eine Mischlösung, also eine Anwendung, die auf die Excel-Daten zugreift, empfehle ich dir nicht. Es besteht dann immer die Gefahr, dass es mit unterschiedlichen Office-Versionen Probleme geben kann. Es soll auch Anwender geben, die kein MS-Excel verwenden. Da kann es dann schon Zugriffs-Probleme auf das Excel-Formular geben.

Du redest von Millionen Zeilen. Selbst bei ein paar 1000 Zeilen würde ich den Einsatz einer Datenbank in Betracht ziehen. Deine Excel-Zeilen sind im Grunde nichts anderes als Datensätze. Es gibt da durchaus Möglichkeiten, bei denen keine komplizierte Datenbank-Installation erforderlich ist. Hierzu gibt es das Stichwort Embedded-Database. Für einen Programmierer ist es relativ egal, ob auf eine "echte" oder eine "embedded" Datenbank zugegriffen werden muss.

Die eigentlichen Schwierigkeiten sind die Auswahllisten, Formeln, bedingten Formatierungen, interne Logik, etc. Aber auch das ist keine unlösbare Aufgabe. Die Auswahllisten können ebenfalls übr die Datenbank verwaltet werden. Die Formeln stehen ja auch in deinem Excel-Blatt und müssen "nur" nachprogrammiert werden. Bei den bedingten Formatierungen ist einiges zu beachten, aber mal eine Zeile auszublenden, ist auch sicher kein großer Akt. Die größte Schwierigkeit wird die Logik hinter deinem Excel-Blatt sein. Die musst du dem Programmierer sehr genau erklären.

Wie aufwendig das nun tatsächlich ist, kann ich dir so natürlich nicht sagen. Dafür müsste man deine Excel-Anwendung schon einigermaßen genau kennen. Aber ich bin mir sicher, dass man das umsetzen kann, ohne dabei in Arbeit zu ersticken.

Ich bin leider zu weit weg, um dir dabei helfen zu können, aber in München dürfte es genug brauchbare Programmierer geben. Frag doch dort vielleicht auch mal in der Uni nach.

Hallo Peter,

ich will auch keine Mischlösung.

Auf Excel läuft die Software schon und das ist eine wertvolle Vorlage für eine Umsetzung in C. Da stecken schon ca. 3.000 Arbeitsstunden drin.
Ich suche eine C-Anwendung, die fast so funktioniert wie Excel, also innerhalb einer WPF-Browseranwendung ein Fenster, das wie Excel aus einer endlos verlängerbaren Anzahl von Zellen besteht. Man kann diese "Excel"-Tabelle kann seitenweise portionieren. Der Nutzer trägt Daten in Seite 1 ein und klickt dann auf S. 2, usw. So ähnlich wie bei PowerPoint. Die Eingabemaske übergibt Daten an den Server und bekommt dort Daten, z. B. Auswahlmenüs.

Diese Zellen kann man dann mit der neuen Datenbank verlinken, was sicherlich mühsam sein wird angesichts der vielen komplexen Berechnungen, die in Excel einfacher funktionieren.

Beim Neuaufsetzen in C muss ich dabeisitzen, um dem Programmierer Schritt für Schritt zu sagen, um was es geht, weil dieser ja von der Software-Materie wenig wissen dürfte. Das ist die Krux: Ich kenn mich in meinem Fachgebiet sehr gut aus, bin aber ein C-Laie. Und ein Programmierer kennt die Fachmaterie nicht. Deshalb suche ich jemanden aus München, der Zeit und Lust hat, hier mit einzusteigen.

Du hast etwas von Bausektor geschrieben.
Kannst du das für potentielle Interessenten schon weiter eingrenzen? Ich hatte auch schon mit der Baubranche zu tun. Es gibt dort ziemlich viele Gebiete. Die Entwicklung eines Ausschreibungsprogrammes ist schon was anderes, als statische Berechnungen und Bau-Planung (Ich weiß, es gibt noch viel mehr). Wäre doch gut, wenn du gleich jemanden bekommst, der vielleicht schon spezielle Fähigkeiten hat. Das erleichtert auch das Verständnis während der Entwicklungsphase.

Hallo Peter,

da will ich die Katze nur etwas aus dem Sack spechten lassen...
Ich arbeite schon seit Jahren an dieser Software, die letzten 2 Jahre intensiv.
Nun kommt das langsam in die heiße Phase, in der das bereits funktionierende Excel in etwas Professionelles überführt werden soll.

Layout, Gliederung, usw., das steht alles schon und allein das schon hat wie gesagt 2 Jahre gedauert.
Daran lässt sich vielleicht der Umfang und die Komplexität erahnen.
Ich sag es mal so: Wenn Du die üblichen AVA-Softwares kennst, die ca. 800 € kosten: Die können ca. 5% von dem, was meine Software kann.
Ich weiß, das klingt großspurig, ist aber so.
Doch genau da liegt auch der Haken, denn damit komplett ein Programmierer-Team zu beauftragen würde vermutlich zu Kosten eines Einfamilienhauses führen.
Und noch weiß ich ja nicht, ob das ein Verkaufserfolg wird.

Als Entwickler ist man ja immer Feuer und Flamme für seine Erfindung, aber der Markt kann einen manchmal grausam auf den Boden zurückholen.
Also will ich die Kosten im Rahmen halten und gehe den für mich neuen Weg über ein Forum.


Lesen gefährdet die Dummheit?
Oo, das kollidiert ja mit dem Trend zum Zweitbuch ...

Aha, eine AVA-Anwendung.
Davon gibt es ja wirklich schon einige, was die Einführung eines neuen Programms im Markt natürlich schwierig macht. Da musst deine Anwendung schon wirklich einige Besonderheiten haben, die man in den anderen Programmen vermisst. Wobei deine Anwendung dann auch die Funktionalitäten der anderen Programme enthalten sollte.

Hinzu kommen Zertifizierungen für die verschiedensten Schnittstellen, die von allen Standard-Programmen genutzt werden. GAEB und StLB sind da ein absolutes Minimum.

Du hast bis jetzt für die Excel-Anwendung 2 Jahre investiert. Damit sind alle Vorgaben schon klar vorhanden. Das wird bei der Umsetzung dann sicher deutlich weniger Zeit beanspruchen.

Wenn du wirklich daran denkst, damit später in den Markt zu gehen, solltest du von vornherein professionelle Ansprüche an die zukünftige Lösung haben. Alles andere wird meistens nicht funktionieren. Zumal die Konkurenz nicht klein ist. Wenn du natürlich schon Anwender hast, die mit deiner Lösung arbeiten, dann solltest du vielleicht dort jemanden um (finanzielle) Unterstützung bitten. Außerdem ist zu bedenken, dass bei einer professionellen Programmierung eine gewissen Kontinuität zu erwarten ist und bei Fehlern mit schnellen Korrekturen zu rechnen ist. Reklamationen sind da dann auch ein Thema.
Falls es aber "nur" eine Anwendung für eine kleine Zielgruppe ist, musst du dir die Frage stellen, ob sich der ganze Aufwand überhaupt lohnt.

Wenn du als Nicht-Programmierer ca. 2 Jahre dafür gebraucht hast und außerdem ja schon alle Vorgaben dadurch definiert sind, sollte ein guter Programmierer das relativ zügig umsetzen können.

Ich drücke dir alle Daumen für dein Vorhaben.

Hallo Peter,

die Software geht weit über AVA hinaus, denn sonst wäre es tatsächlich sinnlos, die 50ste AVA-Software auf den Markt zu bringen. Meine Software enthält auch ein komplettes AVA, aber das macht nur einen kleinen Teil aus, ca. 10%.

Natürlich brauche ich einen Profi, das ist klar und ich bin auch gerade dabei, meine Fühler danach auszustrecken. Parallel dazu möchte ich aber die Software-Architektur wenigstens prinzipiell verstehen, weil sonst eine enge Zusammenarbeit mit dem Programmierer nicht gut laufen würde.

Ja, 2 Jahre Entwicklung am Rohling ist eine Menge Zeit (frag dazu mal meine Frau ...). Aber ich denke auch, dass das dem Programmierer helfen wird, weil er gleich loslegen kann.

Nach 2 Jahren intensivem Excel muss ich komplett umdenken, weil C# ja ganz anders funktioniert. Das ist nicht einfach, zumal ich kaum Ahnung davon habe. Ich habe viele Bücher darüber gelesen und mich geärgert, dass Bücher à la "C# für Anfänger" so schlecht aufgebaut sind. Das ist die Krux von Fachleuten, dass sie nicht mehr verstehen, was ein Laie nicht versteht. Aber mit diesem Kauderwelsch schützt man natürlich auch seinen Elfenbeinturm.

Kennt jemand ein Buch, das die Prinzipien eines Softwareaufbaus gut erklärt? Ich brauch keine 20 Seiten "Hallo Welt", auch keine Codes, sondern etwas, was praxisnah erklärt, wie man z. B. Namespaces, Klassen, usw. vernünftig aufbaut.

Für C# gibt es z.B. dieses Buch, das auch gut als Nachschlagewerk für bestimmte Konstrukte dienen kann:
openbook.galileocomp.../visual_csharp_2012/

ariba hat folgendes geschrieben :

Ich habe viele Bücher darüber gelesen und mich geärgert, dass Bücher à la "C# für Anfänger" so schlecht aufgebaut sind. Das ist die Krux von Fachleuten, dass sie nicht mehr verstehen, was ein Laie nicht versteht. Aber mit diesem Kauderwelsch schützt man natürlich auch seinen Elfenbeinturm. [...] Ich brauch keine 20 Seiten "Hallo Welt", auch keine Codes, sondern etwas, was praxisnah erklärt, wie man z. B. Namespaces, Klassen, usw. vernünftig aufbaut.

Einerseits ist es also unverständlich, andererseits zu ausführlich? Es ist nun einmal so, dass man als absoluter Anfänger erst einmal sehr einfache Beispiele braucht. Wenn man schon zumindest ein wenig VBA kennt, kann man davon sicherlich einiges überspringen. Aber Anfängerbücher müssen nun einmal ganz vorne anfangen.

Und wenn du an anderen Stellen etwas nicht verstehst ("Kauderwelsch"), dann kannst du ja hier im Forum einfach mal nachfragen.

Um zu meiner Ausgangsfrage zurück zu kommen:

Kann man Excel in C# nachbilden, ohne Excel zu verwenden?

Also eine beliebig lange Tabelle mit Zeilen und Spalten, bei denen jede Zelle mit einem Code versehen wird und bei der sich - wie bei Excel - Zeilen automatisch ausblenden, wenn z. B. in Hilfsspalte A eine Null steht.

Das würde mich interessieren.
Genau wie Excel, nur eben dass die Zellen formeltechnisch nicht vorkonfiguriert sind.

Damit ließe sich das machen, was Excel nicht kann, nämlich eine webseitenähnliche Benutzeroberfläche mit mehreren Fenstern für Menü, Eingabeteil, Kopfbereich, usw.

Hallo ariba,

schau dir mal das WinForms-Control SourceGrid an (unter WPF in Verbindung mit WindowsFormsHost benutzbar) oder aber die vom WPF DataGrid abgeleitete Komponente WPF Extended DataGrid.

Danke für den Tipp, hab das Extended Datagrid heruntergeladen.

Bin noch auf Aspose.Cells gestoßen.
Kennt das jemand?

Verstehe ich das richtig, dass man damit als Client eine Exceldatei bearbeiten kann, ohne Excel installiert zu haben?

Das wäre mein Ziel:
Ich "verwandle" mein Excel-Dokument in ein anderes Format (z. B. mit Aspose.Cells oder SpreadsheetGear 2012). Der Kunde kann diese Datei öffnen, Eingaben vornehmen, usw., ohne selbst Excel installiert zu haben.

Ist schon schwierig, als Laie dafür eine Lösung zu finden. Hatte ja schon Gespräche mit Programmierern, aber die Antworten waren nicht so ergiebig.

Stellt Euch das bitte so vor:
Ihr habt eine umfangreiche Excel-Datei entwickelt.
Nun wollt Ihr dieses Excel ins Internet stellen.
Nutzer sollen das dann bearbeiten können, ohne selbst Excel zu haben.

Es soll aber keine starre Eingabemaske sein, sondern eine dynamische, die auf die Eingaben reagiert, z. B. durch Ein- und Ausblenden von Zeilen, andere Farben für Zellen, usw.

Excel WebApp geht nicht, weil es kein VBA kann.

Hätte nicht gedacht, dass es dafür keine Lösung gibt bzw. ich bisher keine gefunden habe. Muss man denn tatsächlich das Excel irgendwie in C' umwandeln?

Das wäre in meinem Fall so umständlich (weil mein Excel ja gut läuft), als würde ich ein ebook in Stein meißeln müssen.

Klar ist C# toll, es kann viel, aber vieles davon brauche ich nicht.

Warum ich meine Software nicht als Excel anbiete?
Weil der Schutz schwierig ist und nicht jeder Nutzer dasselbe Excel hat.

ariba hat folgendes geschrieben :

Weil der Schutz schwierig ist

Das ist es bei C# aber auch. Standardmäßig kann man jede C#-Exe 1:1 in den Quelltext zurückkompilieren (siehe ILSpy usw.). Anders als bei Delphi, das wir u.a. deshalb in der Firma nutzen.
Es gibt auch Obfuskatoren für C#, aber dekompilieren geht dennoch. Man versteht den obfuskierten Quelltext nur kaum noch. Insbesondere, wenn du da eine Excel-Tabelle einbettest, kommt man an die aber immer heran.

Was ich nicht verstehe ist, dass es für Excel nichts Ähnliches in C# oder einer anderen Programmiersprache gibt. Zumindest habe ich bisher nichts gefunden.

Excel ist eine hervorragende Tabellenkalkulation, aber eben eine Einzelplatz-Software.
ExcelWebApp bietet zwar die Nutzung im Web an, ist aber funktional reduziert, z. B. kein VBA.

In Excel gebe ich eine einfache Rechenformel ein, z. B. = summe(...) oder komplexere wie =summenprodukt((...)).
Die daran beteiligten Zellen klickt man an und schon sind sie in der Formel.

In C# erscheint mir das ungleich komplizierter, da wird aus einer einfachen Rechnung schnell ein 20-zeiliger Code.
Bei 100.000 Formeln ein halbes Lebenswerk, auch wenn man durch intelligentes Gliedern sicher einiges verkürzen kann.

Gibt es eine Tabellenkalkulation vergleichbar mit Excel, die man vollständig in C# verwenden kann?
Wichtig wäre mir dabei, dass man Zeilen automatisch ein- und ausblenden kann und Zellen bedingt formatiert werden können.

Ich möchte keine kleinen Eingabe-Steuerelemente, sondern eine große scrollbare Tabelle, eben so wie bei Excel.
Also ein DataGrid mit ca. 20.000 Zeilen.

Rund um dieses Hauptfeld sollen sich - wie bei einer Webseite - andere Elemente mit Hauptmenü, Menüleiste, usw.

So schwierig ist das gar nicht. Es gibt in Datenbanken auch berechnete Felder, zudem kann man einiges in Richtung Zellenbeziehungen auch mit Stored Procedures usw. abbilden. Das kommt ganz auf den Einzelfall an.

Wenn man das von vorne macht, hat man in C# viel mehr Möglichkeiten, allerdings würde man das vermutlich anders aufbauen als mit den eingeschränkten Möglichkeiten von Excel. Da kann man zwar auch einiges machen, aber trotzdem deutlich weniger als mit einer richtigen Programmiersprache mit Datenbank dahinter.

Excel hat natürlich den Vorteil, dass man mit Formeln sehr schnell Beziehungen zwischen Zellen herstellen kann und Berechnungen machen kann. Das kann man mit C# zwar prinzipiell auch, aber eben im Code. Eine direkte Konvertierung einer solchen Excel-Lösung ist vermutlich aufwendiger als eine Neuentwicklung, es sei denn man benutzt dafür eine Komponente wie die folgende.

ariba hat folgendes geschrieben :

Was ich nicht verstehe ist, dass es für Excel nichts Ähnliches in C# oder einer anderen Programmiersprache gibt. Zumindest habe ich bisher nichts gefunden.

Da gibt es einiges, aber billig ist das nicht. Am besten liest sich auf den ersten Blick diese:
www.componentsource....lc/index-de-eur.html
Es gibt aber noch viele mehr:
www.componentsource....rp-net/index-de.html
Und das nur auf der einen Liste...

ariba hat folgendes geschrieben :

Was ich nicht verstehe ist, dass es für Excel nichts Ähnliches in C# oder einer anderen Programmiersprache gibt. Zumindest habe ich bisher nichts gefunden. In Excel gebe ich eine einfache Rechenformel ein, z. B. = summe(...) oder komplexere wie =summenprodukt((...)). Die daran beteiligten Zellen klickt man an und schon sind sie in der Formel. In C# erscheint mir das ungleich komplizierter, da wird aus einer einfachen Rechnung schnell ein 20-zeiliger Code. Bei 100.000 Formeln ein halbes Lebenswerk, auch wenn man durch intelligentes Gliedern sicher einiges verkürzen kann.

Tja, ich habe da so eine Vermutung: Excel wurde als Tabellenkalkulation geschaffen. Es sollte sich daher von vorneherein dazu eignen "mal schnell ein paar Zahlen auszuwerten". Das tut es auch bis heute sehr gut. In der Zwischenzeit wurde der Drang aber immer größer, mehr zu tun. Das hängt dann damit zusammen dass User die Basis kennen und schätzen (also was Excel einem alles abnimmt) aber irgendwann an gewisse Grenzen stoßen. Also gibt es immer mehr Funktionen und Skriptmöglichkeiten wie VBA.

Excel war nie dafür ausgelegt eine "richtige Programmiersprache" zu sein. Das erkennt man auch gut daran, dass sich die API verändert: Ältere Arbeitsmappen mit VBA lassen sich u.U. im aktuellen Office nicht mehr fehlerfrei ausführen obwohl das unter Excel 2003 oder so noch klappte. das versucht man in "richtigen Programmiersprachen" zu vermeiden. (Die kompilierte Datei ist weitgehend aufwärtskompatibel)

C# hingegen ist darauf ausgelegt eine richtige Programmiersprache zu sein. Es setzt "tiefer" an - man muss also mehr selbst machen - aber dafür hat man auch weniger Vorgaben (es muss nicht in Tabellenform sein)

Das eine ist halt einfach eine Tabelle mit ein paar Erweiterungen und das andere ist für alles geeignet. Die Lücke ist einfach sehr groß, und es gibt auch keinen großen Bedarf sie zu schließen. Für richtige programme werden ja extra Leute ausgebildet, Excel kann fast jeder schnell erlernen.

Konkret zur Frage "Was ich nicht verstehe ist, dass es für Excel nichts Ähnliches in C# oder einer anderen Programmiersprache gibt."
Das klingt vielleicht etwas hart, aber es gibt wohl nur geringen Bedarf. Software wird ja oft vorher geplant und man wählt das Tool aus, das zu den Anforderungen passt. Enthalten diese Anforderungen Sachen wie "Schutz" oder "Webseite" dann fliegt Excel einfach schon raus. Und die Größe spricht natürlich auch massiv gegen Excel. Falls es sowas gibt, dann vermutlich nur sauteuer weil es eben so wenige Leute brauchen.

Ich bin gerade bei Matlab. Das fing auch mit Matrizen an, aber die Skripte haben sich enorm entwickelt. Es gibt haufenweise Funktionen und ist ziemlich unübersichtlich wenn man größere Programme schreibt. Es ist besser als Excel (von der Sporache her) lässt aber immer noch zu wünschen übrig. Insbesondere die Unterstützung des Programmmierers ist quasi nicht vorhanden.

Kurzfassung: Da die meisten Menschen vernünftig planen, gibt es wohl eher keine einfache Konvertierung. Aber es geht natürlich auch anders, mir fällt da z.B. ein großer Konzern ein der eine hochkomplexe Planungssoftware in Excel hatte. Mehr als 30 Arbeitsmappen und in denen wurden auch noch dynamisch eine variable Anzahl an Tabellen erstellt. Ein Graus. Sollte dann auf Excel 2007 portiert werden...


Ich hoffe ich konnte dir das etwas logischer erklären. Ich möchte noch anmerken dass es ein wenig so aussieht wie "Ich will was programmieren,und Excel kann ich - passt." - aber ich lasse mich gerne vom Gegenteil überzeugen. Die Wahl des Werkzeugs sollte nicht direkt davon abhängen wie gut man welche Werkzeuge beherrscht. Das kommt jetzt ein bisschen altklug daher, aber ich wäre echt mal gespannt wie die Planungsphase bei dir abgelaufen ist

Hallo jfheins,

da hast Du schon Recht, dass ich die Software bisher in Excel aufgesetzt habe, weil ich nicht richtig programmieren kann. Als ich damit anfing, wusste ich ja gar nicht, ob diese große Aufgabe, die ich mir mit dieser Software selbst gestellt habe, überhaupt stemme. 2 Jahre bastle ich nun schon herum und nun läuft das Ding in Excel, Pflichtfelder formatieren sich, Zeilen blenden sich aus. Alles eigentlich wunderbar. Aber eben nicht geeignet, diese Software auf dem Markt anzubieten, denn da passt der große Nutzen dieser Software für potenzielle Anwender nicht zum Laienstatus von Excel. Vom Schutz und der Lizenzierung gar nicht zu sprechen und auch nicht, rund um Excel eine vernünftige GUI herzustellen.

Da steh ich also mit meinem Excel-Riesen, ca. 80.000 Zeilen mit ca. 1 Mio. Formelzellen, viele bedingt, mit hunderten von Dropdowns. Klar liegt da der Wunsch nah, dieses Excel "irgendwie" in C# zu integrieren. Aber das ist nur ein Wunsch, kein Muss. Wär ja blöd, 2 Jahre Freizeit in einem Pfuscher-Projekt enden zu lassen.

Kennt jemand ComponentOne?
Das scheint Excel in C# integrieren zu können, allerdings ohne Makros.

Ich bin gerade ich der Suchphase, wie es weitergehen soll:

A. Mein Excel nur als optische Vorlage zu verwenden und alles komplett neu aufsetzen.
B. Die Daten aus Excel in C# importieren, um dann kein Excel mehr zu brauchen, weder auf dem Server noch beim Client.

Ich möchte die potenzielle Lösung zumindest konzeptionell verstehen und sie muss mir plausibel sein, sonst begebe ich mich in eine Abhängigkeit, die weit über die Softwareentwicklung hinausgeht (Support, Administration, Datenpflege, Lizenzierung, usw.). Wer sich ein Haus baut, will ja auch verstehen, wie es gebaut wird, wie der Grundriss ist, die Bauweise, die Baukosten und die Folgekosten. Andererseits fehlt einem als Bauherr genauso das Fachwissen wie es mir beim Programmieren fehlt.

Was ich nicht weiß, muss ich glauben und da wird's fast schon religiös ...

Mir ist klar, dass die Lösung nicht alleine aus Internet-Foren kommen kann und natürlich führe ich parallel dazu Gespräche mit Programmierern. Aber da ist so wie in anderen Branchen auch:
5 Gesprächspartner und danach 6 verschiedene Meinungen ...

ariba hat folgendes geschrieben :

Kennt jemand ComponentOne? Das scheint Excel in C# integrieren zu können, allerdings ohne Makros.

Das liest sich als ob tatsächlich die Exceldateien dort geöffnet werden. Das hilft dir aber nur bedingt. Was du eigentlich willst, ist doch davon wegzukommen und eine bessere Lösung zu haben.

Genau das verspricht die Software aus meinem ersten Link: Aus der Excel Datei eine .NET oder Java Lösung oder eine webbasierte Lösung zu erstellen und dann nicht mehr direkt mit der Exceldatei selbst zu arbeiten. Wenn das so funktioniert, ist das wohl das, was deinem Wunsch am nächsten kommt und relativ schnell umsetzbar ist. Kennen tue ich es selbst nicht.

IMHO möchte der TE viel zu viel Kontrolle. Um beim Beispiel zu bleiben: Beim Hausbau möchtest du ganz genau wissen, wie der Beton zuammengesetzt ist, das Wasser analysiert haben und die chemischen Prozesse beim abbinden am liebsten unterm Mikroskop beobachten.

Das ist totaler Overkill und kein Coder der Welt wird sich antun, so ein Projekt mit dir durchzuziehen - denn neben der aus meiner Sicht bös aufwendigen Konvertierung muß er dir auch noch das Programmieren beibringen.

Beim Auto willst du doch auch nur (unter Beachtung ein paar weniger Regeln) einsteigen, losfahren und ankommen. Es ist doch völlig unwichtig, wie die Bremsen samt ABS exakt funktionieren. Welche komplexen Vorgänge im Einspritzmotor in der Zylinderkammer stattfinden. Wie die Klimaanlage nun exakt funktioniert - Hauptsache, der Backofen von Innenraum wird angenehm kühler.

IMHO solltest du dir im Vorwege überlegen, wie die Software konkret aussehen und deren optische Funktionalitäten sein sollen. Dann mußt du dem Coder deine Berechnungen erklären und ihn machen lassen. So wird dann Schritt für Schritt eine ordentliche Anwendung draus.

Was zählt, ist, das unterm Strich dieselben Ergebnisse herauskommen wie in deiner Exceltabelle. Das "wie" (in dem Sinne, wie die Algorithmen nun konkret in C# / Delphi / Java / whatever formuliert sind) ist doch völlig egal. Und noch ein Tip: Wende dich an einen Programmierer. Jeder hat so seine Ansichten und seine Methoden, so das das ganze nur im Chaos endet, wenn du zuviele Köche den Brei bearbeiten läßt.

Hallo Olaf,

woraus schließt Du, dass ich die Zusammensetzung des Betons, Wasseranalyse, usw. wissen will, um beim Beispiel einer Hausplanung zu bleiben?

Ich habe mehrfach geschrieben, dass ich keine Codes brauche, sondern nur PRINZIPIELL verstehen will, wie die Software aufgebaut werden sollte.

Darf also ein Bauherr so gut wie nichts mehr fragen und zu seinem Planer nur sagen: "Ich will ein Haus mit 5 Zimmern." Danach soll er sich aus allem raushalten und einfach darauf vertrauen, dass das Haus gut, schön, praktisch und kostentreu wird?

Und was, wenn nicht?
Ich finde sogar, dass man als Kunde/Auftraggeber eine gewisse Mitwirkungspflicht hat, wobei man natürlich ein Gespür dafür haben sollte, wo Schluss ist mit dem Wissenwollen und Einmischen.

Also ich verstehe nicht, wie Du aus meinen bisherigen Beiträgen eine derart detailversessene Wissensgier ableitest. Ich habe eine große Excel-Software erstellt mit einem sehr hohen Maß an Fachwissen (nein, nicht beim Programmieren, sondern zum Thema meiner Software). Nun denke ich darüber nach, wie sich das in ein richtiges und gutes Programm umsetzen lässt. Und zwar nicht im Detail, sondern im Konzept.

Um beim Hausbau zu bleiben: Ich würde gerne ein paar Grundrisse und Ansichten sehen, die Bauchemie ist mir schnurzegal.

In Excel gibt es keine Klassen wie z. B. in C#. Also muss ich doch darüber nachdenken, wie ich mein Excel-Monster sinnvollerweise in Klassen einteile, damit die Excel-Vorlage in ihrem Aufbau möglichst nah an das spätere Programm herankommt.

Ganz konkret interessiert mich das nur bis zur Ebene der namespaces und Klassen, eben weil ich damit noch meine Excel-Vorlage anpassen kann. Um beim Hausbau zu bleiben, interessiert es mich, welche Zimmer mein Haus haben wird und in welcher Größe.

Wie Du schreibst ist es mir tatsächlich egal, ob das in C#, Delphi oder Java geschieht.

IMHO strebe ich keinen "totalen Overkill" an mit meinen Fragen.

ariba hat folgendes geschrieben :

In Excel gibt es keine Klassen wie z. B. in C#. Also muss ich doch darüber nachdenken, wie ich mein Excel-Monster sinnvollerweise in Klassen einteile, damit die Excel-Vorlage in ihrem Aufbau möglichst nah an das spätere Programm herankommt.

Und warum das ? Um deine Excel-Tabelle in Klassen zu gießen, mußt du bereits ein gehöriges Maß an Programmierkenntnissen haben. Dann aber brauchst du auch keinen Programmierer mehr. Anders herum gesagt: Ist dein Programmierer nach deinen Erklärungen und Erläuterungen nicht in der Lage, das ganze in Klassen zu gießen, ist er der falsche Mann.

Weiterhin sagt doch niemand, das das C#-Programm tatsächlich exakt so aussehen wird, wie deine Excel-Tabelle. In Excel ist man begrenzt in der Auswahl der Controls - nicht so in C#, da gehen noch ganz andere Dinge, auf die du wegen der Grenzen von Excel nie gekommen bist.