Anregungen und Vorschläge zu PROFAN
Hier können Vorschläge für künftige PROFAN-Versionen, Ausgestaltung der PROFAN-Seiten und -Foren, etc. gemacht werden.

| Suchen
| Zurück zur Übersicht

Autor | Thema: Sonstiges:
Thorsten
| Datum:23.05.01 19:57 (galaxy@mrk-soft.de) |
Diese Vorschläge stammen teils auch schon von anderen Teilnehmern, die selbige Ideen hatten, schreibe sie nur noch mal zur Vollständigkeit halber. 1) Kopieren von Inhalten einer Listbox in einer Anderen. MoveListBoxToListBox(N1,N2) n1 = handle der quell Listbox n2 = handle der ziel Listbox Der Inhalt von Listbox N1 wird in n2 Kopiert. Warum: WhileLoop GetCount(n1%) AddString(n2%,getString(n1%,&loop-1)) EndWhile dauert einfach bei gut 1000 Einträgen mit Profan viel zu lange.
Rene Wagner
| Datum:24.05.01 08:28 (apollo@rw-net.de) |
Ich weiss nicht, ob Roland das überhaupt zwecks Kompatibilität in Betracht zieht und ob das für Version 7.5 schon anzuraten ist, aber ich würde mir wünschen, das Profan von ein paar "Altlasten" befreit wird. Das wären imho zum Bleistift: -der Textmodus -Beschränkung auf eine Ausführung der Funktion @create (also entweder alles mit @Create("Button",...) oder @CreateButton(...)) und so ein paar Kleinigkeiten, mehr fällt mir ob der frühen Stunde nicht ein. ;-) Ich denke das käme dem Laufzeitverhalten etwas entgegen und würde die Runtime auch wieder etwas schlanker machen. Was meint Ihr dazu? gruss, René
Daniel
| Datum:24.05.01 20:55 |
Dann lieber createbutton( .... ). Dann läßt sich pRFellow weiter nutzen. Bis dann
Rene Wagner
| Datum:26.05.01 09:02 (apollo@rw-net.de) |
Nee, also ich würde die neuere Notation @create("Button",...) vorziehen. Roland kann imho keine Rücksicht auf Zeugs nehmen, dessen Entwicklung sowieso eingestellt wurde. Was wird z.B. mit den neuen FTP-Befehlen in Profan7.5? Sollen die auch weggelassen werden, weil PrFellow das net kann? gruss, René
Roland G. Hülsmann
| Datum:26.05.01 14:38 (rgh-soft@t-online.de) |
Also zum ersten: In Version 7.5 bleibt es noch beim Alten: Beide Varianten des Create werden komplett unterstützt. Das Herausnehmen der alten Version würde Runtime und Interpreter zwar GERINGFÜGIG (wenige Bytes) verkleinern, aber in der Geschwindigkeit der Runtime NICHTS ausmachen. Der Code für z.B. CreateEdit ist nur einmal in Runtime und Interreter, egal ob er nun über CreateEdit(... oder Create("Edit",... aufgerufen wird. Zum zweiten: Ab Version 8 wird die alte Variante nicht mehr in der Dokumentation auftauchen und in der Runtime nicht mehr vorhanden sein, ABER sowohl der Interpreter und der Compiler werden den alten Code noch verstehen und automatisch umsetzen. Kompatibilität zu alten Versionen war mir immer ein wichtiges Anliegen, da ja kaum ein Programmierer wegen einer neuen Version seiner Sprache alle Programme umschreiben möchte! Einschnitte in der Kompatibilität werde ich nur da machen, wo es wirklich einen Geschwindigkeitsvorteil bedeuten würde oder aus anderen Gründen technisch notwendig ist. So habe ich es auch - hoffe ich - in der Vergangenheit gehalten.
Rene Wagner
| Datum:26.05.01 19:04 (apollo@rw-net.de) |
Dann hätten wir das also auch geklärt. ;-) Spricht ja nix dagegen, dass man der Compiler das noch versteht und umsetzt. Wenn ich das richtig sehe, wird also auch der Textmodus weiterhin beibehalten werden, oder?
Roland G. Hülsmann
| Datum:27.05.01 14:20 (rgh-soft@t-online.de) |
>> Wenn ich das richtig sehe, wird also auch der Textmodus weiterhin beibehalten werden, oder? Ja. Gerade für Umsteiger von DOS basiertem BASIC (z.B. QBasic) ist dieser Modus eine große Hilfe. In Version 7 wurden eigens auf Wünschen vieler Anwender noch einige Funktionen dafür aufgenommen. Ich werde aber für Version 8 etwas experimentieren, um herauszubekommen, ob evtl. das Abschalten des Textmodus in bestimmten Situationen Geschwindigkeitsvorteile bringt. Aber ich vermute fast, daß dem nicht so ist.
Rene Wagner
| Datum:27.05.01 19:39 (apollo@rw-net.de) |
Ja, ok, seh ich ein. Mir geht´s aber vorrangig eher um die Grösse der Runtime. Bei Profan 6.6 lag man da afaik noch bei ~270 kB, was ich als sehr akzeptabel ansehe, jetzt sind´s schon ~350, dazu jeweils noch der kompilierte Quelltext. Wenn dann noch die neuen FTP-Funktionen etc. hinzukommen, haben wir bald die Grösse der VB-Runtime-DLLs. ;-)
Roland G. Hülsmann
| Datum:29.05.01 18:22 (rgh-soft@t-online.de) |
Ich denke die Runtime-DLLs von VB haben einen Vorsprung, den ich mit PROFAN kaum einholen kann. In der Tat bedeutet FTP aber eine Zunahme, aber ich denke und hoffe, ich werde mit PROFAN noch lange unter 500 kB bleiben. Ein PROFAN-Programm wird auch künftig noch auf eine Diskette passen, auch wenn die Diskette als Datenträger kaum mehr eine Rolle spielt.
Stefan Schnell
| Datum:07.06.01 00:01 (mail@stschnell.de) |
Hallo Community, ich wünsche mir eigentlich gar keine Funktionsreduzierung um die grösse der Runtime gering zu halten, wäre es nicht eher ein Ansatz dass nur die Routinen im EXE-Programm eingebunden werden, die durch das Programm verwendet werden (meine eine dynamische Compilierung). Also z. B. wenn einer PRINT in sein Programm einbaut wird PRINT eingebunden, wenn PRINT nicht verwendet wird, dann findet für diese Routine auch keine Einbindung statt; Fazit das EXE-Programm wird relativ klein. Nächtliche Grüsse Stefan Schnell
Norbert Spörl
| Datum:07.06.01 21:20 (NSp_ware@t-online.de) |
Hallo, wegen des Anwachsens der Runtimegröße von Profanversion zu Profanversion hatte ich vor einiger Zeit folgenden Gedanken. Es wäre toll, wenn so eine Art Bibliothekskonzept umgesetzt werden könnte. Für die Exe-Erstellung müßte dann im Quellcode angegeben werden, ob z.B. die Dantenbankbefehle, die Multimediabefehle oder Textmodusbefehle und Funktionen eingebunden werden sollen oder nicht. D.h. also, daß das Runtimemodul nicht immer identisch ist. Es wird je nach Bedürfnis der einzubindenen Bibliotheken aus einer "Grundruntime" und "Runtimesplittern", die die Bibliotheken enthalten, vor der Exe-Erstellung zusammengebaut. Das stelle ich mir so vor, daß die Runtimeteile zu einer Datei gelinkt werden und über Patch-Technik die internen Verbindungen hergestellt werden. Ich verstehe von diesen Technicken nicht viel. Entschuldigt bitte, wenn es Blödsinn war. Falls so etwas nicht machbar ist, gibt es evtl. die Möglichkeit verschiedene Runtimemodule mit unterschiedlichem Funktionsumfang und damit mit verschiedener Speichergröße im Profanpaket anzubieten. Mt der Größe der Runtime (Version 7.0) kann ich noch gut leben. Aber für die Zukunft wäre ein Bibliothekskonzept wirklich nicht schlecht. An dieser Stelle möchte ich mich für den Erhalt der Textmodusfunktionalität aussprechen. Norbert
Rene Wagner
| Datum: 11.06.01 16:09 (apollo@rw-net.de) |
Ich weiss nicht, inwieweit das technisch möglich ist, aber die Idee klingt schonmal gut. :) Noch was anderes: Wie sieht es denn eigentlich mit den dBase-Funktionen aus? Das kann ja auch per ODBC geschehen, sind die dBase-Befehle da noch nötig?
Stefan Schnell
| Datum:06.06.01 23:53 (mail@stschnell.de) |
Hallo Community, ich wünsche mir, das der Textmodus erhalten bleibt. Sehr oft verwende ich gerade diesen Modus für das Monitoring. Mir würde da echt was fehlen, bitte einfach um Berücksichtigung. Tschüss Stefan Schnell

| Zurück zur Übersicht

| Ein kostenloses WebMart Forum WebMart Homepage Tools kostenlos |