Newsgroup: it.comp.programmare.win32
Titolo: int float

quale è il comando corrispondente per i float a
SetDldItemInt?
Grazie e ciaoooo

Grazie e ciaoooo
Non credo ci sia, per cui
char cBuffer[80];
sprintf(cBuffer,"%f",fValue); // fValue č la tua variaible float
SetDlgItemText(hdlg,IDC_FLOAT,cBuffer);
Ciao
Stefano "HappyMan" 
--
Personal Web 
http://www.sgr.info
Email 
happyman...@libero.it
 [Togliere nospam per scrivermi]
Salsa Web 
http://happyman.n3.net
 [Foto salseri/e & I.A.B.L.A. Ring]
IABLA Sezione Lago Maggiore (NO)

Grazie proverň cosě!


 Grazie proverň cosě!
Con una CString č meglio, perň... 8)
-- 
Luc.

> Con una CString è meglio, però... 8)
E con la std::string meglio ancora, dato che è Standard C++, mentre la
CString appartiene alle MFC
Salutoni, il Biondo

 CString appartiene alle MFC
SetDlgItemText non č molto c++, quindi: *pensare* prima di parlare!
-- 
Luc.

CString appartiene alle MFC
Non usando ne CString ne std::string mi fate un esempio pratico di
come mettere una variabile di quel tipo nelle API
SetDlgItemText e GetDlgItemtext, che vogliono un LPTSTR ?
Ciao e grazie


 SetDlgItemText e GetDlgItemtext, che vogliono un LPTSTR ?
Data una
    std::string lamiastringa;
puoi ottenerne un equivalente "puntatore a caratteri" (stringa tipo C,
terminata da 0) con
    lamiastringa.c_str()
Le std::wstring sono analoghe ma usano caratteri 'wide' (Unicode).  Non
c'e` diretto supporto per la convenzione di usare l'una o l'altra a
seconda di un flag di preprocessore (la 'T', per 'testo') ma non e`
difficile, se ti serve, fartela con un #if.
c_str torna un puntatore ad array _costante_ (non modificabile) di
caratteri.  Lo standard C++ non supporta la modifica diretta del
buffer visto come "stringa di tipo C".
Data una
    CString stringozza;
puoi averne un LPTSTR che garantisce una lunghezza di buffer di almeno
n caratteri con
    stringozza.GetBuffer(n)
dovrai poi chiamare stringozza.ReleaseBuffer() prima di potere fare
altre "operazioni da CString" con essa.
Se non hai bisogno di modificare direttamente il buffer, puoi usare
un cast:
    (LPCTSTR)stringozza
ma questo ovviamente ti torna un puntatore ad array _costante_ (non
modificabile) di caratteri.
Alex

 SetDlgItemText non č molto c++, quindi: *pensare* prima di parlare!
come no, e' una funzione di una libreria dichiarata in un header C con
tutti i crismi (e quindi anche c++). Sarebbe come dire che le funzioni che
scrivi tu non sono c++
Oltretutto SetDlgItemText si aspetta una LPCTSTR, ossia un char*, quindi
non vedo perche':
-istanziare una classe CString (invece di allocare un char*, qui sta la
grande differenza, allocare una classe non e'uno scherzo...)
-Assegnare il testo alla CString (non oso pensare come microsoft abbia
implementato la printf, e' gia un mostro la specifica ANSI)
-Convertire la CString in un char* (invece di passare il char * crudo)
A livello di efficienza del codice e' una follia...
ciao
Ermando

 SetDlgItemText e GetDlgItemtext, che vogliono un LPTSTR ?
char lpString[6];//dichiara e alloca memoria, ocio a lasciare un carattere
in piu per lo 0
strcpy(lpString,"PIPPO");//riempie la stringa
SetDlgItemText(hDlg,nIDDlgItem,lpString);
LPCTSTR non e' altro che una redefinizione di char*, una cosa del tipo:
#define LPCTSTR char*
ciao
ermando

 A livello di efficienza del codice e' una follia...
L'efficienza non è a prescindere dal contesto. Questo si impara in anni 
di programmazione. 
-- 
Luc.

 char lpString[6];//dichiara e alloca memoria, ocio a lasciare un carattere
Ok per strcpy, ma inaccettabile per una sprintf!
-- 
Luc.

SetDlgItemText è una funzione MFC.
Prima di essere una funzione MFC è una API Win32, esposta in qualche
classe da MFC.


 classe da MFC.
Ovviamente, ma penso/spero programmi in MFC per queste cose... 8)
-- 
Luc.

On Fri, 25 Jan 2002 10:15:14 +0100, Luc <XXX...@katamail.comXXX>
wrote:

Ti sembrerà strano ma io non ho MAI usato MFC, non per partito preso
ma perché ho iniziato a programmare per Windows con i compilatori
della Borland (per Windows 3.1), che ho aggiornato nel tempo, e il
supporto per MFC non è mai stato il loro forte. Così ho preso
dimestichezza a programmare direttamente con le API.
Per il tipo di applicazioni che scrivo in C++ (la maggior parte, per
diletto,sono utilities, ma ho anche scritto un bel programmone per la
gestione della produzione di fabbriche di sanitari)  non ho mai avuto
la necessità di imparare le MFC, ma so che questo è un mio limite nel
momento in cui vorrò avere a che fare con COM, che utilizzato solo con
le API è un "poco" complesso :-)
Del resto per COM e compagnia uso VB :-/
Ciao


 Del resto per COM e compagnia uso VB :-/
La miglior ragione per usare C++ (diletto a parte, che ognuno si
diverte come preferisce) e` la necessita` di fare cose molto, ma
*MOLTO* veloci e/o minuscole.  ATL (e le API) te lo permettono.
Se non hai bisogno del massimo di prestazioni, forse fai meglio in VB!
Alex

piccolo e di un veloce da sbavarci...
Si possono usare anche per la parte client (ciò che contiene l'Activex
per intenderci) ? Più che creare controlli potrebbe servirmi
utilizzare nelle mie applicazioni Win32 quelli già esistenti (es.
Internet Explorer).


 Internet Explorer).
Si`, puoi farci anche dei container, e` naturalmente un problema
*molto* piu` delicato, ma ci sono buoni articoli in rete, come
http://www.codeguru.com/atl/atlclienttut.shtml
 e altri piu`
avanzati sull'MSDN.
Tuttavia, la magrezza e velocita` dei container e` molto meno
importante di quella dei controlli, E e` molto piu` difficile
scrivere un buon container che un buon controllo, quindi in
questo specifico caso non sono sicuro che il gioco valga la
candela.
Alex

 Ok per strcpy, ma inaccettabile per una sprintf!
non capisco cosa intendi, e' ovvio che devo allocara abbastanza memoria per
poterci scrivere il numero...
che altro?

 di programmazione. 
te ne bastano una ventina? L' efficienza deve essere al primo posto quando
si sviluppa un qualsiasi programma, anche un "hello world". Unica deroga la
leggibilita' quando non si stia sviluppando qualcosa al limite della
macchina. Sviluppare pensando che la memoria sia infinita e' una cosa che
si insegna alle matricole o che sostiene chi non e' capace di fare
altrimenti. Purtroppo questo modo di pensare ha formato una generazione di
programmatori improvvisati e i risultati sono agli occhi di tutti nel
mercato del software

 si sviluppa un qualsiasi programma, anche un "hello world". Unica deroga
Per carita`.  L'esperienza di vent'anni potrebbe bastare eccome, ma...:
"Una persona puo` avere dieci anni di esperienza, o un anno di
esperienza ripetuto dieci volte" (Yukiso Yamamoto).  E visto che
siamo in tema di citazioni, continuiamo con alcune sul tema specifico
da parte di alcuni dei piu` grandi programmatori contemporanei:
"Si commettono piu` errori di programmazione nel nome dell'efficienza (senza
necessariamente raggiungerla) che per qualunque altra ragione, compresa la
pura stupidita`" (W. A. Wulf)
"Dimenticati le piccole efficienze, circa il 97% delle volte: 
l'ottimizzazione prematura e` la radice di tutti i mali" (D. Knuth)
"E` piu` facile ottimizzare il codice gia` corretto che correggere il 
codice gia` ottimizzato.  Il codice corretto non ti sorprende con tanti bug
latenti molto dopo che pensavi di aver finito" (B. Harlan)
"Regole per ottimizzare:
  1. non farlo.
  2 (solo per esperti): non farlo ancora." (M. A. Jackson)
Beh, puo` bastare.  Vediamo piu` analiticamente perche` le cose stanno 
cosi`...
Nei migliori processi di sviluppo, l'efficienza (ottimizzazione) e` 
"l'ultima" considerazione -- non in senso di importanza, in senso temporale:
1. fallo funzionare
2. fallo bello
3. fallo svelto
L'inizio dello sviluppo tipicamente ha le caratteristiche di "prototipo" e 
produce codice, anche di bassa qualita`, ma sufficiente a verificare le
funzionalita` desiderate.  La seconda fase si occupa soprattutto di
qualita` del codice: chiarezza, semplicita`, manutenibilita`.  Se il 
risultato non soddisfa gli obbiettivi di prestazioni, si entra nella terza
fase, che inizia MISURANDO (con un profiler) quali risorse sono consumate e 
da quali parti del programma.  Tipicamente, un 10-20% del codice di un
programma e` responsabile dell'80-90% del suo consumo di risorse, e la
misurazione ci dice quale e` questa parte critica: "se non puoi misurarlo,
non puoi controllarlo".
L'unica eccezione importante a questo schema generale e` nella scelta
di algoritmi e strutture dati (tipicamente in fase 2) che abbiano delle
caratteristiche prestazionali "decenti" -- non necessariamente ottimali
ma non asintoticamente disastrose in termini di notazione O(), che si
usa per indicare appunto le caratteristiche asintotiche di consumo di
risorse.  L'esempio tipico e` con gli algoritmi di ordinamento, dove quelli
"piu` elementari" come bubblesort consumano tempo proporzionale al
quadrato del numero di elementi [O(N**2)] mentre esistono algoritmi
O(N logN).  Il sort (ordinamento) e` un buon esempio anche perche` al
giorno d'oggi l'uso di una buona libreria, gia` ottimizzata per benino, e`
piu` spesso che no la scelta giusta.  Il "micro-ottimizzatore", rimasto
mentalmente al tempo in cui una macchina con 32K parole di memoria
era grossa e costosa, e` capace di preoccuparsi del "costo" di una
chiamata a funzione e trascurare il costo, questo si` enorme, che una
scelta sbagliata degli algoritmi (e strutture dati) comporta particolarmente
nei problemi "veri" (quelli che affrontano i clienti, tipicamente piu` 
grossi di quelli "giocattolo" da usare come test in fase di sviluppo).
Il problema principale dell'informatica (da decenni, ormai) e` quello della
correttezza (bug) e della manutenzione (correzione di bug e aggiunta di
feature).  L'efficienza ha la sua importanza, ma non e` mai al primo
posto.  Se il programma non fa quello che serve al cliente (perche` gli
manca la feature cruciale, o perche` i bug interferiscono) non importa
che fallisca in meta` o un terzo del tempo che impiega un altro programma
che invece il lavoro lo fa.  E` solo fra due programmi entrambi corretti e
funzionalmente completi che puo` interessare quale sia piu` veloce o
consumi meno memoria.  PUO` interessare, non necessariamente
interessa.  Se due programmi interattivi calcolano la stessa cosa, uno
ci mette 100 millisecondi, l'altro, tanto piu` veloce, solo 100 
microsecondi, questo non fa nessuna differenza per il cliente, che
comunque li vede entrambi "istantanei" dal suo punto di vista.  Questo
fenomeno e` gradualmente sempre piu` frequente man mano che i
tipici computer "da due soldi" sono sempre piu` potenti e veloci, e ricchi 
di risorse come la memoria.  Di conseguenza, l'efficienza risulta, con
ogni anno che passa, di sempre minore importanza pratica.
Alex

> SetDlgItemText non è molto c++, quindi: *pensare* prima di parlare!
E per quale motivo non separare l'interfaccia grafica (e quindi le sue
funzioni, specifiche, ecc)  dal "motore" del programma (che è buona regola
sia scritto in c++ standard) ?
In c++ è una buona regola di programmazione, utile anche per il porting.
Mi scusi... spero di aver pensato bene adesso....

 Mi scusi... spero di aver pensato bene adesso....
Si, ora si.
8)
-- 
Luc.

 che altro?
Fa niente, noi vediamo la programmazione in modo completamente diverso 
(vedi mex. precedenti)...
-- 
Luc.

 (vedi mex. precedenti)...
Togli gli occhiali da sole, e' inverno.
strncpy e snprintf ti possono andare bene ?
Sono state introdotte col C99.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Sono state introdotte col C99.
Purtroppo sono mal progettate.  strlcpy (introdotta in OpenBSD e
usata gradualmente in sempre piu` progetti -- altri BSD, componenti
sicuri che da OpenBSD si sono estesi al resto del mondo, Solaris,
ecc) e` meglio.
Confrontiamo ad esempio strlcpy con strncpy.  La seconda ha la
disastrosa specifica di scrivere sempre len bytes, senza peraltro
garantire di scrivere almeno UNO zero.  Risultato: complicazioni
del codice chiamante per controllare che il risultato sia ben
zero-terminato E sciocco overhead di prestazioni tutte le volte
che si usano (come e` buona politica) buffer molto piu` grossi
rispetto alla necessita` media.
Vedi ad esempio una tipica misurazione di tempi per un mucchio
di copie della stringa "this is just a test" su di un buffer di
1K (e spesso naturalmente useremo buffer piu` grossi), come
dettagliato a [URL lunga, rimettila insieme se troncata]:
http://www.usenix.org/events/usenix99/full_papers/millert/millert_html/index
.html
strcpy  0.137
strncpy 0.464
strlcpy 0.140
strlcpy ha praticamente le stesse prestazioni di strcpy, quindi si
puo` serenamente usare SEMPRE, relegando strcpy al dimenticatoio
dove dovrebbe stare.  strncpy puo` facilmente rallentare le cose
di 3 volte o piu` senza nessuna buona ragione -- oltre alla
facilita` d'uso, confronta:
/* con strcpy e strcat: compatto ma insicuro */
strcpy(path, homedir);
strcat(path, "/");
strcat(path, ".foorc");
len = strlen(path);
/* convertito a strncpy e strncat: lungo e brodoso */
strncpy(path, homedir, sizeof(path) - 1);
path[sizeof(path) - 1] = '\ 0';
strncat(path, "/", sizeof(path) - strlen(path) - 1);
strncat(path, ".foorc", sizeof(path) - strlen(path) - 1);
len = strlen(path);
/* convertito invece a strlcpy e strlcat: compatto e sicuro */
strlcpy(path, homedir, sizeof(path));
strlcat(path, "/", sizeof(path));
strlcat(path, ".foorc", sizeof(path));
len = strlen(path);
E` un vero peccato che, per questioni temporali legate alle
tempistiche del nuovo standard C rispetto a quelle della
proposta e pubblicazione a Usenix di strlcat &c, siano le
mal progettate strncat &c a essere entrate nello standard C.
Io consiglio comunque di usare lo stesso strlcat &c invece
di strncat &c -- e` un piccolissimo file sorgente in piu`
da aggiungere ai proprio progetti C, dopo tutto, su quelle
piattaforme che non le supportano direttamente.
Alex

 Sono state introdotte col C99.
No, mi dispiace. Non posso sapere quanto buffer mi serve esattamente.
8-PPPPPPPPP
PS: che sole oggi...
-- 
Luc.