Metodo GetNextImageDocument dell'interfaccia IImageSource
Questo metodo è implementato in FRE per Linux e Windows.
Questo metodo è implementato sul lato client. Restituisce il documento immagine successivo dalla coda di elaborazione delle immagini dell’origine.
In Windows, questo metodo deve essere usato solo se si aprono immagini già caricate in memoria, ad esempio con i metodi OpenBitmap o OpenDib dell’oggetto Engine. Se invece si acquisiscono immagini da file su disco, implementare GetNextImageFile.
Un’implementazione del metodo GetNextImageDocument può prevedere un tempo di attesa per il documento immagine successivo. Tuttavia, si sconsiglia di implementare tempi di attesa lunghi, poiché FineReader Engine non è multithread. Durante l’attesa del documento successivo, l’Engine non sarà in grado di elaborare i messaggi dei processi di riconoscimento né di ricevere notifiche sul completamento dell’elaborazione della pagina. Se è necessario specificare un tempo di attesa lungo, il metodo GetNextImageDocument può restituire 0. In questo caso, l’Engine continuerà a elaborare i messaggi dei processi di riconoscimento e a fornire le immagini riconosciute e, dopo un certo tempo, verificherà se la coda di immagini è vuota. Se la coda non è vuota (ossia, se IImageSource::IsEmpty restituisce FALSE), l’Engine chiamerà di nuovo il metodo GetNextImageDocument. Tuttavia, se il metodo GetNextImageDocument restituisce 0 e non ci sono altre pagine da elaborare, FineReader Engine restituirà il controllo all’utente: il metodo IBatchProcessor::GetNextProcessedPage restituirà 0.
Tutti gli oggetti ImageDocument nella coda devono rimanere validi fino al termine dell’elaborazione. Per garantire il corretto funzionamento, gli oggetti ImageDocument devono essere creati tramite l’oggetto Engine. Se vengono creati tramite l’oggetto FRDocument, può verificarsi un errore perché l’oggetto FRDocument viene distrutto durante la chiamata al metodo GetNextImageDocument.
Poiché il metodo è implementato sul lato client, si applicano le seguenti restrizioni:
tutti i file protetti da password devono essere aperti manualmente sul lato client;
gli attributi specificati nell’oggetto PrepareImageMode durante l’inizializzazione dell’oggetto BatchProcessor non avranno effetto sugli oggetti ImageDocument nella coda.
L’implementazione client di questo metodo deve garantire che tutte le eccezioni generate all’interno del metodo vengano intercettate e gestite e che nessuna eccezione si propaghi all’esterno del metodo. La propagazione di un’eccezione all’esterno del metodo può causare risultati imprevedibili (ad esempio, la terminazione del programma).
// Implementazione di esempio di una sorgente di immagini personalizzata che mantiene una coda di file di immaginepublic class ImageSourceCallback : FREngine.IImageSource{ public ImageSourceCallback( string imageFilesDirectory ) { imageFiles = ImageSourceHelper.LoadFilesNames( imageFilesDirectory ); nextFileIndex = 0; } public bool IsEmpty() { return nextFileIndex >= imageFiles.Length; } public FREngine.IFileAdapter GetNextImageFile() { if( !IsEmpty() ) { return new FileAdapterCallback( imageFiles[nextFileIndex++] ); } return null; } public FREngine.IImageDocument GetNextImageDocument() { ... } private string[] imageFiles; private int nextFileIndex;}public class FileAdapterCallback : FREngine.IFileAdapter{ ...}public class ImageSourceHelper{ ...}