Leider zwickt das net die leading spaces ab, sodass der
unten folgende code-text zerfleddert aussieht.
loesung:
die ursache liegt in der funktion FindNextFile ()
diese bringt den status 0 (keine WEITEREN vohanden)
bereits DANN, wenn von der VORLETZTEN datei aus ausgefuehrt.
(das heisst, dass dabei schon auf die LETZTE zugegriffen wurde.)
dann steht der LETZTE datei-NAMEN zwar richtig im ergebnis,
aber EIGENTLICH sollte diese funktion ERST DANN den
status 0 liefern, wenn AUF dem LETZTEN eintrag durchgefuehrt wurde
(weil ja ERST DANN kein weiterer mehr vorhanden ist).
die ms-realisierung ist aber auch 'ne logic…
…fragt sich nur welche. 
ich danke fuer deine hilfe!
gruss - digi
der jetzt schon zum ZWEITEN MAL in 8 jahren auf diesen ‚trick‘
hereingefallen ist. (((
//##################################################################################################
BOOL CFiles::FindNextImageFile (DRVCHAR drive_letter, PTCHAR p_directory, PTCHAR p_file_name_in_out,
PTCHAR p_image_file_pattern)
{
#if OCR_AUTO_USED
BOOL result;
int fn_l = LENGTH_OF_CONTENT(p_file_name_in_out);
CString p_str_filename;
if (OK == TryToSetDriveAndDir (drive_letter, p_directory))
{ if (ff.FindFile (IMAGE_FILES_PATTERN_ANY_TEXT))
{ do
{ // dirtiest typical trick of m-saft:
// MEANS: the call on the SECOND LAST entry gives the LAST NAME,…
// „“""": …but also returns condition ‚0‘ (no MORE files) ! !
result = ff.FindNextFile ();
p_str_filename = ff.GetFileTitle (); // w/o extension
if ( ! result)
{ // this is the last filename in that directory
break;
}
} while (COMPARE_F (p_str_filename, (LPSTR)p_file_name_in_out, fn_l)
