Kann einer mir mal kurz erklären, was die VCL.NET ist, bzw. wo und wie sie in D8 verwendet werden sollte. Mit D8 habe ich per buttonclicj eine showmessage erzeugen können und dieses gigantische Programm läuft nur als VCL.NET

VCL.NET bietet die Funktionalität, die die originale VCL bietet, nur mit dem Unterschied, dass sie nicht auf der Win32-API aufbaut, sondern auf .NET. Somit kann man originäre VCL-Projekte im Optimalfall 1:1 in .NET-Projekte umwandeln.

Ich glaube du wählst beim erzeugen des Projektes (Datei->Neu->weitere) ob es ein VCL Winforms oder was auch immer anwendung werden soll.

Gruß
Klabautermann

@Chewie: wie wirkt sich das ein oder andere aus ? Bzw., wo ist der Unterschied ? Oder an dem konkreten Beispiel: Was ist mit der Showmessage?

@Klabautermann: wie ich das verstehe, ist es so ähnlich wie mit VCL und WinAPI nur für .NET Die VCL ist dann die VCL.NET und die WinAPI halt .NET Wenn dies so richtig ist, würden sich mit WindowsForms Programme a la Luckie erstellen lassen. Mit geringer Größe und Verlagerung der Hauptarbeit in das Betriebssystem.

Unklar ist noch (u.A.) folgendes: wie reagiert ein Programm, sofern .NET nicht installiert ist und wie läuft die VCL.NET intern ab ?

Also: .NET ist NICHT WinAPI. .NET setzt auf der WinAPI immer noch auf. WinFOrms ist für die Fensterentwicklung unter .NET, das ist also das, womit man neue Projekte in D8 entwickeln sollte. Die VCL.NET benutzt Wrapper-Klassen, um die alten VCL-Klassen ins .NET rüberzubringen, setzt also auf .NET_Interne Klassen auf. Das Problem bei dieser Sache ist dann, dass man beide nicht ohne Schwierigkeiten zusammen verwenden kann, auch nur über erzeugte Wrapper (da muss man in D8 innerhalb der VCL.NET per Import die eigentlichen .NET-Controls wrappen oder so), also ist ein gemächliher Umstieg einer alten VCL-Anwendung ins reine .NET nicht so einfach möglich. Beachten muss man dabei auch, dass alte importierte VCL-Kompos immer noch teilweise auf die WinAPI zugreifen, auch net so toll.

Sollte .NET nicht installiert sein, läuft das Programm nicht, es bringt glaub ich einen Fehler, weils die mscore.dll nicht findet und beendet sich dann.

Hallo,

hansa hat folgendes geschrieben:

@Klabautermann: wie ich das verstehe, ist es so ähnlich wie mit VCL und WinAPI nur für .NET Die VCL ist dann die VCL.NET und die WinAPI halt .NET Wenn dies so richtig ist, würden sich mit WindowsForms Programme a la Luckie erstellen lassen. Mit geringer Größe und Verlagerung der Hauptarbeit in das Betriebssystem.

wenn ich die Leute auf der Borland Roadshow richtig verstanden habe, dann lautet die Antwort ganz eindeutig Ja.
Die VCL.NET ist ein Kapzelung der Nativen .NET Assembies, bei der besonderer Wert darauf gelegt wurde, dass sie wie die klassische VCL funktioniert (aus Anwender [also deiner und meiner] sicht). Genau wie die Klassische VCL produziert sie dadurch einen gewissen Overhad der mit in die "EXE" eingelinkt wird. VCL.NET Programme sind also wieder Single EXE Anwendungen, solange man es nicht anders will (es soll wohl auch wieder eine Compilkerschalter geben, der das verhindert, dann muss man entsprechende Assembies seperat mit ausliefern).
Winforms ist in dem Fall wohl vergleichbar mit WinAPI Programmierung, nur das es wesentlich weniger Caotisch sein soll. Die Borländer auf der Roadshow äußerten sich dazu inetwa so: "Bei der Winforms Programmierung Folgt alles dem selben Scheme. Man erkennt nicht mehr am Aufbau der Parameterliste, welche Arbeitsgruppe diesen Teil der "API" entwickelt hat." Es soll also alles recht Sauber und Logisch sein. KEin wunder, sie haben ja auch Spezialisten bei Borland dafür eingekauft .

Es gibt sogar gerüchte, das die VCL.NET ein reines Portierungsinstrument sein, und das neue anwendungen zwangsweise als Winforma entwickelt werden sollten. Ich kann mir aber nicht vorstellen, dass Borland auf die weiterentwicklung der VCL.NET verzichten wird und somit nicht auch in Zukunft schicke extras, auf einfache weise anzubieten, die mit Standard Mitteln nur umständlich zu implementieren sind.

hansa hat folgendes geschrieben:

Unklar ist noch (u.A.) folgendes: wie reagiert ein Programm, sofern .NET nicht installiert ist und wie läuft die VCL.NET intern ab ?

Wenn das .NET Framework nicht installiert ist, startet das Programm nicht.
Von den interner der VCL.NET kann ich dir nicht berichten, besonders wo ich keine Delphi 8 besitze und es auch nicht werde, wenn es mir nicht wer schenkt (na nicht jemand lust? Die Professional Version würde ja schon reichen [aber kommt mir nicht mit 'ner Kopie, sowas nehme ich nicht]). Aber wie gesagt, es wird ähnlich laufen wie bei der API, einfach das vorhandene Kapzeln und somit die Schnitstellen ändern. Das ganze nach möglichkeit konfortabler bekommen.

Gruß
Klabautermann

Hi,

UGrohne hat folgendes geschrieben:

Beachten muss man dabei auch, dass alte importierte VCL-Kompos immer noch teilweise auf die WinAPI zugreifen, auch net so toll.

also so wie das gesamte .NET Framework.

Auf meine nachfrage wurde mir versichert, dass auch VCL.NET programme unter jedem vollständig implementierten .NET Framework laufen. Also auch in Zukunft aum Mono. Den Praxistest konnten die Programme allerding noch nicht erbringen . Und das gild natürlich auch nur, wenn du deine .NET anwendung nicht von anderen API Anwendungen anbhängig machst.
Wenn du also unter .NET ein BDE Anwenung schreibst (und die BDE wir mit sicherheit nicht zu .NET Portiert) dann läuft die auch weiterhin nur aus Win32 API Systemen (mit zusätzlich installierten .NET Framework ).

Gruß
Klabautermann

Da bleiben noch tonnenweise Fragen offen. Ich war auch auf der Roadshow, allerdings in Köln. Daniel Magin hat das relativ gut erklärt: man müsse sich das ungefähr so vorstellen, wie mit der Dos Box unter Windows. Also eine Art Windows Box für .NET Nun, wie gesagt habe ich 2 Min. in D8 investiert, ein WinForms (also .NET) Programm mit ShowMessage gemacht -> geht nicht. Als VCL.Net Projekt gehts.

Und zu UGrohne: Daß .NET Programme die WinAPI benutzen, glaube ich nicht recht. Das würde keinen Sinn machen. Anders könnte es bei der borländschen VCL.NET aussehen. Wer weiß

Und zu guter letzt noch eine Beschwerde an M$: die Millionen für Fernsehreklame wären besser da hin gegangen, wo sich Leute mit dem Mist befassen. Oder ein reines .NET Betriebssystem müßte bereit stehen, um Reste der WinAPI direkt zu erkennen.

hansa hat folgendes geschrieben:

Da bleiben noch tonnenweise Fragen offen. Ich war auch auf der Roadshow, allerdings in Köln.

Am zweiten oder am dritten?

am ersten Termin. Also am 2.2.2004 und somit vor Dir.

hansa hat folgendes geschrieben:

Und zu guter letzt noch eine Beschwerde an M$: die Millionen für Fernsehreklame wären besser da hin gegangen, wo sich Leute mit dem Mist befassen. Oder ein reines .NET Betriebssystem müßte bereit stehen, um Reste der WinAPI direkt zu erkennen.

Höre ich da eine leichte Überheblichkeit raus? Mal schnell eine .Net Betriebssystem rausgebarcht und die Welt schreit juhuuu ...so ist es aber nicht, schon garnicht schnell entwickelt und schon garnicht mal so auf den Markt gebracht. Wenn man nur mal daran denkt wieviele Leute noch Win 98 verwenden. Innovationen und neuen Techniken sind viele Leute sehr skeptisch aufgeschlossen deshalb aknn und will eine Firma wie Microsoft und borland keinen Umstieg auf .Net von einem Tag auf den anderenn. VCL.net ist da ein guter Weg. Wenn jemand bessere Vorschläge hat immer her damit, aber bitte keine Vorschläge wie:

Zitat:

die Millionen für Fernsehreklame wären besser da hin gegangen, wo sich Leute mit dem Mist befassen

Delphi wie ihr es mal kanntet wird genauso schnell verschwinden wie die BDE die ja auch schon vor einiger Zeit eingestelt wurde (Entwicklung) aber trotzdem noch zu Hauf verwendet wird (wie DBase und Paradox).
Also eher sehr langsam. Übrigens steht in der Anleitung von Delphi 8 etwas von BDe.NET hehe

wieos kann ich im .Net Forum nie editiern?

Da ist wohl was bei der Einrichtung der Sparte falsch gelaufen. Ich werde das weitergeben.

hansa hat folgendes geschrieben:

Und zu UGrohne: Daß .NET Programme die WinAPI benutzen, glaube ich nicht recht. Das würde keinen Sinn machen. Anders könnte es bei der borländschen VCL.NET aussehen. Wer weiß

Es ist eigentlich ganz einfach:
.NET ist das "neue" Framework, dass die WinAPI ersetzen soll. Es ist aus einem Guss und zudem klassenbasiert.
Gedacht ist, dass man in Zukunft nur noch .NET benutzt und nicht mehr direkt auf die WinAPI zugreift. Ob .NET nun auf der WinAPI basiert oder direkt über dem Kernel aufgebaut ist, spielt dann für den .NET-Entwickler keine Rolle mehr. Im Moment ist es halt so, dass .NET auf der WinAPI aufgesetzt ist, aber in zukünftigen Betriebssystemen könnte es durchaus sein, dass .NET direkt über der Kernelebene liegt.

Man muss sich das ganze einfach als geschichtetes Modell vorstellen.

Nach Aussage von Microsoft soll der Windows-XP-Nachfolger "Longhorn" WinAPI-Anwendungen nur noch in einer Art Kompatibilitätsmodus ausführen, also so ähnlich wie die DOS-Box für DOS-Programme. Dies dürfte bedeuten, dass es dann keine Unterstützung für klassische Windows-Anwendungen von Seiten Microsofts aus mehr gibt. Irgendwann - in etlichen Jahren - wird es dann vermutlich auch Windows-Versionen geben, welche derzeit übliche Widows-Programme gar nicht mehr ausführen können, oder nur mit erheblichen Einschränkungen.
Deshalb empfehlen sowohl Microsoft, als auch Borland, ganz neue Software-Projekte gleich auf DotNet aufzusetzen.

@Hansa Wenn du eine Message (showMessage) unter den Winforms anzeigen willst, gibt es 2 Möglichekiten:

• du kannst díe API-FUnktion aus der user32.dll implementieren
  
• oder du gehst den .NET Weg : MessageBox.Show('test');
  

Die anderen Fragen sind ja soweit alle geklärt, oder?

Hi,

ak hat folgendes geschrieben:

wieos kann ich im .Net Forum nie editiern?

Sorry, da habe ich die Einstellung bei der erstellung der Sparte falsch gesetzt, sollte jetzt funktionieren.

Gruß
Klabautermann

Hallo,

Alfons-G hat folgendes geschrieben:

Nach Aussage von Microsoft soll der Windows-XP-Nachfolger "Longhorn" WinAPI-Anwendungen nur noch in einer Art Kompatibilitätsmodus ausführen, also so ähnlich wie die DOS-Box für DOS-Programme.

ja, und das selbe sagen sie über nicht Paladin (oder wie auch immer es heute heißt) Programme. Ich erwarte, das die da eine verquickung der beiden Technologien durchführen werden. So das .NET (V2) Programme dann TCPA fähig sein müssen, was wahrscheinlich dann auch eine (gebührenpflichtige) Lizenz vorraussetzt. Wie gesagt äußerungen in diese richtung gibt es nicht, es erscheint mir aber Logisch und deshalb bin ich .NET gegenüber noch sehr skeptisch eingestellt. Nicht wegen der Technik, sondern wegen der potentiell kommenden Lizenzen.

Gruß
Klabautermann

Also ich bezweifel stark, dass Longhorn schon die API als Komp-Modus laufen lässt und grundsätzlich auf .NET aufbaut, wenn es 2005 rauskommt. Denn Yukon (der neue SQL-Server), der Ende des Jahres kommt, ist nicht .NET, sondern verwendet weiterhin WinAPI, .NET-Procedures werden über ein hinzuzuladendes Modul ausgeführt.