Newsgroup: it.comp.lang.visual-basic
Titolo: classe non registrata

Classe non registrata, non è una novità e normalmente è risolvibile 
registrando qualche OCX
 
Ho installato Vb6 su Win 7 superando una "infinità" di problemi, ma non 
è finita.
Mi riferisco ad un programma compilato da Vb6 e pacchettizzato con 
CyberIntallerStudio sotto Win 7, per essere poi installato su un sistema XP
 
Ho eliminato i percorsi assoluti ("C:\Programmi") e utilizzato App.Path, 
ma mi sono arenato su questo errore:
 
Classe non registrata.
Cercando l'oggetto con CLSID {00000010-0000-0010-8000-00AA006D2EA4}.
 
Ho letto che è riferito all'uso di DAO350.dll non installata nel sistema.
A parte che io uso dao360.dll e non capisco il suggerimento di 
Microsoft: 
http://support.microsoft.com/kb/288706/it
 
 
Il problema è che su XP il percorso "C:\Program Files\Common 
Files\Microsoft Shared\DAO\dao360.dll" non vien accettato e al momento 
della registrazione mi dice che non trova il modulo.
 
Non cambia niente nemmeno se faccio finta di nulla e provo su 
C:\Programmi\Common Files\Microsoft Shared\DAO\dao360.dll
non trova il modulo.
 
Come posso fare?
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

 della registrazione mi dice che non trova il modulo.
 
Naturalmente intendevo anche se ho creato C:\Program Files\Common 
Files\Microsoft Shared\DAO\
 
e ci ho messo dentro la dll!!  :)


 
http://support.microsoft.com/kb/288706/it
 
 
Quel traduttore automatico e' veramente una merda... sarebbe:
 
Sintomo:
Quando si prova ad avviare per la prima volta un appicazione installata
dall'installer di VB6.0 inculdendo quello che il PDW ha creato, puoi
ricevere il seguente errore bla bla bla
 
Causa:
Questo errore avviene quando il progetto VB6 fa riferimento al DAO 3.6
(dao360.dll) anzichè al DAO350.dll bla bla bla
 
Quando la proprietà CONTROL del controllo Data intrinseco è settata su
ACCESS, e l'applicazione ne fa uso, l'applicazione richiede che 
DAO350.dll
sia registrata nel sistema. Tuttavia DAO350.dll non è inclusa nel
pacchetto di distribuzione (installer) creato dal PDW perchè non è
indicata nel progetto.
 
Soluzione:
Per risolvere il problema, impostarela proprietà CONTROL del controllo
Data intrinseco ad ACCESS2000 che fa uso di DAO360.dll. La suluzione
è valida anche se si usa un database access97 bla bla bla.
 
In pratica:
Microsoft ha scazzato la retrocompatibilità DAO di access, per
fixare il problema bisogna settare, nel progetto, la proprietà
control su ACCESS2000 anzichè la default (ACCESS).

 control su ACCESS2000 anzichè la default (ACCESS).
 
Io il loro installer, come scrivevo, nemmeno lo uso, in ogni caso è da un 
po' che non uso tabelle Access 97 e son passato ad Access 2000 che da tempo, 
nelle mie applicazioni, è settato così quando uso un Data-control.
 
Il mio problema sarebbe quindi quello di registrare sotto DIVERSA(O) Path la 
dll in questione. Il problema è che le cartelle (directory) suddette 
dovrebbero essere, anzi sono, cartelle di sistema e il passaggio tra una 
compilazione fatta sotto win 7 e installazione sotto XP, scorre tranquilla 
per quanto riguarda C:\Program Files che sotto XP viene visto come 
C:\Programmi in quanto App.Path Il Problema inizia a sorgere con C:\Program 
Files\Common
Files\Microsoft Shared\DAO\ che sembra essere una cartella fantasma, non 
vien accettata e al momento della registrazione mi dice che non trova il 
modulo.
 
Qualcuno ha suggerimenti? Mi sfugge qualcosa?
 
 
 

 nelle mie applicazioni, è settato così quando uso un Data-control.
 
Se già hai settato nel progetto access2000, di piu non so
aiutarti, però non mi stupirei di scoprire che il prg di setup che stai
usando si crea i riferimenti usando il prg di setup di vb6... ergo
verificherei se tutti i possibili (per quanto improbabili) riferimenti
al DB connect sono impostati per access 2k.

 Qualcuno ha suggerimenti? Mi sfugge qualcosa?
 
E' valido il suggerimento di Franz: tutti i datacontrol presenti devono 
avre la prop database a access2000.
 
Inoltre se rifai il pacchetto con innosetup+istool questo imposta la 
corretta cartella di destinazione delle librerie dao36 a seconda del 
sistema operativo che si incontra. Non devi piu preoccuparti di 
cartelle fantasma
 
-- 
Greg
 
 


 
Con VB6 il DAO può essere utilizzato come componente stand-alone facendo
il corrispondente file manifest dell'EXE che lo utilizza, dove sono registrati le GUID
 
 
-- 
http://freewareonline.org/
 
http://netuser.altervista.org/
 
http://salclem2.altervista.org/
 
 


 
TEDESCO. L'unica in italian: stand-alone  :)



 
Leggi qua
http://salclem2.altervista.org/wiki/index.php/Make_My_Manifest
 


 
http://salclem2.altervista.org/wiki/index.php/Make_My_Manifest
 
 
Grazie molte salclem2 ! Ottimo!
 
Per chiudere questo 3D devo dire che ho risolto...in realtà mi ero perso 
in un bicchiere d'acqua: EXE compilato sotto Win 7 e sovrascritto, come 
tale (solo l'exe) in XP... saltava la path suddetta.
Reinstallando tutto il pacchetto ho risolto.
A proposito di installazione, consiglio CyberInstaller Studio, mooolto 
superiore ad Inno setup.
Grazie ancora.


 Grazie ancora.
 
Hai provato Inno in coppia con IsTool?
 
-- 
Greg
 
 

Il 12/12/14 13:05, Greg ha scritto:

Lo provo.
Grazie


Il 12/12/14 13:05, Greg ha scritto:

Si l'ho, li ho provati, ma due non ne fanno uno. Con Cyberinstaller devi 
solo decidere la piattaforma di programmazione, ed il file di codice 
relativo, es. Visual basic, NomeProgetto.vbp e si arrangia lui ad 
inserire tutto, file cartelle e sottocartelle del progetto, ma 
sopratutto tutti i file di visual basic necessari al funzionamento 
dell'applicazione. Prima della compilazione, controlla eventuali 
incongruenze e ti aiuta a risolverle....penso non si possa pretendere di 
più.
Provalo.
