Voraussetzungen
 |
- Delphi 4 oder höher (Delphi 5 empfohlen)
- Installierte TAPI Komponenten (Compilerschalter siehe
Installationsanleitung ! - TAPI 1.4
empfohlen !)
- Windows 9x oder höher bzw. NT ab Version 4
- Für Delphi 4 wird Version 2.0.1 der Komponenten benötigen !
Die folgenden Ausführungen beziehen sich auf
die aktuelle Version 2.0.1 Beta 3 !
|
| Unterschiede zu TAssistedTAPI Demo |
Wenn sie sich unsere Demo zur Komponente
TAssistedTAPI angeschaut
haben, haben sie sicher festgestellt, dass sie keinerlei Kontrolle über
den erzeugten Anruf hatten. Das soll nun anders werden.
In unserem Formular benötigen wir ein Editierfeld, welches die zu
wählende Telefonnummer entgegen nimmt und mindestens zwei
Schaltflächen eine zum Wählen die andere zum Auflegen. Fügen Sie nun
eine TTAPILineService
Komponente hinzu. |
| TTAPILineService |
Sollten sie TAPI 2.x verwenden, können sie
die Eigenschaft
InitOptions ihren Bedürfnissen anpassen.
Mögliche Werte:
ieoUseHiddenWindow - Die Benachrichtigung über Ereignisse erfolgt über
eine Callback Funktion.
ieoUseEvent - Die Benachrichtigung über Ereignisse erfolgt über einen
separaten Thread !.
ieoUseCompetionPort - nur der
Vollständigkeit halber vorhanden und sollte nicht verwendet werden.
Die Eigenschaft Event enthält das Handle des CopletionPorts bzw. Events.
Unter Windows 98 sollten sie ieoUseHiddenWindow verwenden. Die
Eigenschaft HiVerApp (größte von der Anwendung unterstützte API Version)
sollte gleich der in TAPI.INC eingestellten Version sein, was der
Voreinstellung entspricht. Zur Eigenschaft LoVerApp (Kleinste von der
Anwendung unterstützte Version) lesen sie bitte die Seite
Versionsvereinbarungen. Unter Windows 2000
wurden keine Probleme festgestellt, wenn HiVerApp="$00020002" und
LoVerApp="$00010004" eingestellt wurde. Ggf. ist hier einwenig
experimentieren angesagt ! |
| TTAPILineDevice |
Fügen wir nun die Komponente TTAPILineDevice
ein. Weisen sie der Eigenschaft Service die zuvor erstellte
TTAPILineService Komponente zu. Wenn sie die Komponentensammlung vor
Version 2.0.1 verwenden, sollten sie nun die Eigenschaft StateMessages
konfigurieren. Es handelt sich hier um Statusereignisse des Gerätes an
der ihre Anwendung interessiert ist, standardmäßig sind alle Nachrichten
deaktiviert. In späteren Versionen der Komponenten wird diese
Eigenschaft nur noch public sein, und automatisch durch Zuweisung der
entsprechenden Ereignisbehandlungsroutine gesetzt.
Im Debug - Modus ab der Version 2.0.1 Beta 2 ({$IFDEF DEBUG})
werden grundsätzlich alle Nachrichten aktiviert .
Die Eigenschaft ID identifiziert das zu verwendende Leitungsgerät. Wenn
Sie nur ein Modem installiert haben lassen den Wert auf 0 (das erste
Leitungsgerät). |
| TTAPILine - TTAPIAddress |
Nachdem sie TAPILine in ihr Formular
eingefügt haben, weisen sie Device einen Wert zu. Da wir Anrufe vom Type
"Interactive Voce" tätigen wollen setzen die Eigenschaft CallPrivilege
auf [cpMonitor]. Es handelt sich hier um ein berühmt berüchtigtes
Problem, welches gerade Einsteiger fast zum Verzweifeln bringt. Wir
wollten doch Anrufe erzeugen und warum wählen wir überwachen ? Die
Spezifikation von TAPI sieht nur vor, wer einen Anruf erzeugt, ist auch
sein Eigentümer.
Wir benötigen noch eine Zieladresse, deshalb fügen sie
noch eine TTAPIAddress Komponente ein und verknüpfen die Eigenschaft
Line mit der soeben erstellten TTAPILine. Nun fehlt noch der eigentliche
Anruf, also TTAPICall. Dieser wird entweder der Eigenschaft ActiveCall
(vor 2.0.1) oder OutBoundCall zugewiesen. Zur Eigenschaft
TTAPIAddress.StateMessages , soweit vorhanden gilt das Gleiche wie für
TTAPILineDevice. Wenn Sie die Beta 2 Version 2.0.1 verwenden, benötigen
Sie noch die Komponente TCallParams. |
| Zwielichtige Komponente TTAPIAddress |
| Es wird ihnen sicherlich merkwürdig
vorkommen, dass sie in der TTAPIAddress Komponente keine Einstellungen
durchführen müssen, oder ? Ein Anruf ist die Verbindung mindestens
zweier Adressen, einer lokalen und einer entfernten Adresse. Die
in der Eigenschaft CallParams festgelegte AddressID entspricht der
eigenen lokalen Adresse. TTAPIAddress.ID ist nur bei ankommenden Anrufen
von Bedeutung. An dieser Problematik wird noch gearbeitet.
|
| Ereignissbehandlungsroutinen |
Erzeugen sie nun die
Ereignisbehandlungsroutinen des Formulars :
procedure TDial1.FormCreate(Sender: TObject);
begin
TAPILineService1.Active:=True; // Aktiviere Serviceprovider
TAPILine1.Active:=True; // Öffne Leitung
Edit1.Text:=TAPIAddress1.Address;
end;
procedure TDial1.FormDestroy(Sender: TObject);
begin
TAPILine1.Active:=False; //Schlisse Leitung
TAPILineService1.Active:=False; // Service beenden
end;
procedure TDial1.Edit1Change(Sender: TObject);
begin
TAPIAddress1.Address:=Edit1.Text;
end;
procedure TDial1.Button1Click(Sender: TObject);
begin
TAPIAddress1.MakeCall;
end;
procedure TDial1.Button2Click(Sender: TObject);
begin
TAPICall1.Drop;
end; |
| Andere Ereignisse |
Da wir auch alle Ressourcen wieder freigeben
müssen, benötigen wir noch eine Information wann dies geschehen soll.
Wenn ein Anruf in den Status "IDLE" wechselt (Es gibt keinen Anruf) ,
müssen wir die Ressourcen freigeben.
procedure TDial1.TAPICall1StateIdle(Sender: TObject; Rights:
TLineCallPrivilege);
begin
// Solange die folgende Funktion nicht aufgerufen wird, ist ggf.
kein weiterer Anruf möglich!
TAPICall1.DeallocateCall;
end;
Des Weiteren besteht die Möglichkeit, dass das Gerät nicht verfügbar
ist, weil es z.B. Ausgeschaltet wurde.
procedure TDial1.TAPILine1Close(Sender: TObject);
begin
MessageDLg('Leitung Geschlossen',mtInformation,[mbOK],0);
end; |
| |
| |
