FiveTech Support Forums

Muchas gracias Leandro!!

Estaré atento a ver que publicas.

Yo lo hice funcionar de la siguiente manera:

hb_threadStart( HB_THREAD_INHERIT_PUBLIC, @MyFuncForThreads(),parametro1,parametro2,...)

Y luego para compilar reemplacé:

hbvm.lib x hbvmmt.lib

y

cw32.lib x cw32mt.lib

Sakudos!

Para el envío a Verifactu he utilizado threads en un solo ejecutable.

Todo el envío se gestiona desde el hilo correspondiente sin afectar al hilo principal.

Utilizo el sistema de mutex para notificar nuevos registros de alta del hilo principal al hilo correspondiente y que ejecute el envío.

Utilizo también mutex para bloquear el envío y no lanzar dos envíos si se crea un nuevo registro de alta mientras se está enviando

Utilizo también semáforos para evitar el envío simultáneo desde varios terminales

El hilo correspondiente a los envíos es el que realiza toda la lógica de los tiempos de espera entre los envíos.

Ha sido una buena práctica para asentar los conocimientos de los threads y toda la potencia que tienen para futuras implementaciones.

Para el envío a Verifactu he utilizado threads en un solo ejecutable.

Todo el envío se gestiona desde el hilo correspondiente sin afectar al hilo principal.

Utilizo el sistema de mutex para notificar nuevos registros de alta del hilo principal al hilo correspondiente y que ejecute el envío.

Utilizo también mutex para bloquear el envío y no lanzar dos envíos si se crea un nuevo registro de alta mientras se está enviando

Utilizo también semáforos para evitar el envío simultáneo desde varios terminales

El hilo correspondiente a los envíos es el que realiza toda la lógica de los tiempos de espera entre los envíos.

Ha sido una buena práctica para asentar los conocimientos de los threads y toda la potencia que tienen para futuras implementaciones.

Si hay que modificar muchos proyectos y no tienes tiempo y quieres hacerlo con garantias de que no habrá errores quiza lo mejor es una llamada al .exe y aqui paz y despues gloria.

Todo tiene su envés y su revés. Lo que es bueno para el dolor de muelas es malo para el estómago.

Todo ello sin perjuicio de que hay que aprender todas las técnicas posibles

exacto, cada proyecto es un mundo.

En mi caso, solo tengo un único programa.

En los proyectos con programación más a medida este tipo de cambios que afectan a tantos procesos es una buena faena ya que todo se multiplica por el nº de proyectos.

VictorCasajuana wrote: Para el envío a Verifactu he utilizado threads en un solo ejecutable.
Todo el envío se gestiona desde el hilo correspondiente sin afectar al hilo principal.
Utilizo el sistema de mutex para notificar nuevos registros de alta del hilo principal al hilo correspondiente y que ejecute el envío.
Utilizo también mutex para bloquear el envío y no lanzar dos envíos si se crea un nuevo registro de alta mientras se está enviando
Utilizo también semáforos para evitar el envío simultáneo desde varios terminales
El hilo correspondiente a los envíos es el que realiza toda la lógica de los tiempos de espera entre los envíos.
Ha sido una buena práctica para asentar los conocimientos de los threads y toda la potencia que tienen para futuras implementaciones.

Buenos días Víctor,

Yo sólo me he atrevido a crear un hilo para los envíos cuando se 'dispara' un TIMER (busca; y si encuentra, envía), mientras se está enviando el TIMER está desactivado, por tanto no pueden coincidir varios envios a la vez.

Me hubiera gustado entender lo de los MUTEX pero no tenía tiempo (y seguro que es facil).
Cómo se hace 'para notificar' de un hilo a otro?
Entiendo que tienes 2 hilos activos a la vez constantemente. El principal y el de envío (que estará pendiente de que el principal le 'notifique' nuevas altas), es así? O, además se crean hilos para cada notificación?

Lo de los semáforos entre terminales, cómo lo has hecho? Algún valor concreto en una DBF/BB.DD.? Un fichero que se crea y se borra? ...

En mi caso he optado por un fichero que se crea y se borra; esto permite que algún proceso externo (de mantenimiento por ejemplo, totalmente ajeno y sin saber/poder acceder a DBF) pueda forzar que el proceso de envío quede en 'letargo' hasta que este fichero vuelva a existir.

Y como curiosidad en que porcentaje tienes acabado el desarrollo?
En mi caso no contemplo de manera automática el 100% de la operativa, pero permitiré que sea el SIF externo el que proporcione los parámetros adecuados; me explico, ahora aplico unos parámetros calculados según los datos que recibo del SIF, pero el SIF tendrá la posibilidad de forzar los parámetros a enviar. Esto permite que un SIF proporcione pocos datos y que yo calcule/aplique el resto, facilitando la adaptación del SIF en cuanto a los envíos a Veri*factu.