Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi mciSendString - Aufnahme schließen (https://www.delphipraxis.net/87758-mcisendstring-aufnahme-schliessen.html)

TheMiller 5. Mär 2007 19:37


mciSendString - Aufnahme schließen
 
Hallo,

ich habe mit Hilfe des Tuts aus der DP und den mciSendString-Befehlen recht erfolgreich Audiodaten aufgenommen und in mp3 codiert. Nach dem Speichern der wav-Datei habe ich folgenden String gesendet:

Delphi-Quellcode:
mciSendString('CLOSE mySound',nil,0,Handle);
So steht's ja auch im Tut. Doch wenn ich jetzt ein anderes Form öffne, kommt eine Zugriffsverletzung. Dieses Form greift auf eine DLL und ein Dyn. Array zu. Doch diese Zugriffverletzung kommt nur NACH der Aufnahme. Vorher passt alles!

Ich hab mir gedacht, was das Eine mit dem Anderen zu tun hat, aber ich habe einfach mal die komplette Audio-Sache rausgelassen und siehe da - es funzt prima.

Ich habe EXAKT die Zeilen aus dem TUT übernommen. Liegt das jetzt an meinem Array (ich habe es immer mit [arrayname]:=nil geleert, als ich nicht mehr gebraucht habe) leigen? Oder kann es an der AudioAufnahme liegen?

Danke im Voraus!

turboPASCAL 5. Mär 2007 22:43

Re: mciSendString - Aufnahme schließen
 
Welches Tut., wie schaut denn der Quelltext aus?

TheMiller 5. Mär 2007 23:03

Re: mciSendString - Aufnahme schließen
 
Also, mein "Aufnahme - Anhören - Speichern"-Code sieht so aus: Ist natürlich über 3 Button verteilt (Aufnahme, Anhören und Speichern.

Delphi-Quellcode:
  mciSendString('OPEN NEW TYPE WAVEAUDIO ALIAS meineWav',nil,0,Handle);
  mciSendString('SET meineWav ' +
                   'TIME FORMAT MS ' + 
                   'BITSPERSAMPLE 16 ' +
                   'CHANNELS 2 ' + 
                   'SAMPLESPERSEC 44100 ' + 
                   'BYTESPERSEC 176400 ' + 
                   'ALIGNMENT 4',
                   nil,0,handle);
  mciSendString('RECORD meineWav',nil,0,Handle);
  mciSendString('STOP meineWav',nil,0,Handle);
  mciSendString(PChar('SAVE meineWav "'+Filename+'"'), nil,0,Handle);
  mciSendString('CLOSE meineWav',nil,0,Handle);
  mciSendString(PChar('close ' + "'+Filename+'"'), nil, 0, 0);
Bevor ich auch nur einen mciString sende, habe ich getestet, ob die anderen Programmfunktionen funktionieren. Das ist der Fall. Öffne ich jetzt zb meineWav, nehme auf und speichere, dann bricht das Programm beim Aufruf einer anderen Form zusammen. Diese wiederum benutzt 4 Funktionen aus einer DLL, die nach dem Benutzer von mciSendString auch nicht mehr funktionieren. Das schöne daran ist, dass die 4 Funktionen genau das selbe beinhalten, wie eine andere Form aus diesem Projekt, welche ganz normal arbeitet - nur eben die DLL nicht mehr. Dabei haben die DLLs überhaupt nichts mit Ton o.Ä zu tun. Da besteht KEINERLEI Zusammenhang.

Deshalb dachte ich, dass es so sein muss. Ich lade die DLL statisch und sie belegen Speicher. Ich greife drauf zu - alles paletti. Ich öffne dann ein MCI-Gerät (mciSendString('OPEN....')) und der überschreibt(?) den belegten Speicher der DLLs. Wenn ich jetzt wieder auf die DLL zugreifen will, gibt er mir eine Zugriffsverletzung. Die eine Unit im Hauptprogramm hat aber die gleichen Funktionen, wie die DLL - funktionieren aber richtig. Vielleicht, weil dess Speicher nicht überschrieben wurde?

Ich bin jedenfalls erstmal ratlos und bitte um HILFE!! :wall:

Bye und danke

turboPASCAL 5. Mär 2007 23:10

Re: mciSendString - Aufnahme schließen
 
:gruebel:

Wie lädst du die Dll und kann das u. U mit dem Wandeln zu mp3 zusammenhängen ?

TheMiller 5. Mär 2007 23:25

Re: mciSendString - Aufnahme schließen
 
Die DLL lade ich statisch (stdcall; external '...dll')

Das wandeln in mp3 hat damit nix zu tun, da ich diese Funktion schon rausgenommen habe. Das Problem bestand immernoch. Doch als ich den oben geposteten Code rausgenommen habe, hat alles Funktioniert, wie es funktionieren sollte...

turboPASCAL 5. Mär 2007 23:38

Re: mciSendString - Aufnahme schließen
 
Habe die Brille jetzt ned auf, muss
Delphi-Quellcode:
mciSendString(PChar('close ' + "'+Filename+'"'), nil, 0, 0);
das nicht so
Delphi-Quellcode:
mciSendString(PChar('close "' + Filename + '"'), nil, 0, 0);
sein ?

TheMiller 6. Mär 2007 05:51

Re: mciSendString - Aufnahme schließen
 
Joa, kann sein dass ich mich da jetzt verschrieben habe, aber ich hatte vorher auch statische Namen wie "C:\rec.wav" und da hat es auch nicht funktioniert. Ich werd's heute mittag aber nochmal testen.

TheMiller 8. Mär 2007 01:54

Re: mciSendString - Aufnahme schließen
 
Ok, dieser Fehler besteht also immernoch. Ich habe folgendes Problem:

Ich habe eine DLL, die einen String, den ich aus dem Internet lade nach einem bestimmten Separator teilt und ein Array erstellt. Auf dieses Array greife ich von der Hauptanwendung über den Zeiger zu. Funktioniert immer prima (sogar FASTMM4 hat keine Leaks festgestellt (weder in der Anwendung noch in der DLL). Dazu habe ich auch noch in einer anderen eingebundenen DLL eine Form, die ich aufrufe (ich nenne sie jetzt mal DLLForm1). Sobald ich jetzt allerdings einen mciString gesendet habe und wie oben beschrieben ihn auch wieder geschlossen habe kommen Probleme mit den DLL-Forms. Und zwar wenn ich wieder auf sie zugreifen will kommen mehrere AVs (mit den gleichern Fehlermeldungen). Dies passiert nicht nur bei DLLForm1, sondern bei allen DLLForms. Das Hauptprogramm arbeitet korrekt weiter. Dabei ist es der DLLForm egal, wo sie zusammenbricht. Schon zB bei der Anweisung:

Delphi-Quellcode:
TreeView1.Items.Clear;
Was ist da denn los? Mit den Zeigern kann es ja nix zu tun haben. Die habe ich ja alle wieder freigegeben, auch richtige Typen benutzt. Vor allem funktionieren die ja richtig, auch ohne Lecks. Ich kann mir das nicht erklären.

Achja: Die FormDLLs sind dynamisch geladen und die reine Funktions-DLL ist statisch geladen.

Bitte um Hilfe!


Alle Zeitangaben in WEZ +1. Es ist jetzt 02:47 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz