Welche Sprache für Terminplaner

Status
Nicht offen für weitere Antworten.
Sind alle 3 objektorientiert, also ist keines leichter als das andere. Der Lernaufwand ist überall hoch, da OOP hinzukommt und die soll ja gut gelernt sein.

Zu .NET noch ein Wort: Wenn Du willlst ist .NET für dich auch gratis -> Zum lernen kannst du entweder die 2005er Express Beta verwenden (die funktionieren soweit sehr gut), oder du verwendest eben SharpDevelop. Ist eine kostenlose IDE mit der Du C#, VB.NET usw. programmieren kannst. Das Ding wird auch immer mächtiger ...

Somit bleibt Delphi als einziges Tool über zu dem es nichts kostenfreies gibt.

Und zur Programmierung unter Windows: Wie schon erwähnt, ich würde hier auf alle Fälle .NET nehmen, zumal bezüglich Oberflächen einfach schneller und einfacher und zudem würde ich zu Java dann greifen, wenn eine Anwendung wirklich plattformunabhängig sein soll. Programmierst Du ausschließlich für Windows, hast Du unter .NET die Möglichkeit Windows interne Funktionen zu benutzen, das kannst du mit Java nicht.
 
Original geschrieben von Norbert Eder

Und zur Programmierung unter Windows: Wie schon erwähnt, ich würde hier auf alle Fälle .NET nehmen, zumal bezüglich Oberflächen einfach schneller und einfacher und zudem würde ich zu Java dann greifen, wenn eine Anwendung wirklich plattformunabhängig sein soll. Programmierst Du ausschließlich für Windows, hast Du unter .NET die Möglichkeit Windows interne Funktionen zu benutzen, das kannst du mit Java nicht.

Das stimmt nicht, ich weiss ja nicht wie du darauf kommst. Aber ich kann auch mit Java COM Objecte instanzieren und WinAPI Funktionen aufrufen.
 
Hallo!

Aber ich kann auch mit Java COM Objecte instanzieren und WinAPI Funktionen aufrufen.

Aber auch nur über den JNI Umweg ... bzw einige (zumeist kommerzielle) Libs welche aber auch JNI im Hintergrund verwenden ... und JNI macht nicht wirklich Spaß ... :-(

Gruß Tom
 
Original geschrieben von Thomas Darimont
Hallo!



Aber auch nur über den JNI Umweg ... bzw einige (zumeist kommerzielle) Libs welche aber auch JNI im Hintergrund verwenden ... und JNI macht nicht wirklich Spaß ... :-(

Gruß Tom

SWT ist nicht kommerziell :)
SWT bietet die möglichkeit
 
Nur verstehe ich nicht wo du da das Problem siehst :)

Natürlich basiert es auf JNI, aber mann kommt nicht direkt in Berührung damit.

bsp: Developerworks
Code:
1   public class PDFViewer extendsApplicationWindow
2   {
3      private OleControlSite site;
4      private OleAutomation auto;
5
6      public PDFViewer()
7      {
8         super(null);
9         this.addMenuBar();
10      }
11
12      protected ControlcreateContents(Composite parent)
13      {
14         Shell shell = this.getShell();
15         shell.setText("PDFViewer");
16         shell.setSize(500, 450);
17
18         OleFrame frame = new OleFrame(shell, SWT.NONE);
19
20         try
21         {
22            site = new OleControlSite(frame,SWT.NONE, "PDF.PdfCtrl.5");
23            auto = new OleAutomation(site);
24            
25   ...
 
Hallo!

Schon klar, dass das dort so einfach geht, jedoch besteht bei der Verwendung von SWT immer die Gefahr von Speicherlöchern falls der Entwickler nicht auf das richtige Disposen seiner nicht mehr verwendeten Controls + weis-der-geier achtet. Wenn du das dann mal debuggen willst und dann auf einmal vom Java in den C Code springst wirst du deine wahre Freude haben ... ;-)

Gruß Tom
 
Willkommen im C/C++ Land. Btw - ich würde für's programmieren lernen nicht gerade mit COM und OLE anfangen.
 
Original geschrieben von Thomas Darimont
Hallo!

Schon klar, dass das dort so einfach geht, jedoch besteht bei der Verwendung von SWT immer die Gefahr von Speicherlöchern falls der Entwickler nicht auf das richtige Disposen seiner nicht mehr verwendeten Controls + weis-der-geier achtet. Wenn du das dann mal debuggen willst und dann auf einmal vom Java in den C Code springst wirst du deine wahre Freude habe ... ;-)

Gruß Tom

Der Aufruf von WinAPI Funktionen (die nicht im .net Framework gekapselt sind) verursacht das selbe Problem.

Diesen Fehler kann mann tatsächlich machen, das bedeutet aber nicht das es nicht geht.

Meiner pers. Meinung nach sollte mann COM meiden wo immer es möglich ist, da COM ein sehr hässliches und unsichere Komponentenarchitektur ist.
Dennoch wenn kein Weg daran vorbei führt, und mann eine Java Applikation mit einem Produkt nutzen will das einzig und allein eine COM Schnittstelle bietet kann mann diese nutzen.
Aber wozu COM wenn wir Beans und EJBs, bzw Corba habe.
 
Stimmt, COM ist ja das einzige was die WIndows-Welt zu bieten hat. Und Java hat ja EJBs etc. Also es gibt für alles aus der Java-Welt ein .NET-Gegenüber. Punkt.

Und Deine Struts (als Beispiel) kannst jetzt in Ruhe stecken lassen, denn die kommen net von Sun sondern von Apache und musst mal brav dazuinstallieren :p

Aber jetzt wirds wieder ein lustiger Flame Wars *juhu*
 
Status
Nicht offen für weitere Antworten.

Neue Beiträge

Zurück