Visual C++ 2010 Express e array di textboxes
Shinji
stavo provando di crearmi un progettino in Visual C++ 2010 Express e
avevo qualche dubbio sui form nelle applicazioni CLR.
Venendo dai vari VB mi sono trovato spesso ad utilizzare array di
controlli (non so neanche se è questo il termine) nel senso di avere
una ipotetiva txtTesto[0], txtTesto[1] etc etc in modo da poter
interagire più rapidamente con le stesse e gestirle con dei cicli.
Forse sarò io che non ho capito bene come si fa ma mi sembra che con
Visual C++ non sia possibile fare questo C'è un modo diverso dal
creare Textbox1, Textbox2, Textbox3 (me ne servono più di 50 e non
vorrei stare a duplicare tutto il codice di gestione una infinita di
volte).
Grazie a chi ha avuto la pazienza di leggere :-)
Gianni
Matteo Migliore
> Visual C++ non sia possibile fare questo C'� un modo diverso dal
> creare Textbox1, Textbox2, Textbox3 (me ne servono pi� di 50 e non
> vorrei stare a duplicare tutto il codice di gestione una infinita di
>volte).
In .NET gli eventi restituiscono due parametri:
1. sender: contiene la reference all'oggetto che ha
scatenato l'evento
2. e: � il parametro che contiene eventuali informazioni
addizionali
Per creare quello che era un array di controlli in VB6 ora
� succiente creare n-controlli, a mano/design-time o a runtime sta a te
deciderlo, e far puntare i delegate degli eventi allo stesso metodo:
------------------------------------------
UserControl ^uc1 = gcnew UserControl();
uc1->Click += UserControlClick;
UserControl ^uc2 = gcnew UserControl();
uc2->Click += UserControlClick;
void UserControlClick(System::Object ^sender, EventArgs ^e)
{
UserControl ^uc = safe_cast<UserControl^>(sender);
////Do something with "uc"
}
------------------------------------------
Domanda: perch� non usi C#?
La sintassi � certamente meno ostica di C++, soprattuto per
chi viene da VB.
> Grazie a chi ha avuto la pazienza di leggere :-)
Prego! ;-)
--
Matteo Migliore
http://blogs.ugidotnet.org/matteomigliore
Giovanni Dicanio
news:1F95A3B5-B994-40C6...@microsoft.com...
> Domanda: perch� non usi C#?
>
> La sintassi � certamente meno ostica di C++, soprattuto per
> chi viene da VB.
Esatto.
Se si ha intenzione di usare WinForms per realizzare GUI, conviene
decisamente usare C# (o VB.NET) piuttosto che C++/CLI.
Il supporto dell'IDE � migliore, la sintassi pi� pulita, etc.
C++/CLI ha il suo posto nell'ecosistema dei linguaggi di programmazione di
Visual Studio, ma questo non � certamente lo sviluppo di GUI.
Giovanni
Shinji
> decisamente usare C# (o VB.NET) piuttosto che C++/CLI.
>
> C++/CLI ha il suo posto nell'ecosistema dei linguaggi di programmazione di
>
> Giovanni
L'obiettivo è un porting di una applicazione che ho già scritto in VB6
con un solo form (ma con una 80ina di controlli) che usa qualche API
come Bit Blit e fa qualche elaborazione con dei dati che si è tirato
su da db.
In VB6 ho applicato tutti i trucchi possibili per rendere alcune
elaborazioni più veloci, ma non si può spingere più di tanto e quindi
pensavo al C++ in quanto mi permetterebbe magari di fare le stesse
operazioni in un decimo del tempo.
Stavo optando per il C++ in quanto non sono completamente a digiuno ma
effettivamente è difficile togliersi la testa del programmatore db per
calarsi agevolmente nella sintassi.
Può essere una buona occasione per utilizzare un linguaggio nella
pratica: magari uno si legge dei libri, si studia la sintassi ma se
non si mette a creare un programma di almeno media complessità da zero
non prende mai dimestichezza con un linguaggio.
Inoltre ho provato a convertire un paio di funzioni in VB 2008 e mi
sembrano molto più veloci del VB6 ma non sono in grado di capire se
questa velocità basta.
Gianni
Raffaele Rialdi [MVP]
> con un solo form (ma con una 80ina di controlli) che usa qualche API
> su da db.
Sulle operazioni nativi C++ ha una marcia in piￜ perchￜ non ha il
performance hit del thunking. In parole povere la BitBlt invocata da C#
impiega di piￜ che invocata da C++.
Ovviamente il guadagno dipende dalle volte che la chiami. Se ti scappa
un marshalling delle immagini da memoria managed a nativa, rischi di
buttare performance dalla finestra.
> Puￜ essere una buona occasione per utilizzare un linguaggio nella
> pratica: magari uno si legge dei libri, si studia la sintassi ma se
> non si mette a creare un programma di almeno media complessitￜ da zero
> non prende mai dimestichezza con un linguaggio.
Se stai iniziando, ti invito a provare WPF con C#.
La BitBlt ha delle limitazioni che dipendono da GDI e non ci puoi fare
piￜ di tanto.
WPF usa DirectX e ha delle performance immensamente superiori oltre a
supportare una montagna di altre cose molto interessanti come le
animazioni, le elaborazioni in GPU (Effect) sfruttando HLSL, pixel
shader 3 (da WPF 4.0) e molto altro.
L'unica alternativa competitiva per performance sarebbe usare C++ con
DirectX ma ad un costo di complessitￜ decisamente sproporzionato e
totalmente in controtendenza sulle tecnologie emergenti (cioￜ ogg un
programmatore WPF in C# ￜ certamente piￜ appetibile di uno C++ con
DirectX parlando di sviluppo di applicazioni). Persino nel campo dei
videogame si va verso XNA e non piￜ verso DirectX.
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft .NET MVP http://mvp.support.microsoft.com -
UGIdotNET - http://www.ugidotnet.org
Giovanni Dicanio
news:c012b488-fd0e-4f2d...@c3g2000yqd.googlegroups.com...
> L'obiettivo � un porting di una applicazione che ho gi� scritto in VB6
> con un solo form (ma con una 80ina di controlli) che usa qualche API
> come Bit Blit e fa qualche elaborazione con dei dati che si � tirato
> su da db.
>
> In VB6 ho applicato tutti i trucchi possibili per rendere alcune
> elaborazioni pi� veloci, ma non si pu� spingere pi� di tanto e quindi
> pensavo al C++ in quanto mi permetterebbe magari di fare le stesse
> operazioni in un decimo del tempo.
Di che tipo di operazioni si tratta?
> Stavo optando per il C++ in quanto non sono completamente a digiuno ma
> effettivamente � difficile togliersi la testa del programmatore db per
> calarsi agevolmente nella sintassi.
Non � solo un problema di sintassi. Certamente devi avere delle solide bassi
di sintassi (e *semantica*) del C++.
Poi occorre anche conoscere qualche libreria per lo sviluppo di GUI (ve ne
sono diverse: MFC, ATL/WTL, QT, wxWidgets...).
> Pu� essere una buona occasione per utilizzare un linguaggio nella
> pratica: magari uno si legge dei libri, si studia la sintassi ma se
> non si mette a creare un programma di almeno media complessit� da zero
> non prende mai dimestichezza con un linguaggio.
Certo, la pratica � fondamentale.
> Inoltre ho provato a convertire un paio di funzioni in VB 2008 e mi
> sembrano molto pi� veloci del VB6 ma non sono in grado di capire se
> questa velocit� basta.
Qui mi sfugge qualcosa: cosa vuoi dire? Chi dovrebbe capire "se questa
velocit� basta"? Tu o i tuoi clienti siete soddisfatti dalle performance
della nuova versione VB.NET?
Vi siete prefissati una soglia di performance (tipo "elaborazione X da
eseguire in massimo Y secondi") e tale soglia non viene raggiunta?
Giovanni
Giovanni Dicanio
news:mn.a5967d9b2...@n0spamvevy.com...
> (cioￜ ogg un programmatore WPF in C# ￜ certamente piￜ appetibile di uno
> C++ con DirectX parlando di sviluppo di applicazioni).
Dipende dalle applicazioni.
Per applicazioni scientifiche (che di solito funzionano anche su sistemi
Unix-like), si usa OpenGL e C/C++.
Se devi sviluppare un CAD avanzato ti scrivi il tuo motore di rendering 3D
personalizzato e magari hai bisogni di un'API a basso livello (immediate
mode) tipo DX o OpenGL, invece di WPF.
> Persino nel campo dei videogame si va verso XNA e non piￜ verso DirectX.
Pensavo che XNA fosse per hobbysti piￜ che per sviluppatori professionisti
di videogame.
Che io sappia, la maggior parte dei titoli per PC sono sviluppati usando C++
e DirectX, e anche l'Xbox 360 usa una versione speciale di DirectX, da
programmare in C++.
Inoltre, credo che una grossa fetta del mercato dei videogame sia posseduto
dalla Playstation, che usa una versione ad hoc di OpenGL.
Giovanni
Giovanni Dicanio
news:8602b55e-e3df-4194...@a31g2000yqn.googlegroups.com...
> Venendo dai vari VB mi sono trovato spesso ad utilizzare array di
> controlli (non so neanche se � questo il termine) nel senso di avere
> una ipotetiva txtTesto[0], txtTesto[1] etc etc in modo da poter
> interagire pi� rapidamente con le stesse e gestirle con dei cicli.
Venendo a questa tua richiesta specifica, se usi C++ nativo (perch� se usi
WinForms tanto vale usare C# o VB.NET per le GUI), puoi crearti un array di
HWND, e fare i cicli sugli elementi dell'array.
es.:
#include <vector> // STL vector container
typedef std::vector< HWND > Controls;
Controls controls;
// Riempi l'array di controlli usando constrols.push_back()
...
Quando ti serve un ciclo su tutti gli elementi dell'array di controlli:
for ( size_t i = 0; i < controls.size(); i++ )
{
DoSomething( controls[i] );
}
Se usi ATL puoi usare CWindow al posto degli HWND grezzi; se usi MFC puoi
usare CWnd*.
(Ma considerando che usi la versione Express di Visual Studio, non hai a
disposizione n� ATL n� MFC.)
Giovanni
Shinji
> Di che tipo di operazioni si tratta?
Ricerca di parole di senso compiuto (che ho in memoria piuttosto che
su un db) all'interno di una specie di matrice, una funzione che
richiama recursivamente se stessa per valutare tutte le possibili
combinazioni.
> Qui mi sfugge qualcosa: cosa vuoi dire? Chi dovrebbe capire "se questa
> velocità basta"? Tu o i tuoi clienti siete soddisfatti dalle performance
> della nuova versione VB.NET?
> Vi siete prefissati una soglia di performance (tipo "elaborazione X da
> eseguire in massimo Y secondi") e tale soglia non viene raggiunta?
No niente clienti è una cosa che stavo scrivendo per me, per
automatizzare una serie di operazioni, quasi più come studio.
Intendevo che se la velocità di VB2008 basta non lo posso sapere
finchè non ho implementato l'applicazione di nuovo e nel caso non
andava bene ero costretto a fare un ulteriore porting..
...stavo prendendo anche in considerazione l'ipotesi di lasciare
l'applicativo in VB6 magari fare una DLL C o C++ per i calcoli...
Gianni
Raffaele Rialdi [MVP]
>> con DirectX parlando di sviluppo di applicazioni).
>
> Dipende dalle applicazioni.
> Per applicazioni scientifiche (che di solito funzionano anche su sistemi
> Unix-like), si usa OpenGL e C/C++.
> Se devi sviluppare un CAD avanzato ti scrivi il tuo motore di rendering 3D
> personalizzato e magari hai bisogni di un'API a basso livello (immediate
> mode) tipo DX o OpenGL, invece di WPF.
Non sto dando un giudizio binario, Directx o WPF.
Ho scritto che ￜ piￜ appetibile uno WPF. Cioￜ vedo che sul mercato ￜ
molto piￜ richiesto.
>> Persino nel campo dei videogame si va verso XNA e non piￜ verso DirectX.
>
> Pensavo che XNA fosse per hobbysti piￜ che per sviluppatori professionisti di
> videogame.
> Che io sappia, la maggior parte dei titoli per PC sono sviluppati usando C++
> e DirectX, e anche l'Xbox 360 usa una versione speciale di DirectX, da
> programmare in C++.
> Inoltre, credo che una grossa fetta del mercato dei videogame sia posseduto
> dalla Playstation, che usa una versione ad hoc di OpenGL.
Le varie parti di videogame sono suddivisibili in categorie di sw.
Grossolanamente possiamo dividere almeno in tre: motore di rendering,
motore di fisica e storyboard.
Il rendering e i motori di fisica lo fanno in pochi al mondo, sono
quelli che ha i costi piￜ alti e vengono "riciclati" per tanti
videogame. Tipicamente ￜ sviluppato in C++ e DirectX. La fetta di
mercato ￜ piccola.
La parte di "scripting" cioￜ il videogame vero e proprio che implementa
la logica portante del gioco la puoi sviluppare con qualsiasi
linguaggio. Meglio se non ￜ interpretato per ovvi motivi.
XNA ￜ un buon mix di tutto questo.
Ovviamente sto ipersemplificando...
Per motivi ovvi OpenGL ad oggi ￜ meno performante. I produttori hw
hanno la fetta piￜ grossa di mercato su DirectX e hanno sviluppato
l'hardware in quella direzione.
Inoltre dal punto di vista prettamente di implementazione OpenGL ￜ una
tragedia. Una macchina a stati le cui transizioni sono complesse e in
cui ￜ facilissimo inciampare.
Giovanni Dicanio
> Intendevo che se la velocit� di VB2008 basta non lo posso sapere
> finch� non ho implementato l'applicazione di nuovo e nel caso non
> andava bene ero costretto a fare un ulteriore porting..
Non so che tipo di conoscenze tu abbia in relazione al C++...
Se devi prima imparare il C++, poi anche a programmare le GUI da C++ nativo,
allora forse impiegheresti minor tempo passando direttamente da VB6 a
VB2008.
> ...stavo prendendo anche in considerazione l'ipotesi di lasciare
> l'applicativo in VB6 magari fare una DLL C o C++ per i calcoli...
Questa idea non � male.
Potresti individuare i colli di bottiglia delle performance, e sviluppare
codice C o C++ ottimizzato da racchiudere in una DLL da richiamare dalla tua
GUI VB6.
In questo modo non perdi tempo a riprogrammare la GUI, e focalizzi l'uso del
C++ solo sui punti critici della tua applicazione.
La DLL potrebbe essere una DLL Win32 con interfaccia C pura (all'*interno*
della DLL puoi anche usare C++, ma l'interfaccia deve essere C pura, ed
inoltre devi fare attenzione ad esempio a non far sfuggire eccezioni C++ al
di fuori della DLL), oppure potresti sviluppare una DLL COM (per questo
scopo, la libreria ATL � uno strumento utile a semplificare lo sviluppo lato
C++; per� per usare proficuamente ATL devi conoscere bene C++).
Giovanni
Shinji
riscrivere un pezzo di codice in VB2008 e valutare i tempi nel caso
non fossero accettabili per le mie esigenze provero con la dll win32
per i calcoli cosi almeno non impieghero tempo a combattere con
l'interfaccia grafica.
Grazie a tutti
Gianni