Newsgroup: it.comp.appl.access
Titolo: controllo immagini su REPORT - ormai il danno è fatto

Ho sviluppato una piccola applicazione in ACCESS 2007 per mettere in coda delle etichette con sfondo GRAFICO personalizzato in base alla famiglia di prodotti. In ogni pagina A4, crea 4 etichette con sfondo una bmp 300dpi da 20cmx10cm - circa 8mb ciascuna.
in totale dovrei stampare ogni volta 100/200 etichette. Il tutto è stato condito da controllo errori, statistiche, calcoli costi, ecc..... ma......
 
Purtroppo non mi sono ricordato che tanti tanti anni fa c'era il famoso bug delle immagini sui REPORT!!!!.... ormai il danno è fatto...
 
utilizzando infatti sul corpo del report, la routine su formattazione (Me.NonAssociatoOLE4.Picture = Me.Percorso_file), ottengo un report dove dopo le prime 50 etichette circa, lo sfondo comincia ad essere assente in modalità random...
 
Ricordo che in passato avevo utilizzato un ocx di costarella come workaround, ma poi ci sono stati problemi per farlo funzionare su sistemi a 64bit...
 
Ho provato a convertire l'applicazione in ACCESS 2019 ma il risultato è il medesimo! Possibile che dopo 20 anni non ci siano stati sviluppi?
Qualcuno riesce a darmi un ragguaglio?

Non si usa un NonAssociatoOLE ma un Controllo Immagine, non è la stessa cosa, e peraltro ora è diventato DataBound quindi puoi associarlo.
 
@Alex

Ho provato a sostituirlo con un Controllo immagine, purtroppo non è cambiato nulla. Ho riprovato anche su una versione parallela di access2019.
 
dopo qualche pagina, il report in anteprima restituisce questo errore:
Errore di run-time 2114 - Il formato del file "c:\etichette\1.bmp" non è supportato oppure il file è troppo grande. Provare a convertire il file in formato BMP.

 
 
siamo allo stesso livello del famoso "Keyboard not found. Press any key to 
continue" :/
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........


Quanto è grande l'immagine...?
Se troppo grande servirebbe passare per GDI+ in quanto i filtri, superata una certa dimensione possono disturbare.
 
@Alex

In formato BMP sono 8mb

 In formato BMP sono 8mb
 
Hai provato a ridurre la risoluzione...?
Almeno come test...
 
@Alex


sta cosa del file troppo grande mi pare che venisse risolta con il 
codice di lebans
 
vedi qui
https://www.lebans.com/imageclass.htm
 
 
BFS
 


GDI+ appunto... ma usare quel codice, purtroppo tutto il codice di Lebans, oggi rischia di essere un problema non essendo scritto in modo da essere compatibile VBA7 e/o Win64
 
@Alex

Allora, ho effettuato un bel test che può essere utile a tutti:
1.bmp (8mb) presente 4 volte in 1 foglio, viene replicata per circa 15 pagine, poi va in palla.
1.bmp ridotta a metà risoluzione (2mb), viene replicata per circa 100 pagine, poi va in palla.
1.bmp aumentata al doppio della risoluzione (32mb), viene replicata per circa 2 pagine, poi va in palla.
ho Provato ad effettuare lo stesso test convertendo le bmp in jpg e tif. IL RISULTATO E' IL MEDESIMO.
 
Buttare via questo lavoro per un bug ultraventennale mi sembra vergognoso...
Capisco che se utilizzo immagini di dimensioni minori funziona ma access non si usa solo per didattica...


vedi qui
 
https://access.bukrek.net/
 
 
potresti valutare questo ocx per immagini che tra l'altro offre funzioni 
fantastiche tipo drag and drop immagini direttamente nel controllo, 
acquisizione da fotocamere e da scanner
vari tipi di zoom e crop
io lo uso su tablet windows per scattare le foto dalla camera integrata
e lo trovo fenomenale
 
 
ciao
BFS
 
 
 

Salve,
 
Emiliano Baldoni:

Qualche domanda per forse chiederlo al team di Access:
 
1. Con quale versione di Access hai fatto i test? 2007 o 2019?
2. 32 o 64 bit Office/Access?
4. mdb o accdb?
5. Viene solo il messaggio di errore e l'applicazione continua o Access 
si pianta?
6. Stesso risultato con usare l'origine controllo del controllo imagine 
invece di assegnarlo con codice?
7. Stesso risultato con vis. report invece di anteprima?
 
-- 
Ciao
Karl
*********
http://AccessDevCon.com
 
Access FAQ: 
https://www.donkarl.com/it
 

 7. Stesso risultato con vis. report invece di anteprima? 
Risultato non identico ma molto similare
 

 non saprei come fare (ho bisogno che ogni record abbia una sua immagine)
 
1. Disabiliti il codice che assegna l'immagine alla proprietà Picture.
2. Nella proprietà origine controllo del controllo immagine usi:
 
=Percorso_file
 
Se si tratta di un problema di memoria, questo non aiuterà, ma prima di 
tutto, da Access 2007 dovresti lavorare solo in quel modo e in secondo 
luogo, non si sa mai. ;-)


Era un metodo semplice che non avevo mai utilizzato, quello di utilizzare la proprietà origine del controllo....
Comunque ho eseguito anche questa prova ed il risultato è... IDENTICO.
Tramite la vmmap che hai suggerito, ho verificato che durante l'elaborazione del report, viene occupato circa 1GB di memoria (heap).
 
Comunque la buona notizia è che il controllo OCX suggerito da BFS, che ringrazio, sembrerebbe funzionare... necessari ulteriori test anche per vedere se ci siano difetti di qualità e/o deformazioni.

errata corrige. con OCX stesso problema.

 ...Tramite la vmmap che hai suggerito, ho verificato che durante l'elaborazione del report, viene occupato circa 1GB di memoria (heap).
 
Qui mostro cosa devi come procedere con Access ed il tool:
https://youtu.be/JTTsyNzY_i8?t=1592
 



Troppo complicato mettere online il file?
Fra i tanti che farebbero prove sul "vivo" la soluzuine dovrebbe
trovarsi.
L'errore che si produce è inimmaginabile!
 
Bruno

L'errore è semplicissimo da riprodurre, è sufficiente creare 100/200 record, creare un report dove su formattazione fai caricare la stessa immagine tramite vba su un controllo. Noterai che verso la fine qualche immagine non viene visualizzata in maniera random..

Intanto voglio ringraziare Karl, per la sua preziosissima informazione!
 
Posso confermare che con Large Address Aware il problema viene incredibilmente risolto!!
Essendo un'applicazione distribuibile ad altri utenti , dovrà funzionare in runtime e ci sarà lo scotto di riconfigurare LAA ad ogni installazione.
COMUNQUE è una SOLUZIONE.
 
Per completezza di informazioni e dovere di cronaca posso dirvi che ho trovato una soluzione alternativa senza scomodare LAA.
E' una cosa che non avevo mai sperimentato e mai voluto sperimentare...  funziona in maniera lievemente differente, quindi non andrà bene in tutte le situazioni...  Forse è meglio i deboli di cuore si fermino a leggere qui...
 
Sulla tabella, impostando il campo immagine come tipo dati "Allegato"(quindi incorporata nel record) incredibilmente l'anteprima del report carica e replica correttamente tutte le immagini!!!........


ma se invece di stampare un report di 200 pagine, ne generassi 4 di 50 pagine l'uno?
potrebbe essere fatto anche con un ciclo senza che l'utente debba fare niente
lo so che è uno stratagemma poco elegante, però a mali estremi...

 Sulla tabella, impostando il campo immagine come tipo dati "Allegato"(quindi incorporata nel record) incredibilmente l'anteprima del report carica e replica correttamente tutte le immagini!!!........
 
Quando diventa il DB in questo modo...?
 
@Alex

Ciao Alex,
anche qui sono rimasto sconcertato:
- db backend senza immagini allegate: 416kb
- db backend con 10 immagini allegate (1 immagine per record (10 record)): 1.148kb
ogni immagine è in formato bmp, (RGB ma i colori sono 2) 2362x1299pixels 24bit e pesa 8.780kb
ho verificato che i files non sono collegati (ho anche cancellato gli originali dal fileserver), non chiedetemi come sia possibile, probabilmente i programmatori di access avevano fatto un buon lavoro!!

 
 
Sì, l'allegato è un tipo di dati abbastanza efficiente. Se è 
utilizzabile per il tuo caso d'uso (le immagini non cambiano ecc.) e la 
dimensione del file non diventa problematica, dovrebbe essere una 
soluzione praticabile.


Emiliano Baldoni submitted this idea :

Aspetta che qualcuno lo faccia.
 
Bruno