Ich glaube nicht, daß das so einfach möglich ist.
Schließlich steht der ganze Funktionsumfang von XProfan
in der Prfrun32.exe, die als Resource (bei X4) mitgelinkt
wird. Bei den vorherigen Versionen war praktisch nur ein
Kopieren der Prfrun32.exe und den dazugehörigen Bytecode.
Also im Prinzip so ähnlich, wie JAVA + die JVM, die
installiert sein muß. Nur mit dem Unterschied, daß XProfan
seine VM (virtuale Maschine) mit im Gepäck und damit im
Speicher hat.
XProfan X5
-
-
-
Dazu müsste m.E. so etwas umständliches wie MAKE bei C oder C++ eingeführt werden - da spricht vieles dagegen (z.B.. ich ). Man könnte ev. auch die INC aufsplitten in meherere kleine, wo die Einzelne dann häufig gemeinsam vorkommende Abschnitte zusammenfasst. Zumindest meine mathe.inc habe ich nach Gebieten getrennt (Kombinatorik, Statistik etc)
-
Das lässt sich leider gar nicht realisieren, da ja all die XProfan-Befehle und - Funktionen in der einen Runtime sind, zu der das comilierte Programm dazu gelinkt wird. Und die Runtime (Prfrun32.exe) ist halt der große Brocken.
Bei den Include-Dateien könnte man theoretisch schauen, welche Funktionen tatsächlich benötigt werden, und nur diese im Programmcode (vor dem Compilieren) belassen, aber das würde kaum etwas ausmachen. Ich fürchte, hier stünde der Aufwand (Einbau der Funktionalität) in keinem Verhältnis zum Ertrag (Verringerung der Größe des fertigen Programmes).Gruß
Roland -
Denke ich auch.
Wenn ich mir in meinem Code-Ordner die Dateien anschaue, die
als XProfan Bytecode (im vorcompilerten Zustand) da stehen,
kommen die von 1 KB bis höchstens mal 10 KB.Das macht den Hahn auch nicht fett.
Man muß auch hier sagen, daß die größeren Delphi - Units, die
Roland ja bestimmt auch einbindet, auch einen Teil der Größe
ausmachen.Da bliebe wirklich nur der Ausweg, alles in C oder Assembler neu
zu schreiben. Und einen richtigen Compiler zu schreiben, lohnt
sich hier bei dem wenigen Interesse überhaupt nicht.Und wenn man mal genau überlegt : bis X3 passen die fertigen
Programme größtenteils noch auf eine 1,44er Diskette, zumindest
wenn es nur kleine selbstgeschriebene Tools sind. Bei den heutigen
HDD-Größen also klar vernachlässigbar.Also lassen wir es am besten, wie es ist und erfreuen uns, wenn
Roland noch eine Zeitlang weiter macht. -
Ich rede von Funktionen, die mit Incs eingebunden werden...
-
Wie gesagt, das nimmt sich nicht viel.
Die Incs werden ja genauso behandelt, als ob sie
im Haupt-Quellcode stehen würden.Das sind nur ein paar Byte, die so eine Proc, ob benutzt
oder unbenutzt, da schluckt.Ich habe mal testweise eine Include mit 4 Procs
(sind jetzt nicht allzu groß) eingebunden und kompiliert.
Das macht jetzt einen Unterschied von 2 KB bei den
.exe. Die .inc wird mit 4 KB angezeigt.Bis du da 100 KB zusammen hast, mußt du schon wirklich
riesige Includedateien einbinden.Man könnte jetzt noch einen Test mit .pcu machen, um
zu sehen, wie groß bzw. klein es da wird. -
Und wenn eine Include-Datei wirklich so riesig wird, dass es von Belang ist, ist es sinnvoller, diese in mehrere Include-Dateien aufzuteilen, so dass man nur die Befehls- und Funktionsgruppen einbindet, die man benötigt.
Gruß
Roland -
Vielleicht wären auch die .pcu Dateien einer Überlegung wert.
Schließlich sind sie so ähnlich wie andere LIBs (.lib), also
vorcompiliert. Ich sehe so ein Prinzip in anderen Sprachen,
wie B4A, B4j u.a. Da gibt es eine Core-Lib, die immer eingebunden
wird und halt die Grundfunktionalität enthält. Die anderen zus.
Libs werden rechts in einem TAB-Reiter aufgelistet, sofern sie
in einen bestimmten Ordner kopiert wurden. Die kann man
dann durch Ankreuzen (Checkbox) mit einbinden. Die Funktionen,
die in den einzelnen Libs enthalten sind, sind in einer Textdatei
separat aufgelistet (auch die Parameter). Somit ist im Editor durch
eine andere Schriftfarbe auch ersichtlich, ob die Funktionen aus einer
solchen Lib stammen. Die Parameter könnten dann bspw. in einem
Statusfenster angezeigt werden.Sowas könnte Roland evtl. auch mal überlegen. Die Runtime (Prfrun32.exe)
wäre kleiner (enthält nur Wichtiges wie Grundfunktionalität, usw.) und Updates
bzw. Erweiterungen wären besser zu pflegen. Sollten neue Funktionen, sei es
durch Roland oder sonstige User, dazu kommen, so ist nur die .pcu mit der
entsprechenden Textdatei weiter zu geben. Und die Urheberrechte blieben
dann auch gewahrt.Wäre nur mal eine Idee von mir.
-
Noch ein Zusatz :
Roland, hast du irgendwas beim Compilieren von Programmen,
die eine .pcu einbinden, getestet ?In einer MessageBox wird Zeile für Zeile der
zur .pcu gelinkten Datei angezeigt.Das Compileren der eigentlichen .pcu funktioniert tadellos.
Es wird zwar auch ein Programm (.exe) erzeugt, aber die
vielen MessageBoxen davor sind etwas unnötig.Es geht nur um den Compiler. Im Interpreter funktioniert es.
-
Da muss ich bei Gelegenheit mal schauen ...
Alternativ zunächst Include-Dateien verwenden.
(Ich selbst nutze gar keine PCUs.)
Gruß
Roland -
WindowStyle und %WindowStyle könnte man auch in Set/Get verpacken.
-
Vielleicht wäre es auch möglich GetFDate zu erweitern um nicht nur das Dateum der letzten Änderung einer Datei zu erfassen.
-
Wir haben ja noch GetFTime$() und GetFAttr() zu Verfügung.
Oder brauchst du sonst noch was ?
Oder willst du alle 3 Funktionen in einer Containerfunktion
zusammen haben ? -
Nein, ich meinte mehr Datumsangaben: Erstellung, letzter Zugriff, Änderung...da gibt's einen Quellcode für Xprofan im Netz, der ist aber Recht umfangreich. Ich dachte es geht vielleicht einfacher wenn Roland die Funktion erweitern könnte.
-
Achso, du meinst bestimmt das hier :
https://xprofan.net/intl/de/quellt…x-zeit-zugriff/ -
Im Prinzip ja, ich hatte das hier gefunden:
http://xprofan.net/intl/de/quellt…-informationen/Der Code kann noch etwas mehr.
-
Leider war der Code dort sehr alt und ist wegen fehlender Zeichen für XProfan-11 allein nicht mehr funktionsfähig gewesen. Ich habe versucht, die Sache halbwegs zu reparieren, und soweit klappt es bei mir (Garantie gibt es natürlich keine).
Der Originialcode stammt vermutlich von Frabbing oder A.Miethe, das lässt sich wegen fehlender Beitragsautor-Namen heute nicht mehr erkennen. Das aufrufende Hauptprogramm dazu stammt von Thomas Hölzer.
Hier das Link zum restaurierten Programm: LINK -
Uh, vielen Dank. Das ist aber immer noch sehr unübersichtlich. Wenn ich mal Zeit habe kürze ich das ein.
-
Ich würde mir auch wünschen, dass analog zur Konstruktor Funktion beim Disposen automatisch eine Destruktorfunktion "Exit" aufgerufen wird, sofern sie in einer Klasse definiert ist.
-
Wie sieht's aus Roland? Seit dem Release von X4 sind jetzt fast 2 Jahre vergangen. Geht's weiter mit XProfan, übernimmt jemand anderes die Entwicklung oder kommt's in die Mottenkiste? Ich bin sofort wieder an Bord, einige andere hier auch. Hoffentlich lohnt sich eine Weiterentwicklung.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!