XProfan

- Page 1 -

Nico
Madysa

Lies dir den kursiven Teil des ersten Postings durch.
Es wird nur das in den fertigen Quelltext übertragen, was tatsächlich verwendet wird.
Wär vielleicht auch was per die controls.inc .
Nicht jeder verwendet alle Controls, und da initialisiert man per Testata-Aufruf nur die, die man wirklich will.
Da machst du z.B. alle Prozeduren zu ProgressBars in un Zeile und das definierst du dann meinetwegen als init_progressbars
Und wenn dann jemand progressbars verwenden will, muss er nicht noch CustomListBoxen, TrackBars und schieß-mich-tot-was-noch einbinden sondern ruft in seinem Programm irgendwo einfach auf:
~init_progressbars

Und dann hat er in seinem Programm ausschließlich die ProgressBar-Prozeduren.

capisce?

Nico Madysa

Jac
de
Lad

Aso, das ist naturalmente wieder viel interessanter...hm, ist ne Überlegung wert...

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

Nico
Madysa

Argh, Problem!!
Wie es scheint, gibt es einen bisher unbemerkten Bug bei Headern.
Es sieht so aus, als ob Profan leicht verwirrt tut, wenn im einzusetzenden Text ein = vorkommt, z.B.
Kompilieren Markieren Separieren

proc_IntToStruct = proc IntToStruct:parameters s#,i%:Word s#,0 = i%:endproc;
proc_dgbBox = proc dbgBox:parameters text$:MessageBox(text$,"Debug-Meldung",4144):endproc

Wenn dann danach noch eine Definition kommt, scheint es zu krachen.
Er erkennt ~proc_dbgBox nicht mehr

Nico Madysa

Jac
de
Lad

2 Probleme:

1. Wie übergibst du Parameter?
2. Die Headerdefinition wird immer reinkopiert, das potuto sehr grande programme zur Folge haben...

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

11.11.2006 ▲

Nico
Madysa

Nein, du ruft die Dinger wie normale Prozeduren auf, da die aus dem Testata nur reinkopiert werden.
Alles funktioniert wie normale Incs, mit dem Unterschied, dass man die Procs, die man nutzen will nennen muss
(wie oben im Beispiel ~proc_dbgBox ). Dadurch wird nur das reinkopiert, was auch verwendet wird. Nix weiter.
Höchstens, dass Interpreten vielleicht etwas länger dauert, weil Profan.exe erst im Testata nachsehen muss (einmal pro genutzte Prozedur).
Aber was ist mit dem =-Problem? Könnte Roland oder ein Anderer etwas Aufklärung betreiben? Normalerweise geht der einzusetzende Text doch bis zu einem Semikolon, oder?

Nico Madysa

14.11.2006 ▲

Michael
Wodrich

Ganz einfach:

Hier wird wahrscheinlich SubStr$ benutzt. Trennzeichen ist das Gleichheitszeichen.
Substr$(headerzeile$,1,=) ergibt die Kennung (linker Teil)
Substr$(headerzeile$,2,=) ergibt den Rest (rechter Teil)
(wenn kein weiteres = vorkommt)

Ich kann mich übrigens nicht mit Deiner Idee anfreunden, dann will ich lieber die DEF Funktionen behalten!!!
(Bandwurm-Prozeduren - wer soll die denn pflegen?)

Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

Torsten
Rümker

Das ganze hat aber schon seine Interessanten seiten wie ich finde.

Momentan habe ich es z.b. so das ich eine Funktionen.inc habe in der so ziemlich alles an Schnipseln (ups Proceduren) drin ist die ich öfter verwende.
Wenn ich dann soweit bin, das ich meine jetzt ist mein Programm fertig, fange ich an eine neue Inc zu erstellen in der halt nur die tatsächlich benötigten Funktionen drin sind.
Das würde dann mit Nicos einfall naturalmente wegfallen, da bei einer Testata File ja nur genommmen wird was auch genutzt wird.
MfG
Torsten

Ich lerne, ob ich will oder nicht!
Betriebssystem:
- Ubuntu 15.x
- Windows (diverse)
XProfan Version: X2

- Page 2 -

Eigendlich gehts doch nur darum nur-genutzte-Procs einzubinden. Das wird XPSE bald so tun. Wie er es bei den Headerfiles ja auch schon macht.

Nico
Madysa

@Wod: Es potrebbe nicht schwer fallen, ein kleines Programm zu schreiben, welches eine inc in einen Testata verwandelt(Chr$(13) -> Doppelpunkt, usw.)
Wenn halt nur nicht die Sache mit dem = wäre...

@iF: Mag sein, aber... nunja, ich habe den XPSE bereits getestet und wirklich begeistert war ich nicht...
Wär halt cool, wenn auch nicht-XPSE-Nutzer sowas in der Art hätten...

Wenn Roland doch nur auch mal was zu dem =-Problem sagen würde...
(Ihr seht schon, die Sache wurmt mich merklich

)

Nico Madysa

Also es gibt kein = - Problem. Headerfiles sind Konstantendefinitionen - was Du da abverlangst ist unpassend.

Weshalb Du vom XPSE nicht begeistert wars kann ich nicht nachvollziehen. Gibt es hierfür einen tatsächlichen Grund? XPSE bringt keine Nachteile - woher also die fehlende Begeisterung?

Nico
Madysa

Naja, ich nummeriers mal:
1. Das Konsolenfenster vor jedem Start fand ich unschön (ich fang einfach mal mit dem banalsten Grund an)
2. Resultiert aus 1. Da meine Programme, im Gegensatz zum, sagen mir mal, XProfan-Manager eher kleiner sind, kommt mir das Kompilieren sogar noch länger vor
3. XPSE findet Fehler in meinen Codes, die keine sind (Thread.Do nicht deklariert z.B.)
4. Ein Teil der Funktion mag per Leute, die an Delphi gewöhnt sind, toll sein, aber mir gefällt XProfan gerade ohne diese besser (weswegen sie mir nichts bringen)
5. Geht dir wahrscheinlich nicht so, aber ich find XPSE-Codes, wie {$PREFEREDNAMESPACE} oder hWnd ohne % einfach unübersichtlich/unästhetisch.

Das dürften die Hauptgtründe sein. XPSE bleibt vorsichtshalber aufm Rechner. Aber dauerhaft nutzen werd ichs garantiert nicht.

Nico Madysa

Naja Deine Antwort beweist eigendlich nur mal wieder das die Fehler nicht am XPSE liegen - eher beim Betrachter.

Ich nehme mal Deine Nummerierung:

1. Kompiler sollten immer im Konsolenfenster ablaufen um den output grabben zu können - das hat was mit guten IDEs zu tun, naja Du weist es halt nicht besser. Das Programm ist zweckgebunden - ein Konsolenfenster ist an der Stelle absolut richtig. Kaum Ressourcen, keine Bilderchen etc.etc.
2. Das das Kompilieren Dir länger vorkommt obwohl es deutlich weniger Zeit in Anspruch nimmt - dazu kann man nichts sagen

3. XPSE finded keine Fehler in Deinen Codes welche keine sind. Wenn XPSE Dich auf Fehler hinweist das sind es auch Fehler. XPSE kann nix per Deine Codes

XPSE meckert auch nicht circa die Thread.Do! Sei denn - Du bist nicht UpToDate was XPSE und Unit betrifft! Dafür kann XPSE aber auch nichts - Du musst sicherstellen UpToDate zu sein, andernfalls musst Du den Ball flach halten und darfst nicht so tun als wenn ein XPSE-Fehler vorliegt obwohl der Fehler bei Dir liegt.
4. Die Funktionen von denen Du redest sind optional. Was Du sagst macht keinen Sinn zumal Dich XPSE nicht zwingt diese zu nutzen. Punkt 4 ist also auch Humbug.
5. Wie Du XPSE-Codes findest , in denen XPSEMöglichkeiten genutzt sind - welche aber nicht zwingend sind - tut auch zum XPSE selbst nichts zur Sache. Wieder nur Humbug.

Wenn Du XPSE nicht nutzen willst ist doch ok, mag halt nicht jeder auf die eigenen Fehler hingewiesen werden - dafür habe ich doch Verständnis.

(Thread.Do nicht deklariert z.B.) ist keine XPSE Fehlermeldung.