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
 AutorThema: Sonstiges:
Thorsten
Datum:23.05.01 19:57 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken  


Dann lieber createbutton( .... ).

Dann läßt sich pRFellow weiter nutzen.

Bis dann


Rene Wagner
Datum:26.05.01 09:02 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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 Antwortenals Email verschicken (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
Shortwin - denn Glück ist kein Zufall!