Il 06/02/2011 23:23, Tommaso Russo, Trieste ha scritto:
> Soviet_Mario ha scritto:
>> Il 02/02/2011 00:44, Tommaso Russo, Trieste ha scritto:
>>> Elio Fabri ha scritto
>>>> Tommaso Russo ha scritto
>
>> dunque, purtroppo lo stiamo perdendo ... :-)
>
> Manno', si e' reso necessario un consulto con alcuni luminari, ma ora e'
> piu' chiaro quale defibrillatore usare. Nel frattempo il paziente e'
> stato tenuto in coma farmaceutico (non avrai mica scritto ancora una
> linea di codice, no? Il bravo paziente deve pazientare).
uhm, invero l'intelaiatura del programma l'avevo imbastita
prima ancora di postare la domanda, perch� la questione
delle presentazione interna dei dati e del formato poteva
essere impostata a priori in modo generico, ergo non
inficiava eccessivamente le procedure
>
> Nel seguito do' alcune risposte puntuali ai dubbi del paziente, alla
> fine (in cauda venenum, che vuol dire anche medicina) prescrivo la mia
> cura alla tua domanda da OP.
>
> Ovviamente puoi sentire anche un secondo, terzo, quarto parere, eh! :-)
>
>
>>>> Per me gli argomenti delle funzioni citate *debbono essere numeri
>>>> puri*.
>>> OK, e questa e' la tua posizione. Considerare solo funzioni analitiche
>>> R->R.
>>
>> Houston abbiamo un problema. Quella scrittura non mi dice niente.
>> Anche il termine "applicazione" per me ha il solo significato di
>> "eseguibile", "programma"
>
> E' Analisi I: un'applicazione e' una legge che consente di associare ad
> ogni elemento di un insieme A, detto dominio, un solo elemento di un
> insieme B detto codominio. Se ogni elemento dell'insieme B e' associato
> a un solo elemento di A, l'applicazione e' iniettiva. Se ogni elemento
> di B e' associato almeno ad un elemento di A, l'applicazione e' detta
> suriettiva. Un'applicazione iniettiva e suriettiva e' invertibile, ossia
> consente di risalire da ogni elemento di B ad uno di A.
>
> Applicazione e funzione sono sinonimi, ma il termine funzione e'
> preferito quando il codominio e' un campo numerico.
>
> Se A=B=retta reale, allora hai un'applicazione di R in R (o R->R), dove
> R e' l'insieme di numeri reali.
>
> Una funzione analitica e' esprimibile localmente come serie di potenze
> convergente (Taylor, McLaurin). Le trigonometriche, esponenziali e loro
> inverse sono tutte analitiche.
ok, grazie dei chiarimenti.
>
> Su R, sin(x) non e' ne' iniettiva (sin(x) = sin (k*2pi+x)) ne'
> suriettiva (!Esiste x: sin(x) = 2). Ma restringendo il dominio per
> esempio a ]-2pi,pi] e il codominio a [-1,1], diventa invertibile anche lei.
>
>
>> dunque, nel programma le scritture saranno di tipo in apparenza solo
>> matematico. Sin(X) e stop. Ma X avr� associata una descrizione a
>> parte, indipendente dall'uso sintattico, come a dire dei metadati, che
>> saranno confrontati (match) coi tipi attesi per l'operatore (unario),
>> e il verdetto dipender� dal match o non match
>
> No, non basta: anche se il match c'e', puo' essere ancora necessario
> moltiplicare l'argomento per un fattore di conversione.
semplici i fattori di scala (multipli e sottomultipli) li
implemento in modo intrinseco ai metadati.
Invece conversioni diverse, tipo gradi radianti, o fahreneit
celsius, potrebbero avere moduli a parte
Non ho aree comuni, ma l'oggetto dato ha con s� i propri
metadati che qualsiasi operatore pu� esaminare.
Va da se che anche errori di dominio vengono esaminati (anzi
in realt� far� un trap di condizioni di errore,
intercettando a posteriori, se no mi tocca a scrivere il
doppio del codice)
> E comunque i
> metadati devono essere esaminati dal metodo Sin,
certo, nella rappresentazione interna chi invoca l'operatore
(la routine generica che delega, con array di puntatori a
funzione specifica) ha le informazioni per fare i controlli
> per cui anche se non li
> metti formalmente fra gli argomenti della funzione (informatica), ma li
> lasci in un'area comune,
sono dati di "istanza" pi� che shared, ma credo che volessi
dire la stessa cosa
> ne sono argomenti sostanziali.
certo, questo � incontrovertibile
> Altrimenti hai
> una funzione (informatica) che accetta un floating in input e
> restituisce un floating: insomma, una funzione (matematica) R->R.
no, infatti non mi interessa questo. Cos� sarebbe solo una
calcolatrice programmabile, non un correttore di
procedimenti di risoluzioni
>
> > ... sintatticamente non implemento coppie. I metadati
>> sono etichette visualizzabili solo a parte
>
> Questo pone un'ipoteca sulla soluzione del tuo problema da OP: se tu
> volessi scrivere equazioni fra grandezze fisiche ("quantity equations",
> come riportate dal BIPM da Pangloss), sarebbe giocoforza passare come
> input sia la loro misura o valore numerico, sia l'unita' di misura.
graficamente � un non problema.
L'input non � fatto tramite files di testo, ma in modo
UTENTE via un interfaccia grafica che traccia le scelte (le
grandezze sono selezionate da listbox precompilate), nemmeno
i numeri si digitano, ma si selezionano i dati del problema
o i risultati intermedi da essi ottenuti cos� come stoccati.
Ossia un utente che manipola dati, cliccando le varie
listbox e pulsanti, immette una procedura, che sar� valutata
numericamente e dimensionalmente.
> Visto che vuoi usare funzioni che accettano in input solo un numero
> floating point e danno in output un altro numero floating, dovrai per
> forza usare "numerical value equations".
boh ... non credo che far� nessuna distinzione esplicita.
Quando scegli un dato dai numeri, l'interfaccia si pone in
modalit� di "attesa selezione unit� di misura", che puoi
skippare, ma introduci degli errori dimensionali che poi
danno penalizzazioni anche severe.
>
>>> Alla fine arriviamo alla stessa formula. La differenza e' che per me
>>> Sen(a) (maiuscola per distinguerlo da sin) e' un'applicazione {a:a e' un
>>> angolo} -> R, mentre per te sin(x) e' R->R.
>>
>> E qui l'abbiamo perso (io).
>
> No, tranquillo :-)
>
>> Concretamente devo implementare un'unica scrittura per le funzioni,
>> che siano analitiche, trascendenti o quel che si vuole, ma devo
>> scrivere un "coso" usabile da studenti anche e soprattutto sin dalla
>> prima (cio� il momento in cui perdi l'occasione di imparare che
>> controllare le dimensioni � una cosa importante)
>
> OK. Ne tengo conto.
>
>>> Sen(x,1) = sin(x) (R->R)
>>> Sen(x,rad) = sin(x/1) (angoli in radianti->R)
>>> Sen(x,�) = sin(x*pi/180.00) (angoli in gradi->R)
>>> Sen(x,gon) = sin(x*pi/200.00) (angoli in gradi centesimali->R)
>>> Sen(x,qualsiasi altra cosa) -> errore.
>>
>> Allora, cio' che scrivi dopo la virgola sar� nascosto nei metadati e
>> visibile solo nella scheda del DATO.
>
> OK.
>
>> Cmq ... ,1 cosa significa ? � un numero puro ?
>
> Nelle mie intenzioni doveva essere l'unita' di misura delle grandezze
> adimensionali, cioe' il numero 1.
Mizzeca ... finezze inaccessibili per un comune mortale.
>
>> in definitiva che faccio, accetto come argomenti SIA angoli SIA numeri
>> puri?
>
> No, no: per trigonometriche ed esponenziali saranno sempre numeri puri.
> Eventuali angoli espressi in gradi li trasformerai, prima, in radianti.
>
>> E il valore che esce � un numero puro sempre?
>
> Si'.
>
>> Su questo si � raggiunto l'accordo ?
>
> Direi di si'.
Ok ... bene,
>
>> Dunque, non so, ma non mi pare che questo controllo dimensionale che
>> devo fare coincida con l'analisi dimensionale.
>
> Infatti, sono solo lontani parenti.
>
>> Diciamo solo che i ragazzi devono usare formule, non inventate da
>> loro, ma date per buone, e nell'infilarci dentro gli opportuni valori
>> devono stare attenti a che i dati abbiano le dimensioni attese. Questo
>> dovrebbe potersi fare.
>
> Si', si puo'.
>
>> P.S. dolorosamente osservo che la mia antica spina nel fianco dei
>> logaritmi dimensionali e le costanti di equilibrio sono cascate nel
>> vuoto.
>> ...
>> Ln(Keq) = -DG�/RT
>>
>> il secondo membro � adimensionale
>> il primo DEVE diventarlo
>> l'argomento del logaritmo non lo � ...
>> che azz��_at_@##??!! succede ?
>
> Su questo credo proprio di aver capito il casino che fanno i chimici ed
> Elio Fabri concorda (che e' un casino) :-)
ultimamente ho visto quelle versioni che le concentrazioni o
meglio attivit� sono state rese adimensionali rapportandole
a conc. 1M. PEr me � un escamotage, cmq funziona ... Rimane
il problema che non potr� mai spiegare le cose a quel
livello, ergo l� mi sa che sono destinato a rimanere
infangato in un inconsistenza di fondo ineliminabile.
>
>> Come dicevo mi resta anche la spina nel fianco dei logaritmi ed
>> esponenziali, perch� mi pare che esista almeno una formula (tra
>> l'altro un pilastro della termodinamica, la legge di Guldberg Waage)
>> che "pare" (dico pare per cautela, ma a me sembra certo) avere dei
>> logaritmi con argomento dimensionato.
>
> Non e' un pilastro della Termodinamica, e' un pilastro della Chimica ;-)
vabb� intendevo termodinamica chimica.
I fisici la studiano, i chimici la usano :-) Che poi a volte
molti, me specialmente, la usiamo senza capirla, � un altro
par de maniche.
> E la dimensione dell'argomento e' solo apparente. Nei testi di Chimica
> che ho visto sinora compaiono *quasi sempre* argomenti *non*
> dimensionali. E quando trovi un'equazione dimensionalmente corretta e
> che percio' sembra fra grandezze, come ad esempio
>
> deltaG-deltaG� = R T ln(P/P�)
>
> e' solo perche' e' stata tratta da un libro di Fisica, ma immediatamente
> convertita a "numerical value equation" con la scelta, implicita o
> esplicita, delle unita' di misura che verranno usate nel seguito.
>
>> Uffi
>> Ciao e grazie del vespaio (che non pensavo di sollevare)
>
> E' stato utilissimo, non solo per te, ma anche per un paio di studenti
> qui vicino che stanno affrontando separatamente proprio le equazioni di
> equilibrio :-)
>
>
> OK, ora la /pars construens/.
>
>
>
> Tratto per primo un programma che tratti *solo* problemi di Fisica, si
> capira' dopo perche'.
>
> Nel corpo del programma userai solo "numerical value equations".
>
> Questo significa che, prima di scrivere la prima riga di codice, devi:
>
> - definire esattamente le unita' di misura che userai per ogni singola
> grandezza. Nel caso della Fisica, puoi limitarti a usare strettamente le
> unita' di misura del SI: m, Kg, s, A (o C), K, e le loro derivate: ti
> semplifichera' la vita sia nell'implementazione delle formule, sia nel
> reperimento dei valori numerici delle costanti universali.
nella GUI ho preinserito tutte le possibili grandezze, anche
derivate, SI, con descrizione, nome e dimensioni ridotte
alle potenze di quelle fondamentali.
Nella rappresentazione interna compatta una qualsiasi
grandezza o risultato � ridotto a rappresentazione delle
sette fondamentali con esponente non nullo.
Per le routine generiche (agevolano enormemente le
operazioni tra potenze, trovandosi le varie componenti ad
offset costanti in arrays preallocati identici) invece
implemento un array di sette componenti elementari, e
laddove la grandezza non ci sta l'esponente � zero.
Fa un po' di calcoli ridondanti (tipo a volte somma qualche
zero o sottrae qualche zero), ma evita una notevole parte di
ricerca di componenti omogenee, essendo posizionalmente
corrispondenti.
Ogni dato ha la sua fingerprint di sette componenti (gli
esponenti hanno un algebra overload di frazioni razionali a
numeratore e denominatore interi senza segno, con segno a
parte, credo che non ci saranno errori tipo radici cubiche
etc, perch� nel usare i confronti float temevo in qualche
cricca)
> Ma,
> ovviamente, puoi fare anche scelte diverse: l'importante e' che poi tu
> rispetti la scelta fatta nell'implementazione di tutte le formule che
> userai. Sarai facilitato dal fatto che la maggior parte dei testi di
> Fisica usa "quantity equations", equazioni fra grandezze, assegnando
> alle costanti universali un simbolo piuttosto che esprimerle
> numericamente (dando per implicite le loro unita' di misura) o
> dimensionalmente (p.es. scrivendo 1.3806504*10^-16 erg K^-1 al posto di
> k_B). Per cui potrai assegnare il giusto valore numerico alle variabili
> o simboli "costanti universali" G, kB, eps_0, mu_0, h, hbar... e
> trascrivere le formule esattamente come le leggi.
Si, una parte di interfaccia con costanti universali �
un'ottima idea, probabilmente le metter� tra i dati non
specificamente del problema, che � una piccola complicazione
per l'utente ma utile (nel senso che se fornisco solo quelle
necessarie non c'� la necessit� di sapere cosa serve e cosa no)
>
> - DOCUMENTARE LA TUA SCELTA. Questo e' un punto fondamentale per la
> manutenibilita' e la modificabilita' del software. Poche righe di
> commento messe con grande evidenza all'inizio del main saranno
> sufficienti. Ma se non ce le metti, *sicuramente* prima o poi ti
> capitera' di apportare modofiche usando "numerical value equations"
> buone solo in un set di unita' di misure diverse.
Si in genere sono relativamente ordinato ... ma chi scrive
solo per s�, pi� di tanto non riesce a esserlo.
Cmq do dei nomi a variabili e metodi che somigliano a
ClsEsponIntero
ClsDimensFisicaCompatta
ClsAbsDimensFisicaLstCompleta
e altri anche pi� lunghi :-)
La ragione � che tendo a dimenticare facilmente quello che
scrivo un'ora prima
> (Mi e' capitato di recente di cercare di capire che cavolo di unita' di
> misura usava un programma di simulazione del comportamento di nanotubuli
> di piombo sottoposti a trazioni e temperatura diverse.
se puoi, e chiedi pure il permesso al tuo referente, mi
daresti ragguagli in merito ?
Anni fa volevo calcolare le "ultimate strength" di
nanofilamenti metallici generici, monocristallini, e anche
carichi di rottura di fibre polimeriche, magari quel tuo
amico sta facendo modellazioni che in parte mi
interesserebbero molto.
LA mia di allora tesi era relativa al superiore carico di
rottura di filamenti monocristallini se confrontate con
specimen di materiali reali.
> La persona che mi
> chiedeva aiuto in merito doveva introdurre una rotazione del sample fino
> a un valore prefissato di omega, aggiungendo a ogni step un momento
> della QDM ad ogni atomo. L'unica unita' di misura di cui eravamo certi
> e' che la temperatura veniva misurata in K. Dall'ispezione del sorgente,
> e dal valore di kB, fu possibile capire che l'energia veniva espressa in
> keV. Sul resto, nebbia. Alla fine di una lunga indagine riuscimmo a
> contattare l'estensore della prima versione e scoprimmo che le distanze
> venivano espresse in angstrom, le masse in dodicesimi della massa
> dell'atomo C_12 e i tempi in nanosecondi :-( )
>
> - A questo punto hai due scelte:
>
> 1) dici ai ragazzi che *tutte* le quantita' che verranno immesse come
> dati di input *dovranno* essere misurate nelle unita' di misura del SI.
Si mi attengo al SI, ma manualmente dovranno solo cliccare
in entries precompilate (anche se la lista � lunga e da mal
di capo).
Non avranno mezzi di immettere dimensioni in modo manuale
diretto. I dati hanno le loro. I risultati le acquistano in
modo automatico secondo i dati da cui originano e gli
operatori a cui sono stati soggetti.
> m, m^2, m^3, Kg, rad, joule, newton, pascal eccetera. Banditi i grammi,
uhm, il grammo lo uso,
il cm � un metro pi� un fattore di scala. Sono ammesse per
ora solo le potenze std di tre in tre ... devo meditare se
lasciare immettere anche deca, deci, centi, etto ... mah, mi
piacciono poco
Il litro lo consento ma viene visualizzato 0,001 m^3 come
equazione dimensionale)
> i cm, i litri, i gradi
sui gradi uso i K e stop, li al limite metter� il
convertitore a parte.
Atmosfere nein
roba anglosassone vade retro satana ... gli PSI ! ! ! Pounds
per square inches. Maronn
> , le atmosfere, yarde, pinte, galloni, angstrom,
> barn et citara. Se hanno dati in queste unita' di misura esotiche,
> devono prima di tutto convertirle in quelle del SI. Magari usando
> google: p.es.
>
> http://www.google.it/search?q=3+atm+in+pascal
>
> oppure con un convertitore che fornisci tu.
>
> Io preferisco questo metodo perche' lo trovo molto educativo (e anche
> Elio Fabri e' d'accordo, mi pare). Pero' mi pare troppo restrittivo
> (almeno per quanto riguarda gli angoli misurati in gradi, i celsius vs i
> kelvin, e simili unita' d'uso comune), per cui passerei almeno in parte
> alla seconda scelta:
tenderei a voler usare solo le unit� standard, e le altre
farle convertire esternamente, se necessario.
Ma per ora non immagino come necessario, se i dati del
problema li dar� gi� standard io
>
>
> 2) consenti loro di introdurre i dati come valore numerico *e* unita' di
> misura, scegliendo queste ultime da un elenco - stretto o largo, a
> scelta tua - di simboli ammessi (e DOCUMENTATI) o da menu', convertendo
> immediatamente ogni grandezza nelle unita' di misura usate internamente
> per i calcoli successivi.
Si, questa � la scelta.
Anche perch� internamente sono rappresentati come banali e
rapidi enum, non certo in modo testo, e una gui da filtro mi
consente facilmente di collegare univocamente quel che VEDE
l'utente a quel che acquisisce il programma
>
> 2.b) in questo caso, pero', dovresti anche memorizzare le unita' di
> misura usate per gli input in una tabella di "unita' di misura
> preferite",
credo ci saranno solo le standard
> per evitare all'utente lo shock di introdurre i dati di un
> problema in atmosfere e ottenere un risultato in pascal. Ovviamente
> potresti trovarti di fronte al problema di aver memorizzato due (o piu')
> unita' "preferite" per la stessa grandezza, p.es. cm e anni luce. In
> questo caso una soluzione intelligente potrebbe essere di usare per
> l'output l'unita', fra quelle "preferite", con cui il log_10 della
> misura e' piu' prossimo a 1,5 (dando cosi' preferenza a numeri "umani",
> di ordine di grandezza fra unita' e migliaia).
wow, qui siamo nella finezza !
Invece credo che lascer� la scelta del fattore di scala
(ogni singola grandezza elementare lo consente). Se i numeri
non piacciono, che provino a cambiarlo.
Posso sempre tracciare tentativi maldestri in questo senso.
>
> A questo punto pero' ti trovi nella necessita' di inserire nel progetto
> anche equazioni e problemi tratte da libri di Chimica. E qui i problemi
> sono due: uno riguarda i ragazzi, l'altro te.
>
> - Per i ragazzi: la maggior parte dei problemi che ho visto da' i dati
> in litri (talvolta anche millilitri o cc), moli/litro, grammi (milliKg?
> :-), atmosfere, piccole o grandi calorie, eccetera. Spesso anche
> temperature in celsius anziche' kelvin. Trasformare preliminarmente
> questi dati in unita' SI credo che per loro sia un compito sovraumano, e
> penso anche al di fuori degli obbiettivi didattici. O sviluppi un
> *diverso* progetto, solo per la Chimica, in cui usi anche internamente
> queste unita' di misura e le imponi ai ragazzi, o, per fare un unico
> progetto, fai decisamente la scelta 2).
beh, parte della scelta ricade su chi progetta la verifica,
che inserisce i dati e quindi gi� sceglie lui le dimensioni.
Ogni dato sar� inspectabile (orrido neologismo lol) per
avere dettagli pi� espressivi della semplice equazione
dimensionale ... questo magari � utile x grandezze derivate
complesse, mah.
>
> - Ma, come abbiamo visto, nei testi di Chimica troverai prevalentemente
> "numerical value equations" basate su una scelta precedente delle unita'
> di misura usate, che coincidono solo in piccola parte (mol, K) con
> quelle del SI, e per il resto anticipano quelle che vengono usate nei
> problemi.
>
> Dopo quello che abbiamo visto, *tu te la senti* di trasformare tutte
> queste equazioni in equazioni fra grandezze, in modo da poter poi
> scrivere senza problemi equazioni numeriche si', ma basate sulle unita'
> di misura del SI?
affatto, tenderei invece a usare solo equazioni numeriche a
schermo, ma con l'obbligo di scegliere (selezionare) le
dimensioni dei risultati ottenuti elaborando i dati. Il
programma genera di suo la corretta dimensione, e la confronta.
Per come ho visto che � possibile eliminare le dimensioni
dai termini logaritmici, purtroppo, dovr� scrivere cose
errate, ma coerenti con le spiegazioni.
Secondo il testo del problema un log potrebbe prendere
numeri puri o potenze delle conc. molari.
Non posso inserire quei rapporti con le conc. unitarie o
pressioni unitarie nelle spiegazioni, perch� non hanno
raffronti nei libri n� in esercizi che si trovano.
Pazienza ! Allora diventa almeno importante una coerenza
interna.
>
> Questo significa, ad esempio, traformare tutte le "pressioni misurate in
> atmosfere" in P/P� con P�1325 Pa, tutte le "concentrazioni misurate
> in mol/litro" in C/C� con C�00 mol/m^3, et cetera et cetera et
> cetera... (e sicuramente non ho visto nei libri consultati tutte le
> possibilita', ce n'e' sicuramente qualche altra che ti fara' uscire
> pazzo...).
� troppo avanzato ... io l'ho scoperto la settimana scorsa
dopo avere letto vari libri "pratici" sull'uso di quelle
equazioni. E' ragionevole che possa imporrre ci� a degli
studenti malgrado i libri avversi ? Imho no
> E significa sopratutto *ricordarsi* (DOCUMENTARE) questa
> convenzione, che dovra' essere usata per qualsiasi aggiunta o modifica
> successiva.
>
> Visto che i chimici hanno creato un *loro* mondo di equazioni numeriche
> con il presupposto di aver adottato un *loro* set di unita' di misura
> (anche se non coerenti), e che per questo nelle loro formule troverai
> spesso costanti dimensionali espresse in forma numerica, mi sa che
> l'unica strada non troppo impervia e' di adeguarsi, cercare di spiegare
> quanto sopra ai ragazzi, e separare i due progetti. Nel secondo
> progetto, potrai usare anche internamente le unita' di misura tipiche
> dei testi di Chimica, e limitare a quelle piu' comuni nei laboratori di
> chimica le unita' di misura ammesse per l'input.
>
>
> Mi associo ad Elio nel farti gli auguri, ne avrai bisogno...
mah ... i casi sono due, o mi sottovalutate come "coder", o
sopravvalutate della grossa la reale portata di quel che
voglio fare, che � abbastanza modesto in realt�. Per dirla
con Guzzanti, direi : la seconda che ho detto, lol :-)
A parte gli scherzi : fare il parsing di un input utente
indiscriminato senza restrizioni � la follia pura, e il
controllo della sintassi post-mortem da nightmare (anche se
didatticamente sarebbe molto pi� utile di sicuro, perch�
presupporrebbe una componente compositiva importante).
Ma gestire input filtrati solo via interfaccia grafica
(magari un'interfaccia furba che si pone in stati di attesa
adeguati all'input precedente), si traduce molto facilmente
in rappresentazione interna e relazioni tra operandi e
operatori.
Allora non � poi cos� ambizioso, sul serio.
Cmq un eccesso di vizio lo vorrei evitare. Se uno mi digita
due operatori binari di fila, senza operandi, � giusto che
possa farlo e che venga penalizzato. Un editor troppo smart
e protettivo alla fine ti fa fare il problema giusto per forza.
Cmq, ora avr� scrutini e inutili collegi dementi, ops
docenti ... e non � detto che lo finisca sto benedetto
programma (sono un po' incostante, mi attizzo quando un
problema mi sfida, ma quando � fatto il grosso e devo
mettere apposto la minuzia comincio ad annoiarmi, la caccia
ai piccoli bug � tediosa :-().
Ma in qualsiasi momento ti interessassero delle bozze,
Tommaso, non serve che dirmelo e te le mando.
O almeno ti mando la prima roba senza palesi errori che la
rendono proprio incompilabile.
Sono in VB.net, e in teoria dovrebbero potere essere portate
su tutte le piattaforme che lo supportano.
Cerco anche di usare elementi grafici solo di base, e di
referenziare solo il compact framework (il core minimo
diciamo), in modo poi da fare installazioni di dimensioni
umane. Credo di stare usando la vers. 3.5, ma non me lo
ricordo per certo. Ho fatto la cavolata di installare la
vers. 2008 e la 2008, cos� forse nel sistema ho tante copie
diverse, e non ci capisco pi� una mazza quando referenzio
qualcosa :-)
P.S. l'IDE di visual studio � veramente poderoso, quando ci
si prende anche il minimo di confidenza. Riesce a tenere in
ordine anche il programmatore pi� disordinato
ciao
Soviet
>
> ciao
>
>
Received on Mon Feb 07 2011 - 16:53:26 CET