Hallo Leute. Ich bin in der 9. Klasse und wir programmieren gerade mit Delphi (manchmal mit Lazarus), d.h. ich habe wenig Erfahrung mit Delphi
Unser Lehrer hat uns jetzt ein "Projekt" aufgegeben, in dem wir ein Programm nach unserem Belieben schreiben sollen (Ich mache eine interaktive Geschichte ). Ich will z.B. bei Programmstart einen Sound abspielen lassen. Hab im Internet auch schon diesen Programmcode gefunden

markieren

Code:

sndPlaySound(PChar('C:\Users\Filip\Documents\Schule\Physik und Technik\Physik und Technik\PT-Projekt\Programm\Modem.wav'),SND_ASYNC);

aber damit habe ich gehörig Probleme. Es scheint, der Programmcode an sich ist richtig, aber irgendetwas stimmt mit dem Dateipfad nicht, weil ich immer ein "Fehlerbeep" bekomme. Hab außerdem im Internet was von dem Code gehört:

markieren

Code:

ExtractFilePath(Application.Exename)

dieser ist aber kompliziert und ich verstehe ihn irgendwie nicht.
Würde mich über Antworten freuen
MfG Filip

Dir ist doch bestimmt aufgefallen, daß sndPlaySound eine Funktion ist?

Und Funktionsrückgabewerte sollte man auch auswerten, vorallem wenn es Probleme gibt.


Außerdem sollte man sich die Dokumentation der entsprechenden Funktion ruhig mal ansehn.

Zitat von MSDN: sndPlaySound:

Return value

Returns TRUE if successful or FALSE otherwise.

Remarks

If the specified sound cannot be found, sndPlaySound plays the system default sound. If there is no system default entry in the registry or WIN.INI file, or if the default sound cannot be found, the function makes no sound and returns FALSE.

Und siehe da, schon weißt du, warum ein anderer Ton zu hören ist.



ExtractFilePath(Application.Exename) oder ExtractFilePath(ParamStr(0)) sind recht einfach zu verstehen, aber dafür schau dir diesen Code in seinen Einzelteilen an.

Application.Exename oder ParamStr(0) geben den Pfad der eigenen EXE an.
Man glaubt es kaum, aber auch Delphi und Lazarus haben ein Hilfesystem, wo sowas drinsteht, so wie auch für ExtractFilePath.

Das Ganze gibt also den Pfad (das Verzeichnis) zurück, worin auch die EXE liegt.

Danke für deine Antwort.
Muss man für den

markieren

Code:

ExtractFilePath(Application.Exename)

Code das Projekt zu einer .exe komprimieren oder geht das auch so?

Kennst du eventuell den Unterschied, zwischen nativen Programmen und Scripten?

Nativer Delphi Quellcode wird über einen Compiler in eine EXE, DLL oder Dergleichen umgewandelt.
Das Programm ist die EXE.
Der Quellcode ist für das laufende Programm vollkommen unwichtig.

JavaScript wird über einen Interpreter ausgeführt.


Du mußt also deinen Code kompilieren und eine EXE draus machen.
Ohne läuft da garnichts. (PascalScript-Interpreter ausgeschlossen)

Zitat von Windowscratcher:

Muss man für den

markieren

Code:

ExtractFilePath(Application.Exename)

Code das Projekt zu einer .exe komprimieren oder geht das auch so?

Bei Delphi mußt du immer das Programm zur Exe kompilieren, Delphi ist kein Interpreter wie z. B. das alte Basic. Aber keine Angst, geht sehr schnell.

Was ExtractFilePath(Application.Exename) angeht, ist das gleiche wie ExtractFilePath(ParamStr(0)) (das eine kopiert den wert beim anderen ab), so ergibt sich hier der Pfad zu deinem Programm, inc. abschließendem "\" Backslash. Du brauchst nur noch den Namen (inc. Endung) von deiner Sounddatei. Wenn die Sounddateien in einem Unterordner sind, z. B. "Sounds", dann den Ordner dazugeben ExtractFilePath(ParamStr(0)) + 'Sounds\' . Zuletzt:

ExtractFilePath(ParamStr(0)) + 'Sounds\' + 'MySound.wav'

Danke nochmal für die Antworten.

@himitsu Also könnte ich das nicht mitten beim Programmieren "testen" ?

@Popov Ich habe den Sound in meinem Projektordner und hab jetzt mal den Code ausprobiert, aber ich bekomme die Fehlermeldung "Error: Illegal Expression" (bei Lazarus). Wird das erst mit der .exe-Kompilierung funktionieren, also kann man das nicht "testen"?

PS: Sorry, dass ich mich so dumm anstelle, bin sehr neu mit Delphi und habe sonst so gut wie keine Programmiererfahrung. Also tut mir leid, wenn ich euch auf die Nerven gehe

DELPHI kannst Du auch im DEBUGGER (FEHLERSUCHER MODUS) ausführen, mit F8 und F7 kannst Du jede einzelne Programmzeile ausführen und feststellen wo Dein Programm kracht.

Wenn das Programm macht was es soll erstellst du eine *.exe , die kann dann jeder ausführen. Der Nutzer Deiner Software braucht dann kein Delphi auf seinem Computer


DELPHI, C++, ... verwenden einen Compiler -> Vorteil Ausführungsgeschwindigkeit

JAVA -> Interpreter -> langsame Programme

Zitat von bernhard_LA:

DELPHI kannst Du auch im DEBUGGER (FEHLERSUCHER MODUS) ausführen, mit F8 und F7 kannst Du jede einzelne Programmzeile ausführen und feststellen wo Dein Programm kracht.

Wenn das Programm macht was es soll erstellst du eine *.exe , die kann dann jeder ausführen. Der Nutzer Deiner Software braucht dann kein Delphi auf seinem Computer

Wobei Delphi (die IDE) auch dort schon eine EXE erstellt, aber via F7 und Co. wird diese dabei über automatisch über den Compiler erstellt, danach sofort gestartet und der Debugger hängt sich in das laufende Programm rein, um es debuggen zu können.

Diese EXE kann man auch direkt weitergeben, ohne es nochmals erneut zu kompilieren.

Anbei als Anlage ein kleines funktionierendes Beispiel (Quellcode mit Sounds).

Um mal ein wenig aufzuräumen:

Wenn du, Windowscratcher, dein Programm aus Delphi oder Lazarus heraus startest, verhält es sich weitestgehend genau so, als würde man die .exe die daraus resultiert alleine starten. Heisst, zumindest was dich so weit angeht: Was aus Delphi/Lazarus heraus nicht funktioniert, wird auch mit der .exe allein nicht klappen und umgekehrt.

Grund: Delphi und Lazarus erstellen immer eine .exe, auch wenn man sein Programm aus der Entwicklungsumgebung heraus startet. Der einzige Unterschied ist, dass sich diese Umgebung nach dem Start der .exe in deren Ablauf überwachend "einhängt" (das ist das, was oben "Debugger" genannt wurde), was es ermöglicht den Programmfluss auf Wunsch zu beobachten (F7/F8 und andere) (und in gewissen Grenzen zu beeinflussen).
Fazit ist: Wenn du im Code etwas änderst und das Programm neu startest, sind die Änderungen schon berücksichtigt. Nur dann, wenn das Programm schon gestartet ist - DANN haben Änderungen im Code keine Auswirkungen auf das noch laufende Programm. Das müsste man also erst beenden/abbrechen und neu starten.

Den Vorgang, aus deinem Pascal-Code eine .exe (Abkürzung für "Executable" = "Ausführbare [Datei]") zu machen nennt sich "kompilieren" (=in etwa "zusammenstellen"), nicht "komprimieren" (="zusammenstauchen"). Letzteres wäre das, was ZIP und andere Programme ihrer Art machen: Auf geschickte Weise Daten so verändern, dass sie ohne Informationsverlust weniger Speicherplatz brauchen. Das sind zwei sehr sehr verschiedene Dinge, weswegen dort die Wortwahl ggf. auch mal entscheidender sein könnte als hier. (Hier war aus dem Kontext gut ableitbar, was du eigentlich meintest.) Hat nichts mit dem Thema an sich zu tun, aber ich fühlte mich nach "sag das mal"

Folgendes ist für dich, Windowscratcher, eher uninteressant, daher darfst du gerne jetzt aussteigen:
@bernhard_LA: Das ist grober Unfug.

Zitat:

DELPHI, C++, ... verwenden einen Compiler -> Vorteil Ausführungsgeschwindigkeit
JAVA -> Interpreter -> langsame Programme

Java erzeugt Bytecode, welcher von der JRE zunächst zumindest weitestgehend in nativen Code kompiliert wird. Die Zeiten in denen Java wirklich langsamer war sind schon fast eine Dekade vorbei. Das macht die Sprache nicht schöner, aber sie ist in Sachen Geschwindigkeit mittlerweile maximal in sehr wenigen, sehr sehr speziellen Bereichen und Anwendungen weniger "gut", so dass man im Alltag problemlos von Gleichwertig sprechen darf. Selbiges gilt übrigens auch für .NET.
Solltest du JavaScript meinen: Das ist ein komplett anderes Pferd, dass so dann auch beim vollen Namen genannt werden müsste. Und selbst dort gehen schon einige Browser (und andere Hosts) so weit, dass sie zumindest Teilkompilate erstellen.

Zitat:

Wenn das Programm macht was es soll erstellst du eine *.exe , die kann dann jeder ausführen. Der Nutzer Deiner Software braucht dann kein Delphi auf seinem Computer

Das ist zwar jetzt niggelich, aber "es kommt drauf an": Mit Laufzeitpackages kompiliert? Diese mit ausgeliefert? Andere Abhängigkeiten (DLLs, ActiveX, OLE, etc.pp.)? Soll heissen: Ja, meistens stimmt die Aussage, aber sie ist so nicht ganz allgemeingültig.

So polemisch angehauchte und viel zu undifferenzierte Aussagen halte ich gerade gegenüber Einsteigern für sehr problematisch.