Delphi Sounds Problem

[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 von Windowscratcher:

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

[Dalai]

Zitat von Windowscratcher:

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 von Windowscratcher:

@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 (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