Delphi Sounds Problem

[Windowscratcher]

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 :D). Ich will z.B. bei Programmstart einen Sound abspielen lassen. Hab im Internet auch schon diesen Programmcode gefunden

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:

Code:

ExtractFilePath(Application.Exename)

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

[himitsu]

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

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


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

Zitat:

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. :roll:

Delphi-Quellcode:

ExtractFilePath(Application.Exename)

oder

Delphi-Quellcode:

ExtractFilePath(ParamStr(0))

sind recht einfach zu verstehen, aber dafür schau dir diesen Code in seinen Einzelteilen an.

Delphi-Quellcode:

Application.Exename

oder

Delphi-Quellcode:

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.

[Windowscratcher]

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

Code:

ExtractFilePath(Application.Exename)

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

[himitsu]

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. :zwinker: (PascalScript-Interpreter ausgeschlossen)

[Popov]

Zitat:

Zitat von Windowscratcher (Beitrag 1165728)

Muss man für den

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

Delphi-Quellcode:

ExtractFilePath(Application.Exename)

angeht, ist das gleiche wie

Delphi-Quellcode:

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

Delphi-Quellcode:

ExtractFilePath(ParamStr(0)) + 'Sounds\'

. Zuletzt:

Delphi-Quellcode:

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

[Windowscratcher]

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 :)

[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


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

JAVA -> Interpreter -> langsame Programme

[himitsu]

Zitat:

Zitat von bernhard_LA (Beitrag 1165737)

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.

[Popov]

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

[Medium]

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.

[Windowscratcher]

Ich weiß echt nicht, was ich falsch mache.
Ich hab mir grade den Anhang von @Popov runtergeladen. Hat alles geklappt. Nur wenn ich das mache, klappt es wieder nicht!
Hier mein Code:

Code:

unit Unit1; 

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs,
  Menus, ExtCtrls, ComCtrls, Buttons, StdCtrls, Unit2, mmSystem;

type

  { TForm1 }

  TForm1 = class(TForm)
    EndeBtn: TButton;
    OptionenBtn: TButton;
    StartenBtn: TButton;
    Panel1: TPanel;
    procedure EndeBtnClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure OptionenBtnClick(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end; 

var
  Form1: TForm1;


implementation

{$R *.lfm}

{ TForm1 }

procedure PlayMySound(SndName: String); //uses mmSystem
var
  FilePath: String;
begin
  FilePath := ExtractFilePath(ParamStr(0)) +'Musik\'  + SndName + '.wav';

  if FileExists(FilePath) then
    //SndPlaySound(PAnsiChar(FilePath), SND_ASYNC ); //Alternative
    PlaySound(PChar(FilePath), hInstance, SND_ASYNC or SND_FILENAME);
end;

procedure TForm1.FormCreate(Sender: TObject);

begin

end;

procedure TForm1.EndeBtnClick(Sender: TObject);
begin
  close;
end;

procedure TForm1.OptionenBtnClick(Sender: TObject);
begin
  Form2.ShowModal;
  PlayMySound('Modem');
end;

end.

Das komische ist, dass wenn ich bei "procedure PlayMySound" den Unterordner wegmache, höre ich nicht mal ein Fehlerton, sondern einfach nichts. In dem Beispiel wollte ich zum Test einen Ton für den Optionenbutton ertönen lassen. Ich will gar nicht wissen, wie das wird, wenn ich noch zusätzlich das Dokument dem Lehrer gebe, in dem ich alles erklären muss... -.-

PS: Danke für die zahlreichen Antworten! :)

[Cencil]

Zitat:

Zitat von Windowscratcher (Beitrag 1165906)

Das komische ist, dass wenn ich bei "procedure PlayMySound" den Unterordner wegmache, höre ich nicht mal ein Fehlerton, sondern einfach nichts. In dem Beispiel wollte ich zum Test einen Ton für den Optionenbutton ertönen lassen. Ich will gar nicht wissen, wie das wird, wenn ich noch zusätzlich das Dokument dem Lehrer gebe, in dem ich alles erklären muss... -.-

PS: Danke für die zahlreichen Antworten! :)

Liegt an dieser Zeile hier

Delphi-Quellcode:

if FileExists(FilePath) then

Die prüft ob die Datei überhaupt existiert, falls ja, wird PlaySound aufgerufen. Wenn du die Zeile entfernst, hast du deinen Fehler-Ton wieder. Wenn dann noch immer nur der Fehler-Ton erläutet solltest du evtl. nochmal den Pfad prüfen :wink:

[Dalai]

Zitat:

Zitat von Windowscratcher (Beitrag 1165906)

Das komische ist, dass wenn ich bei "procedure PlayMySound" den Unterordner wegmache, höre ich nicht mal ein Fehlerton, sondern einfach nichts.

Logisch, weil die Existenz der abzuspielenden Datei vorher geprüft wird - existiert sie nicht, wird gar nicht erst versucht, sie abzuspielen.

Zitat:

In dem Beispiel wollte ich zum Test einen Ton für den Optionenbutton ertönen lassen.

Vor dem modalen Anzeigen der Form2 den Sound abspielen lassen, ist notwendig, denn modales Anzeigen bedeutet, dass der Codefluss unterbrochen wird und erst nach dem Schließen des modalen Fensters fortgesetzt wird. Konkret auf deinen Code bezogen bedeutet das, dass PlayMySound erst ausgeführt wird, nachdem Form2.ShowModal fertig ist. Die Anweisungen auszutauschen, wäre daher schonmal eine gute Idee ;).

Falls der Sound aber auch dann nicht abgespielt wird, solltest du selber untersuchen, indem du sogenannte Breakpoints (in den deutschen Delphi- und Lazarus-Umgebungen heißen sie wohl Haltepunkte) setzt, also Punkte, an denen der Debugger die Ausführung des Programms anhält. Kommt der Debugger an einem solchen Punkt an, kann man mit F7 bzw. F8 die Anweisungen im Code Schritt für Schritt durchgehen und so sehen, welche Anweisungen ausgeführt werden und welche nicht. Diese Methode ist für die Fehlersuche unverzichtbar und insofern empfehle ich dringend, das möglichst schnell zu verinnerlichen.

MfG Dalai

[Windowscratcher]

@Dalai Hab mal den Debugger laufen lassen (F8) und der hat ganz normal compiliert. Dann hab ich F7 ausprobiert und dann haben sich ganz viele andere Units geöffnet. Ich bin überhaupt nicht zu meinen Programmcodes gekommen :?

[himitsu]

Tipp: Haltepunkt(e) dort setzen, wo es mit dem Debuggen losgehn soll.
Dann mit F9 beginnen und so lange mit F7/F8 weitermachen, bis man den Code durch hat. Oder mit F9 weiter bis zum nächsten Haltepunkt.

(es gibt auch noch mehr nützliche Tasten-Kombinationen)

[Dalai]

Zitat:

Zitat von Windowscratcher (Beitrag 1165916)

@Dalai Hab mal den Debugger laufen lassen (F8) und der hat ganz normal compiliert.

Natürlich hat er das, sofern keine Syntaxfehler drin sind.

Zitat:

Dann hab ich F7 ausprobiert und dann haben sich ganz viele andere Units geöffnet. Ich bin überhaupt nicht zu meinen Programmcodes gekommen :?

Deshalb der Hinweis auf die Haltepunkte. Der Sinn dahinter ist, Schritt für Schritt durch den Code zu gehen, aber alle unwichtigen Units außen vor zu lassen. Setz mal einen Haltepunkt in der Zeile 45 der Unit1 (

Delphi-Quellcode:

if FileExists()

), indem du auf die Zeilennummer in deinem Lazarus klickst. Dann wird die Zeile rot hinterlegt und wenn du nun dein Programm ganz normal (mit F9) ausführst, hält der Debugger an genau dieser Stelle an, wenn du auf den OptionenBtn klickst. Und erst jetzt kommt das F7 bzw. F8 zum Einsatz.

Ich hoffe, die Sache ist nun etwas klarer.

MfG Dalai


PS: Wobei mich etwas wundert, dass solche Grundlagen nicht schon vermittelt wurden, denn solch theoretische Sachen sollten vor dem Praxiseinsatz schon bekannt sein, um sinnvoll arbeiten zu können. Und dazu zähle ich auch die Kenntnis der Begrifflichkeiten wie "kompilieren" & Co aus dem früheren Verlauf der Diskussion.

[p80286]

oder ohne Haltepunkte, aber nur wenn man Geduld hat (oder neugierig ist)
F8 bis zu "Application.Run;"
dann
F7 und man ist in seinem Programm.

Gruß
K-H

[Windowscratcher]

Ich verstehe noch nicht ganz, was der bewirken soll.
Ich hab mal Zeile 40 markiert, und dann F9 gedrückt. Dann hat sich das Programm gestartet und danach hat das Programm wieder zur Unit gewechselt. Es hat als erstes "begin" grün markiert (falls es nicht grün ist, wisst ihr, dass ich eine Rot-Grün Sehschwäche hab :D), dann die nächste Zeile "FilePath := ....", dann wieder die nächste "if..." und dann hat es einfach alles bis zum nächstgelegenen "end" übersprungen und danach ist es zum "end" des OptionenBtn gegangen. Dann haben sich wieder die Unit-Fenster geöffnet...

[himitsu]

@p80286:

Ich weiß nicht wie es in Lazarus aussieht, aber
geh im Delphi mal in die Projektoptionen, aktiviere dort "Mit Debug-DCUs kompilieren" und nun schau was bei deinem F7 passiert. :stupid:
(alle Delphi-Versionen ala Standard, Personal, Starter und Trial sind davon ausgeschlossen)

Auch drittanbieter Units, welche mit Debiginfos kompiliert sind, machen diesbezüglich sehr viel Spaß.
(Eurekalog, DevExpress und Co. sind diesbezüglich der pure Horror)

In einigen älteren Delphis gibt es den spaß, daß alle beigelegten Indy-Units mit Debuginfos kompiliert wurden.
(obwohl eigentlich/theoretisch zwei Varianten bei lagen, aber leider waren auch die NonDebug-Dateien mit Debuginfos versehn :wall: )

[Dalai]

Und was verstehst du jetzt daran nicht? Das von dir beobachtete Verhalten ist der abgelaufene Codefluss oder Block von Anweisungen, die wirklich ausgeführt wurden. Hast du dich noch nicht gefragt, wie man feststellt, ob ein Programm die Anweisungen ausführt, die man sich im Kopf vorstellt? Genau dafür sind der Debugger und die Haltepunkte da (es gibt noch mehr Dinge, aber die sind weniger wichtig).

Im Konkreten hast du also festgestellt, dass Anweisungen übersprungen wurden, die deiner Meinung nach ausgeführt werden sollten. Nun weißt du, welche das sind und solltest untersuchen, warum das so ist. Am einfachsten ist es wohl, sich den Pfad der abzuspielenden Datei mal mittels ShowMessage anzeigen zu lassen und zu prüfen, ob's diese Datei wirklich gibt. In Codeform:

Delphi-Quellcode:

procedure PlayMySound(SndName: String); //uses mmSystem
var
  FilePath: String;
begin
  FilePath := ExtractFilePath(ParamStr(0)) +'Musik\' + SndName + '.wav';
  ShowMessage(FilePath); //<-- Diese Zeile hinzugefügt
  if FileExists(FilePath) then
    //SndPlaySound(PAnsiChar(FilePath), SND_ASYNC ); //Alternative
    PlaySound(PChar(FilePath), hInstance, SND_ASYNC or SND_FILENAME);
end;

MfG Dalai

[Windowscratcher]

@Dalai Okay, danke für die Erklärung :) Werde es mal gleich ausprobieren.

[Windowscratcher]

@Dalai Okay, hab den Code hinzugefügt und es passiert nichts neues. Würde das jetzt heißen, dass kein Pfad erstellt wird?

[Dalai]

Zitat:

Zitat von Windowscratcher (Beitrag 1165937)

@Dalai Okay, hab den Code hinzugefügt und es passiert nichts neues.

Das kann nicht sein. Die erzeugte Dialogbox mit dem Pfad der abzuspielenden Datei muss in jedem Fall auftauchen, völlig egal, ob letztere existiert.

Zitat:

Würde das jetzt heißen, dass kein Pfad erstellt wird?

Ein Pfad wird gar nicht erstellt. Es wird ein String zusammengebaut aus Einzelteilen und das Resultat benutzt.

MfG Dalai

[Windowscratcher]

Sollte das bei Programmstart angezeigt werden? Bei mir tut sich nichts... Kann ich das auch mit dem Befehl "Panel2.Caption:='...'" machen ?

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1165930)

@p80286:

Ich weiß nicht wie es in Lazarus aussieht, aber
geh im Delphi mal in die Projektoptionen, aktiviere dort "Mit Debug-DCUs kompilieren" und nun schau was bei deinem F7 passiert. :stupid:

Hab ich Blödsinn geschrieben?
Debug-DCUs hab ich nicht aber Linker: DCUs erzeugen reicht doch?

Ein Programm"start" mit F8 stept brav durch die DPR

Delphi-Quellcode:

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(TForm2, Form2);
  Application.Run;
end.

Sobald der Cursor in

Delphi-Quellcode:

Application.Run;

steht F7 und ich bin in meinem eigenen Geschreibsel.

?Lazarus? damit hab ich (noch) nichts am Hut.

Zitat:

Zitat von Windowscratcher (Beitrag 1165948)

Sollte das bei Programmstart angezeigt werden? Bei mir tut sich nichts... Kann ich das auch mit dem Befehl "Panel2.Caption:='...'" machen ?

Sobald der String mit dem Pfadnamen erstellt ist sollte ein Meldungsfenster aufgehen und den Pfadnamen anzeigen. Ist das nicht der Fall, wird PlayMySound nicht aufgerufen.

Gruß
K-H

[Windowscratcher]

@p80286: Ich find die Option nicht... Ich habe jetzt aber den Befehl "ShowMessage(FilePath) Mal VOR den "IF" Satz getan und siehe da: Er erscheint. Wenn er aber im IF Satz steht, passiert nichts. Was muss ich jetzt machen? :?

[BUG]

Bist du dir sicher, das der Pfad und die Datei wirklich existieren?
Was steht in der Message?

[Windowscratcher]

[Window Title]
project1

[Content]
C:\Users\Filip\Documents\Schule\Physik und Technik\Physik und Technik\PT-Projekt\Programm\Modem.wav

[OK]

@BUG Das steht in der Message. Eigentlich der Dateipfad, wo die Datei enthalten ist. Ich versteh es echt nicht...

[Dalai]

Zitat:

Zitat von Windowscratcher (Beitrag 1165952)

Ich habe jetzt aber den Befehl "ShowMessage(FilePath) Mal VOR den "IF" Satz getan und siehe da: Er erscheint. Wenn er aber im IF Satz steht, passiert nichts.

Ich hab den Code doch genau so gegeben. Die Anweisung ShowMessage steht vor der if-Bedingung. Insofern verstehe ich das Problem nicht.

Zitat:

[Window Title]
project1

[Content]
C:\Users\Filip\Documents\Schule\Physik und Technik\Physik und Technik\PT-Projekt\Programm\Modem.wav

[OK]

@BUG Das steht in der Message. Eigentlich der Dateipfad, wo die Datei enthalten ist. Ich versteh es echt nicht...

Ist das Verzeichnis "Physik und Technik" wirklich doppelt? Was passiert, wenn du genau diesen Pfad (ohne den Dateinamen Modem.wav) in die Adresszeile des Explorers kopierst und bestätigst?

MfG Dalai

[Windowscratcher]

@Dalai Der Dateipfad ist richtig, habs mit dem Explorer ausprobiert. Und sorry, dann hab ichs ausversehen nach dem IF Satz hingeschrieben :)

[Dalai]

Wenn der Pfad stimmt, stimmt der Dateiname nicht. Denn die FileExists-Funktion gibt ja nicht ohne Grund False zurück.

MfG Dalai

[Windowscratcher]

@Dalai Ich hab jetzt das hier mal ergänzt (zu Testzwecken)

Code:

procedure PlayMySound(SndName: String); //uses mmSystem
var
  FilePath: String;
begin
  FilePath := ExtractFilePath(ParamStr(0))   + SndName + '.wav';
   ShowMessage(FilePath);
  if FileExists(FilePath) then
      //SndPlaySound(PAnsiChar(FilePath), SND_ASYNC ); //Alternative
     PlaySound(PChar(FilePath), hInstance, SND_ASYNC or SND_FILENAME)
     else //SndPlaySound(PAnsiChar(FilePath), SND_ASYNC ); //Alternative
     PlaySound(PChar(FilePath), hInstance, SND_ASYNC or SND_FILENAME)
end;

Also wird der Befehl ausgeführt, auch wenn "FileExists(Filepath)" false ist. Ich weiß, ich hätte da auch einfach nur den Befehl hinschreiben können, aber ... ich weiß es selber nicht :D

Natürlich kommt der Fehlerton, wie erwartet.
Ich bin unter Windows 7 und da werden ja keine Dateiendungen angezeigt. Muss ich die Datei dann umbenennen und die Dateiendung hinzufügen?

[Dalai]

Zitat:

Zitat von Windowscratcher (Beitrag 1165962)

Ich bin unter Windows 7 und da werden ja keine Dateiendungen angezeigt. Muss ich die Datei dann umbenennen und die Dateiendung hinzufügen?

Lass dir die Dateiendungen anzeigen, alles andere ist Pfusch (verstehe eh nicht, warum MS diesen Unsinn seit Jahren vorgibt, der nur für Verwirrung sorgt und Angriffsflächen bietet). Systemsteuerung > Orderoptionen > Register "Ansicht" > Option "Erweiterungen bei bekannten Dateitypen ausblenden" deaktivieren.

MfG Dalai

[Windowscratcher]

Naja, klappt leider weiterhin nicht...
Mein Vater sagt (er war mal Programmierer, ist aber was länger her :D), der Dateipfad müsste nicht von "C:" aus starten, sondern vom Projektordner. Stimmt das?
Und wie verfahre ich jetzt mit dem Fehler? :? (Tut mir leid, dass ich Druck mache, aber ich habe nicht mehr viel Zeit :/ )

[Dalai]

Zitat:

Zitat von Windowscratcher (Beitrag 1165965)

Naja, klappt leider weiterhin nicht...

Zitat:

Mein Vater sagt [...], der Dateipfad müsste nicht von "C:" aus starten, sondern vom Projektordner. Stimmt das?

Nein. So wie der Pfad da steht, ist er ein absoluter Pfad. Und der Rückgabewert der Funktion FileExists deutet darauf hin, dass es diese Datei nicht gibt. Vom Projektordner aus wäre es ein relativer Pfad, mit denen man immer sehr vorsichtig umgehen muss, denn eine Relation hat immer einen Bezugspunkt.

Zitat:

Und wie verfahre ich jetzt mit dem Fehler?

Gibt es die Datei Modem.wav denn nun in dem angegebenen Verzeichnis, nachdem du die Dateierweiterungen anzeigen lässt? Nicht dass die Datei Modem.wav.wav heißt...

MfG Dalai

[Windowscratcher]

Die Datei existiert und heißt auch nicht Modem.wav.wav. Ich weiß echt nicht, wieso Lazarus so spinnt... Die Datei ist vorhanden, der Pfad ist auch richtig, aber irgendetwas will nicht...

[Dalai]

Mach mal Lazarus zu, öffne es wieder, lade dein Projekt und starte es via Menü Start > Alles neu kompilieren.

Ergänzung:
Gib mal unter Start > Ausführen folgendes ein (am besten den Kram kopieren):

Code:

"%ProgramFiles%\Windows Media Player\wmplayer.exe" "C:\Users\Filip\Documents\Schule\Physik und Technik\Physik und Technik\PT-Projekt\Programm\Modem.wav"

inkl. der Anführungszeichen. Wird die Datei gefunden und abgespielt?

MfG Dalai

[Windowscratcher]

Tut sich nichts, immer noch der Fehlerton...

[Dalai]

Siehe meine Ergänzung im vorigen Post.

[Windowscratcher]

Ja, wird abgespielt.