Neue Version der "Win32API Tutorials für Delphi"
-
So, für alle Fans der Win32API Programmierung liegt nun die aktualisierte und erweiterte Version der "Win32API Tutorials für Delphi" in der Version 1.9 vor.
Was ist neu?
Hier ein Auschnitt aus der History.txt:History.txt schrieb:
Version 1.9 - 2003-12-23:
* Fenster und Controls
- Fenster: Ergänzung zur Hintergrundfarbe unter Windows XP
- Editfelder: Ergänzung zur "SHAutocomplete"-Funktion.
Ergänzung zum "Cue Text" & balloon-Tipps unter Windows-XP
- Listbox: Erweiterung Drag-Listbox
- Combobox: Erweiterung ComboboxEx* Standarddialoge
- "Hilfe"-Schaltfläche bei den Dialogen* CommonControls
- Tooltips: Fehlende Symbolkonstanten für balloon-Tipps ergänzt.
- Tabsheets* Sonstiges
- Anwendung für die Systemsteuerung
- Einen Assistenten erstellenEs sind also neue hinzugekommen ("Sonstiges") und bestehende wurden erweitert ("Listbox2 -> "Drag-Lictbox" und "Combobox" -> "ComboboxEx"). Desweiteren wurden Kleinigkeiten ausgebessert und ergänzt.
Die PDF-Version wurde auch noch mal komplett überarbeitet. Sourcecode-Auschnitte und die API Deklarationen sind jetzt gesondert hervorgehoben. Auch wurde das Layout geändert, so dass jetzt ein beidseitiger Druck möglich ist.Komplette History: http://www.luckie-online.de/tutorials/win32apituts/Win32API_History.txt
Download: Win32API Tutorials für Delphi
Bei Fragen oder Anregungen steht euch mein Forum zur Verfügung: www.luckie-online.de/forum .
-
Darf man Kritik loswerden ?
Ich empfinde es, mal diplomatisch ausgedrückt, als recht unhöflich, in welchem Dateiformat auch immer Schriftarten zu verwenden, die nicht standardmäßig installiert sind.
-
Dessen bin ich mir gar nicht bewußt. Umwelche geht es denn? Und wie hast du es gemerkt? Und welches OS hast du?
-
um die PDF gehts. die schriftart ist erst bei einer höheren Version von AdobeReader verfügbar. Man muss dann ne neue VErsion downloaden, bevor man sich die pdf anschauen kann.
Ist kein Problem vom OS (Win2000).
-
Öhm, jetzt bin ich etwas ratlos. Ursprünglich ist es ein OpenOffice Dokument, welches ich mit der eingebauten Funktion nach PDF konvertiert habe. Ich dachte eigentlich, er würde die Schrift aus dem OpenOffice Dokument nehmen.
-
Ist gut geworden, aber wieso mit Delphi ohne VCL arbeiten? Was bringt das für vorteile außer kleinere Dateien (was mittlerweile total egal ist)? :xmas1:
P.S. Was ist das für eine Schriftart? lässt sich gut lesen :xmas1:
-
Warum sollte man mit dem VC ohne MFC programmieren wollen? Da hat man noch nicht mal eine kleinere Exe.
Aber für ein kleines Tool mit zwei Edits und zwei Butons halte ich die VCL mit ihrer 450 kB Exe für Overkill. Desweiteren fördert es das Verständnis, wie Windows intern funktion usw.
-
Luckie schrieb:
Warum sollte man mit dem VC ohne MFC programmieren wollen? Da hat man noch nicht mal eine kleinere Exe.
kannst du das erklären?
-
Jupp, wenn ich die MFC DLL's nicht statisch Linke, ist eine Anwendung mit MFC nur unwesentlich größer als reine WinAPI, wenn überhaupt.
-
Luckie schrieb:
Aber für ein kleines Tool mit zwei Edits und zwei Butons halte ich die VCL mit ihrer 450 kB Exe für Overkill. Desweiteren fördert es das Verständnis, wie Windows intern funktion usw.
dafür gibt es z.b. upx.
das verständnis ok...
-
Luckie schrieb:
Jupp, wenn ich die MFC DLL's nicht statisch Linke, ist eine Anwendung mit MFC nur unwesentlich größer als reine WinAPI, wenn überhaupt.
*lol*
wenn <insert your favorite GUI Framework> dynamisch linkst, ist die Anwendung immer extrem klein... Weil dann der Code vom Framework ausgelagert ist. Das entbindet dich aber nicht davon die DLLs mitzuliefern. MFC mal abgesehen, da ältere MFC Versionen bei WIndows schon dabei sind - aber bei den neuesten (VS.NET 002 + 2003) wirst du die DLLs auch mitliefern müssen.btw: ich würde die größe der EXE nun wirklich nicht als Entscheidungskriterium nehmen.
-
btw: ich würde die größe der EXE nun wirklich nicht als Entscheidungskriterium nehmen.
Jo, 500K sind fürn Taschenrechner ja auch voll io
Für mich spielt das schon ne grosse Rolle.
Was ist für Dich den entscheident??
-
Also ich weiß ja nicht. Alle beschweren sich, das man schon für irgend welche kleinen Tools Hardware braucht, wie für fünf Jahren für ein anspruchsvolles Spiel. Aber selbst effektiv programmiert wird nicht, weil das Arbeit bedeutet und man eventeull sogar verstehen müsste, was man da macht oder machen will.
Desweiteren ist es imme rnoch ein Unterschied, ob ich mir mit Modem eine 500 KB Exe runter ziehe oder nur eine 20 KB Exe. (Was das gepackt ergibt weiß ich nicht, sollte aber am Verhältnis nichts ändern.)
-
Luckie schrieb:
Desweiteren ist es imme rnoch ein Unterschied, ob ich mir mit Modem eine 500 KB Exe runter ziehe oder nur eine 20 KB Exe. (Was das gepackt ergibt weiß ich nicht, sollte aber am Verhältnis nichts ändern.)
in der heutigen Zeit ist DSL schon standard, wer noch modem benutzt ist selbst schuld (oder die Telekom ;)) :xmas1:
-
upx komprimiert die Ausführbare Datei nur, reduziert aber nicht den Bloat sondern fügt eher weiteren Bloat hinzu, in dem erst eine entpack routine laufen muss.
-
Und man hebelt damit den Windows-Speichermanager aus.
-
Klar schrieb:
btw: ich würde die größe der EXE nun wirklich nicht als Entscheidungskriterium nehmen.
Jo, 500K sind fürn Taschenrechner ja auch voll io
Für mich spielt das schon ne grosse Rolle.
Was ist für Dich den entscheident??Für mich ist entscheidend wie gut man damit programmieren kann.
Wer entwickelt denn schon einen Taschenrechner? Für so kleine Sachen ist es natürlich Overhead, aber 500KB sind ja nun wirklich nicht viel!
Alles was über 1,44MB geht ist doof, da man es dann nichtmehr auf eine Diskette packen kann - aber solange es so klein ist - ist es mir egal.
Und bei richtigen Anwendungen sind die 500KB sowieso unbedeutend, denn dann hat das Programm mehrere MB, und da fallen die läppischen 500KB auch nicht mehr ins Gewicht...