Newsgroup: it.comp.programmare.win32
Titolo: Abbandono le MFC, torno a Win32

Staro' facendo un grosso errore?

 Staro' facendo un grosso errore?
Un grosso errore che hai certamente fatto e` di postare
separate copie di questo messaggio qui e su altri gruppi
(tipo it.comp.lang.c++).  Se un messaggio _deve_ proprio
essere su molti gruppi (e qui non era il caso), usa un
"cross-post" su tutti i gruppi simultaneamente...
Sulla questione specifica: molte cose si fanno bene anche
con le Win32 API, o framework leggerissimi imperniati su
di esse come quello che fornisce l'ATL.  MFC, pero`, ti da`
tanto codice riusabile per funzioni antipatiche anzicheno`,
tipo il print-preview; se hai bisogno di queste cose, forse
ti conviene ricorrere comunque ad un framework "non
leggerissimo" di qualche tipo -- se non MFC, magari ad
esempio VWCL, o altro.
Se queste cose non ti servono, le API (e qualche piccolo
framework su di esse, per organizzare bene il tuo codice;
su cosa si possa fare in C ho qualche cenno nel mio
tutorial su 
http://aleax.supereva.it/
, in C++ ci sono piu`
possibilita` e ATL ad esempio le sfrutta bene) possono
in effetti costituire la soluzione migliore.  Di sicuro, esse
ti permettono di fare programmi piccoli, snelli, rapidi --
sempre che tu non debba offrire il print preview...:-).
Alex

Secondo me un grosso errore lo fai se non provi C++ Builder... poi davvero
non tornerai più indietro. Uomo avvisato...


non tornerai pių indietro. Uomo avvisato...
Quali classi usa come supporto? le OWL?
Comunque qualsiasi tipo di classi fornisca, il problema rimane.
Le MFC non sono da buttar via, e' che essendo delle librerie "general
purpose"
forse creano piu' problemi di quelli che risolvono.
Certo ci sono parecchi punti negativi tipo
L'implementazione Doc/View (non so cosa farmene di questa roba)
Serialize(), (meglio usare Write/ReadFile())
DoDataExchange()
di quelli che mi vengono in mente ora, pero' di queste cose si puo' farne a
meno (se ci riesci).
Si basa ancora sul "Framework"?
Credo che questo modo di fare programmazione sia sbagliato (almeno in C++)
Preferisco essere io a chiamare le funzioni e non aspettare che siano loro a
prendere l'iniziativa, (magari mentro sono di la' a prendere un caffe')
Usa i Wizard o qualcosa di simile?
Preferisco stare alla larga dai maghi, comunque questo tipo di strumento va
bene per fare delle prove altrimenti diventa una palla al piede.
Artu


Non lo so, comunque se anche stai facendo un errore non sei l'unico.
Anch'io ho deciso di abbandonare MFC e mi sto costruendo una libreria a classi,
molto piu' semplice, anche se non so se riusciro' ad usare i controlli ActiveX.

...

Acccc. Hai messo il dito sulla piaga!
Infatti piu' che il print preview, sara' da vedere se saremo capaci di fare
vera programmazione OLE con questo concentrato di tecnologia che sono gli
ActiveX (ma serviranno veramente?)
Comunque ci viene in aiuto il sig. Kraig  Brockschmidt con il suo "Inside
ole" (un po' pesantuccio) che credo  sia il testo sacro della programmazione
ole (come lo e' il Petzold per la programmazione Win32).
Certo e' che adesso che siamo qui sulla scialuppa di salvataggio, tutto
sommato non si sta poi tanto male, io ho ripreso le mie vecchie classi di
incapsulamento della hWnd e hDlg e di altre varie porcherie MS e sto
ripartendo da li', ci piazzo dentro anche un po' di DirectDraw e sono a
posto.
A proposito stando qui sulla barchetta si vedono benissimo le numerose falle
aperte nello scafo di MFC, riesci a vederle? Io dico che nel giro di un paio
di anni MFC cola a picco, anche grazie al siluro ATL (forse destinato a
scoppiare anche quello).
Poi volevo un parere su certe cose (e qui rischio di sputtanarmi del tutto)
tipo i bottoni, le edit box, etc. etc. ma se io mi disegno dei rettangolini
con 2 righe ad angolo scure e 2 chiare, non ottengo lo stesso risultato??. e
quel c...o di file RC e' proprio necessario? (per il momento sono riuscito a
fare una splendida gestione delle lingue con dei semplici file .TXT).
E il REGISTRY poi.... io credo che li dentro non ci mettero' piu' piede,
(salvo i clsid e altre cosettine simili) (non che non funzioni, per carita',
pero'......)
Artu.

 con 2 righe ad angolo scure e 2 chiare, non ottengo lo stesso risultato??.
Se riscrivi tutte le funzionalita` di un controllo standard, si`,
ottieni lo stesso risultato finale.  E` forse un poco assurdo,
secondo me, ma, prego, si accomodi!-)  (Fuori di scherzo,
una volta o l'altra potrebbe farti comodo per implementare
un controllo windowless...).
Alex

un controllo windowless...).
Probabilmente mi si e' annebbiata la mente (sento che e' cosi': mi sta
sfuggendo qualcosa di importante), ma quale complessa funzionalita' avrebbe
un bottone?!!
E una listbox? dici che e' un casino scrivere 10 righe di testo una sotto
l'altra??
Come mai hai tagliato il pezzo sul file RC? hai voluto salvarmi dal pubblico
ludibrio?
Artu.

 ludibrio?
Mi sembra di capire che tu preferisci generare una GUI al volo
in termini di codice eseguibile, mentre a me sembra molto piu`
furbo codificarla invece in una struttura dati (e il compilatore RC,
sempre a parer mio, fa un decentissimo lavoro in merito -- c'e`
anche il comodo fatto che i dialog template, ecc, cosi` generati,
vengono poi interpretati per tuo conto da codice gia` esistente
nelle API).
Troverai l'identica tesi nel testo di Bruce Eckel, "Thinking in Java",
che puoi scaricare gratuitamente dal suo sito 
www.BruceEckel.com
;
egli sostiene che la mancanza di un formato-DATI standard per
le GUI del Java e` stata un errore (concordo; il codice sta
benissimo, al posto suo, ma spesso e` preferibile usare dati
in formato standard e ridurre quanto espresso nel codice
a favore invece di quanto espresso nei dati).
Alex

a favore invece di quanto espresso nei dati).
Pensavo solo che il cliente avrebbe piu' piacere a modificarsi dei semplici
files .TXT con il notepad piuttosto che avere a che fare con l'RC. Ma forse
sono troppo buono con questi clienti.
Artu

 sono troppo buono con questi clienti.
Ma certo -- perche` riutilizzare un formato di testo ben noto,
documentato in cento posti, e per manipolare il quale esistono
gia` grande varieta` di strumenti?  Vuoi mettere che favore
fai ai "clienti", imponendo invece un TUO formato di testo, da
te inventato e da te solo supportato, per cui gli "strumenti" a
disposizione consistono in tutto e per tutto nel potentissimo
"notepad.exe"?  Sei veramente troppo buono a degnarti.
Alex

l'ontogenia, ma forse, nel tuo caso, si`.
Cavolaccio.
Non mi dire che non ci sono dei casi in cui conviene farsi una listbox nuova
nuova!
Passo e chiudo questo argomento seguito assiduamente da MILIONI di
programmatori in tutto il mondo. Meditero' tra un lavoro e l'altro.

 nuova!
Te ne ho gia` indicato uno, ed e` quello in cui per ragioni
di efficienza devi costruire un controllo "windowless".
Non me ne vengono in mente altri (nell'ambito di cui tratta
questo gruppo, cioe` la programmazione in Win32), ma,
naturalmente, cio` non esclude che altri possano esistere.
Alex

 nuova!
A me utente darebbe molto fastidio vedere UNA listbox "molto simile" a TUTTE
le listbox già presenti nel mio windows 98. Che però avrà sempre le sue
diversità, il suo aspetto leggermente diverso che stona con il resto...
--
Stefano Pettini
Risposte solo sul newsgroup, please.

 diversità, il suo aspetto leggermente diverso che stona con il resto...
Osservazione eccellente, ed importante; grazie di averla espressa.
A proposito del tuo altro post quasi simultaneo, pero`, considera
il rischio (OK, non e` una certezza, ma e` un alto rischio) che
implementare un _altro_ parser HTML abbia un risultato simile,
cioe` di finire per accettare (o, nel tuo caso, generare) un
"dialetto" _leggermente_ diverso da quello che accettano i 3 o 4
parser piu` diffusi... se si ha l'opportunita` di riutilizzare un buon
componente gia` esistente, l'uniformita` con cio` cui gli utenti
gia` sono abituati puo` essere un vantaggio -- sia per un parser,
sia [come tu osservi] per un controllo listbox:-).
Alex