XProfan

- Seite 1 -

H.Brill

Hast du den Befehl ProgEnd auch im Quelltext angegeben
und dann auf der Konsole mit Copy /b ... Daten hinzu gefügt ?

Dieser Befehl stammt ja noch aus der Not heraus, als Profan
noch keine Ressourcen unterstützte und ersparte somit einen
Ressource-Editor, wie den ResHacker. War nur gedacht, um
kleine Texte usw. einzubinden.

Mittlerweile braucht man diesen Befehl nicht mehr und ist nur
wegen der Kompatibilität drin.

Aber hier scheint es sich ja offensichtlich um ein Ressourcenproblem
zu handeln (Res.Res). XProfan fügt ja ab X4 die Runtime als Ressource
dazu. Wenn dein Quelltext abwärtskompatibel zu X3 ist, würde ich
mal in X3 compilieren und schauen, ob der Fehler dort auch kommt.

Wenn mit deinen Ressourcen alles in Ordnung ist (Lesen/Schreiben),
müßte Roland mal schauen. Da es ja auch nur in großen Programmen
bzw. Quelltexten vorkommt, könnte es sein, daß Roland irgendeinen
Speicherbereich zu knapp bemessen hat.

Die beiden Fehlermeldung sind für mich logisch. Der erste kommt, um die
Runtime als Ressource dazu zu linken und der zweite, wenn die Ressource
Res.res dazu kommt, ist dann auch logisch. Es ist anzunehmen, daß zuerst
die im Quelltext vorkommenden Ressourcen und dann zuletzt die Runtime als
Ressource dazu gelinkt werden.

Du kannst auch mal versuchen, deine Ressource mit dem ResHacker in die
Prfrun32.exe zu integrieren und in deinem Programm halt nur die Ressource
laden. Kommt dann auch der/die Fehler ?

Es scheint so, daß da nur Roland der Sache auf den Grund gehen kann.

Benutze XPROFAN X3 + FREEPROFAN
Wir sind die XProfaner.
Sie werden von uns assimiliert.
Widerstand ist zwecklos!
Wir werden alle ihre Funktionen und Algorithmen den unseren hinzufügen.

Was die Borg können, können wir schon lange.

Sven
Bader

Danke für die Antwort! ich habe eine Vermutung, werde das noch verifizieren. Ich hab im Runtimemodul Icons ausgetauscht, die etwas größer sind, eventuell liegt es daran. Den Progend Befehl verwende ich nicht.

Grüße
Sven

H.Brill

Das dürfte eigentlich unproblematisch sein. Man kann ja auch
noch mehrere Icons, Bitmaps usw. hinzu fügen. Da wird halt
die Runtime etwas größer. Die Ressourcen selber werden ja
mit ihrem Namen bzw. einer Zahl abgerufen.

Ich denke da eher an riesige Programmcodes. Es ist meistens
so, daß man im allgemeinen so an 50 - 300 Zeilen hat. Meine
kleinen Programme, die ich mir erstelle, kommen meist an die
50 - 100 Zeilen. Wieviele Zeilen hat denn deines ?

Darum ist der Bug wahrscheinlich auch keinem aufgefallen,
weil die Quellcodegröße nicht groß war. Kürze doch mal dein
Programm auf das Nötigste und versuche dann mal neu zu
compilieren. Die Ressourcen natürlich beibehalten. Evtl. finden
wir da eine Richtung, wo der Fehler zu suchen ist.
Und wie gesagt, ab X4 dröselt Roland die Teile (.PRC, Runtime
usw. ) anders zusammen.

Sven
Bader

Nun habe ich etwas getestet und beziehe mich erstmal nur auf die Fehlermeldung "Compilat kann nicht hinzugefügt werden"

Wenn ich in der fertigen EXE Ressourcen hinzufüge, lässt sich das Programm irgendwann nicht mehr ausführen, das war schon immer so. Mit der PRFRUN32.EXE gab es bisher nie Probleme. Das konnte ich aber nun auch ausschließen, es geht auch mit der unveränderten originalen prfrun32.exe nicht.

Auch den Editor konnte ich ausschließen, mit dem "alten" Editor für X4 passiert es auch. "Programm erzeugen" ging in mehreren Versuchen nicht. Compilieren geht immer, das saparete Linken klappte im 2. (!) Versuch.

Das hinzufügen der Resourcen Datei klappt gefühlt erst beim 50. Versuch, nach der oben genannten Fehlermeldung mit dem ProgEnd gibts auch noch eine Zugriffsverletzung:

Die Ressource ist übrigens ein einzelne 32 Bit Bitmap mit einer Toolbar mit 40Kb Größe. Das Programm ist meine Version des Xprofed mit ca. 5.000 Zeilen (+ die Header Dateien von ca. 15.000 Zeilen)

Ich compiliere eigentlich ausschließlich mit Profan2CPP, nur wenn es wegen neuer nicht änderbarer Syntax nicht geht weiche ich auf X4 aus.

unbenannt-1.png	7 kB

Hochgeladen:	07.09.2021

Ladeanzahl:
		Herunterladen

H.Brill

Donnerwetter, 5.000 Zeilen + 15.000 Zeilen Headerdateien
Ein solcher riesiger Code ist schon gewaltig. Sowas kommt
ja höchst selten vor. Das ist auch der Grund, weshalb das
noch niemand vorher gemerkt hat.

Eine Toolbar dürfte nun ja überhaupt keine Probleme machen.
Überschreibst du die originale Toolbar32 oder fügst du deine
hinzu ? Und außergewöhnlich groß, gegenüber den Integrierten,
ist sie ja auch nicht.

Und mit was fügst du die Ressource ein ?
Mit XProfan - Befehlen oder vor dem Erzeugen mit z.B. dem
ResHacker in die Prfrun32.exe ?

Da es aber auch mit der originalen Prfrun32.exe nicht funktioniert,
gehe ich mal davon aus, daß es etwas mit der Umstellung des
Compilers bei Version X4 zu tun hat. Am besten schreibst du mal
in Paules Forum, Abteilung XProfan bei den Bugs. Dort liest Roland
häufiger mit.

Kompilieren Markieren Separieren

Sven
Bader

Danke für die Antwort. Ich forsche selbst noch ein bisschen.

Die Ressource kommt über den Programmcode über die $RES Direktive rein, die gibt es seit X3, in meinem Beispiel liest es sich etwas komisch

Die Datei selbst habe ich mit dem Ressource Hacker erstellt. Ich verwende einen abweichenden Namen für die Ressource.

 $RES RES.RES

Und nochmal: manchmal (selten) funktioniert es einfach!

Ich werde es ggf. nochmal mit dem unverbasteltem XProfed Code probieren, X3 habe ich leider nicht.

Die Größe der Header Dateien ist übrigens nichts besonderes, allein die windows.ph hat schon 11.000 Zeilen. Ich glaube davon landet gar nichts in der EXE, da es sich ja im Grunde nur um eine Übersetzungstabelle handelt und auch beim Compilieren nicht mitgezählt wird.

5.000 Zeilen finde ich für ein ernsthaftes Projekt nicht viel, man muss hier im Code für Übersicht sorgen aber den Compiler sollte es nicht stören. Die meistens Limits sind in Profan 9.0 schon gefallen (u.A. mehr als 64k Zeilen).

H.Brill

Sven Bader (07.09.2021)

Ich werde es ggf. nochmal mit dem unverbasteltem XProfed Code probieren, X3 habe ich leider nicht.

Vielleicht könntest du mal mit FreeProfan probieren. Gibt es hier im Forum
zu laden. Bis auf das WebControl und ein paar kleine Sachen ist das ja
kompatibel zu X3.
Außerdem gibt es auch noch eine 64-Bit Version von FreeProfan.
Benutze ich auch gerne, wenn meine Anwender auf eine 64Bit Version
bestehen.

Sven
Bader

Nachdem es mit FreeProfan (32 Bit, X3.1 basierend) mehrfach sauber durchlief, ging es in X4 jetzt auch wieder mehrfach. Nach einem Systemneustart wohlgemerkt, davor lief es reibungslos wenn der Code in einem Ordner auf dem Desktop lag aber nicht auf einem anderen Laufwerk. Ich höre jetzt auf zu "forschen", werde Roland dennoch mal ansprechen, er weiß ja dann in etwa wo er gucken muss, auch wenn er es nicht reproduziert bekommt.

- Seite 2 -

E.T.

Hatte so ein Verhalten auch schon mal (allerdings ohne Res.).
Compilieren immer, Linken nur manchmal.
Schuld daran war, das nach Compilieren > Linken > Ausführen (zum Test) die .exe noch lief (im Taskmanager sichtbar), ohne das noch ein zugeh. Fenster da war.
Dann kann das linken ja nicht klappen, weil Zieldatei vorhanden und geöffnet.

Vlt. hilfts als weiterer Ansatzpunkt ...

XProfan 11
Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

08.09.2021 ▲

Sven
Bader

Das spielt zumindest mit hinein, nur das es eben nicht im Taskmanager sichtbar war, eventuell aber noch von einem abgestürzten Compiler verwendet.

Ich baue mal eine Abfrage in den XProfed ein, die vor dem Compilieren prüft, ob die Datei verwendet wird.

08.09.2021 ▲

H.Brill

Habs jetzt auch mal ausprobiert.
Die erzeugte .exe gestartet und in die Taskleiste gelegt.
Dann im Editor Programm erzeugen gewählt.
Bei mir kommt dann aber nur eine Fehlermeldung mit :

Programm kann nicht erzeugt werden.

was ja auch richtig ist. Natürlich kann auch das
verwirrend sein. In meinem Falle wußte ich ja, daß ich
vorher die .exe gestartet habe.

08.09.2021 ▲