+ Rispondi al messaggio
Pagina 1 di 2 12 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11

[VB2010] Variabile pubblica non valorizzata da funzione in DLL

  1. #1
    L'avatar di il Fenomeno
    il Fenomeno non è in linea Scolaretto
    Mi succede questo: ho trasferito alcune routines di utilità spicciola in una DLL, ma non si valorizza il contenuto di una stringa pubblica nel programma chiamante.

    Programma chiamante
    
        ...
        Public Apici As String
        ...
        Sub Main()
            ...
            Call Utilities.Utilities.Ambiente()
            Console.WriteLine("Apici = " & Apici)
    
    -------------------------------------------------
    
    Libreria
    
        ...
        Shared Apici As String
        ...
        Public Shared Sub Ambiente()
            ...
            Apici = Chr(34)
            ...
        End Sub
    
    Ho omesso il resto del codice per brevità, i membri si compilano entrambi senza errori, seguendo passo-passo l'istruzione di valorizzazione viene eseguita ma dopo l'esecuzione senza errori il valore riscontrato è "Nothing". Dov'è l'errore?
    ℹ️ Leggi di più su il Fenomeno ...

  2. #2
    L'avatar di Cteniza
    Cteniza non è in linea Amanuense
    Verifica il tipo di dato originale da cui parti ho il sospetto che si tratti di un object che si aspetta dei parametri
    ℹ️ Leggi di più su Cteniza ...

  3. #3
    L'avatar di il Fenomeno
    il Fenomeno non è in linea Scolaretto
    Quote Originariamente inviato da Cteniza Visualizza il messaggio
    Verifica il tipo di dato originale da cui parti ho il sospetto che si tratti di un object che si aspetta dei parametri
    Il tipo di dati della variabile? E' dichiarata "stringa" in tutti e due i punti, e "Ambiente" è una subroutine piccolissima senza parametri.
    Poi non si rilevano errori di alcun tipo ... potresti spiegare meglio ? Se necessario inserisco il codice completo, è abbastanza corto.
    ℹ️ Leggi di più su il Fenomeno ...

  4. #4
    Quote Originariamente inviato da il Fenomeno Visualizza il messaggio
    Mi succede questo: ho trasferito alcune routines di utilità spicciola in una DLL, ma non si valorizza il contenuto di una stringa pubblica nel programma chiamante.

    Programma chiamante
    
        ...
        Public Apici As String
        ...
        Sub Main()
            ...
            Call Utilities.Utilities.Ambiente()
            Console.WriteLine("Apici = " & Apici)
    
    -------------------------------------------------
    
    Libreria
    
        ...
        Shared Apici As String
        ...
        Public Shared Sub Ambiente()
            ...
            Apici = Chr(34)
            ...
        End Sub
    
    Non sono sicuro di aver capito al 100% il problema.
    Ma tu con quel codice ti aspetti che venga assegnato qualcosa nella stringa "Apici" sul Programma chiamante ?

    Perchè se è così è ovvio che non succeda.

    Tu chiami il Metodo Ambiente() e lui valorizzerà la stringa "Apici" della Libreria.
    L'istruzione Call in VB.NET non serve a niente. Evitala SEMPRE.
    In generale se crei Metodi comuni da mettere su librerie DLL esterne e riutilizzabili, non è buona pratica creare delle Sub, quindi ciò che stai facendo non è corretto.
    Una Sub è un Metodo Void, che non restituisce nulla.
    In pratica facendo così sei costretto poi a riassegnare ad Apici del chiamante l'Apici statica a livello di Libreria.
    Usa delle Function.

        Public Shared Function Ambiente( ... args ... ) As String
            ...
            Return Chr(34)
            ...
        End Function
    
    Ultima modifica di MarcoGG; 22-09-2012 18:38 
    ℹ️ Leggi di più su MarcoGG ...

  5. #5
    L'avatar di il Fenomeno
    il Fenomeno non è in linea Scolaretto
    Quote Originariamente inviato da MarcoGG Visualizza il messaggio
    Ma tu con quel codice ti aspetti che venga assegnato qualcosa nella stringa "Apici" sul Programma chiamante ?
    Sì, in effetti mi aspettavo proprio questo : che venisse valorizzata la stringa Apici dichiarata public nel chiamante, e che fosse sufficiente dichiararla shared nella libreria perchè il compilatore la riconoscesse come la stessa unica variabile.

    Quote Originariamente inviato da MarcoGG Visualizza il messaggio
    Perchè se è così è ovvio che non succeda.
    Tu chiami il Metodo Ambiente() e lui valorizzerà la stringa "Apici" della Libreria. L'istruzione Call in VB.NET non serve a niente. Evitala SEMPRE.
    In generale se crei Metodi comuni da mettere su librerie DLL esterne e riutilizzabili, non è buona pratica creare delle Sub, quindi ciò che stai facendo non è corretto.
    Una Sub è un Metodo Void, che non restituisce nulla. Usa delle Function.

        Public Shared Function Ambiente( ... args ... ) As String
            ...
            Return Chr(34)
            ...
        End Function
    
    Sì, conosco la differenza tra Sub e Function, ma la routine "Ambiente" nelle mie intenzioni serviva a valorizzare un notevole numero di variabili che precedentemente dichiaravo come costanti, dunque la Function non serve all'uopo, credo. Posso in alternativa dichiararle nella libreria e "vederle" dal chiamante? In altre parole, mi serve che le variabili possano essere valorizzate in un unico punto, preferibilmente la libreria comune ... invece se ho ben capito così facendo ne ho due diverse, una nel chiamante e una nella libreria, ma la parola chiave "shared", "condivisa", mi sembra inequivocabile ... perchè la mia variabile non viene vista come unica in tutti e due i membri? Come si fa?

    Quote Originariamente inviato da MarcoGG
    In pratica facendo così sei costretto poi a riassegnare ad Apici del chiamante l'Apici statica a livello di Libreria.
    Questa non l'ho proprio capita ... come dovrebbe avvenire la riassegnazione? Scusa l'insistenza, ma la condivisione delle variabili per me è una nozione fondamentale.
    ℹ️ Leggi di più su il Fenomeno ...

  6. #6
    L'avatar di birby
    birby non è in linea Scolaretto
    Ciao!
    Ti segnalo un link (del dicembre 2001) relativo alla visibilità delle variabili e dei metodi nel framework; non l'ho letto tutto ma penso sia tuttora valido
    Variable and Method Scope in Microsoft .NET

  7. #7
    L'avatar di bumm
    bumm non è in linea Topo di biblioteca Ultimo blog: [VB2010] ComboBox ed Enumeratori
    Hai provato ad usare Settings? I settings servono proprio per questo: valorizzare le tue variabili ed eventualmente salvare le modifiche all'uscita dal programma.
    Se proprio devi usare una libreria di classi, crea una classe e metti tutte le inizializzazioni nel costruttore. Dopo, nel tuo programma crea l'istanza di quella classe e accedi ai suoi membri.
    ℹ️ Leggi di più su bumm ...

  8. #8
    Quote Originariamente inviato da il Fenomeno Visualizza il messaggio
    Sì, in effetti mi aspettavo proprio questo : che venisse valorizzata la stringa Apici dichiarata public nel chiamante, e che fosse sufficiente dichiararla shared nella libreria perchè il compilatore la riconoscesse come la stessa unica variabile.
    Ti consiglio di apprendere le basi dell'OOP di VB.NET se vuoi continuare.
    Questi fraintendimenti ti porteranno ad errori gravi, se non hai chiaro come funziona la cosa.
    Questa cosa delle Classi Statiche alla-VB non mi è mai piaciuta e fa parte delle tante cose che secondo me MS poteva risolvere drasticamente nel concepire il nuovo Visual Basic .NET. Invece ha preferito fare il lavoro a metà e favorire la "migrazione indolore", permettendo in pratica allo sviluppatore di portarsi dietro parecchio ciarpame VB6.
    In C# - e fossi stato io, VB.NET l'avrei creato tale-quale a C# ma con la sua sintassi di base, ossia un "C# senza graffe e punti-e-virgola" - la cosa è molto più intuitiva. Una Classe Statica viene dichiarata Static e Static i suoi Metodi :
    Classi statiche e membri di classi statiche (Guida per programmatori C#)

    Quote Originariamente inviato da il Fenomeno Visualizza il messaggio
    Sì, conosco la differenza tra Sub e Function, ma la routine "Ambiente" nelle mie intenzioni serviva a valorizzare un notevole numero di variabili che precedentemente dichiaravo come costanti, dunque la Function non serve all'uopo, credo. Posso in alternativa dichiararle nella libreria e "vederle" dal chiamante? In altre parole, mi serve che le variabili possano essere valorizzate in un unico punto, preferibilmente la libreria comune ... invece se ho ben capito così facendo ne ho due diverse, una nel chiamante e una nella libreria, ma la parola chiave "shared", "condivisa", mi sembra inequivocabile ... perchè la mia variabile non viene vista come unica in tutti e due i membri? Come si fa?
    Shared non ha quel significato.
    Un Membro Shared in una Classe è Statico.

    E comunque è un bene che non sia come tu ti aspettavi.
    Non rispetterebbe incapsulamento e in generale il modello OOP avere delle "variabili globali condivise"...

    Quote Originariamente inviato da il Fenomeno Visualizza il messaggio
    Questa non l'ho proprio capita ... come dovrebbe avvenire la riassegnazione? Scusa l'insistenza, ma la condivisione delle variabili per me è una nozione fondamentale.
    Era per voler dare comunque risposta al tuo modo di vedere la cosa.

    Per come la vedo io tu hai bisogno di un "database".

    Mettiamo 2 Applicazioni : A.exe e B.exe.
    Entrambe fanno uso della stessa libreria L.dll.

    A chiama un Metodo di L, e il valore "persistente" restituito deve essere registrato perchè sia visibile da B.

    I settings, come ti è stato già consigliato. Ma anche un XML...

    Per mia impostazione sono abituato a vedere una "DLL di funzioni" come l'insieme di una o più Classi tipicamente statiche.
    Non capisco il bsigno di avere una lista di parametri da valorizzare con altrettante Sub.

    Tu stesso hai intitolato questa discussione con :
    "Variabile pubblica non valorizzata da funzione in DLL"

    Ma se poi usi delle Sub dove sono le Funzioni ?
    ℹ️ Leggi di più su MarcoGG ...

  9. #9
    L'avatar di il Fenomeno
    il Fenomeno non è in linea Scolaretto
    Questa discussione s'è fatta interessante, almeno per me. Se questo non è il thread giusto posso spostarla altrove, su indicazione dei moderatori.

    Quote Originariamente inviato da MarcoGG Visualizza il messaggio
    Ti consiglio di apprendere le basi dell'OOP di VB.NET se vuoi continuare.
    Questi fraintendimenti ti porteranno ad errori gravi, se non hai chiaro come funziona la cosa.
    Shared non ha quel significato. Un Membro Shared in una Classe è Statico. E comunque è un bene che non sia come tu ti aspettavi.
    Non rispetterebbe incapsulamento e in generale il modello OOP avere delle "variabili globali condivise"...
    Sì, grazie ai vostri interventi sono riuscito a trovare un po' di documentazione sul tema ... me la caverò, in un modo o nell'altro.

    Quote Originariamente inviato da MarcoGG Visualizza il messaggio
    Questa cosa delle Classi Statiche alla-VB non mi è mai piaciuta e fa parte delle tante cose che secondo me MS poteva risolvere drasticamente nel concepire il nuovo Visual Basic .NET. Invece ha preferito fare il lavoro a metà e favorire la "migrazione indolore", permettendo in pratica allo sviluppatore di portarsi dietro parecchio ciarpame VB6.
    In C# - e fossi stato io, VB.NET l'avrei creato tale-quale a C# ma con la sua sintassi di base, ossia un "C# senza graffe e punti-e-virgola" - la cosa è molto più intuitiva.
    Mi sono iscritto a questo forum proprio per acquistare padronanza dei nuovi ambienti di sviluppo, ma il mio obiettivo primario è quello di convertire e migliorare le mie applicazioni già esistenti e piuttosto datate. Mi sono chiesto a lungo se continuare a mantenere separato lo sviluppo con VB.NET e le interrogazioni su ACCESS, o limitarmi a quest'ultimo sviluppando solo in VBA lasciando perdere Visual Studio ... tuttora sono in forse, ma la 1a strada mi garantisce maggior indipendenza da un singolo ambiente.

    Lasciami dire che il Basic originale, pur essendo nato per i principianti (la "B" sta per Beginners"), si è evoluto ed ha avuto un grande seguito soprattutto nella "nicchia" degli elaboratori scientifici e delle macchine a controllo numerico (particolarmente Hewlett & Packard e Olivetti), e si è poi conquistato il favore del grande pubblico grazie alla sua immediatezza e intuitività: all'inizio era solo un interprete, bastava scrivere il programma, lanciarlo, e se non c'erano errori quello "girava" subito. Altro punto di forza era l'allocazione delle variabili in modo dinamico, al momento dell'utilizzo, senza bisogno di dichiarative. Ma questo è il passato.

    Sul VB per Access concordo, non è nè carne nè pesce, mentre con Visual Studio la Microsoft ha scelto la via di integrare vari strumenti sotto un'unica piattaforma, l'intento è lodevole, ma altrettanto lodevole è la salvaguardia di tutto il pregresso scritto con i vecchi sistemi, come tutte le Case serie fanno ed hanno fatto in passato (prima di Microsoft la IBM, la Olivetti, l'HP e via discorrendo, anche se per queste ultime si parla di software proprietario).

    L'evoluzione secondo me va proprio nella direzione da te indicata ... le differenze tra VB e C# si assottigliano e si indirizzano meglio agli utenti professionisti e allo sviluppo in rete, ma lasciando alle spalle un vuoto per quanto riguarda i dilettanti "fai da te", e anche a quelli che - come me - adottano un approccio più sistemistico.

    Quote Originariamente inviato da MarcoGG Visualizza il messaggio
    Tu stesso hai intitolato questa discussione con : "Variabile pubblica non valorizzata da funzione in DLL". Ma se poi usi delle Sub dove sono le Funzioni ?
    Mi dispiace per l'equivoco sui termini, e mi sforzerò di essere più puntuale nelle mie richieste: per me Sub e Function sono due aspetti della stessa cosa (un pezzo di codice richiamabile e rientrante), nel titolo m'è scappato Function ma avrei tranquillamente potuto scrivere Sub, e non sono d'accordo sulla raccomandazione di privilegiare le Function a scapito delle Sub ... può essere giusto per tante funzioni di utilità, come delle semplici conversioni o normalizzazioni di dati, ma se la "funzione" da risolvere è più complessa, la Sub è più flessibile: io sono solito metterci ... di tutto e di più, isolando funzioni applicative complesse che comprendono anche migliaia di statements. Un esempio: passando il percorso di una cartella, recuperare le informazioni sui files contenuti (scansioni fotografiche), filtrarle, interpretarne le caratteristiche e produrre un file ascii con cui alimentare le tabelle di Access.

    La Sub nella DLL: nelle mie intenzioni serviva a valorizzare in un sol colpo tutte le variabili di uso comune che tutti i miei programmi condividono, e che non cambiano mai o quasi, e le dichiarative dei tracciati record più usati; fino ad ora le avevo inserite in moduli separati (.bin) che venivano inglobati nel sorgente tramite i metacomandi di tipo INCLUDE, cosa che non è più possibile con VB.NET. E' un problema che sussiste a prescindere dal porting o meno ... farlo con "settings" ... proverò, ma se mi cambia il valore di un parametro che devo fare? Cambiarlo in tutte le applicazioni che la usano? Quanto all'XML ... se mi risolve la cosa mi studierò anche quello.
    Ultima modifica di il Fenomeno; 24-09-2012 09:38 
    ℹ️ Leggi di più su il Fenomeno ...

  10. #10
    Quote Originariamente inviato da il Fenomeno Visualizza il messaggio
    Mi sono chiesto a lungo se continuare a mantenere separato lo sviluppo con VB.NET e le interrogazioni su ACCESS, o limitarmi a quest'ultimo sviluppando solo in VBA lasciando perdere Visual Studio ... tuttora sono in forse, ma la 1a strada mi garantisce maggior indipendenza da un singolo ambiente.
    Sicuramente non sei un neofita e sai il fatto tuo, ma accetta un consiglio da chi sa cosa significa ordinare un Array in VBA e VB.NET ( ) :
    il VBA di Access lascialo stare. Usa Access come base dati e nient'altro. Sviluppa in .NET.

    Quote Originariamente inviato da il Fenomeno Visualizza il messaggio
    Lasciami dire che il Basic originale, pur essendo nato per i principianti (la "B" sta per Beginners"), si è evoluto ed ha avuto un grande seguito soprattutto nella "nicchia" degli elaboratori scientifici e delle macchine a controllo numerico (particolarmente Hewlett & Packard e Olivetti), e si è poi conquistato il favore del grande pubblico grazie alla sua immediatezza e intuitività: all'inizio era solo un interprete, bastava scrivere il programma, lanciarlo, e se non c'erano errori quello "girava" subito. Altro punto di forza era l'allocazione delle variabili in modo dinamico, al momento dell'utilizzo, senza bisogno di dichiarative. Ma questo è il passato.

    ...

    L'evoluzione secondo me va proprio nella direzione da te indicata ... le differenze tra VB e C# si assottigliano e si indirizzano meglio agli utenti professionisti e allo sviluppo in rete, ma lasciando alle spalle un vuoto per quanto riguarda i dilettanti "fai da te", e anche a quelli che - come me - adottano un approccio più sistemistico.
    Vero. Dare a Cesare quel che è di Cesare. Immediatezza e intuitività non le discuto.

    MS ha ufficialmente iniziato il lungo cammino della convergenza se non erro già da VS2005 FW2.0.
    Personalmente credo che i tempi siano maturi per darci finalmente un taglio con queste "contaminazioni di retro-compatibilità".

    Quote Originariamente inviato da il Fenomeno Visualizza il messaggio
    ...
    La Sub nella DLL: nelle mie intenzioni serviva a valorizzare in un sol colpo tutte le variabili di uso comune che tutti i miei programmi condividono, e che non cambiano mai o quasi, e le dichiarative dei tracciati record più usati; fino ad ora le avevo inserite in moduli separati (.bin) che venivano inglobati nel sorgente tramite i metacomandi di tipo INCLUDE, cosa che non è più possibile con VB.NET. E' un problema che sussiste a prescindere dal porting o meno ... farlo con "settings" ... proverò, ma se mi cambia il valore di un parametro che devo fare? Cambiarlo in tutte le applicazioni che la usano? Quanto all'XML ... se mi risolve la cosa mi studierò anche quello.
    Ti dico come vedo io la cosa, molto semplicemente.
    Tu devi dare persistenza ad un lungo elenco di coppie Chiave-Valore. No ?
    Dal momento che i file INI sono in via di estinzione, queste "variabili di uso comune che tutti i miei programmi condividono" le metti in un file XML.
    L'unico autorizzato a scrivere il file XML e modificarne i valori sarà la DLL.
    Le Applicazioni chiameranno Subs o Functions della DLL e leggeranno dal medesimo XML.
    Un XML in .NET lo gestisci al volo con un DataTable che lo mappa...

    Che tipo di "persistenza" può offrirti una variabile Shared in una DLL ?
    Chiudi / riapri le applicazioni, modifica e ricompila le librerie, riavvia la macchina, ecc... Dove sono andati a finire quei valori ?
    ℹ️ Leggi di più su MarcoGG ...

+ Rispondi al messaggio
Pagina 1 di 2 12 ultimoultimo

Potrebbero interessarti anche ...

  1. Valore variabile pubblica
    Da OsvaldoLaviosa nel forum Microsoft Access
    Risposte: 6
    Ultimo Post: 19-08-2020, 15:56
  2. dichiarare come variabile pubblica la path del database
    Da marco61 nel forum Microsoft Access
    Risposte: 8
    Ultimo Post: 28-03-2019, 14:41
  3. Verificare ultima cella valorizzata in vb2010
    Da GRANDEANTONIO nel forum Visual Basic .Net
    Risposte: 10
    Ultimo Post: 13-05-2011, 10:07
  4. Variabile pubblica in modalità multiutente
    Da MorleyMan nel forum Microsoft Word
    Risposte: 9
    Ultimo Post: 28-04-2008, 15:37
  5. Dichiarare variabile Pubblica in Modulo in vb5/6
    Da satriano nel forum Visual Basic 6
    Risposte: 8
    Ultimo Post: 22-03-2006, 20:24