Newsgroup: it.comp.lang.visual-basic
Titolo: VB6 e VBA6.DLL

Tempo fà trovai del codice di esempio che conteneva le
seguernti istruzioni:
 
Declare Function EbExecuteLine Lib "vba6.dll" _
     (ByVal pStringToExec As Long, ByVal Foo1 As Long, _
    ByVal Foo2 As Long, ByVal fCheckOnly As Long) As Long
 
 
Public Function sCodice(stCode As String, Optional fCheckOnly As Boolean) As 
Boolean
    'Esegue il codice memorizzato nella stringa passata
    sCodice = EbExecuteLine(StrPtr(stCode), 0&, 0&, Abs(fCheckOnly)) = 0
End Function
 
In pratica, tra le altre cose, si poteva memorizzare una stringa
con delle istruzioni (es: (1+2)*3 )
E fare in modo che la stringa venisse eseguita.
 
Io ho sfruttato questa potenzialità per fare un programma
di formule.
 
Tutto bene finchè usavo il programma all'interno di VB6.
 
Quando invece generavo l'exe il programma andava in errore
non appena veniva richiamata la funzione EbExecuteLine
 
Ho provato anche a installare l'exe sia compreso VBA6.DLL
che senza.
L'errore non viene specificato e il programma si interompe.
 
Se qualcuno di voi ci capisce qualcosa ...
 
Grazie e saluti a tutti
Sauro
 
 

 ha scritto nel messaggio news:ldacqs$b42$1...@speranza.aioe.org...

Sotto quale SO lo compili il programma?
 
-- 
blog su google: 
http://salclem.blogspot.it/
 
blog su altervista: 
http://salclem2.altervista.org/blog
 
sito su altervista: 
http://salclem2.altervista.org/
 
 

E' un'istruzione non documentata  e che può essere eseguita esclusivamente 
dall'IDE.
Prova al limite se ti riesce a il VBS. 
 

 Prova al limite se ti riesce a il VBS.
 
Avevo pensato a un problema di indirizzamento di memoria in caso
l'OP l'avesse compilato sotto win7 a 64bit. Comunque, secondo me e'
buona norma compilare i programmi in VB6 sotto winXP, altrimenti
i programmi funzionano solo sul SO dove compili e non funzionano su
altri sistemi. Sviluppo e debug li puoi fare anche sotto win7.


 su altri sistemi. 
 
E' sicura questa affermazione? Non l'avevo mai letta prima.
Se compilo in win7 poi non gira su xp? Ho capito nene?
 
-- 
Greg
 
 

Greg ha scritto:

A me non risulta. Compilo in W7 da quando è uscito, non
ho mai avuto problemi a far girare programmi sotto XP.
 
Bye, G.

"Paperino" <non...@lo.dico.invalid> ha scritto nel messaggio news:ldbc02$kgk$3...@dont-email.me...

A me e' successo piu' di una volta, non so cosa posso dire in piu'


 ha scritto nel messaggio
news:ldcj1p$tpd$
1...@speranza.aioe.org
 

La causa non è il SO host perché anche io sviluppo sotto W7 e tutto gira 
senza problemi anche su XP.
 
-- 
-> G.Chiappori
www.chiappori.it
 
www.chiappori.com
 
 
 

Nel dubbio ho fatto una semplice prova,
ho compilato uno stesso progetto sia sotto XP (in virtuale) che in W7,
ho poi preso i due eseguibili e li ho confrontati in binario con una 
semplice routine.
Gli eseguibili creati sono diversi!!! 
 


Questo è relativamente normale, non farci da conto

 ha scritto nel messaggio news:52fa151a$0$20710$5fc...@news.tiscali.it...

Questa mi sembra la prova di cio' che vado dicendo!
Comunque, per la precisione il problema si verifica se
il programma fa uso di OCX.



da cui scarichi VB60SP6-KB2708437-x86-ITA.msi
(In mezzo c'era qualche altra cosa, ma "l'ultimo ha sempre
ragione"...)
 
Il sistema più semplice *dovrebbe* essere usare il
"Microsoft Update" al posto di "Windows Update",
ma per mia esperienza non sempre aggiorna tutto,
in particolare questi OCX vanno aggiornati a mano.
 
Bye, G.

"Paperino" <non...@lo.dico.invalid> ha scritto nel messaggio news:lddces$gct$1...@dont-email.me...

Ho tutti gli aggiornamenti che hai citato, e comunque se compilo sotto XP
il problema non si verifica. Questo come lo spieghi?


 Sotto quale SO lo compili il programma?
 
XP.
 
Grazie e saluti.
Sauro 
 
 


Sei sicuro o è solo una tua supposizione.?
 
Grazie Federico.
Sauro 
 
 

La prova è stata da me fatta con progetto "senza" OCX e "senza" riferimenti 
a librerie.
L'ambiente di sviluppo è lo stesso identico su entrambe le macchine VB6 SP6. 
 

Sei sicuro o è solo una tua supposizione.?
 
Riporto quel che si dice nei principali forum.
Non ho trovato documentazione da nessuna parte.
Il problema è noto.
 

 Il problema è noto.
 
Ok.
Grazie Federico.
Sauro 
 
 

 il problema non si verifica. Questo come lo spieghi?
 
Aspe', mi sono perso. Di quale problema stai parlando ?
Finora si parlava del problema dell'uso di una funzione
non documentata della VBA6.dll, quella dell'OP, e di
generici problemi di compilazione sotto W7.
Hai un caso specifico ?
Magari con qualche riga da postare per far controllare ?
 
Bye, G.

 Bye, G.
 
Mi riferisco al problema che se compilo un programma in VB6 sotto win7
non funziona su XP (come gia' detto, un prog che faccia uso di ActiveX),
se invece lo stesso prog lo compilo soto XP funziona su tutti e tre (XP, win7 e win8)


 win7 e win8)
 
Senza offesa, solo per battuta, ma come disse qualcuno
qualche anno fa: " 'Non funziona' lo dice tua moglie al
riparatore della lavatrice, questo è un NG tecnico!" :-)
 
Se provi a farlo girare ti dà un errore, suppongo... quale ?
 
Hai fatto il programma di installazione o fai solo girare
l'eseguibile ?
Lo so, non ti offendere per la domanda, ma l'ho visto
fare tante, troppe volte... per poi lamentarsi che il S.O.
o il PC ha dei problemi :-( )
 
E, come dicevo, hai un sorgente minimale da provare,
che ti dia questo problema ?
 
Bye, G.


 
Hai ragione, ma non l'ho specificato perche' mi sembrava ovvio
che l'errore e' quello classico in cui l'activex non e' in grado di
creare la sua istanza. Ovviamente in tutti e tre i sistemi citati e'
presente l'activex desiderato perche' sono io che ce lo metto
manualmente, copiandolo nella system32 (XP, win7, win8)
o nella syswow64 (win7-64bit, win8-64bit). Il mio programma
registra automaticamente il suo activex al primo avvio e crea una
chiave nel registry per contrassegnare l'avvenuta registrazione.
Tutti i miei programmi adottano questa tecnica, non necessitano
di setup. E come ho gia' detto, tutto va a buon fine se il programma
viene compilato sotto XP. Giusto oggi l'ho verificato anche su win8,
solo che al primo avvio bisogna eseguirlo usando la voce di menu
"Run as administrator", dopo il primo avvio puo' essere eseguito
normalmente senza questo accorgimento. Mi sembra di essere stato
abbastanza chiaro stavolta. A te la mossa, ciao!


 abbastanza chiaro stavolta. A te la mossa, ciao!
 
Ho la sfera di cristallo a lucidare... senza sapere neanche
che ActiveX è andiamo sul difficile.
Comunque se fossi sul posto proverei con ProcMon a vedere
dov'è che si crea l'errore:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
 
E' estremamente potente come strumento di analisi,
ma non è proprio semplicissimo da adoperare.
 
Bye, G.

 Bye, G.
 
 
 


Il 12/02/14 23.04.58 salclem2 ha scritto:
 
Salclem2 puoi fare una prova pratica riproducibile anche da altri?
 
Un progettino di una sola form con la sola Flexgrid, compilato, setup 
della casa madre e vediamo cosa succede.
Cosi lo può riprodurre anche Paperino (o chi ha voglia), io sono fermo 
a xp altrimenti avrei gia fatto
 
-- 
Greg
 
 

 ha scritto nel messaggio news:ldj8oo$ok1$1...@speranza.aioe.org...

Forse c'e' un malinteso: il problema si verifica se tenti di eseguire un
programma in VB6 su XP ma compilato sotto win7, e non viceversa.


 programma in VB6 su XP ma compilato sotto win7, e non viceversa.
 
Nessun malinteso, io non ho win7 dove poter compilare. Solo xp.
 
-- 
Greg
 
 

 ha scritto nel messaggio news:ldj9hc$qme$1...@speranza.aioe.org...

Ecco l'errore: 
http://postimg.org/image/zfmgkjm9n/
 


 ha scritto nel messaggio news:ldj9hc$qme$1...@speranza.aioe.org...

Il mio programma fa uso di questi 3 activex:
MSWINSCK.OCX
MSFLXGRD.OCX
MSCOMCT2.OCX


 Ecco l'errore: 
http://postimg.org/image/zfmgkjm9n/
 
 
Bene, ma se sembra essere un server, cosa forse diversa da un comune 
seguibile. Inoltre pesa 350k, invece bisognerebbe provare con il 
classico progetto "Pippo" come si faceva una volta. Solo i controlli e 
il codice indispendabile a riprodurre l'errore.
 
-- 
Greg
 
 

 MSCOMCT2.OCX
 
Compila un form solo con il primo ocx, poi solo il secondo poi solo il 
terzo e vediamo che succede.
 
-- 
Greg
 
 

 ha scritto nel messaggio news:ldlvlf$h5p$1...@speranza.aioe.org...

Ma se funziona perfettamente quando si compila sotto XP, che senso ha
incaponirsi a voler trovare un bug a tutti i costi? Non e' piu' ovvio che
si tratti di un problema di retrocompatibilita' e quindi irresolubile da noi
poveri mortali? Secondo me dovresti rivolgerti al programmatore che ha
sviluppato questi activex (o quello che risulterebbe imputabile dalla tua
ricerca). Se proprio ti interessa lo puoi fare. Ti basta installare, in una VM,
win7 con su VB6, scovare il colpevole e poi fai un reclamo a chi lo ha
sviluppato. A tale scopo ti do' la lista completa degli activex utilizzati.
SCRRUN.DLL
DAO360.DLL
MSDBRPTR.DLL
MSSTDFMT.DLL
MSDERUN.DLL
MSBIND.DLL


 
 
Sono su un tablet Android e non posso fare prove, ma
avete dato un'occhiata ai file .dep di quei controlli?
Cosi a occhio mi par di ricordare che il winsock
abbia bisogno di qualcos'altro per funzionare. 
 
E per l'altro esempio di un altro post, se si deve
aprire un database Mdb non si può fare senza
assicurarsi che ci siano i driver giusti...
L'errore di automazione in quei casi è
normalissimo, anche se non dovrebbe dipendere
dalla piattaforma  di compilazione.
 
Ho i ricordi un po' arrugginiti, e una abbondante
cena di pesce in ottima compagnia (BURP!)
non aiuta molto a schiarirli :-D
 
Domani sera a mente fresca ci butto un'altra
occhiata.
 
Bye, G.


 
Bye, G.

 ha scritto nel messaggio news:ldm62g$28j$1...@speranza.aioe.org...

Negli esempi che hai citato, puoi notare che i due autori del forum
non fanno alcun cenno del SO su cui fanno lo sviluppo e il SO su cui fanno
il test. E' molto probabile che si tratta di due SO non allineati. Se loro
avessero fatto la compilazione sul sistema piu' vecchio (ma ovviamente
con tutte le librerie aggiornate, come faccio io) l'automation error non
si sarebbe verificato, come accade nel mio caso. Io mi sono gia' fatto
un'idea e mi sembra inutile continuare a indagare. Il problema deriva
molto probabilmente dalla type library di ADODB. Se la compilazione
viene fatta sul sistemma piu' vecchio, viene saltato il controllo per la
retrocompatibilita' (sia in late-binding che in early-binding), cosa che
non puo' essere fatto nel caso inverso, se non vi e' retrocompatibilita'.
Ergo, scatta l'errore e non riesce a istanziare l'activex corrispondente.


Il 14/02/14 23.07.40 salclem2 ha scritto:
 
Si, ma cerca di sfoltire un poco, adesso sei troppo sul generico, ed 
arrivare ad una affermazione di questo tipo:
 
progetto con solo form1, un pulsante e flexgrid collegata a nulla. 
Compilato in win7 non gira su xp.
In qursto modo molti possono rapidamente e facilmente ripetere quanto 
da te affermato.
 
-- 
Greg
 
 

 l'errore e non riesce a istanziare l'activex corrispondente.
 
E, *se* le tue librerie fossero aggiornate davvero sulla
macchina di sviluppo, e *se* tu facessi il setup, il programma
si porterebbe dietro le librerie giuste.
 
Fine del problema.
 
Bye, G.

 Bye, G.
Il mio programma funziona perfettamente su XP SP2, win7, win8 e win8.1
se la compilazione viene effettuata sotto XP SP3 con tutte le
librerie, usate dal programma, aggiornate (SP6 e "Cumulative")
e grazie al fatto che il programma ha gia' un setup interno che
registra gli activex automaticamente al primo avvio.
 
Fine del problema.


Fine del problema.
 
Il tuo programma è una porcheria se non hai previsto oltre all'installazione 
di eventuali DLL e OCX mancanti (o ancor peggio con versione differente) 
anche una routine di disinstallazione adeguata, che riporti cioè il sistema 
alle condizioni antecedenti l'installazione!!!
Un programma è veramente portable quando la sua invasione nel sistema è 
limitata o preferibilmente assente!!!
Un vero programma portable dovrebbe avere tutto il codice per il suo 
corretto utilizzo al suo interno tramite classi e controlli, utilizzo di 
createobject e dichiarazioni API, senza riferimento a determinate 
librerie!!!
 
In caso contrario meglio affidarsi a programmi di Setup come Inno, uno dei 
migliori e free sul mercato per quanto riguarda VB6!!! 
 


 
Ci vuole un attimo a farlo diventare portable, ma non era richiesto.
Basta mettere tutti gli activex usati dal programma nella cartella del
programma e invertire il processo di registrazione, cioe' usare la
chiamata Api a "DllUnregisterServer", e poi eliminare il collegamento
che viene creato sul desktop. Non credere che sia cosi difficile!
Invece ho messo solo un /remove a linea di comando che cancella
solo le chiavi di registro del programma. Poi, a discrezione dell'utente,
si possono cancellare i file del programma. Gli activex possono sempre
servire, meglio lasciarli dove stanno!


 chiamata Api a "DllUnregisterServer", e
 
... e mandare a puttane gli altri programmi
su quel pc che usano gli stessi controlli.
Complimenti.
 
Bye, G.

servire, meglio lasciarli dove stanno!
 
Se tu metti tutti gli activex nella cartella del programma e dopo gli 
registri, fai un bel casino, perchè normalmente le librerie devono stare 
nelle cartelle di sistema, dove è anche probabile che già ci siano.
Nel momento in cui tu registri i tuoi controlli, vai di fatto a 
sovrascrivere le registrazioni "corrette" esistenti!!!
E' molto più difficile di quanto una mente presuntuosa non possa pensare, è 
per questo che esistono programmi come Inno! ;)
Come già detto un programma Portable (come quelli che creo io!) non è 
invasivo.
Nel caso debba utilizzare per forza controlli di terzi, realizzo il setup, 
ma non perchè non sappia registrarli, ma perchè mi rendo conto che non tutti 
i sistemi sono uguali!
Se veramente vuoi fare il "Togo", prova a utilizzare solo farina del tuo 
sacco al posto di utilizzare librerie esterne! E comunque se distribuisci 
queste cose al pubblico... informarli prima... sarebbe cosa gradita e 
corretta! ;) 
 

 Nel momento in cui tu registri i tuoi controlli, vai di fatto a sovrascrivere le registrazioni "corrette" esistenti!!!
 
Allora non mi sono spiegato, chiedo venia. E' proprio per questo che adotto la cartella di sistema,
la mia era solo un'ipotesi partendo dal presupposto che il sistema fosse vergine, privo
degli OCX e DLL secondarie di VB6 (come sai M$ ti da gia' alcune librerie VB nel sistema vergine, come MSVBVM60.DLL
e librerie correlate). Il fatto e' un altro. Ti sei mai studiato il codice sorgente di un setup?
Ebbene, il mio programma incriminato fa esattamente quello che farebbe un SETUP. E infatti funziona
perfettamente. Quindi non capisco tutto questo allarmismo!


 
Stai facendo confusione. Il fatto e' un altro. Ti sei mai studiato il codice sorgente di un setup?
Ebbene, il mio programma incriminato fa esattamente quello che farebbe un SETUP.
E infatti funziona perfettamente. Quindi non capisco tutto questo allarmismo!
 
