title: MVVM: due view sullo stesso view model?

text:
Mauro Servienti [MVP] presented the following explanation :
> Ciao Giulio,
>
> You wrote on 27/06/2011 :
>> 1. è giusto tenere la visualizzazione sincronizzata usando LO STESSO VIEW
>> MODEL per entrambe le view (l'editor che visualizza ClassFile.Code e il
>> solution explorer che visualizza ClassFile.ClassName)?
>
> broker.
>
>> 2. in alternativa, devo far implementare INotifyPropertyChanged al mio
>> oggettod i dominio? (e la cosa mi romperebbe alquanto perché MVVM è bello
>> anche perché il dominio non si "sporca" con queste cose)?
>
> Sacrilegio :-)
> Il dominio è il dominio e mi facci il dominio :-)
> Come dice Corrado wrappa e se vuoi scrocca da Radical
> (
http://radical.codeplex.com
) tutti gli automatismi del mondo per wrappare
> con semplicità, in Radical c'è una cosa che ti potrebbe interessare:
> Radical.Design che parte con uno scopo diverso ma potrebbe darti qualche
> idea:
>
http://milestone.topics.it/blog/post/design-time-data-reloaded
>
http://milestone.topics.it/blog/post/wrappa-che-ti-passa-how-to-in-salsa-tdd
>
> Quello che ti "interessa" è quel Wrapper<T> del secondo post :-)
>
>> 3. in alternativa, uso un message broker e tutti i VM che insistono su una
>> entità registrano un evento EntityChanged?
>
> amen
>
>> 4. (altre soluzioni?)
>
> baracchino in spiaggia? voi venite a suonare e i ci metto le bibite e i
> panini? :-)
>
> .m
Baracchino sulla spiaggia tutta la vita!
Non so suonare ma vengo lo stesso, porto i teli mare alle bagnanti :-P


title: MVVM: due view sullo stesso view model?

author: Giulio Petrucci

text:
Ciao a tutti,
On 6/27/2011 4:42 PM, Giulio Petrucci wrote:
[cut]
Grazie a tutti del consiglio.
Il baracchino in spiaggia si può fare: viste le competenze, io e
marcosabba diamo lezioni di musica, Corrado e Mauro danno lezioni di
MVVM. ;-)
Ciao e grazie,
Giulio
--


title: MVVM: due view sullo stesso view model?

author: Raffaele Rialdi [MVP]

text:
Mauro Servienti [MVP] wrote:
> Sacrilegio :-)
> Il dominio è il dominio e mi facci il dominio :-)
> Come dice Corrado wrappa e se vuoi scrocca da Radical
> (
http://radical.codeplex.com
) tutti gli automatismi del mondo per wrappare
> con semplicità, in Radical c'è una cosa che ti potrebbe interessare:
> Radical.Design che parte con uno scopo diverso ma potrebbe darti qualche
> idea:
>
http://milestone.topics.it/blog/post/design-time-data-reloaded
>
http://milestone.topics.it/blog/post/wrappa-che-ti-passa-how-to-in-salsa-tdd
>
> Quello che ti "interessa" è quel Wrapper<T> del secondo post :-)
Ah su questo non sono daccordo.
Non esiste un dominio puro. È e sempre sarà dipendente dal linguaggio
con cui lo scrivi. Domain C++ != Domain C#
Se il wrapping non è pesante, la soluzione del wrapper la prediligo
anch'io, ma se hai un dominio complesso che si sviluppa in un grado non
ordinato il wrapping non è facile neppure con la generazione di codice,
figuriamoci con classi helper.
La valutazione alla fine la devi fare sulla base del rapporto
benefici/costi, perchè il wrapper complesso ha sempre un costo alto
(manutenzione).
In pratica non mi piace una soluzione che viene adottata solo per
motivi "estetici" sacrificando pesantemente i costi di implementazione
e manutenzione.
--
Raffaele Rialdi
http://www.iamraf.net
Weblog:
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET -
http://www.ugidotnet.org/


title: MVVM: due view sullo stesso view model?

author: Mauro Servienti [MVP]

text:
Ciao Raff,
You wrote on 02/07/2011 :
> Ah su questo non sono daccordo.
> Non esiste un dominio puro. È e sempre sarà dipendente dal linguaggio con cui
> lo scrivi. Domain C++ != Domain C#
+1
> Se il wrapping non è pesante, la soluzione del wrapper la prediligo anch'io,
> ma se hai un dominio complesso che si sviluppa in un grado non ordinato il
> wrapping non è facile neppure con la generazione di codice, figuriamoci con
> classi helper.
> La valutazione alla fine la devi fare sulla base del rapporto benefici/costi,
> perchè il wrapper complesso ha sempre un costo alto (manutenzione).
ovvio :-) il wrapper complesso spesso ha un costo improponibile, ma ci
sono stati casi in cui mi sono reso conto che il wrapper complesso era
un sintomo di un dominio che alla fine non funzionava; non è una regola
generale ovviamente, am potrebbe essere un segnale da tenere in
considerazione.
> In pratica non mi piace una soluzione che viene adottata solo per motivi
> "estetici" sacrificando pesantemente i costi di implementazione e
> manutenzione.
condivido.
Dunque:
a) mai dare torto a Raf, i punti fragola che potrei guadagnare non
valgono mai il rischio :-)
Scherzi a parte, condivido su tutta la linea, è che domande come questa
varrebbero 3 giorni di corso non un post e quando si risponde ad un
post si rischia sempre di tralasciare molte cose.
La soluzione unica non c'è mai, proprio mai, quel Wrapper<T> l'ho usato
qualche volta in produzione, l'ho usato una quantità notevole di volte
per realizzare velocemente i design-time-data in situazioni complesse
per far si che Blend funzionasse.
Tendo ad evitare come la peste gli automatismi che sono la manna in
casi semplici ma quando lo scenario è vasto (o complesso) gli
automatismi sono il male perchè sei blindato proprio negli automatismi.
Gli automatismi che "amo" invece sono quelli che mi possono permettere
di risparmiare poche righe di codice quasi sempre semplici (penso ad
esempio a INotifyPropertyChanged), dove però quelle poche righe di
codice sono ripetute una quantità spaventosa di volte; anche in questo
caso però pretendo che se su 100 volte 2 devo farle diverse non devo
impazzire per liberarmi dell'automatismo.
In questa direzione "Compiler as Service" mi sollazza non poco, e
spesso spero che "lui" (il papà di C#) si convinca che AOP possa essere
un first-class-citizen valido nel framework :-)



title: MVVM: due view sullo stesso view model?

text:
Mauro Servienti [MVP] wrote:
> Ciao Raff,
Hi Mauro,
> ovvio :-) il wrapper complesso spesso ha un costo improponibile, ma ci sono
> stati casi in cui mi sono reso conto che il wrapper complesso era un sintomo
> di un dominio che alla fine non funzionava; non è una regola generale
> ovviamente, am potrebbe essere un segnale da tenere in considerazione.
Si, chiaro, ma la fase di design del domain è antecedente e se è fatto
male la paghi a tutti i livelli e sempre più cara man mano che vai
avanti nel progetto.
È piuttosto comune chge il dm sia un grafo ciclico (quindi non un
albero) su cui il wrapping diventa immediatamente complesso.
> condivido.
>
> Dunque:
> a) mai dare torto a Raf, i punti fragola che potrei guadagnare non valgono
> mai il rischio :-)
LOL :)
>
> Scherzi a parte, condivido su tutta la linea, è che domande come questa
> varrebbero 3 giorni di corso non un post e quando si risponde ad un post si
> rischia sempre di tralasciare molte cose.
verissimo, ma preferisco che rimanga almeno il dubbio in chi legge
questi post piuttosto della certezza di "obbedire" ad una supposta
regola generale nel considerare un sacrilegio l'implementazione di
un'interfaccia 'di servizio' nel dm ;)
> La soluzione unica non c'è mai, proprio mai, quel Wrapper<T> l'ho usato
> qualche volta in produzione, l'ho usato una quantità notevole di volte per
> realizzare velocemente i design-time-data in situazioni complesse per far si
> che Blend funzionasse.
Non mi fraintendere, anche se non l'ho provato, la soluzione che
proponi è una manna dal cielo per una serie di casi.... ma non certo
per tutti.
>
> Tendo ad evitare come la peste gli automatismi che sono la manna in casi
> semplici ma quando lo scenario è vasto (o complesso) gli automatismi sono il
> male perchè sei blindato proprio negli automatismi.
> Gli automatismi che "amo" invece sono quelli che mi possono permettere di
> risparmiare poche righe di codice quasi sempre semplici (penso ad esempio a
> INotifyPropertyChanged), dove però quelle poche righe di codice sono ripetute
> una quantità spaventosa di volte; anche in questo caso però pretendo che se
> su 100 volte 2 devo farle diverse non devo impazzire per liberarmi
> dell'automatismo.
La INPC è il classico esempio in cui si sente la mancanza di un
supporto specifico a livello di linguaggi ... alla fine non è
nient'altro che la generazione di una manciata di righe di codice.
Magic-Attribute su codeplex risolve in modo semplice l'implementazione
di INPC anche se ho preferito non utilizzarlo nei miei progetti.
> In questa direzione "Compiler as Service" mi sollazza non poco, e spesso
> spero che "lui" (il papà di C#) si convinca che AOP possa essere un
> first-class-citizen valido nel framework :-)
quoto, ma ho paura che sia passato in secondo piano visto che nelle
ultime conference non ne hanno più parlato.



title: MVVM: due view sullo stesso view model?

text:
Ciao Raff,
You wrote on 02/07/2011 :
>> Scherzi a parte, condivido su tutta la linea, ï¿œ che domande come questa
>> varrebbero 3 giorni di corso non un post e quando si risponde ad un post si
>> rischia sempre di tralasciare molte cose.
>
> verissimo, ma preferisco che rimanga almeno il dubbio in chi legge questi
> post piuttosto della certezza di "obbedire" ad una supposta regola generale
> nel considerare un sacrilegio l'implementazione di un'interfaccia 'di
> servizio' nel dm ;)
yes
>
>> La soluzione unica non c'ï¿œ mai, proprio mai, quel Wrapper<T> l'ho usato
>> qualche volta in produzione, l'ho usato una quantitï¿œ notevole di volte per
>> realizzare velocemente i design-time-data in situazioni complesse per far
>> si che Blend funzionasse.
>
> Non mi fraintendere, anche se non l'ho provato, la soluzione che proponi ï¿œ
> una manna dal cielo per una serie di casi.... ma non certo per tutti.
io sono un po' piï¿œ drastico, la soluzione che proprpongo e che ho io
stesso ho realizzato ï¿œ una manna dal cielo in pochi casi purtroppo,
perchï¿œ ha dei vincoli strutturali che per come funziona la risuluzione
dei tipi nel framework sono insormontabili....maledizione :-)
>> In questa direzione "Compiler as Service" mi sollazza non poco, e spesso
>> spero che "lui" (il papï¿œ di C#) si convinca che AOP possa essere un
>> first-class-citizen valido nel framework :-)
>
> quoto, ma ho paura che sia passato in secondo piano visto che nelle ultime
> conference non ne hanno piï¿œ parlato.
giï¿œ... :-/



title: MVVM: due view sullo stesso view model?

text:
Mauro Servienti [MVP] wrote:
> io sono un po' piï¿œ drastico, la soluzione che proprpongo e che ho io stesso
> ho realizzato ï¿œ una manna dal cielo in pochi casi purtroppo, perchï¿œ ha dei
> vincoli strutturali che per come funziona la risuluzione dei tipi nel
> framework sono insormontabili....maledizione :-)
generazione di codice... questa ï¿œ la soluzione secondo me



title: Salvataggio file Base64 da web service

text:
Ciao,
pensavo fosse una cosa banale ma mi sono incartato e non riesco a
chiuderla...
Dunque, ho un web service con una property byte[] con datatype
"base64Binary":

[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified,
DataType="base64Binary")]
        public byte[] file {get; set;}
Come faccio a salvare il file su file system decodificandolo?
Grazie
Stefano


title: Salvataggio file Base64 da web service

text:

NB: sò che posso usare Convert.FromBase64String(), è corretto fare una
chiamata del tipo:

Convert.FromBase64String(Encoding.Default.GetString( attachment.file))
?


title: [1/2OT] Riviste

text:
Secondo voi c'è qualche rivista che vale la pena di acquistare per
essere aggiornati su novità con tecniche e tecnologie di
programmazione?


title: [1/2OT] Riviste

text:
Ciao _merlinO_,

You wrote on 29/10/2011 :
> Secondo voi c'è qualche rivista che vale la pena di acquistare per essere
> aggiornati su novità con tecniche e tecnologie di programmazione?

"MSDN Magazine" per il mondo MS (e ultimamente non solo)

.m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro

blog @
http://milestone.topics.it

whynot [ at ] topics [ dot ] it


title: [1/2OT] Riviste

text:
On 29 Ott, 16:55, Mauro Servienti [MVP] <mauroservie...@online.nospam>
wrote:

> "MSDN Magazine" per il mondo MS (e ultimamente non solo)

Ma esiste in cartaceo con spedizione a casetta?

Al3x


title: [1/2OT] Riviste

text:
Ciao Al3xI98O,

si,
http://msdn.microsoft.com/en-us/magazine/ee358702.aspx




title: Punti comuni tra DataReader e DataTable

author: vbMizio

text:
Ciao a tutti,
sto cercando qualche cosa che, a naso, dovrebbe essere difficile trovare, ma
io ci provo ugualmente.
Quando ho una classe fortemente legata ad un database, all'interno della
classe stessa c'e' sempre la presenza di una funzione ReadData che, tramite
una query SQL, ottiene un DataReader a singola riga. Da questo DataReader,
carico i dati, valorizzando le variabili locali della classe stessa.
Nella maggior parte dei casi, questa tecnica e' quella che preferisco.
Ci sono situazioni pero', ad esempio se mi serve una lista corposa di
oggetti della classe in esempio, in cui l'utilizzo di un DataSet, e quindi
di un DataTable, migliorerebbe di molto le prestazioni totali.
Vorrei pero' evitare di scrivere due metodi distinti di caricamento dati,
uno per il DataReader, uno per il DataTable, ed a questo punto parte la
domanda....
Esiste una interfaccia comune tra un DataReader e un DataTable (o, nel caso,
un DataRow) ?
In fondo a me serve di leggere solo il contenuto della prprieta'  "Item" del
DataReader o del DataRow.
Qualche idea?
Ah, solo per completezza di informazione, uso VB.Net 2008


title: Punti comuni tra DataReader e DataTable

author: Sander

text:

se posso darti un consiglio, guarda gli ORM tra i quali Entity Framework
mi pare finora svolga un egregio lavoro. Anch'io ero un fan di DataTable
e DataReader ed ero titubante...ma una volta che 'assaggi' cosa vuol
dire lavorare con delle 'pettinatissime' classi già modellate che
rispecchiano il db e ti offrono dei semplicissimi metodi per le CRUD, la
tecnologia precedente sembra preistoria!
Sander


title: Punti comuni tra DataReader e DataTable

text:
Ciao vbMizio,
You wrote on 21/12/2010 :
> Quando ho una classe fortemente legata ad un database, all'interno della
> classe stessa c'e' sempre la presenza di una funzione ReadData che, tramite
> una query SQL, ottiene un DataReader a singola riga. Da questo DataReader,
> carico i dati, valorizzando le variabili locali della classe stessa.
> Nella maggior parte dei casi, questa tecnica e' quella che preferisco.
> Ci sono situazioni pero', ad esempio se mi serve una lista corposa di oggetti
> della classe in esempio, in cui l'utilizzo di un DataSet, e quindi di un
> DataTable, migliorerebbe di molto le prestazioni totali.
falso, punto :-) resta col tuo bel DataReader.
.m
--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @
http://milestone.topics.it
whynot [ at ] topics [ dot ] it


title: Punti comuni tra DataReader e DataTable

text:
On 12/22/2010 8:15 AM, Mauro Servienti [MVP] wrote:
> falso, punto :-) resta col tuo bel DataReader.
e a questo punto un "perché?" ci sta tutto! :-D
Ciao e buona giornata,
Giulio
--


title: Punti comuni tra DataReader e DataTable

text:
Ciao Giulio,
You wrote on 22/12/2010 :
> On 12/22/2010 8:15 AM, Mauro Servienti [MVP] wrote:
>> falso, punto :-) resta col tuo bel DataReader.
>
> e a questo punto un "perchï¿œ?" ci sta tutto! :-D
semplicemente perchï¿œ la DataTable per essere "fillata" con i dati ha
bisogno di un DataAdapter che probabilmente smarona un CommandBuilder
che sicuramente ha bisogno di un DataReader ergo alla fine c'ï¿œ un
DataReader ma sopra c'ï¿œ un sacco di roba in piï¿œ che non ï¿œ detto che
serva :-)
> Ciao e buona giornata,
> Giulio
.m



title: Punti comuni tra DataReader e DataTable

text:
...
>falso, punto :-) resta col tuo bel DataReader.
...
Mmm...
tenderei a fidarmi :-) pero' c'e' qualche cosa che non mi quadra,
probabilmente utilizzo una tecnica errata per leggere i miei dati.
Provo a fare qualche esempio per spiegarmi meglio.
In una classe, ho una proprieta' ID, quando valorizzo questa proprieta',
lancio una routine che "carica" i dati....
Public Property ID as Integer
    Set (byVal value as Integer)
        ' valorizzo la variabile locale
        ReadData
    End Set
    ' blocco Get
End Property
Private sub ReadData
    Dim DR as Datareader (bla bla)
End Sub
Adesso, ammettiamo che mi serva una lista di oggetti di questa classe; mi
costruisco una query sql che mi restituisce una lista di ID in base ai
parametri che mi servono, anche qui usando un DataReader, tipo:
Select ID from Tabella where *qualchecosa"
da questa query ottengo un DataReader, lo ciclo e memorizzo tutti gli ID
ottenuti in una lista (ad esempio List (of Integer) ).
Una volta ottenuta la lista, devo ciclare ogni elemento della lista stessa,
che non e' altro che un intero che rappresenta l'ID dell'oggetto, e per ogni
elmento mi costruisco un oggetto andando poi a valorizzare la proprieta' ID
dell'oggetto stesso, cioe':
For Each ID as Integer in lstID ' lstID, ovviamente e' la lista di integer
    Dim MioOggetto as New MiaClasse
    MioOggetto.ID = ID
    ' lo utlizzo o lo memorizzo in base a cio' che mi serve
Next
Da notare che ogni volta che chiudo un DataReader, chiudo automaticamente la
connessione associata, dato che per default passo sempre
CommandBehavior.CloseConnection come argomento al metodo ExecuteReader
dell'oggetto SqlCommand... forse e' questo che mi fa perdere tempo?
Cio' che mi viene in mente, e che comunque provero' (Mauro, nun t'arrabbia',
a Natale siamo tutti piu' buoni) e' che utilizzare una singola chiamata per
costruire un DataSet e da quello estrarre una DataTable, e poi ciclare le
righe della stessa, dovrebbe essere piu' veloce, nelle condizioni che ho
descritto.
Chiaro che sulla lettura singola, e probabilmente anche di poche righe, il
DataReader dovrebbe essere un bel po' piu' veloce.
Voi che ne dite?


title: Punti comuni tra DataReader e DataTable

author: Andrea Saltarello

text:
Il 29/12/2010 09:28, vbMizio ha scritto:
> Adesso, ammettiamo che mi serva una lista di oggetti di questa classe;
> mi costruisco una query sql che mi restituisce una lista di ID in base
> ai parametri che mi servono, anche qui usando un DataReader, tipo:
> Select ID from Tabella where *qualchecosa"
> da questa query ottengo un DataReader, lo ciclo e memorizzo tutti gli ID
> ottenuti in una lista (ad esempio List (of Integer) ).
che poi:
- Reflector alla mano, è la stessa strategia attuata dal metodo Fill del
DataAdapter quando "riempie" un DataSet/DataTable
- è la stessa cosa che fa un O/RM (Entity Framework, Linq2SQL,
NHibernate, ...) quando materializza una lista di oggetti
un consiglio: passa ad Entity Framework (più che altro a causa del Linq
provider, che in NH purtroppo è ancora troppo acerbo) e vivi felice :-)
--
.A
GUISA -
http://www.guisa.org
UGIdotNET -
http://www.ugidotnet.org
Read my blog at:
http://blogs.ugidotnet.org/pape


title: Punti comuni tra DataReader e DataTable

text:
Ciao, grazie per  la risposta
...
>un consiglio: passa ad Entity Framework (più che altro a causa del Linq
provider, che in NH purtroppo è ancora troppo acerbo) e vivi felice :-)
...
Lo faro', ma non subito.
Purtroppo in produzione non abbiamo molto tempo per studiare e provare
soluzioni nuove (solito annoso problema delle piccole realta'.. e forse da
qualche anno anche di quelle piu' grandi).
Ho pero' iniziato a studiare da capo il C# 2008, un po' per il linguaggio in
se, un po' per le novita' che ci sono state nel tempo fino al 2008... poi
appena finito, passero' al 2010 ma nel frattempo sara' uscito 2015 ecc... e'
tutto un rincorrere, ed in ritardo :-)
Oggi mi tocca della manutenzione su roba vb6 :-)


title: Punti comuni tra DataReader e DataTable

text:

butto lï¿œ un paio di considerazioni:
1. in .net non c'ï¿œ nulla di piï¿œ efficiente (per la lettura) di un
datareader. ï¿œ un cursore di tipo server, forward-only. Se usi un
provider puro managed non hai neppure il performance hit
dell'interoperabilitï¿œ verso codice nativo, di conseguenza ï¿œ il top.
2. La datatable non sa neppure cosa sia un database. ï¿œ un oggetto
'generico' in memoria che viene riempito da un dataadapter (che usa un
datareader. Come scrive Andrea nulla di piï¿œ di quello che fanno gli
OR/M quando materializzano oggetti.
Ergo il paragone tra datareader e datatable non ï¿œ neppure fattibile
3. Datatable/dataset hanno grossi problemi di performance se non fai
alcune operazioni vitali come la disabilitazione degli eventi durante
il caricamento. In piï¿œ hai tonnellate di boxing/unboxing se i dati che
metti nella datatable sono dei valuetype. Ergo le performance con la
datatable sono tragiche in molti casi.
4. Se guardi
rafcollection.codeplex.com
 trovi la mia collection che ha
gli stessi vantaggi di una datatable ma senza gli hit di performance.
Per farti un'idea leggi almeno il documento iniziale.
Nell'esempio (sempre pubblicato su codeplex) c'ï¿œ un sistema per fillare
oggetti che usa in modo generico un datareader ma ti consente di
gestire il mapping verso una tua classe in modo molto semplice.
ï¿œ di fatto un micro-or/m in cui il mapping ï¿œ fatto via codice. Diciamo
un modo per avvicinarsi ali or/m veri.
5. Come giï¿œ scritto dagli altri, vai con EF4. Grazie all'ultimo feature
pack 'code-first ctp5' non ï¿œ ancora il  paradiso, ma poco ci manca :)
--
Raffaele Rialdi
Microsoft .NET MVP
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog:
http://blogs.ugidotnet.org/raffaele


title: Punti comuni tra DataReader e DataTable

author: LudovicoVan

text:
On Dec 29, 3:04 pm, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
>
wrote:
> [...] il mapping verso una tua classe in modo molto semplice.
> di fatto un micro-or/m in cui il mapping fatto via codice. Diciamo
> un modo per avvicinarsi ali or/m veri.
Per un approccio a basso livello, citerei anche il DAAB.
> 5. Come gi scritto dagli altri, vai con EF4. Grazie all'ultimo feature
> pack 'code-first ctp5' non ancora il  paradiso, ma poco ci manca :)
Paradiso del RAD vorrai dire... ;)
-LV


title: Punti comuni tra DataReader e DataTable

text:
> Paradiso del RAD vorrai dire... ;)
Non necessariamente.
Personalmente uso la CTP5, nessun designer, ma solo le fluent api.



title: Punti comuni tra DataReader e DataTable

text:
On Dec 29, 5:17 pm, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
>
wrote:
>
> > Paradiso del RAD vorrai dire... ;)
>
> Non necessariamente.
> Personalmente uso la CTP5, nessun designer, ma solo le fluent api.
Si', ma tu sei Raf... :)
-LV


title: Punti comuni tra DataReader e DataTable

text:
Ciao Raf
....
>butto lì un paio di considerazioni:
1. in .net non c'è nulla di più efficiente (per la lettura) di un
datareader. È un cursore di tipo server, forward-only.
...
Ok, mi ri-fido e provo a cambiare approccio alla cosa, anziche' aprire la
connessione, chiedere una riga, chiudere la connessione e ripetere per n
volte, mi faccio restituire un DataReader "completo" e poi costruisco i vari
oggetti
...
>5. Come già scritto dagli altri, vai con EF4. Grazie all'ultimo feature
pack 'code-first ctp5' non è ancora il  paradiso, ma poco ci manca :)
...
Ehhh...
sto ancora lontano da quella roba. Come ho detto piu' volte, qui si pretende
che le cose funzionino dopo due ore dalla richiesta, non c'e' tempo per
studiare cose nuove.
Per studiare e provare, lo devo fare solo soletto, a casa, quando ho tempo.
Tra i buoni propositi del 2011 c'e' anche il dedicare almeno un'ora, ma
anche un'ora e mezza, 3 giorni alla settimana, allo studio di C#2008 con
tutte le novita' (per me) che ci sono nel FW 3.5... vedremo qundo riusciremo
a vedere il 4 :-)


title: Punti comuni tra DataReader e DataTable

text:
On Dec 30, 11:06 am, "vbMizio" <
vbmi...@io.it
> wrote:
> Ciao Raf
> ....>butto l un paio di considerazioni:
>
> 1. in .net non c' nulla di pi efficiente (per la lettura) di un
> datareader. un cursore di tipo server, forward-only.
> ...
> Ok, mi ri-fido e provo a cambiare approccio alla cosa, anziche' aprire la
> connessione, chiedere una riga, chiudere la connessione e ripetere per n
> volte, mi faccio restituire un DataReader "completo" e poi costruisco i vari
> oggetti
Ado.Net fa di default il "connection pooling", per cui la best
practice resta quella di aprire e subito chiudere la connessione li'
dove ti serve. Inoltre (correggetemi se sbaglio) un datareader read-
only/forward-only ha proprio il vantaggio di non restituirti nulla di
"completo", e' piuttosto l'equivalente di uno stream in lettura...
La bottom line e' che di solito conviene fare le cose da manuale, a
meno che uno non abbia la necessita' e le idee abbastanza chiare da
voler davvero fare altro.
> ...>5. Come gi scritto dagli altri, vai con EF4. Grazie all'ultimo feature
>
> pack 'code-first ctp5' non ancora il  paradiso, ma poco ci manca :)
> ...
> Ehhh...
> sto ancora lontano da quella roba. Come ho detto piu' volte, qui si pretende
> che le cose funzionino dopo due ore dalla richiesta, non c'e' tempo per
> studiare cose nuove.
Ti capisco, ed e' ovviamente un problema alquanto diffuso. La mia
strategia in proposito e' comunque forzare sempre un po' verso il
nuovo: per esempio, passare a .Net 4, con annessi e connessi, non
necessariamente deve implicare che ne conosci a menadito tutte le
potenzialita': di sicuro da guardare le realease notes, per vedere le
principale differenze con la versione precedente (e quindi gli
eventuali problemi di compatibilita'/portabilita' rispetto a cio' che
gia' hai), ma poi le cose nuove uno le puo' vedere una alla volta, con
calma e via via che se ne presenta la necessita' o, ancora meglio,
l'opportunita'... In ogni caso, escono talmente tante cose a talmente
alta velocita' che pensare e tentare di padroneggiarle tutte piuttosto
comporta la paralisi...
La bottom line qui per me e' sempre ricordare che, poiche' compromesso
ci deve essere, allora sono i requisiti espliciti che vengono prima di
quelli impliciti.
My 2c,
-LV


title: Punti comuni tra DataReader e DataTable

text:
Il 30/12/2010 16:25, LudovicoVan ha scritto:
> La bottom line qui per me e' sempre ricordare che, poiche' compromesso
> ci deve essere, allora sono i requisiti espliciti che vengono prima di
> quelli impliciti.
da scolpire nella pietra ed esporre all'ingresso di ogni software house
(e non solo)



title: Punti comuni tra DataReader e DataTable

text:
On Dec 30, 6:10 pm, Andrea Saltarello <andysalTOGL...@NOgmailSPAM.com>
wrote:
> Il 30/12/2010 16:25, LudovicoVan ha scritto:
>
> > La bottom line qui per me e' sempre ricordare che, poiche' compromesso
> > ci deve essere, allora sono i requisiti espliciti che vengono prima di
> > quelli impliciti.
>
> da scolpire nella pietra ed esporre all'ingresso di ogni software house
> (e non solo)
Nell'ambito della dialettica problema/soluzione, non ti seguo... Il
RAD da solo basta forse oggi ed e' sicuramente un debito domani: il
compromesso, mi pare, e' tutto e solo li'.
-LV


title: Punti comuni tra DataReader e DataTable

text:
Il 30/12/2010 20:29, LudovicoVan ha scritto:
> Nell'ambito della dialettica problema/soluzione, non ti seguo...
semplicemente, stavo affermando che condivido in toto la tua
affermazione che avevo quotato, tutto qui



title: Punti comuni tra DataReader e DataTable

text:
vbMizio wrote:
> Ciao Raf
> ....
>>butto lì un paio di considerazioni:
> 1. in .net non c'è nulla di più efficiente (per la lettura) di un
> datareader. È un cursore di tipo server, forward-only.
> ...
> Ok, mi ri-fido e provo a cambiare approccio alla cosa, anziche' aprire la
> connessione, chiedere una riga, chiudere la connessione e ripetere per n
> volte, mi faccio restituire un DataReader "completo" e poi costruisco i vari
> oggetti
Essendo un cursore server il datareader non restituisce nulla di
completo, come anche ha scritto Ludovico.
Tu apri la connessione, esegui la query, fai un ciclo sulla Read del
datareader e nel finally chiudi il datareader e la connessione.
Al momento in cui fai la Read ottieni i dati di una riga e con questa
crei l'oggetto corrispondente.
Se guardi l'esempio di codeplex che ti ho linkato trovi anche questa
parte, resa opportunamente generica con tanto di gestione dei
DBNull.Value (cioè i null del db che non corrispondono e non possono
ovviamente corrispondere ai null di .net).



title: Punti comuni tra DataReader e DataTable

text:
Ciao a tutti,
mi accodo qui per dare una risposta unica, naturalmente i ringraziamenti
vanno a tutti
...
>Essendo un cursore server il datareader non restituisce nulla di
completo, come anche ha scritto Ludovico.
...
Si si, il concetto mi e' e mi era chiaro, mi sono espresso male,
per "completo" intendevo dire proprio quello che suggerisce Raffaele,
quindi...
...
>Tu apri la connessione, esegui la query, fai un ciclo sulla Read del
datareader e nel finally chiudi il datareader e la connessione.
...
Intendevo proprio questo, so bene che per la natura del DataReader non mi
viene dato nulla in memoria, se non la riga corrente.
Grazie ancora a tutti e buon 2011! (non saro' l'unico che il 31 e' ancora al
lavoro... vero?!?! )


title: Punti comuni tra DataReader e DataTable

text:
Ciao,
...
> La mia
strategia in proposito e' comunque forzare sempre un po' verso il
nuovo: per esempio, passare a .Net 4, con annessi e connessi, non
necessariamente deve implicare che ne conosci a menadito tutte le
potenzialita'
....
Questa e' anche la mia strategia, ho dovuto insistere non poco per passare
da VB6 a Net, pero' per giustificare una "perdita di tempo" (mooolto
virgolettato) per apprendere un nuovo linguaggio o una nuova tecnica, devo
far risaltare i vantaggi "visibili".
Sembrera' un assurdo, ma di manutenibilita', praticita' ecc.. fanno fatica a
capire, ma il far vedere una listview "colorata", giustifica il passaggio a
Net :-(


title: Punti comuni tra DataReader e DataTable

text:

E' ovviamente un serio limite che nel nostro campo oggi sempre piu'
viga una sorta di... schizofrenia: uno scollamento fra la realta'
tecnologica e le aspettative del nostro committente interno, il quale
sempre piu' pensa di poterci "condurre" li' dove noi per primi
mostriamo poca solidita'.
Alcuni ulteriori consigli sparsi (al viandante che si trovi a
leggere):
1) certe distinzioni devono essere chiare a te e a nessun altro (non-
tecnico: i requisiti impliciti sono cio' di cui *non* si deve
discutere);
2) ne consegue che, se puoi farne a meno, *non* devi chiedere
autorizzazione su niente a nessuno: cio' che conta e' produrre il
risultato; e continuare a produrlo; (es. l'ultimo mio cliente era
ancora a ASP/VB/SQL2K: l'applicativo strategico l'ho fatto con VS2010
Express su SQL2008 Express su SVN: una favola... poi la fiducia
comunque era compromessa e me ne sono andato, ma chi mi ha sostituito
non ripartira' da ASP/VB... ho fatto bene o ho fatto male?)
3) i costi dell'apprendimento/aggiornamento non devono ricadere sul
committente: cioe', non ufficialmente/direttamente/esplicitamente...
piuttosto ricordagli sempre quanto e' scomodo il tuo sedile; (dopo
circa 20 anni di professione mi ritrovo una tendinite: usate i poggia-
polsi se davvero intendete fare questo mestiere;)
4) il nostro committente va preso... per la gola! Questo come minimo
significa che su certe cose fondamentali "o e' cosi' o niente". Oserei
dire che e' li' la principale differenza fra un principiante e un
esperto: nella capacita' di tirare quella linea.
Se uno consistentemente risolve problemi, la fiducia viene; e se poi
non viene (c'e' cliente e cliente), comunque non avrai perso il tuo
tempo...
D'altronde, e cosi' questo piccolo cerchio si chiude, construire
quella fiducia con buoni clienti e' uno di quegli skill da appendere
al muro, molto piu' importante della versione del framework in uso...
In bocca al lupo,
-LV


title: Punti comuni tra DataReader e DataTable

author: dedalus

text:
On 29/12/2010 09:28, vbMizio wrote:
> lancio una routine che "carica" i dati....
> Public Property ID as Integer
>    Set (byVal value as Integer)
>        ' valorizzo la variabile locale
>        ReadData
>    End Set
>    ' blocco Get
> End Property
>
> Private sub ReadData
>    Dim DR as Datareader (bla bla)
> End Sub
Quindi non separi DAL da BLL?


title: Punti comuni tra DataReader e DataTable

text:
Ciao,
...
>Quindi non separi DAL da BLL?
...
Beh, qui c'e' poco da separare... la mia classe deve saper leggere i propri
dati dal DB, e credo che questo metodo sia il migliore.
Fare una classe separata per fare da parser? In questo caso mi sembra
davvero una lungaggine... naturalmente IMHO :-)


title: Punti comuni tra DataReader e DataTable

text:
Ciao,
>Alcuni ulteriori consigli sparsi (al viandante che si trovi a
leggere):
....
Facciamo che il viandante in questione sia io :-)
....
>1) certe distinzioni devono essere chiare a te e a nessun altro (non-
tecnico: i requisiti impliciti sono cio' di cui *non* si deve
discutere);
...
*quasi* vero.
Nel mio caso, dato che sono un semplice dipendente di una piccola azienda,
se il mio capo (che poi e' quello che mi paga) mi dice...
"fammi questa cosa, e me la fai per domani mattina", hai voglia a dire...
guarda, se mi dai piu' tempo, te la faccio con una nuova tecnologia ecc..
ecc..
Pero' per farla devo imparare come si fa, e poi mi rimane utile per i tempi
a vernire; la risposta e'.. mi serve per oggi pomeriggio, se fai prima a
farla in Access, falla in Access :-)
....
>2) ne consegue che, se puoi farne a meno, *non* devi chiedere
autorizzazione su niente a nessuno
....
Vedi sopra :-)
...
>3) i costi dell'apprendimento/aggiornamento non devono ricadere sul
committente
...
Dipende da cosa intendi per committente. Se intendi il cliente finale, hai
perfettamente ragione, se intendi la mia azienda.. beh... qualche appunto lo
farei.
In qualunque azienda, la formazione del personale e' una spesa a carico
dell'azienda stessa. O sbaglio?
Che poi, io, armato di buona volonta' voglia studiare, migliorare ed
imparare per conto mio , ci sta, ma non credo sia un obbligo.
Chiaro poi che se, invece di un dipendente, uno e' un libero professionista,
tutto il discorso che ho fato cade a pezzi :-)


title: Punti comuni tra DataReader e DataTable

text:
Ciao LV,
On 12/30/2010 4:25 PM, LudovicoVan wrote:
> La bottom line qui per me e' sempre ricordare che, poiche' compromesso
> ci deve essere, allora sono i requisiti espliciti che vengono prima di
> quelli impliciti.
Ci potresti spendere due parole?
Grazie,
Giulio
--


title: Punti comuni tra DataReader e DataTable

text:
Ciao vbMizio,
On 12/30/2010 12:06 PM, vbMizio wrote:
> sto ancora lontano da quella roba. Come ho detto piu' volte, qui si
> pretende che le cose funzionino dopo due ore dalla richiesta, non c'e'
> tempo per studiare cose nuove.
Dal basso della mia esperienza, posso dirti che questo è un pessimo
approccio che porta sempre a soluzioni "fragili" e spesso di scarsa
qualità. Inoltre - ma questo lo dovrebbero capire i tuoi "boss" - a
lungo termine è una strategia antieconomica. Ovviamente non lo dico solo
per rigirare il coltello nella piaga, sia chiaro. :-P
Ciao e tanti auguri per i toi buoni propositi per il 2011,
Giulio
--


title: Punti comuni tra DataReader e DataTable

text:
Ciao Giulio,
...
>Dal basso della mia esperienza, posso dirti che questo è un pessimo
approccio che porta sempre a soluzioni "fragili" e spesso di scarsa
qualità.
...
Come credo ormai si sia capito chiaramente, io sono assssssssolutamente
d'accordo con quanto dici.
Il problema e' sempre il solito... chi mi paga non mi da la possibilita' di
prendermi del tempo per approfondire, migliorare ecc.. il problema poi sara'
principalmente il suo;  certo, anche io avro' difficolta' a crescere
professionalmente, questo e' certo, ecco perche' comunque *voglio* studiare
ancora. Ci mettero' un po' di tempo in piu', questo e' sicuro.
Grazie degli auguri, che naturalmente sono ricambiati :-)


title: Punti comuni tra DataReader e DataTable

text:
On Jan 3, 11:46 am, "vbMizio" <
vbmi...@io.it
> wrote:
> i requisiti impliciti sono cio' di cui *non* si deve discutere
> ...
> *quasi* vero.
E *totalmente* vero: che poi le realta' in cui ci troviamo a muoverci
sono tutte un po' compromesse, con inversioni di ruoli e dislocazione
di responsabilita' e competenze... insomma che e' troppo spesso tutto
sottosopra, e' un problema alquanto diverso. Quello che mi premeva
sottolineare, oltre al fatto che perlomeno uno dovrebbe sapere a cosa
assomigliano le cose fatte per bene, e' che la situazione nel nostro
settore e' tanto compromessa in primis per nostra stessa e diretta
responsabilita' (dell'intera categoria e dei suoi auto-goal), una
situazione che appunto solo noi operatori del settore potremo mai
risanare.
> Nel mio caso, dato che sono un semplice dipendente di una piccola azienda,
> se il mio capo (che poi e' quello che mi paga) mi dice...
Se il mio capo e' troppo fuori dal ragionevole, io lo mollo per altri
lidi. Non e' un consiglio, ma nemmeno ci sono scuse: la scelta di
fondo, di starci o non starci, e' tua e solo tua, e dovrebbe dipendere
da valutazioni non solo per l'immediato. A volte uno investe... a
volte gli investimenti vanno a male... ma nel complesso pagano... ecc.
E se non siamo disposti a fare discorsi un po' lungimiranti, di nuovo
siamo noi in primis a consolidare un trend generale di cui poi e'
inutile lamentarsi.
> autorizzazione su niente a nessuno
> ....
> Vedi sopra :-)
A te sta far "evolvere" il tuo capo verso qualcosa di tecnologicamente
piu' sensato (e professionalmente piu' dignitoso)... se e' possibile,
altrimenti dimmi che perlomeno ti da' ancora qualcosa da imparare
(risolvere problemi e' comunque lo skill che conta), altrimenti di
mollarlo alla prima occasione e' l'unico consiglio che mi sentirei di
dare.
> i costi dell'apprendimento/aggiornamento non devono ricadere sul committente
> ...
> Dipende da cosa intendi per committente. Se intendi il cliente finale, hai
> perfettamente ragione, se intendi la mia azienda.. beh... qualche appunto lo
> farei.
Questione di opinioni: su questo parto dal presupposto che il divario
fra cio' che e' e cio' che dovrebbe essere e' talmente abissale che la
formazione uno se la deve fare da se' (per non menzionare poi il
problema della *qualita'* della formazione disponibile, altro capitolo
dolente): semmai al mio capo "chiedo" di non fare *mai* straordinario,
e quanto alla mia formazione e' il motivo per cui da CV risulta che
lavoro una media di sei-nove mesi all'anno...
> In qualunque azienda, la formazione del personale e' una spesa a carico
> dell'azienda stessa. O sbaglio?
Sbagli... forse in Utopia, ma li' tanto per cominciare la qualita' dei
corsi e' tutt'un'altra cosa...
> Che poi, io, armato di buona volonta' voglia studiare, migliorare ed
> imparare per conto mio , ci sta, ma non credo sia un obbligo.
Certo che e' un obbligo: lo vuoi fare o non lo vuoi fare questo
mestiere? E *come* lo vuoi fare? :)
> Chiaro poi che se, invece di un dipendente, uno e' un libero professionista,
> tutto il discorso che ho fato cade a pezzi :-)
E' uguale: mai come nel nostro mestiere, con il suo altissimo
contenuto professionale, vale la massima che siamo tutti imprenditori
di noi stessi...
-LV


title: Punti comuni tra DataReader e DataTable

text:

Un po' di parole in questo thread ce le ho gia' spese: mi puoi
specificare un po' di piu' cosa ti interessa approfondire, o qual'e'
il dubbio, ecc.?
-LV


title: Punti comuni tra DataReader e DataTable

text:
Ciao LV,

Dal basso della mia ignoranza (e soprattutto dal basso di uno che non ha
una connessione internet dal 25 dicembre a causa di un guasto che la
Telecom non ha voluto riparare :-)) ti chiedo di:
- spiegare cosa intendi per bottom line
- spiegare cosa intendi per requisiti espliciti/impliciti
Grazie,
Giulio
--


title: Punti comuni tra DataReader e DataTable

text:
On Jan 3, 2:51 pm, Giulio Petrucci <sis...@nonono.boh> wrote:
> ti chiedo di:
> - spiegare cosa intendi per bottom line
E' un modo di dire anglofono: "the bottom line is...", che penso
corrisponda a "la morale della favola e'..."... right?
> - spiegare cosa intendi per requisiti espliciti/impliciti
In ingegneria informatica si distinguono i requisiti espliciti da
quelli impliciti:
-- I *requisiti espliciti* sono quelli che derivano da esigenze
(esplicite) del cliente: sulle funzionalita' desiderate, le
prestazioni attese, i livelli di interattivita'; ovviamente il cliente
parte da un'idea piu' o meno vaga, e sta al consulente informatico, in
qualita' di analista, di arrivare insieme al cliente ad una
comprensione adeguata del dominio del problema/soluzione;
:: se questi requisiti sono rispettati, il cliente e' soddisfatto.
-- I *requisiti impliciti* sono quelli che derivano da considerazioni
tecniche (implicite): sulla usabilita', la manutenibilita' (correzione
errori ma anche modifiche e estensioni), il riuso, ecc.; non e'
pensabile che il cliente debba o possa dare feedback a questo livello,
e sta al consulente informatico provvedere per un'adeguata
implementazione;
:: se questi requisiti non sono rispettati, il cliente e' molto
insoddisfatto.
Con il Quality Function Deployment (QFD, una tecnica sviluppata dalla
Mitsubishi negli anni '70) si aggiunge un terzo tipo di requisiti (i
primi due vengono chiamati requisiti normali e requisiti attesi):
-- I *requisiti straordinari* sono quelli che superano le attese del
cliente (per esempio in termini funzionali, ecc.);
:: se caratteristiche straordinarie sono presenti, il cliente e' molto
soddisfatto.
Ma con questo siamo gia' alla fantascienza... :)
Occorre un buon manuale di ingegneria informatica/del software per
fissare questi concetti.
-LV


title: Punti comuni tra DataReader e DataTable

text:
Ri-ciao,
....
>Se il mio capo e' troppo fuori dal ragionevole, io lo mollo per altri
lidi. Non e' un consiglio, ma nemmeno ci sono scuse: la scelta di
fondo, di starci o non starci, e' tua e solo tua, e dovrebbe dipendere
da valutazioni non solo per l'immediato. [... e tutto il resto...]
...
Si si, ci sto lavorando su. Assolutamente d'accordo con quello che dici, ed
infatti sto iniziando a guardarmi intorno.
Il problema e', credo sia comune a tutti, che non posso fare troppo lo
schizzignoso. Ho comunque una casa da portare avanti :-)
In realta' ho fatto anche un colloquio con una azienda *decisamente* piu'
organizzata, ed ero disposto anche a perderci dei soldi nell'immediato,
proprio perche' comunque offrivano la possibilita' di crescere (corsi, studi
e quant'altro).... Mi sa che pero', la mia richiesta economica era ancora
troppo alta per loro (e non ho chiesto la luna), oppure non gli sono
piaciuto.. boh.
In ogni caso avevo gia' dall'inizio preso la cosa come una piccola
esperienza, anche per capire come si fa un colloquio "serio", dato che
fin'ora non ne ho mai avuto bisogno (non che sia un raccomandato, ma ho
sempre lavorato con persone che in qualche modo mi conoscevano e sapevano
come lavoro).


title: rendere persistente una immagine e errore GDI+

text:
Ciao a tutti,
sto lavorando ad un progettino che deve essere in grado di rendere
persistente (su file in primis, ma non solo) una serie di oggetti che hanno,
tra le varie proprieta', una immagine.
Immaginate un catalogo di oggetti, dove ogni oggetto ha un codice articolo,
un prezzo ed una foto illustrativa.
Questo progettino implementa una funzione per salvare il catalogo, generando
un file xml che ha tanti elementi quanti sono gli oggetti del catalogo
stesso.
Sono riuscito anche a trovare un modo per rendere persistente le immagini,
senza naturalmente salvare l'immagine in formati immagine, e per fare questo
uso, per salvare l'immagine:

Dim bt() As Byte
Dim cnv As System.ComponentModel.TypeConverter =
System.ComponentModel.TypeDescriptor.GetConverter(GetType(System.Drawing.Bitmap))
bt = DirectCast(cnv.ConvertTo(ImageToSerialize, GetType(Byte())), Byte())
SerImg = Convert.ToBase64String(bt)

a questo punto posso salvare SerImg come testo all'interno del mio xml.
Naturalmente la ImageToSerialize e' la mia immagine (System.Drawing.Image)

Per recuperare l'immagine, invece, uso:

Dim bt() As Byte = Convert.FromBase64String(strImg)
Dim mem As System.IO.MemoryStream = New System.IO.MemoryStream(bt)
Dim img As System.Drawing.Image = New System.Drawing.Bitmap(mem)
mem.Dispose()
mem = Nothing

ed ora sono in grado di restituire la img come System.Drawing.Image

Apparentemente funziona tutto. Se ad esempio mi creo un catalogo con diversi
oggetti, e provo a fare un salvataggio verso un file xml, ho il mio bel file
con i vari oggetti dentro. Una volta creato il file, tento di riaprirlo, et
voila', ho il mio catalogo caricato.
Il problema nasce quando tento di risalvare un catalogo (anche con un altro
nome su un file inesistente); nel tentare di "codificare" la mia immagine,
alla chiamata

bt = DirectCast(cnv.ConvertTo(ImageToSerialize, GetType(Byte())), Byte())

viene sollevata una System.Runtime.InteropServices.ExternalException , che
come descrizione ha semplicemente un "Errore generico in GDI+"

Avete qualche idea di cosa sta succedendo?
Qualche altra idea per fare quanto mi serve?
Ciao  e grazie...Maurizio


text:
Aggiornamenti:
come da guida msdn, quando si crea una bitmap da stream, "È necessario
mantenere il flusso aperto per l'intera durata di Bitmap".
Quindi, eliminando le righe di codice che "chiudono" lo stream, torna a
funzionare tutto.
Non mi piace molto, pero', lasciare aperta tutta questa roba, quindi cerco
di girare intorno alla cosa, vediamo che esce fuori.
Si accettano suggerimenti :-)


text:
Mi rispondo da solo.
Ho prima provato a creare un clone della immagine, chiudere lo stream e a
restituire l'immagine clonata, dopo di cio' ho chiuso lo stream, ma comunque
l'errore persisteva.
Per ovviare, dall'immagine originale, ho creato una pseudo-miniatura,
utilizzando il metodo GetThumbnailImage dell'immagine originale, passando
come argomenti di larghezza ed altezza, gli stessi valori ricavati
dall'immagine originale, creando quindi una "miniatura" delle medesime
dimensioni dell'originale.
Una volta ottenuta la nuova immagine, ho potuto chiudere lo stream di
memoria, restituire al chiamate la nuova immagine, e tutto si e' messo a
funzionare correttamente.
Mi rimarrebbe da capire come mail il metodo Clone della immagine originale,
che dovrebbe restituire un nuovo oggetto, non ha funzionato allo stesso
modo.

Posto un po' di codice, chissa' se puo' essere utile a qualcuno.

Dim bt() As Byte = Convert.FromBase64String(strImg)
Dim mem As System.IO.MemoryStream = New System.IO.MemoryStream(bt)
Dim img As System.Drawing.Image = New System.Drawing.Bitmap(mem)
bt = Nothing
Dim img2 = img.GetThumbnailImage(img.Width, img.Height, Nothing,
System.IntPtr.Zero)
mem.Close()
mem.Dispose()
mem = Nothing
img.Dispose()
img = Nothing
Return img2


text:
"vbMizio" <
vbm...@io.it
> wrote in message
news:4eb8f565$0$1382$4faf...@reader1.news.tin.it...

> Per ovviare, dall'immagine originale, ho creato una pseudo-miniatura,
> utilizzando il metodo GetThumbnailImage dell'immagine originale

Il metodo GetThumbnailImage restituisce una nuova immagine a qualita' web,
per cui occhio alla perdita di qualita' anche quando le dimensioni non
vengono ridotte.  Sarebbe meglio semplicemente istanziare la nuova Bitmap
passando nel costruttore la bitmap di partenza.  Oppure usare un oggetto
Graphics per fare la copia, se sono necessarie opzioni piu' sofisticate
sulla qualita', ecc.

> Mi rimarrebbe da capire come mail il metodo Clone della immagine
> originale, che dovrebbe restituire un nuovo oggetto, non ha funzionato
> allo stesso modo.

Il metodo clone fa una shallow copy, cioe' le due Bitmap puntano agli stessi
dati.  (In generale, dalle implementationi di Clone ci si aspetta che
facciano la shallow copy.)  Come detto sopra, va creata una nuova Bitmap.

> Posto un po' di codice, chissa' se puo' essere utile a qualcuno.

Il tuo codice ha alcuni problemi: 1) andrebbe usato il pattern Using (che e'
un try-finally), altrimenti le risorse non vengono rilasciate in caso di
eccezione; 2) garbage collection non avviene ogni pochi colpi di clock, per
cui non e' necessario nullificare le referenze se non nel caso di metodi che
impiegano molto tempo ad eseguire!  Nel tuo caso quindi stai aggiungendo
istruzioni inutili che, oltre al fatto piuttosto di rallentare (per quanto
di poco) l'esecuzione, rendendo anche il codice piu' difficile da leggere.

-LV



text:
Ciao Ludovico, grazie per la risposta.
...
>Il metodo GetThumbnailImage restituisce una nuova immagine a qualita' web,
per cui occhio alla perdita di qualita' anche quando le dimensioni non
vengono ridotte.
...
Perfetto, faro' delle prove. In realta' nel mio caso e' sufficiente anche
quello che viene restituito dalla Thumbnail, ma in linea generale mi fa
comodo sapere quanto hai detto.
...
>Il tuo codice ha alcuni problemi:
1) andrebbe usato il pattern Using
...
Ok, terro' conto

...
2) garbage collection non avviene ogni pochi colpi di clock, per
cui non e' necessario nullificare le referenze se non nel caso di metodi che
impiegano molto tempo ad eseguire!
...
Si, lo so che quel settare a Nothing e' abbastanza ridondante, e' che ho
preso l'abitudine di impostare a nothing quello che non uso, subito dopo
averli usati.

Grazie ancora... Maurizio


title: [LINQ] Select su tutte le entità il cui Id è contenuto in una lista

text:
Ciao a tutti,
questo è il mio primo post su questo ng, tuttavia sono un ex "accanito"
frequentatore dei vecchi newgroup della microsoft. :-)
La mia domanda riguarda un problema che sto avendo in questi giorni con
Linq. Ho delle entità di tipo Foo con un Id di tipo Int32. Dati un
IQueryable<Foo> che contiene tutti i Foo e una lista di Id:
IQueryable<Foo> all = ...;
List<Int32> idList = ...;
dovrei tirare fuori tutti i Foo che hanno Id contenuto in questa lista.
Come posso fare?
Grazie,
Giulio
--


text:

prova con:
var result = from o in all where idList.Contains(o.Id) select o


author: Andrea Zani

text:
Il 11/2/2010 11:06 AM, Giulio Petrucci ha scritto:
> La mia domanda riguarda un problema che sto avendo in questi giorni con
> Linq. Ho delle entità di tipo Foo con un Id di tipo Int32. Dati un
> IQueryable<Foo> che contiene tutti i Foo e una lista di Id:
>
> IQueryable<Foo> all = ...;
> List<Int32> idList = ...;
>
> dovrei tirare fuori tutti i Foo che hanno Id contenuto in questa lista.
> Come posso fare?
Se ho ben capito, dovrebbe essere:
var final=all.Where(t=>idList.Contains(t.Id));
> Grazie,
> Giulio
Ciao
--
AZ


text:
Ciao Andrea,
On 11/2/2010 12:54 PM, Andrea Zani wrote:
> Se ho ben capito, dovrebbe essere:
> var final=all.Where(t=>idList.Contains(t.Id));
Alla fine sono riuscito a testare e... pare funzionare. :-)
Grazie,
Giulio
--


title: WPF Proprietà IsOverFlowOpen non presente

author: Fabio

text:
Salve a tutti
Utilizzando Blend 4, ho aggiunto ad una window una toolbar. Ho notato
però che ad ogni finestra cui ho inserito il controllo toolbar, per
operare sugli altri controlli ma anche, ad es., per spostare la
finestra, devo cliccare due volte sull'oggetto. Per esclusione, nel
codice xaml ho notato la proprietà in oggetto, che non è presente in
blend ma anche nella finestra delle proprietà in visual studio.
Perchè?
Saluti
Fabio


title: Distruttori e Dispose

text:
Buongiorno a tutti,
sto testando una classe che implementa un agente che ogni tot secondi
lancia un job. Fin qui nulla di trascendentale. Il problema è: come
faccio a testare il distruttore? MI spiego meglio:
class Foo : IDisposable
{
	public Foo() { ... }
	~Foo()
	{
		this.Dispose();
	}
	upblic void Dispose() { ... }
}
Di fatto, il distruttore si limita a richiamare Dispose() quindi nel
caso specifico basta richiamare il dispose. Ora, se dovessi modificare
il mio distruttore inserendo ulteriore codice, come potrei fare?
Grazie in anticipo e buona giornata,
Giulio
--


title: Distruttori e Dispose

text:
On 10/12/2010 10:31, Giulio Petrucci wrote:
> Di fatto, il distruttore si limita a richiamare Dispose() quindi nel
> caso specifico basta richiamare il dispose.
Se ho capito bene il problema, forse sei fuori strada perchè in c# il
distruttore non è deterministico come in c++, ma viene richiamato
automaticamente: in altre parole si potrebbe dire che è "decorativo" ;-)


title: Distruttori e Dispose

text:
dedalus wrote:
> Se ho capito bene il problema, forse sei fuori strada perchè in c# il
> distruttore non è deterministico come in c++, ma viene richiamato
> automaticamente: in altre parole si potrebbe dire che è "decorativo" ;-)
quoto e aggiungo che viene pure eseguito su un thread differente con
tutto quello che ne può conseguire (specie se si usa com ma non solo).
Come tutte le cose ci sono scenari che non si possono coprire e i test
automatizzati non si esimono da questi problemi.
--
Raffaele Rialdi
http://www.iamraf.net
Weblog:
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET -
http://www.ugidotnet.org/


title: Distruttori e Dispose

text:
Ciao Raf,
On 12/10/2010 10:54 AM, Raffaele Rialdi [MVP] wrote:
> Come tutte le cose ci sono scenari che non si possono coprire e i test
> automatizzati non si esimono da questi problemi.
Ecco, questa è una di quelle cose che so che ci sono ma faccio di tutto
per ignorare! :-) Scherzi a parte, il mio problema è che nel distruttore
dell'oggetto in questione viene richiamato - ad esempio - il Dispose()
su un componente dell'oggetto.
In uno scenario di test, se l'oggetto in questione e mockato, il
distruttore viene richiamato al TearDown, ossìa *dopo* che sono state
verificate tutte le expectations. L'alternativa è quella di non inserire
una expectation sulla dispose del componente mockato, ma così facendo
NUnit "scoppia" dopo che il test è passato.
Insomma: una bella rogna. :-)
(Che ovviamente si risolve usando un fake scritto a mano e non un
oggetto mockato con Rhino Mocks, ma tanto valeva verificare la
possibilità di una via meno dispendiosa)
Ciao,
Giulio
--


title: Distruttori e Dispose

text:
Giulio Petrucci wrote:
> Ecco, questa è una di quelle cose che so che ci sono ma faccio di tutto per
> ignorare! :-) Scherzi a parte, il mio problema è che nel distruttore
> dell'oggetto in questione viene richiamato - ad esempio - il Dispose() su un
> componente dell'oggetto.
Guardiamola da un altro punto di vista.
Se implementi il pattern dispose molto probabilmente è perché stai
usando delle risorse native (file, socket, periferica, etc.)
Se vuoi veramente fare dei test automatizzati:
- doveresti controllare che veramente quella risorsa sia stata
rilasciata. Quindi interagire con il sistema operativo (via WMI in
certi casi o un driver in altri) per controllare l'effettivo rilascio.
- dovresti interagire con la coda di finalizzazione per sapere
esattamente quando verrà rilasciato l'oggetto.
Questo è più facile perché (solo nei test e mai in produzione) puoi
sparare a raffica GC.Collect e GC.WaitForPendingFinalizers.
Ma quanto sia affidabile questo sistema è tutto da dimostrare perché
con quelle chiamate rendi 'quasi deterministici' i finalizzatori e
quindi lo scenario cambia rispetto al codice che andrà in produzione.
Questi test *non* solo fedeli e ci possono essere scenari dove queste
differenze si fanno sentire.
Ergo, imho, la code review è un must, sempre e comunque.
> In uno scenario di test, se l'oggetto in questione e mockato, il distruttore
> viene richiamato al TearDown, ossìa *dopo* che sono state verificate tutte le
> expectations. L'alternativa è quella di non inserire una expectation sulla
> dispose del componente mockato, ma così facendo NUnit "scoppia" dopo che il
> test è passato.
>
> Insomma: una bella rogna. :-)
> (Che ovviamente si risolve usando un fake scritto a mano e non un oggetto
> mockato con Rhino Mocks, ma tanto valeva verificare la possibilità di una via
> meno dispendiosa)
E ne vale la pena di fare tutto questo giro?
Meglio allora limitare il test alla parte 'core' e poi un coded ui
testing sulla distanza per verificare la stabilità e la "quota" di
memoria, handle, etc. per verificare eventuali leak.
Meno tempo developer, migliori risultati ... altrimenti il test rischia
di essere una mania compulsiva :D



title: Distruttori e Dispose

text:
Ciao Raf,
innanzitutto grazie per la risposta.
On 12/10/2010 3:36 PM, Raffaele Rialdi [MVP] wrote:
> Guardiamola da un altro punto di vista.
> Se implementi il pattern dispose molto probabilmente è perché stai
> usando delle risorse native (file, socket, periferica, etc.)
Nel mio caso devi interrompere un timer affinché non venga richiamato un
metodo di un oggetto che è stato disposed.
> Se vuoi veramente fare dei test automatizzati:
> - doveresti controllare che veramente quella risorsa sia stata
> rilasciata. Quindi interagire con il sistema operativo (via WMI in certi
> casi o un driver in altri) per controllare l'effettivo rilascio.
> - dovresti interagire con la coda di finalizzazione per sapere
> esattamente quando verrà rilasciato l'oggetto.
> Questo è più facile perché (solo nei test e mai in produzione) puoi
> sparare a raffica GC.Collect e GC.WaitForPendingFinalizers.
> Ma quanto sia affidabile questo sistema è tutto da dimostrare perché con
> quelle chiamate rendi 'quasi deterministici' i finalizzatori e quindi lo
> scenario cambia rispetto al codice che andrà in produzione.
>
> Questi test *non* solo fedeli e ci possono essere scenari dove queste
> differenze si fanno sentire.
Anche se non è il mio caso specifico, ti ringrazio per questa esauriente
panoramica: ne terrò conto in seguito. :-)
> Ergo, imho, la code review è un must, sempre e comunque.
Ah, certo!!! :-)
> E ne vale la pena di fare tutto questo giro?
Nel mio caso direi di si perché devo verificare che il metodo che viene
richiamato ogni tot non venga richiamato se nel mezzo di quel tot
l'oggetto è stato Disposed (o finalizzato).
> Meglio allora limitare il test alla parte 'core' e poi un coded ui
> testing sulla distanza per verificare la stabilità e la "quota" di
> memoria, handle, etc. per verificare eventuali leak.
Uhm... su questo ci dobbiamo ragionare. :-)
Cosa intendi per "handle"?
> Meno tempo developer, migliori risultati ... altrimenti il test rischia
> di essere una mania compulsiva :D
Guarda... a lungo termine i migliori risultati forse non ci sono. :-)
Se impiego 2h a scrivere i test automatizzati e poi a ogni modifica devo
verificare la non regressione con mille-mila ore di test "a mano"... ci
ho guadagnato? ;-) (ah... questo è un *tipico* ragionamento da
manager!!! :-ppp)
Ciao,
Giulio
--


title: Distruttori e Dispose

text:
Giulio Petrucci wrote:
> Nel mio caso devi interrompere un timer affinché non venga richiamato un
> metodo di un oggetto che è stato disposed.
dipende dal timer. Se è un system.threading.timer ha senso visto che
implementa dispose e dipende da risorse native. Se invece è solo
managed il finalizzatore non ti dovrebbe mai servire (il finalizzatore
ha un costo alto, e di fatti esiste la GC.SuppressFinalize)
> Anche se non è il mio caso specifico, ti ringrazio per questa esauriente
> panoramica: ne terrò conto in seguito. :-)
:)
> Ah, certo!!! :-)
Beh a vedere molto codice in giro non è così scontato.
Sono in tanti a scrivere codice non debuggabile per esempio...
> Nel mio caso direi di si perché devo verificare che il metodo che viene
> richiamato ogni tot non venga richiamato se nel mezzo di quel tot l'oggetto è
> stato Disposed (o finalizzato).
E usare un tuo metodo ThrowIfDisposed (come del resto è pieno il
framework internamente)?
>> Meglio allora limitare il test alla parte 'core' e poi un coded ui
>> testing sulla distanza per verificare la stabilità e la "quota" di
>> memoria, handle, etc. per verificare eventuali leak.
>
> Uhm... su questo ci dobbiamo ragionare. :-)
> Cosa intendi per "handle"?
Numero totale di handle win32 disponibili. Tutti i numeracci che vedi
nel task manager e disponibili via WMI
>> Meno tempo developer, migliori risultati ... altrimenti il test rischia
>> di essere una mania compulsiva :D
>
> Guarda... a lungo termine i migliori risultati forse non ci sono. :-)
> Se impiego 2h a scrivere i test automatizzati e poi a ogni modifica devo
> verificare la non regressione con mille-mila ore di test "a mano"... ci ho
> guadagnato? ;-) (ah... questo è un *tipico* ragionamento da manager!!! :-ppp)
Stai dando per scontato che i test ti coprano tutti gli scenari e
questo è quasi sempre clamorosamente falso se l'applicazione è
complessa :)
Unit testing è uno strumento valido per scenari circoscrivibili dove il
numero di variabili in ingresso e uscita è predeterminabile in un
intervallo decente (il tipico esempio è il controllo di un algoritmo di
parsing).
Ma quando il campo si allarga allora è molto più attendibile un test
sulle funzionalità nel globale, cosa che puoi automatizzare con il
coded-ui testing che serve proprio a testare scenari reali di utilizzo.
(tanto per capirci, nessuno dei due è mutualmente esclusivo)



title: Distruttori e Dispose

text:
Ciao Raf,
On 12/10/2010 5:57 PM, Raffaele Rialdi [MVP] wrote:
> dipende dal timer. Se è un system.threading.timer ha senso visto che
> implementa dispose e dipende da risorse native. Se invece è solo managed
> il finalizzatore non ti dovrebbe mai servire (il finalizzatore ha un
> costo alto, e di fatti esiste la GC.SuppressFinalize)
In realtà non è nessuno dei due ma una classe "mia" che implementa un
timer un po' particolare. Internamente usa un ManualResetEvent. Mi
serviva perché così posso usare l'interfacci ITimer per mockarla.
> Beh a vedere molto codice in giro non è così scontato.
> Sono in tanti a scrivere codice non debuggabile per esempio...
Cosa sarebbe il codice non debuggabile? :-O
> E usare un tuo metodo ThrowIfDisposed (come del resto è pieno il
> framework internamente)?
Si, i metodi "pubblici" utilizzano quella cosa lì. :-)
Il problema è questo: il metodo X, al termine della sua esecuzione
"carica" il timer perché lo richiami dopo tot millisecondi. Se nel
frattempo è arrivata una Stop (o Dispose) il timer va fermato.
> Stai dando per scontato che i test ti coprano tutti gli scenari e questo
> è quasi sempre clamorosamente falso se l'applicazione è complessa :)
Ovvio. Ma nel mio caso stiamo parlando di un componente con tre casi
d'uso. :-)
> Ma quando il campo si allarga allora è molto più attendibile un test
> sulle funzionalità nel globale, cosa che puoi automatizzare con il
> coded-ui testing che serve proprio a testare scenari reali di utilizzo.
Il coded-ui testing non lo conosco: mi documenterò.
Ma se per UI si intende "user interface" sarà dura, visto che il codice
che devo testare è quello di un demone che se ne sta nascosto a fare il
suo sporco lavoro. :-)
Ciao e grazie,
Giulio
--


title: Distruttori e Dispose

text:
>> Beh a vedere molto codice in giro non è così scontato.
>> Sono in tanti a scrivere codice non debuggabile per esempio...
>
> Cosa sarebbe il codice non debuggabile? :-O
parlo di oscenità scritte da chi non sa usare o non usa mai il
debugger, come questa (vista scrivere da un docente di TDD):
public Something MyMethod()
{
  return new SomeObject().Shame.EvenWorse();
}
che è ovviamente inutile perché l'auspicabile variabile temporanea
verrebbe ottimizzata dal compilatore.
Aggiungi tutti quei casi in cui c'è un forte disaccoppiamento (che è
una buona cosa) ma che rende impossibile fare "goto definition". Per
esempio di metti di mezzo un'interfaccia, mef, ioc, quellochevuoi :)
Disclaimer:
1. questo non implica che tutto il tdd sia come sopra anche se ritengo
sia estremamente facile scivolare in schifezze del genere.
2. per non-debuggabile ovviamente intendo difficoltoso al debugging e
alla code-review
> Si, i metodi "pubblici" utilizzano quella cosa lì. :-)
> Il problema è questo: il metodo X, al termine della sua esecuzione "carica"
> il timer perché lo richiami dopo tot millisecondi. Se nel frattempo è
> arrivata una Stop (o Dispose) il timer va fermato.
Valuta se fermarlo sia più costoso di rimandare la sua chiusura al
momento in cui scade il suo tempo.
> Il coded-ui testing non lo conosco: mi documenterò.
> Ma se per UI si intende "user interface" sarà dura, visto che il codice che
> devo testare è quello di un demone che se ne sta nascosto a fare il suo
> sporco lavoro. :-)
Si, sta per UI. L'equivalente per un daemon è il test del suo
funzionamento a "scatola chiusa". Cioè riprodurre uno scenario reale
dove testi il globale e non le singole funzionalità.
(il che non esclude certamente l'utilità di unit testing laddove questo
sia pratico applicarlo)
Ciao



title: Distruttori e Dispose

text:
Ciao Raf,
On 12/13/2010 11:04 AM, Raffaele Rialdi [MVP] wrote:
> parlo di oscenità scritte da chi non sa usare o non usa mai il debugger,
> come questa (vista scrivere da un docente di TDD):
>
> public Something MyMethod()
> {
> return new SomeObject().Shame.EvenWorse();
> }
> che è ovviamente inutile perché l'auspicabile variabile temporanea
> verrebbe ottimizzata dal compilatore.
Onestamente mi sfugge il punto. :-)
> Aggiungi tutti quei casi in cui c'è un forte disaccoppiamento (che è una
> buona cosa) ma che rende impossibile fare "goto definition". Per esempio
> di metti di mezzo un'interfaccia, mef, ioc, quellochevuoi :)
E perché codice basato su IoC sarebbe scarsamente debuggabile?
> 1. questo non implica che tutto il tdd sia come sopra anche se ritengo
> sia estremamente facile scivolare in schifezze del genere.
Capisco.
> Valuta se fermarlo sia più costoso di rimandare la sua chiusura al
> momento in cui scade il suo tempo.
onestamente - nel mio caso - non saprei.
> Si, sta per UI. L'equivalente per un daemon è il test del suo
> funzionamento a "scatola chiusa". Cioè riprodurre uno scenario reale
> dove testi il globale e non le singole funzionalità.
Capito.



title: Distruttori e Dispose

text:
Giulio Petrucci wrote:
Ciao Giulio
> Onestamente mi sfugge il punto. :-)
Ci sono diversi punti in quel codice.
Principalmente il problema ï¿œ che non ci sono variabili locali da vedere
con il debugger.
Poi l'uso di un metodo su una proprietï¿œ. Di default le proprietï¿œ
vengono saltate con F11 (step into), questo significa che chiamerai il
metodo senza neppure vedere l'oggetto riportato dalla proprietï¿œ.
Il primo avvio del codice dovrebbe essere fatto con breakpoint e F10 e
non vedere le lucine verdi e rosse accendersi, questo ï¿œ sempre
necessario. Il codice che funziona non ï¿œ detto che lo faccia *nel modo*
in cui l'hai pensato.
> E perchï¿œ codice basato su IoC sarebbe scarsamente debuggabile?
Premesso che il disaccoppiamento, mef e ioc sono ottime soluzioni,
purtroppo by design se fai un goto definition non vedi le stesse cose
che vedrai a runtime, quindi lo rende piï¿œ complesso da debuggare.
Prendi una app wpf con mvvm che carica i vari controlli via MEF. ï¿œ poco
ovvio cosa faccia leggendo il codice.
Architetturalmente parlando ï¿œ molto pregevole. A livello di bug-hunting
ï¿œ complesso.
> Ciao e grazie,
> Giulio
Ciao!



title: Distruttori e Dispose

text:
Ciao Raf,
On 12/13/2010 5:01 PM, Raffaele Rialdi [MVP] wrote:
> Ci sono diversi punti in quel codice.
> Principalmente il problema è che non ci sono variabili locali da vedere
> con il debugger.
> Poi l'uso di un metodo su una proprietà. Di default le proprietà vengono
> saltate con F11 (step into), questo significa che chiamerai il metodo
> senza neppure vedere l'oggetto riportato dalla proprietà.
Capito. Però ad esempio, se ho una libreria di terze parti con una
interfaccia "fluent", mi aspetto comunque che tutto funzioni, no?
> Il primo avvio del codice dovrebbe essere fatto con breakpoint e F10 e
> non vedere le lucine verdi e rosse accendersi, questo è sempre
> necessario. Il codice che funziona non è detto che lo faccia *nel modo*
> in cui l'hai pensato.
Si, sono d'accordo.
> Premesso che il disaccoppiamento, mef e ioc sono ottime soluzioni,
> purtroppo by design se fai un goto definition non vedi le stesse cose
> che vedrai a runtime, quindi lo rende più complesso da debuggare.
Onestamente il senso della frase mi sfugge.
> Prendi una app wpf con mvvm che carica i vari controlli via MEF. È poco
> ovvio cosa faccia leggendo il codice.
Mai usato MEF.
Dici che è ora di iniziare? ;-)
Ciao e buona giornata,
Giulio
--


title: Distruttori e Dispose

text:
Giulio Petrucci wrote:
>
Ciao Giulio,
> Capito. Però ad esempio, se ho una libreria di terze parti con una
> interfaccia "fluent", mi aspetto comunque che tutto funzioni, no?
le fluent api pluggano lambda in una pipeline e di solito si usano per
scegliere membri di un oggetto o elaborazioni relativamente di bassa
complessità. Se ne abusi sei da capo.
L'eredità di C++ ha portato a fare le gare per scrivere il minor numero
di statement, a causa delle scarse ottimizzazioni dei compilatori
dell'epoca fino agli anni 90.
Oggi è un discorso da sfatare e si deve scrivere codice leggibile e
manutenibile perché il resto lo fanno le ottimizzazioni del
compilatore.
>> Premesso che il disaccoppiamento, mef e ioc sono ottime soluzioni,
>> purtroppo by design se fai un goto definition non vedi le stesse cose
>> che vedrai a runtime, quindi lo rende più complesso da debuggare.
>
> Onestamente il senso della frase mi sfugge.
Se prendi uno statement tipo IQualcosa q = GetOggetto(); la "goto
definition" ti porta a IQualcosa e rende ovviamente più complesso a
design time quale possa essere la classe che implementa
quell'interfaccia.
Se ci aggiungi CreateInstance, MEF o IOC diventa ancora più "nascosta".
>> Prendi una app wpf con mvvm che carica i vari controlli via MEF. È poco
>> ovvio cosa faccia leggendo il codice.
>
> Mai usato MEF.
> Dici che è ora di iniziare? ;-)
Provalo e ne diventerai dipendente :)
> Ciao e buona giornata,
> Giulio
Ciao



title: databinding

author: Gabryy

text:
Buongiorno,
     ho una form con un db con dei campi byte()  array. Facendo il
databinding con datasource e dei textbox non funziona. Non si
memorizzano le modifiche, addirittura si blocca. Come si fa per i campi
byte() o blog?

--- news://
freenews.netfront.net/
 - complaints:
ne...@netfront.net
 ---


title: FilterDescriptor

author: Giovanni

text:
Un saluto a tutti.
Scenario: Silverlight
Praticamente quando carico la pagina mi compaiono due messaggi di errore di
questo tipo :
System.InvalidOperationException:Impossibile valutare FilterDescriptor con
PropertyPath uguale a 'DATARILEVAZIONE', --->
System.ArgumentException:Operatore 'IsEqualTo' incompatibile con tipi di
operandi 'DateTime' e 'null' .....
un volta scaricati i messaggi (click sull'unico button presente sulla
finestra del msg) si riempie la combobox e poi le due datagrid che dipendono
dalla combo. Selezionando poi date diverse sulla combo le datagrid si
aggiornano correttamente.
Credo che il problema sia dovuto alla sequenza di caricamento dei controlli,
ho provato ad inserire anche questo nella MainPage :
Public Sub New()
InitializeComponent()
Me.ddsuvSelDataRil.Load()
End Sub
ma la sostanza non cambia.
Cosa mi sfugge?
Grazie e ciao
Giovanni


title: FilterDescriptor

text:
Ciao Giovanni,
You wrote on 07/04/2011 :
> Praticamente quando carico la pagina mi compaiono due messaggi di errore di
> questo tipo :
> System.InvalidOperationException:Impossibile valutare FilterDescriptor con
> PropertyPath uguale a 'DATARILEVAZIONE', --->
> System.ArgumentException:Operatore 'IsEqualTo' incompatibile con tipi di
> operandi 'DateTime' e 'null' .....
RIA? sembra che la tua "data source" contenga dei DateTime e anche un
valore null che in fase di filtro non può essere confrontato,
ovviamente, con un DateTime.
.m
--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @
http://milestone.topics.it
whynot [ at ] topics [ dot ] it


title: FilterDescriptor

text:
"Mauro Servienti [MVP]"  wrote in message
news:mn.71eb7db48...@online.nospam...
Ciao Giovanni,
You wrote on 07/04/2011 :
> Praticamente quando carico la pagina mi compaiono due messaggi di errore
> di questo tipo :
> System.InvalidOperationException:Impossibile valutare FilterDescriptor con
> PropertyPath uguale a 'DATARILEVAZIONE', --->
> System.ArgumentException:Operatore 'IsEqualTo' incompatibile con tipi di
> operandi 'DateTime' e 'null' .....
>RIA? sembra che la tua "data source" contenga dei DateTime e anche un
>valore null che in fase di filtro non può essere confrontato, ovviamente,
>con un DateTime.
Si RIA, più che contenere un valore null non contiene nessun dato.
In questo evento VF risulta False, come mai?:
Private Sub ddsDataRil_LoadingData(sender As Object, e As
System.Windows.Controls.LoadingDataEventArgs) Handles ddsDataRil.LoadingData
       Dim VF As Boolean = ddsDataRil.IsLoadingData
   End Sub
Quello che non capisco è che scaricati i messaggi il datagrid alimentato da
ddsDataRil si popola e anche il datagrid collegato si popola con i dati
filtrati. Questo mi succede solo con le date.
Grazie e ciao
Giovanni


title: FilterDescriptor

text:
Ciao Giovanni,
You wrote on 15/04/2011 :
> Si RIA, più che contenere un valore null non contiene nessun dato.
> In questo evento VF risulta False, come mai?:
> Private Sub ddsDataRil_LoadingData(sender As Object, e As
> System.Windows.Controls.LoadingDataEventArgs) Handles ddsDataRil.LoadingData
>        Dim VF As Boolean = ddsDataRil.IsLoadingData
>    End Sub
> Quello che non capisco è che scaricati i messaggi il datagrid alimentato da
> ddsDataRil si popola e anche il datagrid collegato si popola con i dati
> filtrati. Questo mi succede solo con le date.
riesci a pacchettizare un esempio che riproduca il problema?
.m
--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro



title: FilterDescriptor

text:
"Mauro Servienti [MVP]"  wrote in message
news:mn.82517db43...@online.nospam...
Ciao Giovanni,
You wrote on 15/04/2011 :
> Si RIA, più che contenere un valore null non contiene nessun dato.
> In questo evento VF risulta False, come mai?:
> Private Sub ddsDataRil_LoadingData(sender As Object, e As
> System.Windows.Controls.LoadingDataEventArgs) Handles
> ddsDataRil.LoadingData
>        Dim VF As Boolean = ddsDataRil.IsLoadingData
>    End Sub
> Quello che non capisco è che scaricati i messaggi il datagrid alimentato
> da ddsDataRil si popola e anche il datagrid collegato si popola con i dati
> filtrati. Questo mi succede solo con le date.
>riesci a pacchettizare un esempio che riproduca il problema?
Si, era mia intenzione chiedere a qualcuno di dargli un'occhiata.
Dove lo posto poi?
Grazie e ciao
Giovanni


title: FilterDescriptor

text:
"Mauro Servienti [MVP]"  wrote in message
news:mn.82517db43...@online.nospam...
Ciao Giovanni,
You wrote on 15/04/2011 :
> Si RIA, più che contenere un valore null non contiene nessun dato.
> In questo evento VF risulta False, come mai?:
> Private Sub ddsDataRil_LoadingData(sender As Object, e As
> System.Windows.Controls.LoadingDataEventArgs) Handles
> ddsDataRil.LoadingData
>        Dim VF As Boolean = ddsDataRil.IsLoadingData
>    End Sub
> Quello che non capisco è che scaricati i messaggi il datagrid alimentato
> da ddsDataRil si popola e anche il datagrid collegato si popola con i dati
> filtrati. Questo mi succede solo con le date.
>riesci a pacchettizare un esempio che riproduca il problema?
Il progetto con allegati il db SQL completo e qli script per generare le
tabelle e per inserire i dati li trovi qui:
http://www.mediafire.com/myfiles.php
Grazie e ciao
Giovanni


title: FilterDescriptor

text:
"Mauro Servienti [MVP]"  wrote in message
news:mn.82517db43...@online.nospam...
Ciao Giovanni,
You wrote on 15/04/2011 :
> Si RIA, più che contenere un valore null non contiene nessun dato.
> In questo evento VF risulta False, come mai?:
> Private Sub ddsDataRil_LoadingData(sender As Object, e As
> System.Windows.Controls.LoadingDataEventArgs) Handles
> ddsDataRil.LoadingData
>        Dim VF As Boolean = ddsDataRil.IsLoadingData
>    End Sub
> Quello che non capisco è che scaricati i messaggi il datagrid alimentato
> da ddsDataRil si popola e anche il datagrid collegato si popola con i dati
> filtrati. Questo mi succede solo con le date.
>riesci a pacchettizare un esempio che riproduca il problema?
Credo di aver inviato un link errato nel post precedente. Questo dovrebbe
essere corretto:
http://www.mediafire.com/?pcmdz8dol5d8vwj
Ciao
Giovanni


title: FilterDescriptor

text:
Ciao Giovanni,
You wrote on 18/04/2011 :
> Credo di aver inviato un link errato nel post precedente. Questo dovrebbe
> essere corretto:
>
http://www.mediafire.com/?pcmdz8dol5d8vwj
l'inghippo potrebbe essere l'ordine del binding, il "details" fa
binding sul SelectedItem prima che questo sia popolato. Una soluzione
interessante potrebbe essere quella di piazzare un converter sul
binding che intercetta il passaggio del valore e se è nulla ritorna un
valore "fake" di default che compensa questo scenario.
> Ciao
> Giovanni



title: FilterDescriptor

text:
> Credo di aver inviato un link errato nel post precedente. Questo dovrebbe
> essere corretto:
>
http://www.mediafire.com/?pcmdz8dol5d8vwj
>l'inghippo potrebbe essere l'ordine del binding, il "details" fa binding
>sul SelectedItem prima che questo sia popolato. Una soluzione interessante
>potrebbe essere quella di piazzare un converter sul binding che intercetta
>il passaggio del valore e se è nulla ritorna un valore "fake" di default
>che compensa questo scenario.
Ho inserito questo in un file *.vb all'interno del progetto SL:
Imports System.ServiceModel.DomainServices.Client
Imports System.Windows.Data
Namespace Test
    Public Class DateTimeConverter
        Implements IValueConverter
        Public Function Convert(ByVal value As Object, _
                    ByVal targetType As System.Type, _
                    ByVal parameter As Object, _
                    ByVal culture As System.Globalization.CultureInfo) _
                    As Object _
                    Implements System.Windows.Data.IValueConverter.Convert
            Dim DateValue As DateTime = CDate(value)
            Return DateValue.ToShortDateString()
        End Function
        Public Function ConvertBack(ByVal value As Object, _
                    ByVal targetType As System.Type, _
                    ByVal parameter As Object, _
                    ByVal culture As System.Globalization.CultureInfo) _
                    As Object _
                    Implements
System.Windows.Data.IValueConverter.ConvertBack
            Dim StrValue As String = value.ToString()
            Dim ResultDateTime As DateTime
            If DateTime.TryParse(StrValue, ResultDateTime) Then
                Return ResultDateTime
            End If
            Return value
        End Function
    End Class
End Namespace
Poi ho modificato lo XAML in questo modo:
<UserControl x:Class="Filtro.MainPage"
    xmlns="
http://schemas.microsoft.com/winfx/2006/xaml/presentation
"
    xmlns:x="
http://schemas.microsoft.com/winfx/2006/xaml
"
    xmlns:d="
http://schemas.microsoft.com/expression/blend/2008
"
    xmlns:mc="
http://schemas.openxmlformats.org/markup-compatibility/2006
"
    xmlns:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"
    xmlns:converter="clr-namespace:Filtro.Test"
    mc:Ignorable="d"
    d:DesignHeight="387" d:DesignWidth="691"
    xmlns:riaControls="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.DomainServices"
    xmlns:my="clr-namespace:Filtro.TestFilter"
    xmlns:sdk="
http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk
">
    <UserControl.Resources>
        <converter:DateTimeConverter
            x:Key="dateconverter">
        </converter:DateTimeConverter>
    </UserControl.Resources>
    <Grid x:Name="LayoutRoot" Background="White">
        <riaControls:DomainDataSource AutoLoad="True"
d:DesignData="{d:DesignInstance my:TADataRil, CreateList=true}" Height="0"
Name="ddsDataRil" QueryName="GetTADataRilQuery" Width="0">
            <riaControls:DomainDataSource.DomainContext>
                <my:FILTRODS />
            </riaControls:DomainDataSource.DomainContext>
        </riaControls:DomainDataSource>
        <sdk:DataGrid AutoGenerateColumns="False" Height="131"
HorizontalAlignment="Left" ItemsSource="{Binding ElementName=ddsDataRil,
Path=Data}" Margin="12,12,0,0" Name="dgDataRil"
RowDetailsVisibilityMode="VisibleWhenSelected" VerticalAlignment="Top"
Width="141">
            <sdk:DataGrid.Columns>
                <sdk:DataGridTemplateColumn x:Name="DATARILEVAZIONEColumn"
Header="DATARILEVAZIONE" IsReadOnly="True" Width="SizeToHeader">
                    <sdk:DataGridTemplateColumn.CellTemplate>
                        <DataTemplate>
                            <TextBlock Text="{Binding Path=DATARILEVAZIONE,
Mode=OneWay}" />
                        </DataTemplate>
                    </sdk:DataGridTemplateColumn.CellTemplate>
                </sdk:DataGridTemplateColumn>
            </sdk:DataGrid.Columns>
        </sdk:DataGrid>
        <riaControls:DomainDataSource AutoLoad="True"
d:DesignData="{d:DesignInstance my:TAMaster, CreateList=true}" Height="0"
Name="ddsTAMaster" QueryName="GetTAMasterQuery" Width="0">
            <riaControls:DomainDataSource.DomainContext>
                <my:FILTRODS />
            </riaControls:DomainDataSource.DomainContext>
            <riaControls:DomainDataSource.FilterDescriptors>
                <riaControls:FilterDescriptor x:Name="CP"
PropertyPath="DATARILEVAZIONE" Operator="IsEqualTo"  Value="{Binding
Converter={StaticResource dateconverter},ConverterParameter='dd-MMM-yyyy',
ElementName=dgDataRil,  Path=SelectedItem.DATARILEVAZIONE}" />
            </riaControls:DomainDataSource.FilterDescriptors>
        </riaControls:DomainDataSource>
        <sdk:DataGrid AutoGenerateColumns="False" Height="200"
HorizontalAlignment="Left" ItemsSource="{Binding ElementName=ddsTAMaster,
Path=Data}" Margin="12,149,0,0" Name="dgTAMaster"
RowDetailsVisibilityMode="VisibleWhenSelected" VerticalAlignment="Top"
Width="667">
            <sdk:DataGrid.Columns>
                <sdk:DataGridTextColumn x:Name="CODASLColumn"
Binding="{Binding Path=CODASL, Mode=OneWay}" Header="CODASL"
IsReadOnly="True" Width="SizeToHeader" />
                <sdk:DataGridTextColumn x:Name="CODEROGATOREColumn"
Binding="{Binding Path=CODEROGATORE, Mode=OneWay}" Header="CODEROGATORE"
IsReadOnly="True" Width="SizeToHeader" />
                <sdk:DataGridTextColumn x:Name="CODPRESTAZIONEColumn"
Binding="{Binding Path=CODPRESTAZIONE, Mode=OneWay}" Header="CODPRESTAZIONE"
IsReadOnly="True" Width="SizeToHeader" />
                <sdk:DataGridTemplateColumn x:Name="DATARILEVAZIONEColumn1"
Header="DATARILEVAZIONE" IsReadOnly="True" Width="SizeToHeader">
                    <sdk:DataGridTemplateColumn.CellEditingTemplate>
                        <DataTemplate>
                            <sdk:DatePicker SelectedDate="{Binding
Path=DATARILEVAZIONE, Mode=OneWay}" />
                        </DataTemplate>
                    </sdk:DataGridTemplateColumn.CellEditingTemplate>
                    <sdk:DataGridTemplateColumn.CellTemplate>
                        <DataTemplate>
                            <TextBlock Text="{Binding DATARILEVAZIONE,
Converter={StaticResource dateconverter},ConverterParameter='dd-MMM-yyyy'}"
/>
                        </DataTemplate>
                    </sdk:DataGridTemplateColumn.CellTemplate>
                </sdk:DataGridTemplateColumn>
                <sdk:DataGridTextColumn x:Name="GARANZIA_TMAXColumn"
Binding="{Binding Path=GARANZIA_TMAX}" Header="GARANZIA TMAX"
Width="SizeToHeader" />
                <sdk:DataGridTextColumn x:Name="N_AGENDE_AColumn"
Binding="{Binding Path=N_AGENDE_A}" Header="N AGENDE A" Width="SizeToHeader"
/>
                <sdk:DataGridTextColumn x:Name="N_AGENDE_CColumn"
Binding="{Binding Path=N_AGENDE_C}" Header="N AGENDE C" Width="SizeToHeader"
/>
                <sdk:DataGridTextColumn x:Name="N_FOLLOW_SCREENINGColumn"
Binding="{Binding Path=N_FOLLOW_SCREENING}" Header="N FOLLOW SCREENING"
Width="SizeToHeader" />
                <sdk:DataGridTextColumn x:Name="N_PRENOTATIColumn"
Binding="{Binding Path=N_PRENOTATI}" Header="N PRENOTATI"
Width="SizeToHeader" />
                <sdk:DataGridTextColumn x:Name="N_PRIMADIAGNOSIColumn"
Binding="{Binding Path=N_PRIMADIAGNOSI}" Header="N PRIMADIAGNOSI"
Width="SizeToHeader" />
                <sdk:DataGridTextColumn x:Name="N_URGENTIColumn"
Binding="{Binding Path=N_URGENTI}" Header="N URGENTI" Width="SizeToHeader"
/>
                <sdk:DataGridTextColumn x:Name="N_UTENTI_INIZIOColumn"
Binding="{Binding Path=N_UTENTI_INIZIO}" Header="N UTENTI INIZIO"
Width="SizeToHeader" />
            </sdk:DataGrid.Columns>
        </sdk:DataGrid>
    </Grid>
</UserControl>
Ma nulla l'errore compare sempre. Andando di debug le due Function sopra
vengono valutate dopo la comparsa dell'errore, cosa ho sbagliato?
Poi... quello che non capisco è che se utilizzo un altro tipo di dati in
luogo di DateTime per il binding, tutto funziona.
Grazie e ciao
Giovanni


title: FilterDescriptor

text:
Ciao Giovanni,
You wrote on 19/04/2011 :
>                 <riaControls:FilterDescriptor x:Name="CP"
> PropertyPath="DATARILEVAZIONE" Operator="IsEqualTo"  Value="{Binding
> Converter={StaticResource dateconverter},ConverterParameter='dd-MMM-yyyy',
> ElementName=dgDataRil,  Path=SelectedItem.DATARILEVAZIONE}" />
è SelectedItem che è null e di conseguenza la Data, inoltre prova a
mettere un breakpoint sul tuo converter come può funzionare?



title: FilterDescriptor

text:
>                 <riaControls:FilterDescriptor x:Name="CP"
> PropertyPath="DATARILEVAZIONE" Operator="IsEqualTo"  Value="{Binding
> Converter={StaticResource dateconverter},ConverterParameter='dd-MMM-yyyy',
> ElementName=dgDataRil,  Path=SelectedItem.DATARILEVAZIONE}" />
>è SelectedItem che è null e di conseguenza la Data, inoltre prova a mettere
>un breakpoint sul tuo converter come può funzionare?
Nulla da fare, come ti avevo già detto nel post precedente prima compare
l'errore poi VS si ferma sul breakpoint del converter che ovviamente
contiene la data.
Ciao e grazie
Giovanni


title: differenza API win e NET framework

author: MasterControl

text:
Ciao
come da oggetto.
grazie


title: differenza API win e NET framework

text:
.Net si pone ad un livello di astrazione piu' alto e infatti incapsula (nativamente) l'accesso a molte delle API di Windows.
Incidentalmente: alle API di Windows e piu' in generale a librerie native si puo' comunque accedere da .Net managed (quindi dal nostro codice), attraverso la piattaforma P/Invoke, pero' con costi non banali in termini di performance.
-LV


title: differenza API win e NET framework

text:
LudovicoVan wrote:
[...]
Scusami, una domanda totalmente OT.
Ultimamente tutti le te tue risposte (e solo le tue) "rompono" i
thread, cioè non vengono classificati nel tree come se l'id del
messaggio non fosse negli headers.
Hai mica cambiato newsreader?
--
Raffaele Rialdi
http://www.iamraf.net
Weblog:
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET -
http://www.ugidotnet.org/


title: differenza API win e NET framework

text:
On Saturday, 7 May 2011 12:03:25 UTC+1, Raffaele Rialdi [ MVP ]  wrote:
> LudovicoVan wrote:
> [...]
>
> Scusami, una domanda totalmente OT.
> Ultimamente tutti le te tue risposte (e solo le tue) "rompono" i
> thread, cioè non vengono classificati nel tree come se l'id del
> messaggio non fosse negli headers.
> Hai mica cambiato newsreader?
Mm, grazie della segnalazione. Temo che sia la nuova google groups. Tempo di migrare, la nuova interfaccia e' pessima sotto quasi tutti i punti di vista, solo che mi serve un accesso via web... se avete alternative da suggerire, sono benvenute: potete rispondere al mio indirizzo personale.
-LV


title: differenza API win e NET framework

text:
LudovicoVan wrote:
> Mm, grazie della segnalazione. Temo che sia la nuova google groups. Tempo di
> migrare, la nuova interfaccia e' pessima sotto quasi tutti i punti di vista,
> solo che mi serve un accesso via web... se avete alternative da suggerire,
> sono benvenute: potete rispondere al mio indirizzo personale.
Prego.
Io uso mesnews sul server gratuito
news.eternal-september.org
Non so se questo può aiutarti ma l'accesso web a nntp proprio non mi
piace e non lo uso.



title: differenza API win e NET framework

text:
On 7 May, 17:59, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
> wrote:
> Non so se questo può aiutarti ma l'accesso web a nntp proprio non mi
> piace e non lo uso.
No che non mi aiuta: il requisito qui era una interfaccia web, le tue
preferenze personali lasciano il tempo che trovano.
-LV


title: differenza API win e NET framework

text:

Questo genere di affermazione su un tentativo di aiuto è quello che
prendo come esempio lampante di pruriginosa antipatia.



title: differenza API win e NET framework

text:
On 7 May, 19:18, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
> wrote:
> LudovicoVan wrote:
> > On 7 May, 17:59, Raffaele Rialdi [MVP] <
malta@n0spam_vevy.com
> wrote:
>
> >> Non so se questo può aiutarti ma l'accesso web a nntp proprio non mi
> >> piace e non lo uso.
>
> > No che non mi aiuta: il requisito qui era una interfaccia web, le tue
> > preferenze personali lasciano il tempo che trovano.
>
> Questo genere di affermazione su un tentativo di aiuto è quello che
> prendo come esempio lampante di pruriginosa antipatia.
Anche le tue simpatie e antipatie sono alquanto fuori luogo.
-LV


title: differenza API win e NET framework

text:


-LV
nel ringraziarti
un'ultima domanda :)
le API di Windows sono implmentate mediante DLL giusto?
le DLL che fornisce il Net Framework in pratica 'avvolgono' quelle di
Windows semplificandone l'utilizzo?
Come dire che se utilizzassi direttamente le API potrei fare esattamente
tutto quello che è possibile fare con il .NET framework?
scusami ancora per le banali domande, ma sono nuovo in questo mondo del .NET
grazie!


title: differenza API win e NET framework

text:
"MasterControl" <
Master...@cmp.it
> wrote in message
news:iq5kqp$vvm$3...@speranza.aioe.org...
> le API di Windows sono implmentate mediante DLL giusto?
DLL e non solo, c'e' tutto il Windows SDK. Si tratta anche in questo caso
essenzialmente di wrapper, sul sistema operativo stesso. Puoi guardare
questo articolo per farti un'idea piu' precisa:
http://en.wikipedia.org/wiki/Windows_API
> le DLL che fornisce il Net Framework in pratica 'avvolgono' quelle di
> Windows semplificandone l'utilizzo?
Le DLL .Net sono in realta' codice managed, da non confondere quindi con
quelle native (infatti si chiamano Assemblies). Parte della Class Library
incapsula (wrappa) appunto le API di Windows, in particolare nei namespace
System e Microsoft. Di nuovo, puoi guardare un articolo introduttivo in
proposito:
http://en.wikipedia.org/wiki/.NET_Framework
> Come dire che se utilizzassi direttamente le API potrei fare esattamente
> tutto quello che è possibile fare con il .NET framework?
Come dire che potresti persino tornare all'Assembler per programmare...
Insomma, .Net si pone ad un certo livello di astrazione: non ci farei un
device driver, ma non farei mai per esempio un sito web in C++ nativo: in
particolare, il framework .Net ti fornisce molto di piu' che solo dei
wrapper sulle API di Windows.
-LV

--- Posted via news://
freenews.netfront.net/
 - Complaints to
ne...@netfront.net
 ---


title: differenza API win e NET framework

text:
Il 08/05/2011 12:49, LudovicoVan ha scritto:
> tornare all'Assembler per programmare...
> Insomma, .Net si pone ad un certo livello di astrazione: non ci farei un
> device driver, ma non farei mai per esempio un sito web in C++ nativo: in
> particolare, il framework .Net ti fornisce molto di piu' che solo dei
> wrapper sulle API di Windows.
thx!


title: differenza API win e NET framework

text:
MasterControl wrote:
> Come dire che se utilizzassi direttamente le API potrei fare esattamente
> tutto quello che è possibile fare con il .NET framework?
Assolutamente no.
Alcune delle funzionalità del framework sono wrapper delle win32 ma
ormai la stragrande maggioranza di codice managed presente nel
framework fornisce funzionalità che non sono presenti nelle win32.
Per esempio:
- WPF si avvale delle DirectX (che non fa parte delle win32) per il
rendering ma tutto il modello di WPF è nuovo.
- Tutte le librerie WCF e WF sono uniche e nate nel
framework.net
. I
Windows Web Services nati dopo WCF per C/C++ implementano una versione
ridotta di ciò che è invece disponibile in WCF.
- A partire dalla versione 2.0 le Windows Forms (che si avvalgono per
la maggior parte delle funzionalità di GDI+ e User32/Win32) hanno
aggiunto tantissime funzionalità e controlli non presenti prima
(pannelli, toolstrip, grid, float layout, etc.)
- Tutta la parte web (
asp.net
 nelle varie versioni) è totalmente e solo
managed.
- Persino i provider
ado.net
 sono stati tutti riscritti con codice
managed invece di usare oledb che era già pronto all'uso
E così per altre librerie del framework.
Il motivo è semplice: l'interoperabilità con il codice nativo ha un
costo in termini di performance che non lo rende conveniente in molti
casi.



title: differenza API win e NET framework

text:
Il 08/05/2011 19:41, Raffaele Rialdi [MVP] ha scritto:
> Il motivo è semplice: l'interoperabilità con il codice nativo ha un
> costo in termini di performance che non lo rende conveniente in molti casi.
thx !


title: Comunicazione asp.net e silverlight

author: Smalville

text:
Ciao,
mi sto approcciando da poco a Silverlight.
Vorrei capire nello specifico come lo usate solitamente, ovvero
sviluppate pagine
asp.net
 nelle quali includete in determinate sezioni
dei controlli silverlight ?
Come fare in modo efficiente la comunicazione tra
asp.net
 e
silverlight ?
Ho visto degli esempi ma mi sembra tutt'altro che banale realizzarla e
per altro mi sembra poco efficiente ?
Se volessi passare degli oggetti e non delle semplici stringhe da
asp.net
 e silverlight come potrei fare?
Quali sono le best practices ?
Grazie mille
Buona giornata


title: Comunicazione asp.net e silverlight

author: Corrado Cavalli [MVP]

text:
Smalville explained on 11/04/2011 :

"Dipende" :-)
Silverlight e Host possono comunicare tra loro ma non scambiarsi
oggetti (sono ambienti diversi) la comunicazione non è poi complessa,
diciamo che da SL puoi comunicare facilmente con la pagina host (anche
invocare js) e dalla pagina puoi accedere a degli oggetti esposti
appositamente da SL e utilizzarli via JS.


title: Entity Framework  tabella e campo nel config

text:
Come posso dare la possibilità al cliente (che me lo ha richiesto) di
indicare una tabella ed un campo esternamente alla mia applicazione (4.0
C# Wpf), che sarà preso come riferimento per prelevare dati da un DB ?
Impostando i due parametri nel file exe.config, come posso poi
considerarli con EF, dove tutto è allettantemente 'tipizzato' ?  Forse
per questa cosa è piu facile ricorrere al vecchio
ado.net
 dove tutto è
stringa :) ? Pero non mi volevo arrendere...
Grazie
Alessandro


text:

Io lo faccio ma con EF 4.1 (che è l'estensione a EF 4.0 che si chiamava
Code-First).
Occhio che è ancora "release candidate" cioè non è ancora rilasciata ma
ha la licenza go-live e quindi le API non cambieranno.
In pratica diciamo di avere un contesto che si chiama ctx:
ctx.Database.SqlQuery<Customer>("Select * from mycustomer");
Nel secondo parametro di SqlQuery puoi passare i parameters che
verranno utilizzati nella query.
In quel modo la tua entity Customer l'hai decisa tu a compile time, ma
la mycustomer è stringa e quindi può assumere qualsiasi valore.
--
Raffaele Rialdi
http://www.iamraf.net
Weblog:
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET -
http://www.ugidotnet.org/


text:
Il 28/03/2011 22:25, Raffaele Rialdi [MVP] ha scritto:
> Sander wrote:
>> Come posso dare la possibilità al cliente (che me lo ha richiesto) di
>> indicare una tabella ed un campo esternamente alla mia applicazione
>> (4.0 C# Wpf), che sarà preso come riferimento per prelevare dati da un
>> DB ?
>> Impostando i due parametri nel file exe.config, come posso poi
>> considerarli con EF, dove tutto è allettantemente 'tipizzato' ? Forse
>> per questa cosa è piu facile ricorrere al vecchio
ado.net
 dove tutto è
>> stringa :) ? Pero non mi volevo arrendere...
>
> Io lo faccio ma con EF 4.1 (che è l'estensione a EF 4.0 che si chiamava
> Code-First).
> Occhio che è ancora "release candidate" cioè non è ancora rilasciata ma
> ha la licenza go-live e quindi le API non cambieranno.
>
> In pratica diciamo di avere un contesto che si chiama ctx:
> ctx.Database.SqlQuery<Customer>("Select * from mycustomer");
>
> Nel secondo parametro di SqlQuery puoi passare i parameters che verranno
> utilizzati nella query.
>
> In quel modo la tua entity Customer l'hai decisa tu a compile time, ma
> la mycustomer è stringa e quindi può assumere qualsiasi valore.
Grazie Raffaele, in sostanza dovrebbe assomigliare a questa qui che ho
trovato nel frattempo e che non conoscevo (la ObjectContext.CreateQuery) ?
http://msdn.microsoft.com/it-it/library/bb339670.aspx
Se non potessi ricorrere al 4.1 RC, ritieni che potrei usare questo
'ibrido' qui sopra? Insomma, devo solo fare una select su una tabella il
cui nome sta in una stringa...e mica vogliamo la luna :)


text:
Sander wrote:
> Grazie Raffaele, in sostanza dovrebbe assomigliare a questa qui che ho
> trovato nel frattempo e che non conoscevo (la ObjectContext.CreateQuery) ?
>
http://msdn.microsoft.com/it-it/library/bb339670.aspx
>
> Se non potessi ricorrere al 4.1 RC, ritieni che potrei usare questo 'ibrido'
> qui sopra? Insomma, devo solo fare una select su una tabella il cui nome sta
> in una stringa...e mica vogliamo la luna :)
Si, direi che sono equivalenti.



title: migliorare prestazioni applicativo in framework

author: Andrea

text:
Ciao a tutti,
ho un applicativo sviluppato .net su framework 4 che risulta
esageratamante lento nell'aprirsi (circa 40 secondi), mi chiedevo se
c'era un modo per precaricare il programma in cache sui client.
Non essendo un programmatore vorrei avere da voi dei consigli.
grazie
Andrea


text:
Ciao Andrea,
You wrote on 18/07/2011 :
> Ciao a tutti,
> ho un applicativo sviluppato .net su framework 4 che risulta
> esageratamante lento nell'aprirsi (circa 40 secondi), mi chiedevo se
> c'era un modo per precaricare il programma in cache sui client.
si, si chiama jitting.
> Non essendo un programmatore vorrei avere da voi dei consigli.
ma non è detto che risolva il tuo problema, 40 secondi sono comunque
troppi, dovresti prima scoprire cosa fa il programma allo startup
perchè il jitting si limita a "precompilare" in codice x86 l'IL ma se
il programma fa un po' di roba applicativa di troppo non cambia nulla.
> grazie
> Andrea
.m
--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
blog @
http://milestone.topics.it
whynot [ at ] topics [ dot ] it