View Full Version : [VC++/MFC]Non c'è MFC AppWizard (exe)
Premetto che non ho mai programmato con mfc e vc++.
Ho appena instalato VC++ 6.0 e seguendo ciò che tutte le guide dicono in giro ho cercato di realizzare il mio primo progetto.
File->NewProject->New
Qui appaiono le cartelle:
-InterDev Projects( che permette di aprire progetti del tipo New web project e Single app wizard)
-VisualStudio contente a sua volta:
+Database project
+Distribution unit
+Utility project
+VisualStudio Analyzer
Ovviamente in nessuna di esse è contenuta la tipologia MFC AppWizard (exe).
Come posso fare???:confused:
tomminno
30-05-2008, 13:48
Premetto che non ho mai programmato con mfc e vc++.
Ho appena instalato VC++ 6.0
VC++ 6 :confused:
Hai appena installato un compilatore uscito 10 anni fa prima della ratifica dello standard C++.
Io scaricherei VS2008 Express Edition, visto che è gratuito.
me lo hanno dato in ufficio x il pc dell'ufficio...uso quello che passa il convento....:(
Io scaricherei VS2008 Express Edition, visto che è gratuito. e anche, ahimè, pesantemente mutilato* :muro:
me ne sto rendendo conto ultimamente e ci soffro non poco :cry:
*tra l'altro mancano anche gli appwizard, quindi in questo topic è fuori discussione.
tomminno
30-05-2008, 14:17
e anche, ahimè, pesantemente mutilato :muro:
me ne sto rendendo conto ultimamente e ci soffro non poco :cry:
Se non sbaglio dovrebbe mancare l'editor visuale e il supporto ai plugin.
Per i plugin Refactor! ancora non funziona su VS2008, nonostante affermino il contrario, non credo che siano così indispensabili altri plugin per sviluppare.
Per l'editor visuale, beh visto lo schifo di codice che generano è meglio che non ci siano :D
Se non sbaglio dovrebbe mancare l'editor visuale e il supporto ai plugin. e ATL e MFC e i wizards e IL COMPILATORE A 64 BIT (non so se mi spiego...)
Per l'editor visuale, beh visto lo schifo di codice che generano è meglio che non ci siano :D l' "editor visuale" come lo chiami tu non genera un bel niente (posto che si tratti di quello che penso io, ovvero l'editor di risorse); a meno che non ti scandalizzi della qualità del codice dei resource scripts, ma in tal caso ho tre domande:
1) normalmente invece quel codice lo scrivi a mano?
2) quali sarebbero le motivazioni?
3) l'hai mai visto in vita tua il suddetto codice? o sei rimasto a quello generato da Visual C++ 6.0?
ma perchè nn andate a disquisire in un altro thread??
Nessuno che può darmi un mano?
ma perchè nn andate a disquisire in un altro thread?? perché siamo in-topic e nessuno può dirci niente :asd: :ciapet:
tomminno
30-05-2008, 15:42
e ATL e MFC e i wizards e IL COMPILATORE A 64 BIT (non so se mi spiego...)
Come noto XP64 e Vista64 sono i sistemi operativi più diffusi...
Gli wizard si possono fare tranquillamente senza un progetto apposito, che oltretutto non è presente nemmeno su VS2005 Professional Edition.
MFC tra le librerie grafiche C++ è forse quella peggiore.
Anche le wx ormai non usano più le macro per lo scambio di messaggi.
Inoltre mancano i box! Concetto ormai presente in tutte le altre librerie grafiche, mancano anche in C# evidentemente alla Microsoft non sono molto graditi.
ATL? Sono realmente necessarie?
l' "editor visuale" come lo chiami tu non genera un bel niente (posto che si tratti di quello che penso io, ovvero l'editor di risorse); a meno che non ti scandalizzi della qualità del codice dei resource scripts, ma in tal caso ho tre domande:
1) normalmente invece quel codice lo scrivi a mano?
2) quali sarebbero le motivazioni?
3) l'hai mai visto in vita tua il suddetto codice? o sei rimasto a quello generato da Visual C++ 6.0?
Ah non genera nessun codice?
E i file .h e .cpp che derviano dal dialog o dal frame chi ce li mette nel progetto e chi li modifica?
A me risulta direttamente l'editor visuale.
L'ultima volta che ho dovuto usare l'MFC è stato con VS2005, quindi non sono rimasto al VC6, ma non mi sembra cambiato poi molto, visto che le MFC sono rimaste praticamente le stesse, hanno solo qualche funzione in più.
In ogni caso gli editor automatici (per qualunque linguaggio) ti impediscono di organizzare il codice come meglio credi, visto che ti obbligano a mantenere il codice della GUI secondo le loro regole.
Quindi si preferisco di gran lunga scriverlo a mano il codice, ci metto meno tempo e soprattutto scrivo codice che è meglio organizzato, il che è un vantaggio non da poco quando la GUI è un minimo più complessa di un singolo dialog.
tomminno
30-05-2008, 15:50
Scusa ma nell'elenco dei progetti non compare nemmeno Win32 Application/Console Application/Dynaminc-Link Library/Static Library?
Come noto XP64 e Vista64 sono i sistemi operativi più diffusi... sono molto diffusi: se uno ha una macchina a 64 bit di certo non ci mette Windows a 32 bit.
qualche tempo fa ho iniziato a sviluppare un mio programma freeware che ho rilasciato su un mio sito e che purtroppo non posso compilare in versione a 64 bit; non sono passate due settimane dalla seconda release che mi è arrivata una mail in cui un mio utente mi diceva che su Vista 64 il programma non partiva. è una limitazione estremamente fastidiosa.
Gli wizard si possono fare tranquillamente senza un progetto apposito, che oltretutto non è presente nemmeno su VS2005 Professional Edition. eh?
MFC tra le librerie grafiche C++ è forse quella peggiore. è l'unica che avrei potuto utilizzare in quel famoso programma e anche in un altro.
Anche le wx ormai non usano più le macro per lo scambio di messaggi. danno problemi?
Inoltre mancano i box! Concetto ormai presente in tutte le altre librerie grafiche, mancano anche in C# evidentemente alla Microsoft non sono molto graditi. infatti non lo conosco, nonostante per anni abbia lavorato anche con la VCL; sarà che erano versioni vecchie (ho abbandonato Delphi alla versione 6). di cosa si tratta?
ATL? Sono realmente necessarie? si. io per quel programma ho dovuto praticamente riscriverle...
Ah non genera nessun codice?
E i file .h e .cpp che derviano dal dialog o dal frame chi ce li mette nel progetto e chi li modifica?
A me risulta direttamente l'editor visuale. stai grandemente confondendo tra editor di risorse e Class Wizard; non esiste nessun "editor visuale". ribadisco, hai mai usato un'edizione diversa dalla Express? e per quanto tempo?
L'ultima volta che ho dovuto usare l'MFC è stato con VS2005, quindi non sono rimasto al VC6, ma non mi sembra cambiato poi molto, visto che le MFC sono rimaste praticamente le stesse, hanno solo qualche funzione in più. infatti lo sviluppo ora s'è praticamente fermato, ma rispetto alla versione 4.2 (distribuita con Visual C++ 6.0) ce n'è stato parecchio.
In ogni caso gli editor automatici (per qualunque linguaggio) ti impediscono di organizzare il codice come meglio credi, visto che ti obbligano a mantenere il codice della GUI secondo le loro regole.
Quindi si preferisco di gran lunga scriverlo a mano il codice, ci metto meno tempo e soprattutto scrivo codice che è meglio organizzato, il che è un vantaggio non da poco quando la GUI è un minimo più complessa di un singolo dialog. questo discorso, validissimo ad esempio in Java per Visual Editor e concorrenti, proiettato su Visual C++ risulta solo un'ingenua generalizzazione. le regole imposte dal Class Wizard di MFC sono minime. inoltre in Java i controlli vanno creati e posizionati manualmente da codice uno per uno e la cosa richiede design, e Visual Editor ti impone il suo che fa schifo, e ok; nella programmazione Win32 invece il concetto stesso di risorsa elimina il problema: i controlli vengono generati automaticamente dal subsystem Win32 e a te non serve di design-are un bel nulla, devi solo chiamare CreateDialog/DialogBox e rispondere alle notifiche.
tomminno
01-06-2008, 12:02
sono molto diffusi: se uno ha una macchina a 64 bit di certo non ci mette Windows a 32 bit.
qualche tempo fa ho iniziato a sviluppare un mio programma freeware che ho rilasciato su un mio sito e che purtroppo non posso compilare in versione a 64 bit; non sono passate due settimane dalla seconda release che mi è arrivata una mail in cui un mio utente mi diceva che su Vista 64 il programma non partiva. è una limitazione estremamente fastidiosa.
Pensa a quanti portatili Core2 ci sono e a che Vista hanno preinstallato.
Io ho un portatile con Vista 32bit e a lavoro pur avendo dei Core2 ho sempre Vista 32 bit (anche se stiamo pensando di tornare a Windows Server 2003 perchè Vista è veramente pietoso e IIS7 è ancora peggio).
Gli wizard si possono fare tranquillamente senza un progetto apposito, che oltretutto non è presente nemmeno su VS2005 Professional Edition.
eh?
Io a lavoro non ho un progetto apposito per gli wizard con VS2005.
è l'unica che avrei potuto utilizzare in quel famoso programma e anche in un altro.
Io preferisco di gran lunga le wx (sebbene anche queste non siano proprio il massimo quanto a pulizia della libreria), con le AUI inoltre riesci a creare interfacce d'effetto, anche se questo spesso non è un obiettivo primario.
Come "side effect" girano anche su WinCE e su Linux, con look & feel nativo.
danno problemi?
Le wx o le macro? Per le wx mai avuto problemi, mentre ne ho avuti spesso con le MFC.
Per le macro preferisco 10000 volte scrivere qualcosa come
Connect(ID_BUTTON,...);
su cui posso eseguire anche un Disconnect se mi serve.
infatti non lo conosco, nonostante per anni abbia lavorato anche con la VCL; sarà che erano versioni vecchie (ho abbandonato Delphi alla versione 6). di cosa si tratta?
Mi riferisco ai BoxLayout e simili del Java, ai wxSizer per le wx e QBoxLayout delle QT.
Sono dei contenitori per cui puoi impostare il layout di tutti i controlli che ci inserisci, puoi farli espandere o meno con la dimensione della finestra in modo uniforme oppure differenziato a seconda del controllo (ad esempio se hai una riga con textbox e pulsate puoi fare in modo che si espanda solo la textbox), il tutto rimane organizzato come lo hai impostato a qualunque risoluzione.
Con le MFC devi dannarti l'anima per avere un effetto simile o impostare una risoluzione fissa, personalmente non ci sono mai riuscito in modo soddisfacente, e anche con gli ancoraggi del C# se la finestra è un minimo complessa il risultato non è altrettanto valido (anche con questo linguaggio ho maledetto Microsoft per non avere inserito una funzionalità a dir poco essenziale per il disegno di interfacce grafiche).
stai grandemente confondendo tra editor di risorse e Class Wizard; non esiste nessun "editor visuale". ribadisco, hai mai usato un'edizione diversa dalla Express? e per quanto tempo?
Diciamo che non ho mai usato la versione Express, ho usato tutti gli editor Microsoft dal VS6 in poi, oltre all'EVC4 che come funzionalità e libreria è messo peggio di VC6.
Poi chiamalo come vuoi ma se aggiungo un button su un dialog e ci faccio doppio click mi viene creato sia il messaggio sia l'evento sul codice h e cpp.
Magari sbaglio a chiamarlo io, ma tutti gli altri editor che fanno questo si chiamano editor visuali, che poi il dialog venga messo nel file di risorse o venga generato del codice poco importa (anzi meglio che venga generato del codice che non il file di risorse, altro punto a sfavore delle MFC).
infatti lo sviluppo ora s'è praticamente fermato, ma rispetto alla versione 4.2 (distribuita con Visual C++ 6.0) ce n'è stato parecchio.
Diciamo che dopo la pausa presa da Microsoft per lo sviluppo del C# qualche novità e tornata con VS2008.
questo discorso, validissimo ad esempio in Java per Visual Editor e concorrenti, proiettato su Visual C++ risulta solo un'ingenua generalizzazione. le regole imposte dal Class Wizard di MFC sono minime. inoltre in Java i controlli vanno creati e posizionati manualmente da codice uno per uno e la cosa richiede design, e Visual Editor ti impone il suo che fa schifo, e ok; nella programmazione Win32 invece il concetto stesso di risorsa elimina il problema: i controlli vengono generati automaticamente dal subsystem Win32 e a te non serve di design-are un bel nulla, devi solo chiamare CreateDialog/DialogBox e rispondere alle notifiche.
E' il concetto di risorsa a non essere altrettanto potente quanto quello esprimibile da codice e infatti programmare interfacce grafiche con le MFC è molto più rognoso che con altre librerie.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.