Programm in sich neu starten (Differenz Debugger / Exe)

[Daffy0815]

Hallo Leute,

Folgendes Problem:

Ein Programm wird gestartet und dabei geprüft ob eine gültige Konfigurationsdatei vorhanden ist.
Falls nicht, so wird innerhalb des Programms auf den Programmteil verzweigt der die Erzeugung einer gültigen
Konfigurationsdatei ermöglicht. Ein Verlassen dieses Programmteils ohne das diese Datei erzeugt wird ist nicht möglich.

Die Sache sieht ungefähr so aus:

Code: Alles auswählen

Start:
;
Quit.i = #False
Restart.i = #False

Repeat
    ;
    ....
    ..... 
                Case #NumEinstellenSystemparameterWindow
                    GetSystemparameter()
                    SpeichernSystemparameter()
                    Restart.i = #True
                    Quit.i = #True
   ....
   ....
Until Quit.i = #True
;
If Restart.i = #True
    Goto Start
Else
    End 
EndIf

Nun das Problem:
Innerhalb der Oberfläche von PureBasic funktioniert das einwandfrei.
Will heißen, das Programm findet nun die gültige Konfigurationsdatei und startet normal.

Wird das Programm als Executable compiliert so wird das Programm beendet obwohl "Restart.i = #True" ist!

Weiß jemand warum das so ist oder kennt jemand einen besseren Weg?

Gruß

Daffy

[ullmann]

Mit so wenig Code kann man nur spekulieren.

Zuerst setzt du "Quit" und "Restart" auf #False. Dann erstellst du im Case-Zweig die Konfigurationsdatei und setzt "Quit" und "Restart"
auf #True. Damit wird bei Until die Schleife verlassen und bei If springst du mit Goto wieder zu Start.

Nun wird wieder "Quit" und "Restart" auf #False gesetzt. Nach Repeat ist die Konfigurationsdatei vorhanden und du gelangst nicht mehr
zu dem Case-Zweig. "Quit" und "Restart" verbleiben deshalb auf dem Wert #False.

Normalerweise müsste nun die Repeat-Until Schleife endlos durchlaufen werden. Da dieses Verhalten nicht so ist, setzt du vermutlich in
einem anderen Case-Zweig, den du hier nicht angegeben hast, oder irgendwo anders in der Repeat-Schleife den Wert "Quit" auf #True.

Damit wird bei Until die Schleife verlassen. Da "Restart" immer noch #False ist, verzweigt IF-Else zu dem Befehl End.

Wird das Programm als Executable compiliert so wird das Programm beendet obwohl "Restart.i = #True" ist!

Ich habe mal folgendes probiert:

Code: Alles auswählen

Restart.i = #False
Restart.i = #True
If Restart.i = #True
  MessageRequester("", "Wahr")
Else
  MessageRequester("", "Falsch")
EndIf
End

Das funktioniert auch als Exe korrekt (PB 4.51 32 Bit). Also liegt es nicht am If-Befehl und nicht an der Verwendung von boolschen
Konstanten. Kann es sein, wenn die Konfigurationsdatei schon existiert, dass dann "Restart" den Wert #False hat, da der Case-Zweig nicht
durchlaufen wird?

[GPI]

Das goto solltest du dir abgewöhnen....

Nimm entweder eine Schleife (repeat until) oder bau das ein bischen um:

Code: Alles auswählen

Procedure ReadConfig()
    if Config_gelesen
       procedurereturn #true 
    endif
    procedurereturn #false
endprocedure
procedure CreateConfig()
   if config_erzeugt
     procedurereturn #true
  endif
  procedurereturn #false
endprocedure

;Version1
if ReadConfig()=#false
  if CreateConfig()=#false
    messagerequester("titel","Configdatei konnte nicht gelesen oder erzeugt werden")
    end
  endif
endif

;Alternative
While Readconfig()=#false
  if CreateConfig()=#false
    messagerequester("titel","Configdatei konnte nicht gelesen oder erzeugt werden")
    end
  endif
wend 

Sprich mein Tip: Verteil dein Code auf mehrere Prozeduren und gib konsequent ein #True oder #False je nach erfolg zurück und frag das ab.
Damit behälst du den Überblick und ein versehentliches ändern von anderen Variablen vermeidest du damit auch.

Andere mögliche Probleme wären, das deine EXE in einen Schreibgeschützen Bereich schreiben will. Unter Vista/Win7 ist das Verzeichnis C:\Program Files\ schreibgeschützt und nur mittels Adminrechte zu bearbeiten. Vielleicht liegts daran?

[BSP]

Hallo Daffy0815

Wie ermittelst Du den Dateipfad Deiner Config- Datei?
Vieleicht mit "GetCurrentDirectory()" ?
Schreibe mal den Pfad komplett aus.

Gruß: BSP

[Falko]

Ich weiß jetzt nicht wie es sich bei IF .. Goto ... elesif ...Endif verhält.
Aber beim Select Case goto in einer anderen Selectschleife springen löst ein Stapelfehler aus.
Somit kommen bei X86 unvorhersehbare Variablenwerte raus,
was im englischen Forum vor kurzem gepostet wurde.

http://www.purebasic.fr/english/viewtop ... =4&t=47178

Beim X64 stürzt das Programm sogar ab.
Leider ist dieses Beispiel nicht vollständig.
Sonst hätte ich mal den gleichen versuch mit X64 probiert.

Laut freak wird die Hilfe für Goto schon mal geändert. Man hätte es ja auch so wie beim Gosub
machen können, das der Debugger sofort darauf reagiert, wenn man mit Goto aus Schleifen herausspringt.

Laut der Hilfe sollte man bei Goto ein Return ermöglichen. Dazu gibt es ein FakeReturn, was ähnlich wie
das Return beim Gosub hinter dem Goto zurückspringt. Somit werden wohl offene Schleifen abgearbeitet.

Ich hoffe das ich es so richtig erklären konnte, warum man das Goto dann lieber vermeiden sollte.

Gruß Falko

[Daffy0815]

@Ullmann

Tut mir leid, aber das Programm umfasst mittlerweile über 100000 Zeilen und es ist sehr schwierig da einen Teil heraus zu brechen der das Problem evt. anschaulicher gemacht hätte.

@GPI

Das mit dem "Goto" kommt auch nur an dieser Stelle vor und wäre auch die sinnvollste aller Lösungen gewesen.
Warum so viele Leute etwas gegen "Goto" haben wird sich mir als 75% Assemblerprogrammierer allerdings nie erschließen.
Da gibt es nur Jump's und Call's und auch damit kann man sehr übersichtliche Programme schreiben!
Jedenfalls übersichtlicher als so manche "Schachtelmonster" in C und Co.
Und natürlich ist mein Programm über Prozeduren verteilt das war doch nur ein Beispiel um das Problem zu veranschaulichen.

@BSP

Kann den Sinn deiner Frage nicht nachvollziehen. Was hat der Dateipfad mit dem nicht erfolgten Restart des Programms zu tun?
Die Konfigurationsdatei wird im Übrigen ja noch erzeugt. Was nicht funktioniert ist der Sprung zum Anfang des Programms im "EXE". In der IDE
funktioniert es einwandfrei!

@Falko

Ich habe das Problem mittlerweile durch eine weitere "Repeat-Schachtel" um fast das ganze Programm gelöst.
Das erklärt natürlich immer noch nicht warum es diese Differenz im Verhalten gibt. Mein Basic-Interpreter/Compiler für die SiLabs C8051F- und Dallas DS89CXXX-Microcontroller hat damit keine Probleme eine If/EndIf-Konstruktion via GoTo zu verlassen da ich diesem eine CLEAR S[tacks]-Anweisung "spendiert" habe.
Ich bin mir da nicht sicher ob in PureBasic auch ein einfaches "Zeilen-If" ohne EndIf so in der Art wie:
"IF <Bedingung> Then GoTo <Marke>
funktioniert.
Diese Konstruktion benötigt keinen Platz in einen "If-Stack" (zumindestens bei mir nicht).

[GPI]

Goto ist ein relikt, das man bei höheren Programmiersprachen nicht braucht. Es verursacht dort mehrere Probleme, wie bspw. Stack-Eintragungen die nicht zurückgesetzt werden können oder auch konflikte in Namensraum einzelner Teile. Eine entsprechende Kontrolle kst auch nahezu unmöglich.

Ein If-Goto geht ohne Probleme - if ist keine Schleife oder ähnliches - das Problem liegt da woanders.

Assembler kennt ja keine schleifen oder sowas wie in höheren Programmiersprachen. Es kennt auch keinen Gültigkeitsbereich von Variablen usw. Dagibts diese Probleme alle nicht.

Ich müßte dei Quellcode sehen, um eine bessere Möglichkeit zu finden. Viele Verschachtelungen kann man auch besser Lösen oder einfach Programmteile als Prozedur kennzeichnen.

Die Möglichkeit eigene Falten zu setzen, kennst du? Sorgt auch für viel Ordnung.

Eigentlich sollte am besten der Compiler eine Warnung bei der Verwendung bringen.

[BSP]

Hallo Daffy0815.

Ja, hast recht. War ne dumme Frage von mir.
Ich fragte nur deshalb, weil ich es schon hatte,
dass meine EXE die mit dem PB- Prg erzeugte Datei nicht wiedergefunden hat und deshalb falsch lief.
Aber wenn Deine EXE auch selber die Config erzeugt,
wird die EXE die auch wiederfinden.
Und Du hast Dir sicher auch die Anweisungen gebastelt,
die Dir in der EXE anzeigen, das Deine geforderten Rückgabewerte alle stimmen.
Der Debug aus dem PB funktioniert ja so nicht in der EXE.
Also, vergiss meine Frage. War ne dumme.

MfG: BSP

[Daffy0815]

@GPI

Na ja, die Diskussion über den Sinn und/oder Unsinn von Goto und Co. möchte ich hier nicht unbedingt anfachen!
Mich erstaunt nur immer wieder wieviel Mist von den hochbezahlten Informatikern mit all den "Glaubensgrundsätzen" zu diesem Thema
gebaut wird den ich mir als "dummer, kleiner" Elektronikentwickler im industriellen Bereich nie leisten dürfte.
Für mich ist die "Windows"-Programmierung nun mal ziemliches "Neuland" und ich vermisse schon einiges wie zum Beispiel "echte" Interrupts oder vernünftige Timer sprich meine gewohnte, echte ereignisgesteuerte Programmierung.

Was das mit dem "Falten" betrifft so habe ich das schon gesehen muss aber sagen, dass ich den Editor der IDE nicht verwende da er mir einerseits zu ungewohnt ist und andererseits nicht genug kann.
Ich benutze seit Jahren den Semware-Editor weil er den Vorteil hat eigentlich kein Editor ist sondern eine Programmiersprache mit dem Ziel einen Editor zu erzeugen. Mit dem Teil kann ein "Tastatur-Fan" so ziemlich alles machen was er will.
Falls ich mal Lust und Zeit habe (also nie ) werde ich mir mal so eine "Faltung" einbauen.

Gruß

Daffy

[Max_der_Held]

@Daffy0815

• Was der Bauer nicht kennt isst er nicht..
  Sag mal zu einem C++ Entwickler "Purebasic" oder gar "Java" (was syntaktisch fast wie c++ ist.. )

Zu obigem Problem:

• Wann immer eine EXE anders reagiert als in der IDE liegt es entweder an DEBUG befehlen oder am Pfad.. (oder woanders)
  
  BsP:

  debug starte_game()

  geht nur im debug Modus; in der EXE wird die ganze Zeile gelöscht.
  
  [Offtopic]
  Geil, ich hab gerade deinen Schreibtisch auf der HP angeschaut.. Ich hab die gleiche Quietscheente.. nur in Grün, kann blinken.. aber die gleiche Form...
  Btw. Oszi-habenwill-effekt bei Bild 2..
  [/Offtopic]

MfG

Max W. Aigner (Unter Einfluss einer langen Nacht)

PS: was macht ein 100.000 Zeilen programm bei Elektronik? RFM12? KI?