Newsgroup: it.comp.programmare.win32
Titolo: framework, framework, ancora framework

a proposito di framework...
quale framework usate? quale avete provato? quale vi č piaciuto?
su questa pagina ce n'č una bella lista
http://www.atai.org/guitool/#free_toolkit
io conoscevo solo Fltk, gtk+ e wxWindows....
ho trovato 
www.beyondata.com
 che offre una versione free (non ho bene capito
che tipo di licenza) di MFC. chissą come č.....
ciao!
f.


http://www.atai.org/guitool/#free_toolkit
Conoscevo anch'io quella pagina e la prima volta che la vidi sono
rimasto sopreso dalla quantita' di progetti, alcuni interessanti,
altri perso nel nulla...
wxWindow l'ho scaricato tempo fa e l'ho provato, ma in generale quando
ho a che fare con piu' di una decina di files include e/o cpp rimango
scontento. Idem quando devo portarmi a spasso qualche dll.
Il mio ideale di framework/wrapper deve essere piccolo, in C++, pochi
files .h e .cpp e non fornirmi un mare di cose che non uso. Se poi mi
permette di scrivere codice portabile (con poche modifiche per la user
interface) anche per Linux ancora meglio.
Io sto scrivendo per un mio progetto un framework simile per
incapsulare in modo OO i controlli di Windows, senza scomodare
templates, quando lo avro' completato lo rendero' disponibile
(attualmente consta di un file .h e un file. cpp)
Ciao
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
despammed.com

 (attualmente consta di un file .h e un file. cpp)
anche io tempo fa ne feci uno
consisteva solo di una classe Application e una classe Window (ereditabile),
e pochi handler (OnPaint, OnInit, OnDestroy, ecc... i + comuni...)
però aveva la particolarità di non usare il SetWindowLong o il SET_DATA (non
ricordo esattam,ente il nome), ma usava invece un piccolo hack in assembler,
che dalla windowproc richiamava la classe corretta, gestendo lui il
puntatore e tutte cose...
il codice di questo hack non me lo sono inventato io, ma lo trovai in un
articolo di programmazione...
se ti interessa.... fai un fischio!
ciao
f.

se ti interessa.... fai un fischio!
Ti ringrazio ma ormai il progetto e' molto avanti e ho seguito la
strada "classica" dello spazio GWL_USERDATA tramite
SetWIndowLong/GetWindowLong. Tu perche' hai preferito l'uso dell'hack
in assembler ?
Anch'io nel mio wrapper ho deciso di gestire solo cio' che mi serve
(non ho certo intenzione di riscrivere le WTL o MFC) ma e' comunque
piuttosto completo: mi manca di gestire i ListBox ownerdraw (per i
Combo uso i ComboBoxEx), le dialog box modeless e poi quando ho un
minimo di tempo mettero' sula pagina sul mio sito...
Mi piacerebbe rendere disponibile uno "scheletro" che ognuno puo'
prendere ed ampliare in base alle proprie esigenze partendo da quello
che ho gia' scritto, vedremo se sara' utile :-)


 (attualmente consta di un file .h e un file. cpp)
Curiosità: come gestisci gli eventi?
-- 
Marco Barisione
http://marcobari.altervista.org/

 Curiosità: come gestisci gli eventi?
probabilmente usera' dei metodi virtuali da "overridare"... :)
On<Evento>()...

 in assembler ?
per avere l'user-data libero....
essendo una funzione che offre windows ho pensato che potrebbe servirmi in
futuro per fare delle cose, che farei appunto con
SetWindowLong(GWL_USERDATA), ma continuando a usare il mio "framework".
ciao
f.

On<Evento>()...
Esatto, non invento certamente l'acqua calda :-)
In pratica quando nella window procedure del controllo (subclassato)
ho un messaggio , es. WM_COMMAND (ho preso quello meno indicato per
tutta una serie di motivi sui quali ora sorvolo) eseguo un
p->OnCommand(...)
dove p e' il puntatore alla classe associata alla finestra e OnCommand
e' un metodo della classe derivabile.
Fosse cosi' sarebbe banale, in realta' la complessita' deriva dal
fatto che in WM_COMMAND arrivano molti messaggi/notifiche che smisto
chiamando i vari metodi OnQualcheCosa in base al controllo.
Pero' gestendo quello e anche il WM_NOTIFY la pulizia del codice che
ne deriva e' notevole, ed e' stato il motivo principale per cui mi
sono imbarcato in questo progetto :-)
In pratica avevo gia' un programma venduto (un piccolo PIM) scritto
direttamente in C++ e Win32 (in modo standard, con windows procedure,
gestione messaggi etc.) ma pur funzionando benissimo ho deciso di
riscriverlo (nel tempo libero) sviluppando contemporaneamente il
framework/wrapper che avevo iniziato a maggio e poi "sospeso" quasi
subito (ma mi era servito per capire come farlo e verificarne
l'effettiva portabilita' su Linux e Motif)
Ora sto sviluppando alcuni dettagli tipo un controllo Picture che
incapsuli la OleLoadPicture e i suoi casini (Render, StreamOnGlobal e
compagnia), mi manca il controllo Tab e le versioni ownerdrawn del
menu, del combo e del listbox che pero' credo faro' piu' avanti.
Quanto prima mettero' su una paginetta html con i files ed un
progettino completo MDI con dialog box che faccia da manuale :-)


 sono imbarcato in questo progetto :-)
Io non sono d'accordo di gestire da framework gli eventi visto che si
aggiungono limitazioni e il codice rimarra sempre meno leggibile(senza
parlare dei "troppi" metodi virtuali aggiunti).
Secondo me la gestione deve essere lasciata al programmatore per evitare
troppi livelli di elaborazione.Sul sito in firma c'è un framework open
source  per chi volesse capire quello che intendo e magari dare una mano
allo sviluppo.La licenza è quella tipica dei framework (LGPL)
ciao :)
------------------------
http://visualwx.altervista.org/
nuova release 0.77e [freeware]
VisualWx rad per c++,python,perl,lua e wxwindows

allo sviluppo.La licenza č quella tipica dei framework (LGPL)
Ho visto gia' qualche tempo fa il vostro progetto ed e' veramente
notevole, ma i miei obiettivi sono diversi: continuare ad usare VC+ ed
il suo resource editor (anche se un po' squallido).
Non ho ben capito cosa intendi per "non voler gestire da framework gli
eventi": se incapsuli un controllo in una classe poi dove li gestisci
? Sempre da window procedure ? Io lo avevo fatto per un oggetto
griglia che avevo scritto: i suoi messaggi venivano spediti alla
parent window (sotto forma di WM_APP+x) cosi' come succede per i
controlli standard ma con la scrittura del mio wrapper ne ho
approfittato per rendere gestisci la griglia anche con metodi
virtuali, che preferisco. Chiaramente sono scelte soggettive :-)
Ciao e buon lavoro !




Un'altra soluzione che avevo valutato era una "prop" con
SetProp/GetProp ma volendo mascherare il piu' possibile lo strato
inferiore (voglio fare il porting su Linux) occupare lo spazio
userdata non mi preoccupava.
Ciao


 virtuali, che preferisco. Chiaramente sono scelte soggettive :-)
mah infatti sono scelte :))
ciao
