Spectragram

[EWeiss]

Projekt entfernt..

[EWeiss]

Zitat von jaenicke:

Zitat von EWeiss:

Zitat:

Also mir ist da der gewohnte Datei-Öffnen Dialog von Windows lieber.

Sagte ja schon mir auch.
Nur er passt halt nicht in mein Design Konzept. (Und fertiges ist immer besser)

Da wäre es doch sinnvoller die seit XE2 in Delphi vorhandenen VCL Styles zu benutzen. Die modifizieren auch die Systemdialoge, so dass das Design dem eigenen entspricht, aber die Funktionalität ist halt immer noch da.
Noch dazu ist es viel weniger Arbeit. Natürlich muss man so einen Style auch erst einmal erstellen, aber im Vergleich mit dem manuellen stylen einer Anwendung ist das nicht so viel.

Dann ist es aber kein NonVcl mehr und ich besitzt kein Delphi-XE.
Vielleich fällt mir ja noch eine lösung ein.

Ich möchte unabhängig von jeglichen fremden Komponenten sein das ist der Hauptgrund warum ich mir die Arbeit mache.
Zudem ist es nur ein Hobby

gruss

[Luckie]

Nun ja. Ich habe den Code gesehen. Die Units, die den Code aufblähen, hast du ja wieder alle drin. Also, ich verstehe dein Ansinnen nicht so ganz bezüglich NOnVCL.

[EWeiss]

Zitat von Luckie:

Nun ja. Ich habe den Code gesehen. Die Units, die den Code aufblähen, hast du ja wieder alle drin. Also, ich verstehe dein Ansinnen nicht so ganz bezüglich NOnVCL.

Zitat:

Die Units, die den Code aufblähen, hast du ja wieder alle drin

Nirgendwo wirst du irgend eine Unit Forms in meinem Quelltext finden.
Welche meinst du denn die den Code aufblähen?

Classes, Windows, SysUtils, Graphics
Viel mehr ist da nicht.
Sollte ich besser sagen Win32Api ist letztendlich nichts anderes.

gruss

[Luckie]

Classes zum Beispiel.

[EWeiss]

Zitat von Luckie:

Classes zum Beispiel.

Ich finde jetzt nur nicht den Widerspruch Classes <> NonVcl
Wusste jetzt nicht das es verpönt ist die Unit mit einzubinden. Die kapselt am ende auch nur die Win32API.
Es wird ja auch nicht die gesamte Unit mit kompiliert sondern nur die Teile die Verwendung finden.

gruss

[Luckie]

Verpönt ist gar nichts. Nur ist der Hintergedanke bei der NonVL Programmierung ja, dass man möglichst kleine Exe-Dateien haben will, sonst würde mir kein anderer Grund einfallen. Sinnvoll zum Beispiel bei SFX Archiven (http://michael-puff.de/Programmierung/Delphi/Programme/ -> SFX-Tools.zip). Aber meine Eigentliche Intention war es zu verstehen wie Windows funktioniert. Dass dabei dennoch nützliche Programme (xpusermanager.de) abgefallen sind, war eigentlich unbeabsichtigt und ursprünglich nur Fingerübungen.

[EWeiss]

Die Frage wäre wie Interface erstellen.

Ob ich nun die ActiveX einbinde und über CoCreate die Interface einbinde oder diese von den Classen direkt verwende.
Da ist irgendwo ein Widerspruch oder?

Wie soll ich eine Classe ohne TObject/TComponent erstellen das sind so die Feinheiten.
Wenn ich komplett auf die Classes verzichten will.

Hmm muss nachdenken.

EDIT:
Und das ist alles NonVcl Konform von Windows mal abgesehen?
ShlObj, ActiveX, Windows, Messages, CommCtrl, CommDlg, ShellAPI

Habe jetzt nicht nachgesehen welche von den Units letztendlich auf die Classes zeigt.

gruss

[Luckie]

Und du solltest deine E-Mail Benachrichtigungen abstellen, sonst schläfst du nie.

Es ist dir ganz alleine überlassen. Ich will dir nicht rein reden oder kritisieren. Ist super, was du bisher geschafft hast. Ich wäre überfordert bzw. hätte schon lange vorher wieder auf die VCL zurückgegriffen bei so einem Projekt. Aber um es mal auf den Punkt zu bringen: Warum nutzt du die VCL nicht? Meine ursprüngliche Intention habe ich mitgeteilt.

PS: Nur für mein Ego. Inwiefern haben dir meine NonVCL Tutorials geholfen? Win32API-Tutorials für Delphi Jetzt sag nichts falsches. Ich meine, Kommentare von mir in deinem Code wiedererkannt zu haben.

[Medium]

TObject ist in der system.pas beheimatet, und quasi ein "Sprachfeature". Alles was TComponent mit bringt, kann man auch zu Fuß machen.

Die Aussage, dass nur benötigte Teile gelinked werden, ist auch mit Vorsicht zu genießen. Schaut man sich an welche Rattenschwänze an Abhängigkeiten sich allein schon durch die Teile in den Initialization- und Finalization-Abschnitten ergeben, bekommt man je nach Unit eine unerwartete Menge an impliziten "benötigten Teilen", selbst wenn man sie im eigenen Code gar nicht verwendet. Aus reinem "Prestige" NonVCL zu gehen ist imho fehlgeleitet, da man sich Unmengen an Arbeit (und Fehlerquellen) einhandelt, ohne nachher von dem wirklichen Nutzen einen Mehrwert zu haben. (SysUtils ist da, glaube ich, auch so ein Kandidat für viele implizite Abhängigkeiten. Mag mich irren, aber das schwirrt mir im Kopf rum.)

[EWeiss]

Zitat von Luckie:

Und du solltest deine E-Mail Benachrichtigungen abstellen, sonst schläfst du nie.

Es ist dir ganz alleine überlassen. Ich will dir nicht rein reden oder kritisieren. Ist super, was du bisher geschafft hast. Ich wäre überfordert bzw. hätte schon lange vorher wieder auf die VCL zurückgegriffen bei so einem Projekt. Aber um es mal auf den Punkt zu bringen: Warum nutzt du die VCL nicht? Meine ursprüngliche Intention habe ich mitgeteilt.

PS: Nur für mein Ego. Inwiefern haben dir meine NonVCL Tutorials geholfen? michael-puff.de/Programmierung/Delphi/Tutorials/Win32API_Delphi.pdf jetzt sag nichts falsches.

Bei manchen Dingen habe ich schon Nachgeschaut.
Aber mein wissen bzg. NonVCL kommt asuschließlich aus VB weil man dort jede einzelne Funktion/Procedure/konstante zusammen suchen musste um ein Projekt auf die Beine zu stellen
Na das hab ich 15 Jahre gemacht und dann keinen Bock mehr gehabt.

Ich Arbeite nur noch damit wenn mein Hauptprojekt zufällig noch einen Fehler hat.

Ich habe mir bei dir zum Beispiel Infos darüber geholt wie ich die Combobox Transparent setzen könnte und nachgesehen welche Flags du verwendest.

Es gibt nix Win32API_Delphi.pdf ist schon eine feine Sache inklusive der Samples natürlich

Zitat:

Warum nutzt du die VCL nicht?

Mit VCL hätte ich so ein Projekt wie mein VPiano gar nicht erst erstellen können ohne fremde Komponente.


gruss