Newsgroup: it.comp.lang.c++
Titolo: Conversione di formato (jpeg->bmp)

Salve a tutto il NG,
devo realizzare in Builder C++ una conversione di formato da jpeg a
bitmap, come posso fare? esistono delle librerire o dll gratuite che
possono fare al mio scopo?
grazie!
	Roberto .oO Sig8 Oo.

possono fare al mio scopo?
Ci sono degli oggetti e dei metodi built-in nel builder ( :-) ), basta che salvi
la jpeg nella clipboard, e poi la ricarichi sempre dalla clipboard in formato
bmp.
L'ho fatto una volta in Delphi, ma quando ho riprovato a farlo in CBuilder non
ci sono riuscito (cmq ci deve essere il modo, xchè la VCL è sempre la stessa).
Bye,
            Daniele
--- Per rispondere in e-mail, togliere "cutme" dall'indirizzo.

 Ci sono degli oggetti e dei metodi built-in nel builder ( :-) ),
Non so se avete notato che una volta, quando si cercava del codice che
risolvesse un particolare problema, questo quasi sempre era in formato
sorgente, magari non del linguaggio desiderato ma comunque sufficiente
per capire come funzionavano le cose e quindi per utilizzarlo. Ora,
invece, la programmazione per componenti preconfezionati rende la
diffusione del codice molto più difficoltosa. Alla faccia delle nuove
"comode" tecnologie!...
EMG

 "comode" tecnologie!...
Occhio che la direzione e' giusta!
Si preferisce e si "dovrebbero" usare i componenti proprio per nascondere il
codice...
Un progettista harware, quando decide che gli occorre un chip di memoria non
lo riprogetta ogni volta, lo acquista e lo assembla senza reinventare
l'acqua calda,
l'idea e' quella, acquistare i componenti che dovrebbero essere affidabili
ed utilizzarli senza doversi concentrare sulla loro complessita...
Pensa a Word, e' un grosso componente che devi acquistare (e costa caro...),
pero' se lo hai e vuoi fare un programma Visual Basic che ti permetta di
correggere l'ortografia di una casella memo, fai in un attimo: agganci Word
e lo fai fare a lui... t'immagini dover riprogettare Word? Se pensi ad un
esempio con Excel l'utilita' del riutilizzo e' ancora piu' evidente...
A questo punto si possono fare tante cose nell'ambito della programmazione:
puoi decidere di sviluppare componenti da rivendere e concentrarti solo su
di loro...
puoi FINALMENTE sviluppare applicazioni concentrandoti solo sulla reale
complessita' del problema senza dover gestire la stampa, l'apertura e la
visualizzazione dei file, la conversione delle immagini e cosi' via...
Ho reso l'idea?
Fammi sapere cosa ne pensi, cordialmente Davide.
/ - / - | - \ - \
Davide Piras
New (
pir...@engineer.com
)
Old (
pir...@iname.com
)
\ - \ - | - / - /

esempio con Excel l'utilita' del riutilizzo e' ancora piu' evidente...
hmmm.. non sapevo che potevi distribuire Word assieme al programma VBasic...
Marco

 Fammi sapere cosa ne pensi
Penso che la cosa funzionerebbe se ci fosse un unico sistema operativo
ed un unico linguaggio. La programmazione per componenti non puň
funzionare nel mondo reale dell'informatica composto di tanti sistemi
operativi diversi e di tanti linguaggi altrettanto diversi. Il
progettista hardware ha alcuni grossi vantaggi:
1. Puň scegliere tra un campionario di componenti molto piů vasto.
2. I componenti hardware costano (com'č giusto che sia) molto poco.
Quelli software hanno invece, in generale, un costo semplicemente
spropositato.
3. I componenti hardware non impongono vincoli oltre a quelli inerenti
il loro utilizzo specifico (input, output, alimentazione, segnali di
controllo, etc.). Quelli software, oltre a questo, impongono in generale
di essere utilizzati con un particolare sistema operativo e con un
particolare linguaggio.
EMG

 hmmm.. non sapevo che potevi distribuire Word assieme al programma VBasic...
Ottima osservazione. Aggiungete quindi:
4. I componenti hardware diventano parte integrante del prodotto
sviluppato. Quelli software invece comportano, in generale, diverse
difficoltà che li rendono meno comodi e comunque molto più costosi.
EMG

> hmmm.. non sapevo che potevi distribuire Word assieme al programma
VBasic...
infatti non si puo', forse non sono stato abbastanza chiaro.
Se la tua applicazione si appoggia a Word, l'utente deve avere Word per
eseguirla, non devi e non puoi mica dargielo tu!
Io comunque vedo la cosa in maniera ottimistica, tralasciamo per un attimo
la portabilita' tra i vari sistemi operativi, secondo te quanti pc con
windows 95/98/NT non hanno installato anche office? Se fai un'applicazione
seria l'utente potrebbe poi starci ad acquistarlo...
Io credo che nel prossimo futuro il software sara' talmente atomicizzato
("componentizzato "), che al lancio di un'applicazione se non si ha il
componente in locale, si potra' accedere ad internet per scaricarlo o,
meglio ancora, utilizzarlo (mai sentito parlare di CORBA e di DCOM?)... ed
ecco trovata la soluzione al problema della portabilita'...
P.S. che poi potrebbe succedere che sia Word, WordPerfect ed AmiPro mettano
a disposizione le stesse interfacce, a quel punto basta avere uno dei tre ed
il gioco e' fatto.


il gioco e' fatto.
Magari! Pensa che a volte nemmeno nella stessa casa si mettono d'accordo...
un programma che gira sul 95 puo' non girare sul 98 (e viceversa)...
Marco
PS: sulla mia macchina Office non c'e'. E nemmeno Word.

il gioco e' fatto.
Secondo me non è in nessun caso giusto limitare il funzionamento di un
applicativo alla presenza di un altro software commerciale nel sistema.
Ciao, Giuseppe
---------------------------------------------------------------------------
_Guybrush su IRCNet canale #programmazione
ICQ: 42227764
---------------------------------------------------------------------------

 applicativo alla presenza di un altro software commerciale nel sistema.
OK, allora non e' giusto che la fiat limiti il funzionamento delle sue auto
alla presenza dei pneumatici pirelli, deve farli lei!!!
Se non usiamo i componenti reinventiamo la ruota tutti i giorni...
Le considerazioni economiche/etiche/sociali sono un'altra cosa, a noi
informatici dovrebbe interessare risolvere i problemi in maniera brillante,
se per questo non utilizziamo software gia' collaudato ed affidabile la vedo
grigia...
Pensa a quando nei programmi usiamo le Common Dialog (File open/save
ecc...), potremmo anche fare ogni volta una nuova form da zero, ma ha senso?
Credo proprio di no.
Ciao Davide

Credo proprio di no.
Infatti quelle le fornisce il SO e sono sicuro che sulla  macchina del
cliente c'e'.
Marco

 applicativo alla presenza di un altro software commerciale nel sistema.
Infatti. Io, ad esempio, ho fatto un programma che richiede la presenza
di WinPhone per inviare i fax ma è una funzione completamente
accessoria. Anche senza WinPhone tutto il resto dell'applicazione (che è
la cosa importante) continua a funzionare tranquillamente. Se provi a
mandare un fax senza aver installato WinPhone semplicemente ti avvisa e
non esegue la funzione.
Sarebbe invece assurdo che il programma fosse pesantemente basato su
componenti che possono non essere disponibili. Praticamente potrebbe
risultare completamente inusabile se non a fronte di ulteriori spese
che, visti i prezzi, potrebbero essere parecchio onerose.
EMG

 alla presenza dei pneumatici pirelli, deve farli lei!!!
Come ho già detto per i componenti hardware, è diverso. I pneumatici
diventano parte integrante del prodotto automobile e non ho bisogno di
un ambiente particolare per utilizzarli.
EMG

particolare linguaggio.
Sono limiti superabili molto piu` facilmente di quanto si creda, anzi
mentre problemi quali il voltaggio non permettono di adattare una
componente hw senza reinventarla, in un software tutti questi vincoli
possono essere isolati e modificati all'occorenza senza dover
rifare tutto da 0.
Il punto e` cmq che l'affermazione di una tecnologia oggi non e`
dettata dalla sua fattibilita` ma dalle ragioni di mercato. Windows e
i processori intel (ma non solo) non sono certo lo stato dell'arte
anzi hanno diverse pecche, ma si sono imposte vuoi per posizioni
di dominanza, vuoi per ragioni di costo...
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

interfacce,
Infatti questo e` quello che intendo io per "ragioni di mercato"...
Gli standard almeno in parte ci sono, ma quanti li rispettano...
M$ no di certo!


 di dominanza, vuoi per ragioni di costo...
Infatti. Purtroppo lo so...
EMG

Credo proprio di no.
Non ha senso ciò che dici tu perchè le common dialog sono un componente di
base del win32, non c'è bisogno di farle comprare all'utente.


Solo se hai il sorgente.
Non credo che distribuire i componenti senza sorgente sia
molto proponibile, andrebbe a finire come Borland con OWL.


 molto proponibile, andrebbe a finire come Borland con OWL.
Uhm... se con i componenti viene sempre dato anche il sorgente allora
tutta la mia filippica non ha alcun senso. Io li pensavo come strutture
chiuse.
EMG

operativi diversi e di tanti linguaggi altrettanto diversi.
<Snip...>
CORBA e COM?
Scrivere un componente COM (o CORBA) risulta language - independent e platform -
independent.
Tecnicamente la soluzione esiste.
Ciao
AB
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrea Baruzzo
Via Circonvallazione, 26
Muzzana del Turgnano (UD) - Italy
e-mail: 
andrea....@ud.nettuno.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 giovane...
Beh, in effetti era stata auspicata già nel '79 da Terry Winograd: "Beyond
programming Languages" (ACM).
Poi la mania di OOpizzare tutto ha oscurato per un po' questi concetti,
anche se in effetti ha permesso di migliorali e adattarli un po' a tutti i
linguaggi.
A dir la verità i componenti di Winograd erano un po' un misto tra le
interfacce di Ada e gli oggetti di Smalltalk, ma pur non conoscendo bene
COM, Actvex, Corba et similia, non mi sembra che siano molto diversi.
--
Alessandro Monti

 Tecnicamente la soluzione esiste.
Secondo te se io domani mattina dicessi al mondo - "Da oggi dovete tutti
seguire questo nuovo standard da me appena creato" - qualcuno mi darebbe
retta? Ebbene, la Microsoft ha sicuramente più possibilità di me ma a
quanto pare neanche la sua potenza economica è sufficiente.
Questo per dire che non basta proporre una tecnica e sperare che lo
standard richiesto per il suo funzionamento venga adottato
universalmente. Bisogna che lo sia effettivamente prima di dire che una
tecnica funziona.
EMG

chiuse.
Non credo si possa prescindere da cio`, non sarebbe diverso da quanto
e` gia` successo in passato con OWL.


COM, Actvex, Corba et similia, non mi sembra che siano molto diversi.
Anche la OOP risale piu` o meno a quel periodo, anzi se non ricordo
male mi pare che qualcosa fosse stata teorizzata anche diversi anni
prima. La prima versione del C with classes risale proprio al '79.
Il punto e` che teoria e tecnologie commerciali viaggiano a velocita`
molto diverse e commercialmente parlando la programmazione
per componenti e` ancora giovane.


 e` gia` successo in passato con OWL.
Resta il fatto che se uno vuole sapere come funziona una certa cosa la
risposta "utilizza quel componente" non è di molto aiuto.
EMG

risposta "utilizza quel componente" non č di molto aiuto.
Il mio intervento non voleva affermare cio`, era solo la mia
opinione riguardo la validita` o meno della programmazione per
componenti. Volendo possiamo fare tutto senza bisogno di
librerie specializzate o componenti che siano, ma chiaramente
cio` allunga di molto i tempi di sviluppo.



Credo che sia una cosa importante questa dei problemi creati da una
programmazione "modulare". Credo che  il problema principale di win95 siano
state le dll più che la scarsa qualità della programmazione della Microsoft.
Oltre ai driver di dispositivo fatti da cani (la Creative alla pubblica gogna),
tutte le volte che mi si è piantato il SO è stato perché installando qualche
applicazione avevo sovrascritto una dll già utilizzata da altri programmi (o dal
SO, :-<) e i programmi precedenti non funzionavano più. La cosa che mi ha più
colpito della beta di Windows 2000 è stata la certificazione dei driver di
dispositivo. Tutti i produttori di driver per Windows 2000 devono richiedere la
certificazione alla Microsoft e questa dopo averli testati decide se
concederglielà. Se installi un driver non certificato il sistema operativo di dà
un bel warning terroristico dicendoti che il SO potrebbe avere dei problemi,
potrebbe scoppiare una guerra nucleare, un asteroide di proporzioni immense
potrebbe colpire la terra, zombi e cadaveri potrebbero uscire dalle loro tombe e
così via. Inoltre se si tenta di sovrascrivere una dll utilizzata dal SO (non
pensate che sia così pazzo da farlo di proposito, accade ad esempio installando
Office 2000) il sistema ti avverte e automaticamente SENZA POSSIBILITA' DI
SCELTA ripristina la dll originale. Se la Microsoft (leggevo recentemente che il
suo valore potrebbe entrare della classifica delle 10 nazioni più ricche del
mondo) ha deciso di porre dei limiti, tutta questa COMponentistica presenta
anche diversi problemi. Ciao FBF.

anche diversi problemi. Ciao FBF.
Sono d'accordo.
Pensa, nemmeno M$ si mette d'accordo con se stessa (il vecchio computer con
95 non si era mai piantato fino a quando non ho messo IE4. Il nuovo si
pianta regolarmente 3-4 volte al giorno, a volte anche mentre sono in
bagno). Figurati come possono fare gli altri produttori!
Ora, a parte i discorsi sulla qualita' del software e sulla disponibilita'
di informazioni (serie) da parte di M$, il problema che si verrebbe a creare
e' un altro. Se M$ decide che l'approvazione da parte della casa madre di un
determinato componente e' necessaria per eseguire quell'applicativo, questo
implica un enorme potere di censura da parte di M$ nei confronti dei
produttori piu' "scomodi".
Basta non approvare i componenti della casa X e la casa X fallisce. Oppure,
senza essere cosi' tragici, basta dare le informazioni giuste alla casa Y
piuttosto che alla X e il componente che passa e' quello di Y.
Da un lato la regolamentazione sarebbe cosa buona e giusta, dall'altro
evidentemente no.
E' ovvio che il tutto nasce dal fatto che si parla di software commerciale.
Secondo me occorrerebbe un po' piu' di trasparenza da parte di M$ nel
rilascio delle specifiche, ma se questa dice a tutti come fare per produrre
ottimo software per windows (nota: windows sara' anche fatto male, ma i
programmi al 90% si piantano non per colpa del SO ma perche' usano male le
risorse del SO) lei poi Office non lo vende piu'.
Marco

"comode" tecnologie!...
Sono pienamente d'accordo. Rimpiango i tempi in cui x fare qualcosa bastava
sapere come farlo (magari in pseudo-codice) e poi ci si poteva sbizzarrire in
qualsiasi linguaggio, o al massimo c'era la libreria da linkare, con il relativo
sorgente.
Bye,
            BackSlash