Problema con TAdTerminal de los Async 4 Prof.

[AGAG4]

http://sourceforge.net/projects/tpapro/
Uso D7

Buen día estoy haciendo un pequeño programa que recibira las llamadas tomadas por un conmutador, tome el ejemplo que vienen junto con los Apro y funciona muy bien, el programa recibe todas las llamadas, pero el problema que tengo es que no encuentro como guardar en un archivo de texto las llamadas recibidas, en la propiedad CaptureFile le pongo c:\Recibe.ap ó c:\Recibe.txt y al abrirlo no hay nada, y probe con la propiedad Capture los siguientes valores (cmAppend,cmOn,cmOff)

Agradezco cualquier comentario al respecto

[[egostar]]

Prueba con este código

Código Delphi [-]
procedure TForm1.FormShow(Sender: TObject);
begin
  ApdComPort1.Open    := True;
  AdTerminal1.Capture  := cmAppend; // Importante
  AdTerminal1.Active    := True;
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  AdTerminal1.Active := False;
  ApdComPort1.Open   := False;
end;

El problema que le veo es que solo podrás abrirlo hasta que cierras la AdTerminal, ya que abre el archivo de forma no compartida.

Debes de asignar la propiedad Capture en cmAppend de otra forma cada vez que abras la AdTerminal te va a crear un nuevo archivo y esto lo debes hacer por código no en tiempo de diseño.

Salud OS.

[AGAG4]

Gracias EgoStar por su pronta respuesta, voy a probarlo.
Que tengas buen día.

[AGAG4]

Ya hice la prueba EgoStar asi como me la planteo por codigo le meti las lineas

Código Delphi [-]
Capture := cmAppend ;

Y no puedo abrir el archivo que crea cuando recibe la llamada, tengo que cerrar el programa para poder ver el contenido del archivo, de plano no se puede abrir el archivo, porque lo que quiero es leer el archivo grabar los datos de la llamada(s) en una Base de datos firebird y borrar el contenido del archivo, no hay otro componente igual que el TapdTerminal pero que deje accesar el archivo ????

[[Al González]]

¡Hola Alfredo!

Gusto en saludarte. Me parece muy interesante tu caso. No me sorprende que Eliseo sepa de esos componentes.

En lo personal, me tocó manejar un par de componentes de TurboPower Async Professional hace tiempo. Aún recuerdo el día en que un contacto en el mensajero me lanzó la noticia "¿Qué crees? ¡Han liberado los TurboPower!" (yo ni los conocía entonces ). Empezaba la cultura del Open Source.

Bueno, pero la razón principal de mi intervención es sugerirte una solución que podría ser viable. No sin antes preguntarte si te sirvió cerrar temporalmente el TAdTerminal en tiempo de ejecución cada vez que deseas leer el archivo, como de alguna manera ya lo sugiere Eliseo.

La alternativa: En algún lugar del código fuente, estará seguramente la sentencia o grupo de sentencias que se encargan de guardar cada una de las llamadas en el archivo. Creo que podrías echarte un clavado en dicho código fuente para ver de qué manera puedes interceptar ese momento. Quizá haya un evento o método virtual que puedas aprovechar, o ya de plano modificar el código fuente del componente.

Inténtalo por ese lado y si tienes alguna dificultad, no dejes de comentarnos.

Un abrazo conmutado.

Al González.

[AGAG4]

Gracias Alberto, tambien es un gusto saludarlo por este rumbo, ya lo había pensado en cerrar la terminal y volverla abrir, pero mi temor es que cuando este cerrada la terminal y en el comutador envia otra llamada se pierda dicha llamada, espero que no pase eso, porque por lo que he leido el que se encarga de recibir la llamada es el componente ApdComPort y de mostrarla es el TAdTerminal, ya si no es por alli, a espurgar el fuente de los APRO , bueno voy a continuar con las pruebas, yo les platico como me fue.

Gracias por su respuesta Al.

[AGAG4]

Como se podrá simular que llegue una llamada a la TApdTerminal ????
Como las pruebas reales las tengo que hacer con el cable del conmutador conectado a la pc, ahorita no cuento con eso porque no estoy con el cliente, pero me gustaría hacer las pruebas sin estar con el cliente, si alguien sabe como emular algo por el estilo solo para hacer pruebas con el archivo que genera el TApdTerminal, para que me permita Visualizarlo y Editarlo.

Agradezco cualquier sugerencia.

[[Al González]]

Creo que tengo copia del código fuente de esos componentes. Trataré de darme un espacio de tiempo para revisarlo en las próximas 24 horas.

Saludos.

[[egostar]]

Hola Alfredo,

Mira, lo que yo hago para almacenar la cadena que me llegue a través de ApdComPort es usar el componente ApdDataPacket y configurarlo para que reciba la cadena del equipo al que se conecta, solo necesitas saber el comienzo y el final de la cadena, lo mas común es que el comienzo sea scAnyString y el final #10#13 o #13#10. Algunos equipos tienen un protocolo que te facilita mas la identificación del paquete, por ejemplo INICIO = #2 (StartofText) y FIN #3 (EndofText).

Una vez que se recibe el paquete, yo la grabo en un archivo de texto con código y no uso el AdTerminal.

algo asi:

Código Delphi [-]
procedure TLector.ApdDataPacket1StringPacket(Sender: TObject;
  Data: String);
begin
  AssignFile(Archivo,'recibe.txt');
  if FileExists('recibe.txt') then
     Append(Archivo)
  else Rewrite(Archivo);
  Writeln(Archivo,Data);
  CloseFile(Archivo);
end;

Solo una anotación: Yo proceso las cadenas recibidas en tiempo real, es decir, una vez que la tengo el paquete disparo los procesos correspondientes y sólo grabo la cadena en un archivo para tener un registro de los eventos.

Salud OS.

[[egostar]]

Empezado por AGAG4

Como se podrá simular que llegue una llamada a la TApdTerminal ????
Como las pruebas reales las tengo que hacer con el cable del conmutador conectado a la pc, ahorita no cuento con eso porque no estoy con el cliente, pero me gustaría hacer las pruebas sin estar con el cliente, si alguien sabe como emular algo por el estilo solo para hacer pruebas con el archivo que genera el TApdTerminal, para que me permita Visualizarlo y Editarlo.

Agradezco cualquier sugerencia.

Pues yo te recomiendo esto, ve con tu cliente, graba el archivo con hiperterminal, por ejemplo deja que lo recibas unas dos horas (o mas), después con un cable null modem conecta dos puertos seriales de tu maquina para que hagas un "candado" entre los puertos seriales (o con dos maquinas) y ya podrías hacer las pruebas que quieras.

Eso es lo más práctico, mi laptop no tiene puertos seriales pero con dos USB-DB9 se resuelve el problema y no son caros, en cualquier steren, (incluso los he visto en Wallmart) los puedes comprar y no son caros.

Salud OS.

[[egostar]]

Empezado por Al González

Gusto en saludarte. Me parece muy interesante tu caso. No me sorprende que Eliseo sepa de esos componentes.

Hola Al.

Todo se lo debo a mi manager.....

Salud OS históricos, como lo dirías tú.

[AGAG4]

Gracias EgoStar y Al gonzalez, voy hacer pruebas !!!!

Un saludo tAPD_EMPAQUETADO

[[egostar]]

Muy bien, comentanos tus resultados, sin embargo yo te recomiendo ampliamente usar el componente ApdDataPacket, me parece lo mejor.

Salud OS.

[AGAG4]

Ya realize las pruebas, me fue más ó menos, primero hice pruebas con el componente apdDataPacket no me funciono, no entra nunca al evento ApdDataPacket1StringPacket, por lo que me fui con la siguiente prueba que fue cachar el buffer en el evento OnTriggerAvail del componente apdComPort, haciendo un intervalo de tiempo de 2 segundos en cada llamada para que la cadena quedara en una sola linea, no se si sea lo más adecuado pero logre cachar la llamada.

Lo que se me hizo raro es que no me funcionara el componente apdDataPacket, lo tengo enlazado al apdComPort, tengo la propiedad AutoEnables = true y Enabled = True, y al hacer una llamada no entra a ninguno de los 3 eventos que tiene, le meti un ShowMessage('Hola') para hacer la prueba, uso los Apro 4.06

Gracias por sus sugerencias.

[[egostar]]

Vamos por partes amigo Alfredo.

El componente ApdDatacket requiere que se configuren las siguientes propiedades para que funcione correctamente.

EndCondition = [ecString]

EndString = Depende que te llegue del PBX, pero lo normal el #10#13 que al momento de dar enter te va a poner ^J^M, si no, puede ser #13#10 o su equivalente ^M^J

StartCond = scAnyData

StartString = vacio

Usa el evento OnStringPacket para que leas lo que recibe como ya te lo mostre en un mensaje previo, Data es el string que deberá contener la cadena que recibes.

Nota: Si me dices que PBX estas usando o si puedes postear el archivo que recibiste del PBX te puedo configurar correctamente el componente.

Salud OS.

[AGAG4]

Te soy sincero no se que sea el PBX, pero te paso los 2 archivos que recibí del conmutador....
Estos los recibí del componente ApdComPort en el evento OnTriggerAvail.

Dentro de dicho evento tengo el siguiente código:

//Con Sleep
....
var
i : integer;
c : Char ;
Lista : TStringList;
begin

for i := 1 to Count do
begin
c:= ApdComPort1.GetChar;
cadena := cadena + c;
end;

Sleep(2000);
try
Lista := TStringList.Create;
if FileExists('C:\TELConSleep.TXT') then
Lista.LoadFromFile('C:\TELConSleep.TXT');

//Agregamos Línea
Lista.Add(Cadena);

Lista.SaveToFile('C:\TELConSleep.TXT');
finally
Cadena:='';
Lista.Free;
end;
end;

[[egostar]]

Empezado por AGAG4

Te soy sincero no se que sea el PBX, pero te paso los 2 archivos que recibí del conmutador....
Estos los recibí del componente ApdComPort en el evento OnTriggerAvail.

Haber amigo Alfredo, trata con esto.

EndCondition = [ecString]
EndString = #13#10 que se verá así: ^M^J
StartCond = scString
StartString = C

En el evento OnStringPacket pon esto:

Código Delphi [-]
procedure TForm1.ApdDataPacket1StringPacket(Sender: TObject; Data: String);
begin
  Memo1.Lines.Add(Data);
end;

Con eso creo que debe funcionar correctamente.

Salud OS.

[AGAG4]

Gracias EgoStar, voy hacer pruebas, que tengas buen día.!!!!

[[Al González]]

¡Hola a todos!

Alfredo:

Le eché un vistazo al código fuente del componente. Veo que es en el método mensaje TAdCustomTerminal.ApwTermStuff donde se hace el guardado al archivo:

Código Delphi [-]
procedure TAdCustomTerminal.ApwTermStuff(var Msg : TMessage);
var
  DataLen  : integer;
  DataPtr  : pointer;
  PaintRgn : HRGN;
begin
  {this message is sent by the tmTriggerAvail, and the WriteChar/
   WriteString methods; note that if there are two or more
   APW_TERMSTUFF messages in the message queue, the first one to be
   accepted will clear the byte queue, so the others need to take
   account of the fact that there may be no data}

  DataLen := TaaByteQueue(FByteQueue).Count;
  if (DataLen > 0) then begin
    DataPtr := TaaByteQueue(FByteQueue).Peek(DataLen);

    {if we are capturing, save the data to file}
    if (Capture = cmOn) then begin
      if (FCaptureStream <> nil) then
        FCaptureStream.Write(DataPtr^, DataLen);
    end;
...

FCaptureStream.Write(DataPtr^, DataLen);


Al observar este código, lo primero que se me ocurrió fue que podría crearse un componente derivado TAGAGAdTerminal, agregando un evento OnCapture (que sinceramente extraño que no venga ya incluido). Esto con el objetivo de acceder al campo FByteQueue o al campo FCaptureStream, pero desgraciadamente tanto uno como el otro están declarados en la sección privada de la clase TAdCustomTerminal (hace tiempo que evito usar secciones Private; suele resultar algo desalentador a otros programadores bibliotecarios cuando desean crear clases derivadas).

Aún así, la solución es viable. Podrías derivar una nueva clase de componente, redefiniendo el método mensaje ApwTermStuff, pero tendrías que agregarla en la misma unidad (ADTrmEmu.pas) para acceder "decentemente" al campo privado FByteQueue.

Una solución más fácil es modificar directamente el código de ese método y leer la variable DataPtr para el propósito buscado.

TAdCustomTerminal.ApwTermStuff ofrece una ventana a la solución, pero es muy probable que, examinando el código con mayor detalle, encontremos alternativas. ¿Cómo ven la situación? ¿Por dónde nos vamos?

Un abrazo terminal.

Al González.

[[egostar]]

Empezado por Al González

Al observar este código, lo primero que se me ocurrió fue que podría crearse un componente derivado TAGAGAdTerminal, agregando un evento OnCapture (que sinceramente extraño que no venga ya incluido). Esto con el objetivo de acceder al campo FByteQueue o al campo FCaptureStream, pero desgraciadamente tanto uno como el otro están declarados en la sección privada de la clase TAdCustomTerminal (hace tiempo que evito usar secciones Private; suele resultar algo desalentador a otros programadores bibliotecarios cuando desean crear clases derivadas).

Aún así, la solución es viable. Podrías derivar una nueva clase de componente, redefiniendo el método mensaje ApwTermStuff, pero tendrías que agregarla en la misma unidad (ADTrmEmu.pas) para acceder "decentemente" al campo privado FByteQueue.

Una solución más fácil es modificar directamente el código de ese método y leer la variable DataPtr para el propósito buscado.

TAdCustomTerminal.ApwTermStuff ofrece una ventana a la solución, pero es muy probable que, examinando el código con mayor detalle, encontremos alternativas. ¿Cómo ven la situación? ¿Por dónde nos vamos?

Un abrazo terminal.

Al González.

Bueno, bueno, como que eso escapa a mi conocimiento, pero se me ha ocurrido que eso me resolvería un problema que traigo rezagado y que no le he metido mano por falta de elementos.

Gracias por el dato Alberto.

Salud OS recordatorios....