Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Comunicazione via socket tcp/udp senza ocx
56 views
Skip to first unread message
RobertoA
Aug 13, 2021, 4:21:33 AM8/13/21
to
Stavo vedendo questo esempio di comunicazione usando il controllo
MSWINSCK.OCX
https://www.youtube.com/watch?v=fk_Zb9kBuS0
E' fatto per Excel ma e' facilmente portabile anche su Access
Usare una connessione via socket tcp/udp e' un ottimo sistema per far
reagire l'applicativo rispetto ad eventi esterni asincroni
Il problema e' l'ocx da usare, il famigerato MsWinsck.ocx
Funzionare funziona, ma bisogna registrarlo, bisogna poi attivarlo con
la licenza, e sperare che non ti sbotti con l'errore 429 o simili
Insomma, potendo evitarlo, come per tutti gli ocx, credo sarebbe meglio
Quindi la domanda e': come ottenere le stesse funzionalita' del
controllo MsWinsck.ocx, senza usare un ocx?
Esistono delle dll o altro che 'rendano' uguali funzionalita' e siano
contemporaneamente piu' semplici/affidabili da usare?
MSWINSCK.OCX
https://www.youtube.com/watch?v=fk_Zb9kBuS0
E' fatto per Excel ma e' facilmente portabile anche su Access
Usare una connessione via socket tcp/udp e' un ottimo sistema per far
reagire l'applicativo rispetto ad eventi esterni asincroni
Il problema e' l'ocx da usare, il famigerato MsWinsck.ocx
Funzionare funziona, ma bisogna registrarlo, bisogna poi attivarlo con
la licenza, e sperare che non ti sbotti con l'errore 429 o simili
Insomma, potendo evitarlo, come per tutti gli ocx, credo sarebbe meglio
Quindi la domanda e': come ottenere le stesse funzionalita' del
controllo MsWinsck.ocx, senza usare un ocx?
Esistono delle dll o altro che 'rendano' uguali funzionalita' e siano
contemporaneamente piu' semplici/affidabili da usare?
@Alex
Aug 13, 2021, 4:43:21 AM8/13/21
to
Io 20 anni fa circa avevo scritto codice per Access che usava le API del Socket per emulare l'OCX senza doverlo usare... ma ai tempi ero masochista.
Funzionava ma un massacro di ore/uomo per andarcene fuori, risultato però troppo complesso, non so nemmeno se oggi sarebbe riciclabile ma non lo trovo nemmeno più...
Ci sono, a Pagamento, OCX compatibili con Access, questi sono molto quotati e mi pareva ci fosse anche il Socket.
https://www.dbi-tech.com/ProductPage.aspx
Alternativa altrettanto valida, ma serve essere capaci, è sviluppare un componente COM con C# o NET, ed usarlo con Access accertandosi solo della compatibilità del Framework.
Questa soluzione che ti ho appena esposto, ultimamente sta prendendo molto piede tra gli sviluppatori multipiattaforma, ho visto ottimi esempi invidiabili.
Io purtroppo non mi sono evoluto.
@Alex
Funzionava ma un massacro di ore/uomo per andarcene fuori, risultato però troppo complesso, non so nemmeno se oggi sarebbe riciclabile ma non lo trovo nemmeno più...
Ci sono, a Pagamento, OCX compatibili con Access, questi sono molto quotati e mi pareva ci fosse anche il Socket.
https://www.dbi-tech.com/ProductPage.aspx
Alternativa altrettanto valida, ma serve essere capaci, è sviluppare un componente COM con C# o NET, ed usarlo con Access accertandosi solo della compatibilità del Framework.
Questa soluzione che ti ho appena esposto, ultimamente sta prendendo molto piede tra gli sviluppatori multipiattaforma, ho visto ottimi esempi invidiabili.
Io purtroppo non mi sono evoluto.
@Alex
RobertoA
Aug 13, 2021, 10:27:01 AM8/13/21
to
Il 13/08/2021 10:43, @Alex ha scritto:
> Alternativa altrettanto valida, ma serve essere capaci, è sviluppare un componente COM con C# o NET, ed usarlo con Access accertandosi solo della compatibilità del Framework.
> Questa soluzione che ti ho appena esposto, ultimamente sta prendendo molto piede tra gli sviluppatori multipiattaforma, ho visto ottimi esempi invidiabili.
> Io purtroppo non mi sono evoluto.
> @Alex
Si, mi rendo conto che l'ambiente Access non riesce a tenere il passo
> Alternativa altrettanto valida, ma serve essere capaci, è sviluppare un componente COM con C# o NET, ed usarlo con Access accertandosi solo della compatibilità del Framework.
> Questa soluzione che ti ho appena esposto, ultimamente sta prendendo molto piede tra gli sviluppatori multipiattaforma, ho visto ottimi esempi invidiabili.
> Io purtroppo non mi sono evoluto.
> @Alex
con la miriade di tecnologie che saltano fuori ogni giorno
Purtroppo alcune sono irrinunciabili, e quindi, volendo 'collegarsi' con
tecnologie non previste dal mondo vba, e' indispensabbole costruirsi
delle procedure ad hoc
Ho provato, anche grazie ai tuoi suggerimenti, la costruzione di una
libreria da integrare con Access, ma finora non ce l'ho ancora
funzionante completamente come vorrei
Una volta strutturata realizzata la prima, poi credo sia banale metterci
nel codice quello che deve fare di volta in volta
@Alex
Aug 14, 2021, 1:49:06 AM8/14/21
to
Questo è un tipico esempio di come far collaborare i 2 sistemi.
Nella sostanza Kallal crea una DLL in NET per il Merge di PDF e la richiama poi da MsAccess...
Parte da quì, trovi il codice anche e varie considerazioni poi sul metodo di Loading della DLL:
https://www.utteraccess.com/topics/2060859
https://www.utteraccess.com/topics/2060859/posts/2784817
@Alex
Nella sostanza Kallal crea una DLL in NET per il Merge di PDF e la richiama poi da MsAccess...
Parte da quì, trovi il codice anche e varie considerazioni poi sul metodo di Loading della DLL:
https://www.utteraccess.com/topics/2060859
https://www.utteraccess.com/topics/2060859/posts/2784817
@Alex
RobertoA
Aug 15, 2021, 4:41:01 AM8/15/21
to
una dll da usare in ambiente vba, senza che sia necessaria la
registrazione preventiva, come e' obbligatorio per gli ocx
0 new messages