Newsgroup: it.comp.appl.access
Titolo: Immagini

Io seguo access dalla versione 1 e ora sono alla 2002. Trovo praticamente
incredibile la sua incapacita' a gestire correttamente le immagini cui si
puo' ricorrere con vari artifizi ma che sicuramente sono sempre rimedi
raffazzonati. Ho provato a dare una sbirciata a file maker dove un mio amico
in 10 minuti ha messo in piedi un archivio fotografico della scarpe della
sua ditta (anche l'allestimento del lavoro in rete con tutti gli accessi mi
e' sembrato infinitamente piu' semplice di access)
 Naturalmente si puo' ricorrere ai collegamenti, ma mi chiedo come sia
possibile che i programmatori access a fronte di modifiche che onestamente
nessuno di noi magari usera' mai, non risolvano questo problema. Ho dato
un'occhiata anche al sito di gary prague che tratta di molti add on di
Access per vedere se qualcuno avesse scritto qualcosa ma non c'e' niente di
niente. Io ho la necessità di gestire immagini (anche migliaia) e mi sembra
questa un'esigenza molto sentita: sono io che non guardo nei prodotti giusti
oppure semplicemente utilizzo il prodotto sbagliato e devo navigare verso
altri lidi come File Maker?
Ciao Angelo

 ha scritto nel messaggio
news:FMEi8.15004$tC3.4...@twister1.libero.it...

hy Angelo,
non spezzerò nemmeno la punta di uno spillo per difendere ACCESS. Anche io
ho la neccessità di gestire una grande quantità di immagini. Mi appassionano
le schede telefoniche  e la cinematografia. Quindi ho deciso di avere a
portata di mano 23000 foto di schede e 8000 facce (piccoline!) di
altrettanti attori o registi.
Neanche provarci a metterle in un database MDB, collasserebbe molto presto,
diventando grasso (e a ragione).
Gestirle come oggetti esterni è gravoso, ma alla fine si può fare. Devo dire
che il compromesso è stridente solo quando devo fare un elenco di records e
delle relative immagini, poichè non posso mettere in maschere continue e
caricare con LOADPICTURE poichè ottengo tutte immagini uguali!(l'ultima
caricata).
Ho risolto il problema passando dai REPORTS, c he sull'evento FORMAT
permettono di caricare una immagine diversa dall'altra e quindi mi danno
risultati accettabili.
Non sò se sarebbe facile gestire il tutto in multiutenza o in rete, comunque
se ti interessa qualcosa di più specifico ti invio qualche straccio di
codice, che tu puoi modificare a tuo uso.
Ora ti faccio una domanda io :
ma il tuo amico con File MAKER ha gli archivi GROSSI!!
(le immagini riempiono, o lui le gestisce come oggetti collegati?)
ciao
van

 e' sembrato infinitamente piu' semplice di access)
Non conosco File Maker, quindi prima di esprimermi ti chiedo cosa ha fatto
il tuo amico per fare questo archivio di immagini.
Ad ogni modo, non vedo cosa ci sia di difficile nel prevedere una
sottocartella che contenga le immagini (jpg, tif o come vuoi) da cui
caricarle quando visualizzi un prodotto, dato che l'istruzione da dare e'
solo una:
Me.CotrolloImmagine.Picture="Percorso"
Sib

 oppure semplicemente utilizzo il prodotto sbagliato
Per visualizzare immagini??
Mah...
 >e devo navigare verso altri lidi come File Maker?
Proprio vero che "ogni cò lè na crapa"
Ciao.

 (le immagini riempiono, o lui le gestisce come oggetti collegati?)
Scusa ma hai mai visto FM?
E' una cacatina che si pilota con script interpretati lenti come la fame, è
relazionale com il database di Works, non lo puoi usare come FE verso nessun
motore Server ... tranne il suo che quando i dati sono tanti non si muove
nemmeno ad accendegli un fuoco sotto il sedere!
E' ottimo proprio per fare cosette piccole che non richiedano sforzi di
programmazione, ma da qui a paragonarlo anche solo ad Access 2.0, ci passa
tutta l'impopolarità di zio Billy.
Informatevi ragazzi, studiate, documentatevi.
Ciao.

 altrettanti attori o registi.
CUT
Io al tuo posto avrei fatto una cosa diversa, se hai necessita' di vedere le
immagini in maschere continue, evidentemente le immagini in questione sono
piuttosto piccole. A questo punto potevi benissimo realizzare delle immagini
piccoline (non zoommate, proprio piccole) da memorizzare nel db, in questo
modo non ti avrebbero occupato chissa' quanto (8000 immagini 100x100 pixel
che già sono piuttosto grandi per visualizzarle in maschere continue ti
occupano 260Mb, se poi le fai 60x60 ti occupano circa 80Mb il che rende le
dimensioni del db perfettamente accettabili. Se poi le devi vedere piu'
grandi, te le carichi al momento.
Sib

 Proprio vero che "ogni cò lè na crapa"
Per uno che e' siculo e non conosce dialetti nordici lo traduci?
Sib

 Per uno che e' siculo e non conosce dialetti nordici lo traduci?
Impossibile tradurre alla lettera ;-)
Piů o meno: siamo troppo egocentrici, ognuno la vede a modo suo...
Ciao.

risultati accettabili.
Ma che te ne fai di una lista d'immagini in una Form Continua?
Come ti dice Sib, o sono in formato mignon o sarebbe comunque inutile...
Ciao.

altri lidi come File Maker?
Almeno, almeno voglio sentirti dire Delphi, Omnis Studio o qualcos'altro di serio.
FileMaker, immagini o no, è davvero scarsino  ;-)


Penso di avere capito comunque il senso :-)
Ciao
Sib

 ha scritto nel messaggio
news:a6fq0e$7j2$1...@fe2.cs.interbusiness.it...

... immaginazione !
un FILM è interpretato da + di UNA FACCINA! ergo necessito di maschera
continua! :---))
un foglio raccoglitore (trasparente) necessita di una mappa da posporre con
una selezione ben precisa di skede, prova a farmele vedere in anteprima che
non sia da report. Vuoi mettere averle a portata d'occhio senza per forza
aprire un'anteprima? (una mascherina [continua!] collegata)
... e poi dopo quattro anni di tentativi, spinte e cambiamenti, ho deciso di
non gestirle all'interno, ma ecco che c'è chi mi consiglia di fare le
FACCINE piccole piccole! asserendo che 80MB sono una dimensione accettabile!
;-|
la realtà, forse, è che ACCESS non è un buon gestore di documenti grafici se
devono essere visti a gruppi.
io però uso la 2000 e non so che novità dopo la mia.
anche per l'ignoranza su FILE MAKER avrei da polemizzare! :-((
ma quanto tempo ci vuole ( e quanti amici o quanti soldi ) per conoscere gli
altri programmi?
io FILEMAKER l'ho scartato quattro anni fa ( ma era una release veramente
vecchia e ferraginosa) e poi non ho più avuto modo, ne voglia, di
documentarmi.
parliamo di ACCESS, per quel che ne conosciamo!  è meglio ! :-)))
van
PS  diamo un consiglio spassionato a Michele, così può finire questo tread

 PS  diamo un consiglio spassionato a Michele, così può finire questo tread
Il mio suggerimento l'ho dato, per il resto ognuno fa le sue scelte.
Sib



era ogni collo ha la sua testa?
Saluti.
Emanuele.

 ha scritto nel messaggio

Come assonanza ci siamo.
Sib

On Sun, 10 Mar 2002 16:15:16 +0100, "Sib" <si...@SPAMiol.it> wrote:

era ogni collo ha la sua testa?
Saluti.
Emanuele.

PS  diamo un consiglio spassionato a Michele, così può finire questo tread
Chi è Michele?
Non si chiama Angelo?
Il consiglio l'ha già avuto: scarica gli esempi che trovi sul Sito Comune.
Ciao: warp

Per Oscar Manfredini (abbiamo lo stesso cognome!!).
Come segnalo sotto il mio amico gestisce 30 terminali con Win 2000,
Microsoft SQL Server e come front end proprio File Maker cui si era
avvicinato nel 95 quando usava MAC e Hypercard. Ovviamente usa la versione
server e non mi ha proprio dato l'impressione di lentezza
pero' non posso certo fare confronti.
Ciao Angelo

 alcun problema e noi con access dobbiamo ricorrere sempre a trucchetti.
Non capisco cosa tu intenda per "gestire nativamente": forse inglobare?
Possiamo proseguire col Thread fino all'anno prossimo, ma la realtà non
cambia: è tatticamente sbagliato inglobare fisicamente in un DB un archivio
d'immagini, qualunque database tu utilizzi, File-sharing o Client-Server.

 pero' non posso certo fare confronti.
Ho espresso giudizi perchè abbiamo collaboratori esterni che
lavorano in FM: francamente sono assai stupito della possibilità
di connetterlo (anche con la versione Server) a un altro DBMS, in settimana
vado a fondo.
Ma il discorso alla base è diverso: FM non contiene alcun linguaggio di
programmazione Host, bensì un sistema di *macro* (script) interpretati
davvero
farragginoso la cui flessibilità non può essere paragonata a quella di un
qualunque Visual Basic.
Fin che si creano semplici applicazioni aziendali FM può sembrare l'uovo di
colombo, ma quando si fanno i conti con vere procedure si deve essere pazzi
per investire tempo e risorse in quella direzione.
I FE diventano arzigogolati, difficili da leggere per chi non li abbia
creati, non contengono una gestione degli errori accettabile, non
raggiungono i necessari livelli di flessibilità.
C'è chi sviluppa gestioni con Access utilizzando esclusivamente Macro
(sebbene meno potenti degli Scritp di FM) e autocomposizioni: visti di
sfuggita sembrano buoni lavori, poi bisogna provarli però...
Ciao, Oscar.