Problema con TAdTerminal de los Async 4 Prof.

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

[AGAG4]

Gracias EgoStar eso era lo que me faltaba en el apdDataPacket, configurar el caracter de inicio, ya puedo cachar la llamada, el unico y pequeño inconveniente que no veo problema es que me pone 1 renglon en blanco después de la llamada, pero eso se puede arreglar.

Gracias Al por el Tip, es muy bueno ....

Que tengan buen día....

[[Al González]]

¡Hola a todos!

Que bueno que lograste solucionarlo.

Empezado por AGAG4

...Gracias Al por el Tip, es muy bueno...

De nada, pero para la otra contesta el teléfono y cacha mi llamada. No te olvides de los cuates.

Un abrazo con salto
de línea.

Al González.

[[egostar]]

Me da mucho gusto que te haya servido, ahora viene lo bueno, tienes que tomar en cuenta muchas cosas, por ejemplo:

Listado de claves lada para identificar el destino de la llamada
Horarios de la llamada para saber si es con tarifa plena o reducida,
Si vas a considerar multi carriers (proveedores de LD o Local),
Tarifas de LD, celular 044, local, celular nacional 045,
Como vas a reportar la información, por extension, departamento, troncal,

en fin, no es poca cosa hacer un tarificador.

Te deseo suerte.

Salud OS.

[AGAG4]

Ahora el problema que tengo es que me encontre con otro Conmutador, este no me arroja ningun caracter de inicio , al principio me arroja la fecha (06/14/07) de la llamada, ahora en la propiedad StartString del apdDataPacked se lo quito pero ya no entra al evento OnStringPacket.

Sinceramente que raro que me pida caracteres este componente, porque ya habia visto un programa ( Hecho en Delphi ) usandose, similar al que estoy desarrollando, pero este programa en cualquier lugar donde lo instalas te funcionaba, lo unico que le configurabas era la velocidad,bit datos,bit parada, puerto, paridad y es todo y rápido recibia la llamada y te lo guardaba en un archivo de texto, por eso se me hace raro que en estos componentes le tenga que decir, este es el caracter de inicio y este el final, siendo que me voy a trompezar en estos casos de que el conmutador no te arroje el caracter de inicio ó final.

[[egostar]]

Empezado por AGAG4

Ahora el problema que tengo es que me encontre con otro Conmutador, este no me arroja ningun caracter de inicio , al principio me arroja la fecha (06/14/07) de la llamada, ahora en la propiedad StartString del apdDataPacked se lo quito pero ya no entra al evento OnStringPacket.

Sinceramente que raro que me pida caracteres este componente, porque ya habia visto un programa ( Hecho en Delphi ) usandose, similar al que estoy desarrollando, pero este programa en cualquier lugar donde lo instalas te funcionaba, lo unico que le configurabas era la velocidad,bit datos,bit parada, puerto, paridad y es todo y rápido recibia la llamada y te lo guardaba en un archivo de texto, por eso se me hace raro que en estos componentes le tenga que decir, este es el caracter de inicio y este el final, siendo que me voy a trompezar en estos casos de que el conmutador no te arroje el caracter de inicio ó final.

Hola Alfredo

Para esos casos entonces debes utilizar lo que ya te habia comentado en otra de las respuestas

EndCondition = [ecString]

EndString = #13#10 (^M^J)

StartCond = scAnyData

StartString = vacio

Y ya que veo que estas desarrollando un sistema para que se conecte a cualquier conmutador, te encontrarás casos mucho más complejos.

Salud OS.

[[egostar]]

Empezado por AGAG4

Sinceramente que raro que me pida caracteres este componente, porque ya habia visto un programa ( Hecho en Delphi ) usandose, similar al que estoy desarrollando, pero este programa en cualquier lugar donde lo instalas te funcionaba, lo unico que le configurabas era la velocidad,bit datos,bit parada, puerto, paridad y es todo y rápido recibia la llamada y te lo guardaba en un archivo de texto, por eso se me hace raro que en estos componentes le tenga que decir, este es el caracter de inicio y este el final, siendo que me voy a trompezar en estos casos de que el conmutador no te arroje el caracter de inicio ó final.

Pues yo si le veo ventajas y muchas, te explico, cuando estas leyendo un puerto serial sin este componente tienes que leer caracter por caracter y 'manualmente' debes hacer lo mismo ya que debes conocer donde comienza y donde termina un paquete de datos (que es precisamente lo que hace este componente), así que te evita por un lado estar pendiente de cachar los caracteres y por otro la definición de tu paquete de forma manual.

Pues nada, a mi me ha dado muy buenos resultados.

Salud OS.

[IVAND]

Yo capturo los datos tal como dice egoestar , pero el componente de monitoreo del componente async pro , me mueestra los datos que entra al sistema pero estos solo me trasmite a mi sistema (memo) solo 6 o maximo nueve veces luego deja de enviar el dato al memo , pero repito el componente de monitoreo sigue capturando el dato , ademas si me pueden guiar el dato de envia en espacio de 2 lineas

Gracias por su interes

[[egostar]]

Hola IVAND, puedes colocar el código que estas usando para la captura de los datos?, así te podremos ayudar mejor.

Salud OS