Kylix verkaufen?

[Andreas Kosch]

Hallo,

richtige Frage, aber falscher Zeitpunkt. Zur Zeit darf außer Borland diese Frage niemand beantworten :-

[Bernhard Geyer]

@Patrick Sack

Ich als Entwickler von Access und Delphi-Applikationen kann die Aussage "Wieso geht das mit Access (VB) und nicht mit Delphi" eigentlich nicht bestätigen. Sicherlich gibt es einige Sachen die in Access einfacher zu realisieren sind, jedoch nur in der Kombination Access + Access-DB gehen. Es gibt aber viele Dinge, welche m.E. in Delphi viel besser, einfach und eleganter zu lösen sind als unter Access. Hier mal ein paar Beispiele:

- So geht bei Access(97) die Verbindung Komponente -> Eventhandler verloren, wenn das Control umbenannt wird.

- Bei lang andauernden Operationen ist es nicht so einfach wie bei Delphi (oder anderen Entwicklungsumgebungen) möglich, einfach mittels Application.ProcessMessages (oder entsprechenden Anweisungen) dem BS zum neuzeichnen von Fenstern, ... die Kontrolle zu übergen

- AccessBasic ist keine objektorientierte Sprache -> Keine so einfache Wiederverwendung von eigens in Access-Basic entwickelten "Komponenten".

- Auch Access kann komplett abstürzen (Wenn mehrmals Division durch 0 auftritt)

- Viele von Delphi gewohnte Komponenten/Funktione müssen umständlich über ActiveX-Komponenten nachgerüstet werden, welches einen Aufwand bei der Verteilung der Applikation nach sich zieht. Selbst ein Datei öffnen/speichern-Dialog ist bei Access nicht dabei

Meine Tipp ist: Datenbank zwar in Access (wenn SQL-Datenbank oversized wäre), aber, falls eine etwas komplexere Bedienoberfläche nötig ist, diese mit Delphi entwickeln

[Bernhard Berger]

Sicher, wer Bücher mit den Titeln "COM/DCOM/COM+" und "Delphi - Win 32 und Lösungen" (...waren übrigens beider hervorragend) und wahrscheinlich auch dementsprechende Programme schreibt, wird von der Idee Delphi für Linux nicht so begeistert sein ;-) .


<p>


Doch wer braucht schon wirklich z.B. die Win-API? Ich habe jetzt meine letzten Programme analysiert, und _alle_ wären auch problemlos aus Klynx umsetzbar. Klar, ein paar Win-API-Aufrufe sind dabei, aber die stellen wirklich kein Problem für die Umsetzung dar: Bei den wenigen geschwindigkeits-kritischen Programmstellen kann man ja immer noch per Compilerswitch beide Betriebssystems getrennt behandeln. Ok, bei sehr OS-spezifischen Dingen wie z.B. einen Kopierschutz etc. bedeutet das Entwickeln für zwei Betriebssysteme wahrscheinlich mindestens auch die doppelte Arbeit, solche Programme sind aber die absolute Ausnahme. Alle Standartanwendungen, Datenbankgschichten etc. können aber ohne größeren Mehraufwand problemlos für zwei (...oder in Zukunft sogar mehr?) Betriebssysteme geschrieben werden.... (zumindestens sobald endlich Delphi 6 erschienen ist)........... geniale Idee von Borland.


<p>


Das Open-Source-Gedanke war schon immer tief in der Delpi-Programmiergemeinde verankert, mehr als bei jeder anderen Windows-Programmiersprache (...man braucht sich nur einmal anzuschauen, wieviele hervorragende Komponenten mit Source es kostenlos z.B. auf der Torry-Seite gibt...). Ich denke, daß es deswegen eine hervorragende Idee war ein "Delphi für Linux" zu produzieren. Borland hat damit eine gute, zukunftsträchtige Marktnische gefunden, die der Gigant Microsoft kaum besetzen wird.


<p>


Das die Zeit nicht reif für Linux ist, würd ich nicht sagen.<br>


Als ich als genervter Windowsinaer zum ersten mal Linux installiert habe, war ich bitter enttäuscht: Langsame Geschwindigkeit, unverständliche Programme, wenig Dokumentation, zäher Aufbau, fehlende wichtige Anwendungen. Nach der zweiten Installation war schon alles etwas verständlicher und ich habe die Linux-Philosophie ein wenig besser verstanden. Mittlerweile bin ich bei meiner vierten Linux-Installation..... und bin inzwischen von diesem Betriebssystem restlos begeistert, Windows boote ich nur mehr in Ausnahmefällen. Im Desktop-Bereich hat Linux sicher einiges aufzuholen, jaa, dafür bietet das System so viele andere Plus-Punkte die diesen Nachteil locker wieder wettmachen. Es ist einfach ein unbeschreiblich tolles Gefühl, wenn man mal schnell den Quellcode von fast jeden Linux-Programms (einschließlich Kernel etc.) umändern und neu kompelieren kann, einfach um es an seinen eigene Wünsche anzupassen......<br>


Ob die Zeit für komerzielle Linux-Programme reif ist, wage ich allerdings auch zu bezweifeln.


<p>


Klynx war für mich die beste Idee von Borland seit langem,<br>


hoffentlich erntet Kylxn die Loorbeeren die es verdient,
Schönen Gruß,<br>


Bernhard


<p>


PS: Reagieren die MS Access-Oberfläche so wie man es vom Windows-Standart her gewohnt ist? .....na also

[Patrick Sack]

Hallo Bernhard,
<br>
<br>genau das ist es ja, für Entwickler ist Delphi perfekt (das ist ja auch der Grund warum ich mich von der dunklen Seite lösen konnte und wieder den Weg zurück gefunden habe (back to the roots)). Nun ja wenn ich für einen Entwickler ein Programm entwickele, dann wird er das verstehen, wenn ich ihm sage das ich in der EditMask jetzt nicht "/" darstellen kann sondern nur "\". Hauptsache es funktioniert. Leider gibt es auch andere Menschen, die nicht umbedingt diese Einstellung haben. Mmmh und genau dann artet es in Arbeit aus. Meine Angst ist immer (bei allen Programmen) das die Entwickler sich zu sehr auf neue Sachen versteifen (konzentrieren) und dann die "alten" Problemchen zu kurz kommen. Ein Dilemma, in dem sich Entwickler oft befinden:
Termindruck => Schnell Schuß => Problem in ein bis zwei Jahren, das man ggf. hätte verhindern können, wenn man mehr Zeit gehabt hätte.
<br>
<br>"Im Desktop-Bereich hat Linux sicher einiges aufzuholen," da kann ich dir dann mal BeOS empfehlen. Den Desktop finde ich sehr gut, sowie die gesamte organisation finde ich übersichtlicher als bei Suse (vieleicht auch nur weil das System erst mal nicht soviel installiert). Auch sonst im großen und ganzen (Stabilität, Geschwindigkeit usw.) spricht mich dieses System mehr an als Suse oder Win 9x. Nur leider leider gibt es noch viel viel zu wenig Programme und leider auch noch kein Kylix für BeOS.
<br>
<br>"Doch wer braucht schon wirklich z.B. die Win-API? "
<br>Egal was es ist es sollte nur funktionieren und bei der Arbeit nicht behindern.
<br>
<br>"Das die Zeit nicht reif für Linux ist, würd ich nicht sagen."
<br>Würde ich auch nicht sagen Linux/Derivate sind heute schon in manchen Bereichen mehr als eine Alternative. Die Kombination Apache, MySQL und PHP finde ich beängstigend gut.
<br>
<br>mfg
<br>Patrick
<br>
<br>PS: Vieleicht hätte ich den "Access-Windows-Standard" sagen sollen ;-

[Roland Best]

hallo Bernhard, wann ist eine Zeit reif? Wenn der Markt mit Anwendungen überschwemmt ist und meine Software eins von 25 Alternativen ist

[Roland Best]

hallo Bernhard,
<< Meine Tipp ist: Datenbank zwar in Access (wenn SQL-Datenbank oversized wäre), aber, falls eine etwas komplexere Bedienoberfläche nötig ist, diese mit Delphi entwickeln. >>

dann lieber in Foxpro, dort gibts die von dir beschriebenen Probleme nicht. IMO ist eine Kombination von Delphi (Oberfläche) und VFP (Auswertungen) ideal

[Bernhard Geyer]

Hallo Roland,

Ich kenn bisher nur Access und den MS-SQL-Server (in kombination mit Delphi) genauer und bin damit eigentlich immer ganz gut gefahren. FoxPro kenn ich nur vom Namen her und kann damit nicht darüber aussagen. Wie steht es eigentlich mit der weiterentwicklung von FoxPro bei M$? Versucht man hier nicht auch alles auf eine DB-Engine (MS SQL-Server) wie bei MS-Access "umzubiegen"? Wie steht es mit der ADO-Schnittstelle aus

[Roland Best]

hi Bernhard,

seit Version 3.0 behaupten Gerüchteköche, daß VFP nicht weiterentwickelt werde. Jetzt ist 8.0 in Arbeit. <g> SQL Server - klar. Wir arbeiten seit 02/2000 mit SQL Server. ADO ist schon seit Jahren integriert, aber xBase-Handling ist wesentlich einfacher (vor allem wenn alles schon geschrieben ist <g>).

Die nächsten Projekte werden wir in Delphi (ebenfalls mit SQL Server) realisieren, wobei ich für Reporte und Abfragen der Einfachheit aber VFP bevorzuge. Ein Beispiel für eine Abfrage, VFP ist gestartet, Eingabe im Befehlsfenster:

lnConn=SQLConnect("servername","loginName","passwo rt")

SQLExec(lnConn,"select * from dbo.tab1 where cFeld1 like '0%'","tmp")

SQLDisconnect(lnConn)

Das Ergebnis wird in einem VFP-Cursor geliefert.
Was ich in Delphi am meisten vermisse, daß ich beim Maskendesign keinen "Builder" einsetzen kann. Selbigen lasse ich in VFP über mehrere selektierte Objekte laufen, dann werden diverse Properties eingestellt, die Breite des Objektes und ein Label hinzugefügt.

Oder gibt es dafür in Delphi ein Tool, von dem ich noch nichts weiß

[Roland Best]

hi Bernhard,

seit Version 3.0 behaupten Gerüchteköche, daß VFP nicht weiterentwickelt werde. Jetzt ist 8.0 in Arbeit. <g> SQL Server - klar. Wir arbeiten seit 02/2000 mit SQL Server. ADO ist schon seit Jahren integriert, aber xBase-Handling ist wesentlich einfacher (vor allem wenn alles schon geschrieben ist <g>).

Die nächsten Projekte werden wir in Delphi (ebenfalls mit SQL Server) realisieren, wobei ich für Reporte und Abfragen der Einfachheit aber VFP bevorzuge. Ein Beispiel für eine Abfrage, VFP ist gestartet, Eingabe im Befehlsfenster:

lnConn=SQLConnect("servername","loginName","passwo rt")

SQLExec(lnConn,"select * from dbo.tab1 where cFeld1 like '0%'","tmp")

SQLDisconnect(lnConn)

Das Ergebnis wird in einem VFP-Cursor geliefert. Was ich in Delphi am meisten vermisse, daß ich beim Maskendesign keinen "Builder" einsetzen kann. Selbigen lasse ich in VFP über mehrere selektierte Objekte laufen, dann werden diverse Properties eingestellt, die Breite des Objektes und ein Label hinzugefügt.

Oder gibt es dafür in Delphi ein Tool, von dem ich noch nichts weiß

[Wolf Fietz]

Da bin ja erstaunt : meines Wissens der erste Eintrag, der VFP
positiv erwähnt; okay, damit habe ich mal eine größere Warenwirtschaft aufgesetzt.
Gut : ein bestimmtes MAskendesign
ließ sich ohne längere "Informatikstudien" auf auf alle App-MAsken
vererben, das ging mir bei Delphi und VB nicht so einfach ab..
Aber : bei der Mehrnutzerverwaltung ddurch die VFP-Database
kommen mir Zweifel auf, ob das alles so sicher ist wie bei
ORACLE oder SYBASE.. ???

[Patrick Sack]

Hi,
<br>
@A.Kosch:
<br>"Außerdem wird dort auf den "GPL-Virus"
hingewiesen, d.h. der Entwickler muss höllisch aufpassen, dass er sich keinen rechtlichen Ärger einhandelt, weil er eine Komponente einsetzt, die
unter der GPL-Lizenz entwickelt wurde, aber sein Programm verkaufen will (was er dann nicht mehr darf)."
<br>
<br>Die Komponenten die mit Kylix installiert werden unterliegen doch nicht der GPL oder?
<br>D.h. ich muß nur bei neuen Komponenten darauf achten, das diese nicht der GPL unterliegen, richtig?
<br>
<br>Danke für eine Antwort!
<br>
<br>mfg
<br>P

[Andreas Kosch]

Hallo Patrick,

ja - dieser Hinweis bezieht sich generell auf neue Komponenten bzw. Klassen, die von dritter Seite zur Verfügung gestellt werden