Newsgroup: it.comp.programmare.win32
Titolo: [OT] - Perchè programmare in Delphi ?

Salve a tutti.
Sviluppo da circa un anno e mezzo applicazioni in visual c++ per ambienti
windows.
Premetto che  non mi intendo di Visual Basic ma trovo molta difficoltà a
realizzare
interfacce particolarmente accattivanti ed intuitive con VC++. Devo pero'
ammettere
che le potenzialità (in termini di velocità ed affidabilità del codice) di
VC++ sono
notevoli e quindi questa mancanza di facilità nella creazione
dell'interfaccia passa
in secondo piano.
Negli ultimi tempi mi hanno parlato molto bene di Delphi che per quel che ne
so
dovrebbe essere la versione ad oggetti del vecchio linguaggio Pascal.
Vorrei sapere se delphi è + o - facile di Visual Basic, per la creazione di
interfacce.
Inoltre mi chiedo se sia adatto per la scrittura di applicazioni che scenono
fino ad
un livello abbastanza vicino alla macchina (operazioni bit a bit,
preparazione ed invio di buffer
su linee seriali, ottimizzazione dell'uso della cache e della ram, ecc ).
Insomma sono alla ricerca di un linguaggio stabile e robusto come il C++ ma
che mi
aiuti a divertirmi nella realizzazione di interfacce grafiche. Mi piacerebbe
inoltre capire
se Delphi è un buon strumento per lo sviluppo di applicazioni DataBase.
So' di aver avanzato diverse pretese ma spero che qualcuno mi aiuti a capire
se è il caso
di passare da VC++ a Delphi.
Grazie anticipatamente a tutti.

 se è il caso di passare da VC++ a Delphi.
Una sola cosa: VC++ è molto più richiesto di Delphi nel mondo del lavoro.
-- 
Luc.

 inoltre capire se Delphi č un buon strumento per lo sviluppo di
applicazioni DataBase.
Se il tuo scopo e' quello di scrivere rapidamente applicazioni DB, potenti,
robuste e con un'interfaccia grafica accattivante, allora Delphi e'
sicuramente la scelta migliore.
Il C++ e' un linguaggio il cui uso, a mio avviso, nella programmazione
gestionale, e' da ponderare molto bene.
VC++ poi, nella progettazione dell'interfaccia, lascia molto a desiderare.
Io, comunque, ti consiglio di conoscerli entrambi (VC++ e Delphi).
--------------------------------
Inviato via 
http://usenet.libero.it

 VC++ poi, nella progettazione dell'interfaccia, lascia molto a desiderare.
Perchč? L'editor di risorse ed il Wizard connesso č di livello piů che 
buono!
Lo uso quasi giornalmente da 3 anni, ormai... ;)
-- 
Luc.

Harloc wrote:
[CUT]
Esiste una terza alternativa il C++ Builder, puoi usare tutti i controlli di
Delphi scritti con le VCL e il linguaggio di programmazione rimane il C++.
Antonio.

buono!
Scherzi? Devi comunque fare quasi tutto a mano (questo č comunque
dovuto alle limitazioni del formato delle risorse di win), e in piů le
API di Windows non offrono neanche nessun sistema per gestire il
layout.
-- 
Marco Barisione (ICQ 84277092)

 layout.
Cosa intendi?
-- 
Luc.

Cosa intendi?
Come gestisci il ridimensionamento delle finestre in Windows?
Spostando manualmente i controlli?


 buono!
Secondo te, secondo me no.
Ribadisco: se non hai mai usato Delphi, non puoi capire perche' non la pensi
come te.


 Spostando manualmente i controlli?
Richiamando quando finestra ridimensionata questo.... ;-)
void CMyClass::HandleSize( int dx, int dy )
{
  ResizeWidget( IDC_LIST, dx, dy );
  DispWidget( IDC_REMOVE, dx, 0 );
  DispWidget( IDC_SHOW, dx, 0 );
  DispWidget( IDOK, dx, dy );
  DispWidget( IDCANCEL, dx, dy );
  DispWidget( IDC_DESCRIPTION, 0, dy );
  ResizeWidget( IDC_DESCRIPTION, dx, 0 );
  DispWidget( IDC_PREVIEW, 0, dy );
} // HandleSize
PS: ovviamente le funzioni Widget ce le siamo fatte noi... ;-)
-- 
Luc.

> Come gestisci il ridimensionamento delle finestre in Windows?

Questo complica però le cose. Delphi non lo conosco ma da quello che
so offre un meccanismo per gestire il layout molto semplice e che può
essere "disegnato". Le stesse caratteristiche le offrono i gui
designer usati con altre librerie, ad esempio QTDesignet, Glade, Boa
Constructor, wxGlade...
Se non sbaglio caratteristiche simili si possono ottenere con .net.


 Se non sbaglio caratteristiche simili si possono ottenere con .net.
Visual Studio .NET e' una vile scopiazzatura di Delphi ;)


OnCanResize e OnResize.
Questo alla fine vale anche per le API di win dove viene mandato il
messaggi WM_SIZE. Ma poi ne OnResize cosa succede? Devi gestire
l'evento oppure puoi impostare in fase di creazione della finestra un
layout e poi c'è un algoritmo che si occupa di gestirlo?


 layout e poi c'è un algoritmo che si occupa di gestirlo?
Puoi impostare un layout con tanto di constraints e allineamenti tra i
controlli, in modo che, a run-time, quando l'utente ingrandisce o
rimpicciolisce le dimensioni della finestra, i controlli si adattino in modo
automatico.


automatico.
Ecco, proprio quello che puoi fare con con wxWindows, QT e altre
10.000 librerie ma che VC++ fino alla versione 6 non gestisce.


 automatico.
Noi lo si fa con 3 funzioncine, da programma.
-- 
Luc.

 Noi lo si fa con 3 funzioncine, da programma.
Non capisco che vuoi dire.
Con Delphi lo si fa a disegno, non da programma.


 Spostando manualmente i controlli?
MFC lo fa, normalmente, ed esiste un framework per fare lo stesso con 
la WTL, mi pare scritto da Pietrek
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 essere "disegnato".
Visual J++ aveva un meccanismo di layout automatico identico a quello 
di Delphi, immagino che sia stato integrato nelle versioni più recenti 
di MFC


 Con Delphi lo si fa a disegno, non da programma.
Con VC++ lo si fa da programma, non da disegno.
;)
-- 
Luc.

 Con VC++ lo si fa da programma, non da disegno.
Appunto, quindi si torna la punto di partenza: VC++ per l'implementazione
dell'interfaccia grafica, lascia molto a desiderare...


 dell'interfaccia grafica, lascia molto a desiderare...
Esageri, al solito.
-- 
Luc.

 Esageri, al solito.
Vediamo di chiudere questo battibecco a frasi smozzicate.
Io gradirei che tu ribattessi quando hai argomenti per farlo.
Non devi difendere a tutti i costi il tuo ambiente di sviluppo, limitati a
confrontarlo.
Io conosco il modo di gestire l'interfaccia grafica di Delphi e quindi posso
confrontarlo con il modo di gestire l'interfaccia grafica di VC++ e, a
ragione (NON sto esagerando) posso dire che, rispetto a Delphi, VC++ lascia
molto a desiderare.
Con questo, nessuno dice che VC++ fa cagare.
"Al solito", mi sembra che tu sia restio ad accettare la realta' dei fatti.



wrote:

Come utilizzatore del Borland C++ 5.02, del Visual C++ e del Visual
Basic dico questo:
- chi usa prodotti non RAD (es. i primi 2 che ho citato) deve
necessariamente via codice smazzarsi (quasi) tutti gli attributi dei
controlli (tranne la posizione e qualche valore che va a finire nel
campo DWORD dwStyle della CreateWindow), tramite il processo dei
messaggi WM_*
- chi usa prodotti RAD ha la comodita' di poter gestire in design time
(quasi) tutti gli attributi dei controlli (font, colori etc.) grazie
al framework che ci sta sotto
Dal mio punto di vista non dico che i secondi sono migliori dei primi,
e' come comparare un Land Rover con una Espace, sono prodotti
destinati ad uso diverso e rispondono ad esigenze diverse.
Il fatto che poi il RAD sia piu' comodo nel disegno delle interfacce
e' innegabile, ma il vantaggio lo paghi nel doverti appoggiare ad un
framework.
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email 
happyman...@libero.it
 [Togliere nospam per scrivermi]
Salsa Web 
http://web.tiscali.it/happyman
 [Foto salseri/e & I.A.B.L.A. Ring]

 framework.
Lo paghi in che senso ? appoggiarsi a un framework non e' una cosa negativa,
anzi.
La VCL, poi, e' una buona gerarchia di classi.
Delphi (che non e' VB), tra l'altro, non ti vieta di smazzarti a mano i
messaggi.


messaggi.
Il mio era un discorso generico: se il framework e' fatto bene non hai
difetti o problemi di overhead, ma pensa a Visual Basic (anche se non
e' corretto parlare in questo caso di framework) o al nuovo .NET (che
da solo quando parte un .exe occupa almeno 10 MB, ho provato con il
classico "Hello World").


 provato con il classico "Hello World").
toglimi una curiosità, chè al momento di .NET non so un'acca. Se provi 
a far girare il programma due volte, di quanto sale la memoria occupata 
in totale dal sistema?


 Vediamo di chiudere questo battibecco a frasi smozzicate.
Purtroppo non posso facilmente mostrarti pubblicamente che HO RAGIONE a 
dire che con VC++ non è affatto complicato gestire i resizing dialog, 
specialmente se hai perso un po di tempo una sola volta a farti una 
bella:
class CElasticDialog: public CDialog
{
....
}
Certo, in delphi sarà già tutto fatto, ma il C++ non ha lo stesso target 
di delphi....
E chiudo anche io la polemica.
-- 
Luc.

Stefano "HappyMan" (Lago Maggiore - NO)
Debug o Release?
Ciao 
-- 
^^^ From 1991 2:332/407.490 ^^^ 
Air conditioned environment - Do not open Windows. 
New live is possible: 
http://makeashorterlink.com/?O28941C91

 di delphi....
Ti sbagli. Un ulteriore conferma che NON conosci Delphi.
Il "target" e' esattamente lo stesso.


in totale dal sistema?
Dalle brevi prove che ho fatto ho rilevato che i 10 MB sono
l'allocazione della CLR quando parte e sono liberati quando il
programma termina. Non ho provato a far girare due o piu' programmi
diversi contemporaneamente  (o anche lo stesso) basati su .NET, ne' ho
verificato di quanto sale l'occupazione sulla base della quantita' e
sul tipo di controlli in un form, ti sapro' dire.
Cio' che piu' mi lascia perplesso (anche se per altri puo' essere un
dettaglio) e' la lentezza dell'apertura dei form con un po' di
controlli la prima volta: ho creato un form sul quale ho messo una
datagrid, la prima volta che si visualizza (ho un P3 a 866 Mhz) si
vede _distintamente_ la comparsa dei controlli, la seconda volta e'
immediato (la seconda volta la CLR lo trova gia' compilato).


 Un ulteriore conferma che NON conosci Delphi.
Confermi l'ovvio. ;)
-- 
Luc.

in totale dal sistema?
Sinceramente non sale
--
Rhymes (rhy...@NOSPAMmyself.com)
http://www26.brinkster.com/rhymes
" ride or die "

Debug o Release?
Ho fatto questa prova:
Creato con 
VB.NET
 un exe che apre un form _vuoto_, senza alcuna
istruzione
Ho Windows XP Pro
Guardando il Task Manager ottengo:
Form vuoto - release
Utilizzo memoria 5604 kb
Dimensione memoria virtuale 4772 kb
Form vuoto - debug
Utilizzo memoria 7136 kb
Dimensione memoria virtuale 5600 kb
In entrambi i casi se lo stesso exe è lanciato 2 o più volte ogni
instanza occupa la stessa quantita' di memoria, kb più o meno.
In pratica vedo il counter verde del Task Manager che ad ogni
esecuzione cresce di un 6 kb.
Un eseguibile win32 puro, che apre una finestra senza fare altro
occupa:
Utilizzo memoria 808 kb
Dimensione memoria virtuale 276 kb
Stefano "HappyMan" (Lago Maggiore - NO)


Sinceramente non sale
Nel senso che quando termina dealloca la memoria, per riallocarla
nella stessa quantita' la volta dopo, ho fatto una prova in merito
proprio ora (leggi l'altro post nel quale ho dimenticato di scrivere
questo, la memoria viene deallocata)



Si, con tutta la liberta' che vuoi:
- librerie di accesso ai dati di vario tipo, da quelle native a
Microsoft ADO, ODBC, ...
- componenti visuali RAD (Rapid Application Development) per la
visualizzazione/modifica/navigazione dei dati.
etc...
C++Builder, ovviamente, ha gli stessi vantaggi.
--
Roal Zanazzi

 la personal, provalo.
Per cortesia, usare queste librerie da Delphi è cosa ottima (e, per
quanto non mi piaccia Delphi, è sicuramente meglio che utilizzare il
VB), ma utilizzarle in C++ vuole dire *uccidere* il linguaggio
stesso.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.