18. august 2010 - 13:13 Der er 28 kommentarer og
1 løsning

LÆSNING FRA GRAFIK-MEMORY:

HEJ,

Jeg har på job adgang til programudskrifter, som udskriver en liste i følgende format:

< TEKST >  <TIDKODE1>  < TIDSKODE 2>

eksempel:

JØRGEN PETERSEN      14:15:10:14    14:16:22:24
FRATERNISERING        16:33:59:00    17:45:00:10

(tekstfelt er max 25 chars og tidkode1 og tidskode2 altid 11 chars med kolon'er).

Listen er variabel fra (mindst) 1 til (ofte) flere 10-tals (oftest 35 - 100).

Jeg skal bruge disse data til tekst- og tids-verifikation i forhold til en anden SQL-base. (Jeg har IKKE adgang til original SQL-data (den base som danner listerne)). 

Problemet er at programmet ikke skriver det i kopier-bart format (Windows CTL-A - CTL-C og CTL-V) til skærmen (er det direkte tilgang ?).

Er der nogen som kender en DELPHI-7 komponent (alternativt et gratis program), som kan læse GRAFIK-hukommelsen og omdanne dette bitmøster til læsbart tekst ?

(Jeg kunne gemme bitmønsteret (CTL + PRT-SCR, gemme i Paint, udskrive og SCANNE med OCR men da der er ca. 5000 lister LIGE NU ... (jeg vil gerne pensioneres når jeg bliver 70 --- )..)

KRistian
Avatar billede hrc Mester
18. august 2010 - 14:04 #1
Kan du ikke udskrive listerne til en fil, eks. en tekstfil?
18. august 2010 - 14:15 #2
HEJ

Svar til HRC,

Nej, desværre.

Listerne genereres fra en SQL-base på en server langt herfra (centralbasen) og sendes via intra-nettet til local-serveren som dirigerer data videre til min(e) PC('ere). Og ledelsen (centralt) har besluttet (sikkerhed) at externe servere IKKE har central adgang.. (det sker via XML-scripts)...

KR
18. august 2010 - 14:17 #3
PS:

Og XML_script'en er også restriktive ... (DAMN) ..

KR
Avatar billede martinlind Nybegynder
18. august 2010 - 15:31 #4
Kan du ikke lave en makro som kan gemme et skærmdump i en fil, eller kan du evt. lave dit dump i et delphi program og gemme det i en fil derfra :-)
18. august 2010 - 17:40 #5
hej

Tak for responsa,

DET ENESTE jeg kan med data er at jeg kan tage et screen-dump (CTL PRT-SCR), gemme 10 liste-elementer som et picture (JPEG/BMP/TIF)  i PAINT , udskrive til local-printer og siden scanne med OCR-option (og håbe at scanneren og OCR-programmet kan læse teksten korrekt.)

Derefter sreeen-dumpe de næste 10 liste elementer, gemme, scanne OCr - osv..

Derefter sreeen-dumpe de næste 10 liste elementer, gemme, scanne OCR - osv..

til alle liste elementer er taget. (10 gange ved 100 liste elementer).

Det jeg håbede var at jeg kunne springe hele PRT-SCR , gemme, printe, scanne OCR + + + + +    procedurerne over og hente tekten direkte via en Delphi-/ program - Komponent (eller et andet).

At jeg skal hente teksten 10 gange ( ved 100 listelementer) er uomtvisteligt. 



Eller jeg kan manuelt taste dem ind som ren tekst ... (og det gider jeg ikke .. !)

KR
Avatar billede preppydude Nybegynder
18. august 2010 - 20:04 #6
Kan ikke se hvordan et array of pixels skal kunne hjælpe dig mere end et screendump, som egentlig er det samme?
18. august 2010 - 21:03 #7
Hej,

Vi er ganske enige. En JPEG fil er jo egentlig et screendump med lidt kontrolinfo foran. Men det er heller ikke der mit problem reelt er, det er at finde ud af hvilken byte (pixel-start) hvorfra den aktuelle tekst begynder og siden fortolke/ oversætte dette bit-mønster til Delphi forståelig tekst (ISO / ASCII ). (også kendt som OCR... ).

Men jeg tror jeg har fundet noget kode (efter intens søgen på nettet - pyha ), som kan klare en del af problemet. Skal prøve det på job i morgen og må så arbejde videre derfra ... 

KR
Avatar billede martinlind Nybegynder
18. august 2010 - 22:25 #8
lyder da spændene, smid gerne et link :-)
Avatar billede preppydude Nybegynder
18. august 2010 - 23:48 #9
Er det sort på hvidt, så er det jo bare at loope igennem array'et og finde den første sorte pixel og den sidste - eller hvad?

Tror jeg har misforstået det her fuldstændigt. ^_^
19. august 2010 - 01:02 #10
Hej,

Jeg skal her lidt mere detaljeret prøve at forklare hvad dette her går ud på:


Jeg arbejder i Arkiv afdelingen i en større media-hus, hvor jeg arbejder med gamle video-tapes (BetaMax typen). Vi er i færd med at digitalisere disse analog-tapes og til det har vi CENTRALT en SQL-base, som vi almindelige dødelige ikke på nogen måde har adgang til. Skal vi arkivere de nye digitaliserede video-sekvenser (kaldet Clips) sker dette via lokalt genererede XML-filer, som sendes via intranettet til denne server. 

Denne Centrale SQL-base indeholder så en masse tabeller. Hver tabel har et variabelt antal records, hvor hver record repræsenterer hvert clip på den aktuelle tape. (Tittel, fotograf, start-tidskode, sluttidskode, opdagedato,  etc. etc. etc.)

Disse data sendes via intranettet til min PC (eller den i organisationen, som skal bruge disse data) via den lokale server.

På min PC er et program, som kommunikerer med samme SQL-base på ren præsentations-niveau. Det kører under Windows, men bruger IKKE windows skærm-driver (de har deres egen,) og det gør at  windows CLIPBOARD-funktionerne (CTL-A, CTL-C og CTL-V)  IKKE fungerer.

Grundet en BUG i samme software er der adskillige tabeller, hvor data ikke er konstistente og det er min (forbaskede (undskyld jeg bander !)) opgave at rette dette op. Men uden direkte SQL-adgang (fordi jeg arbejder på et lokal-kontor og ikke dirkete ved siden af serveren (spørg mig ikke hvorfor, sådan er det bare !)) .

Jeg kan få samtlige tabellers SQL-tittel  (som er det samme som CLIP-tittel), deres tidskoder (clip-start og clip-slut) and THATS 'it. Men kun som visning på skærmen (SOM IKKE TILLADER CTL-A- CTL-C ... ). 

Jeg skal bruge disse data til fysisk at finde det pgl. clip på den fysiske tape, derefter kan jeg så hente de andre data for dettet clip (se ovenfor), generere en ny XML-fil (indholdende de data, som ikke er tilgængelige pga bug'en) og så returnere / skrive XML-filen tilbage og dermed rette/ ophæve  bug'en.

Hvis der var tale om et par hundrede kunne jeg vælge at gøre det manuelt, men her taler vi om 1000'er (måske 10.000'er eller flere ?) Jeg gider ikke taste 10.000 (* 16 pr. tape), når det kan gøres intelligent, hurtigere og (sikrere) under program-kontrol. (jeg er programmør - ikke terminal-abe..)

(Det program, som genererer og overfører XML-filen er NATURLIGVIS (hva ellers  (he he)) skrevet i Delphi-7 og fungerer som en drøm).

KR

(håber det forklarer hvorfor jeg har brug for en VIDEO-OCR - GRAPPER ?
Avatar billede preppydude Nybegynder
19. august 2010 - 01:39 #11
Aha. ;)

Var jeg dig ville jeg - såfremt man faktisk havde mulighed for det - lave lidt reverse engineering mht. hvordan programmet kommunikere (packet sniffer, evt.) og så lave mit eget tilsvarende program der klarede opgaven ordenligt.

Kan du ikke det, så kan du vidst nok udnytte Microsoft Office's "Document Imaging" objekt i Delphi. Det gøres via ActiveX og burde være lige til. Et konkret eksempel - der er testet og virker - kan jeg ikke give dig nu (det bliver nok først i morgen), men indtil videre kan du jo se om det her virker:

// Husk at importere ActiveX objektet Microsoft Office Document Imaging og tilføje ComObj og MODI_TLB til uses
function OCRTest(const AFileName: String): String;
var
  Doc:    IDocument;
  Img:    IImage;
  Layout: ILayout;
begin
  Result := '';

  Doc := IDispatch(CreateOleObject("MODI.Document")) as IDocument;
  try
    Doc.Create(AFileName);
    Doc.OCR(miLANG_ENGLISH, True, True);

    Img    := IDispatch(Doc.Images[0]) as IImage;
    Layout := IDispatch(Img.Layout) as ILayout;
    Result := Layout.Text;
  except
    on E:Exception do
      Result := Format('Error: %s (%s)', [E.Message, E.ClassName]);
  end;
  Img    := nil;
  LayOut := nil;
  Doc.Close(False);
end;


Virker mit eksempel ikke, og vil du selv til at lege med det, så kan du læse lidt om dets interface her:
http://msdn.microsoft.com/en-us/library/aa270402(v=office.11).aspx

Det er godt nok i VB, som jeg intet kender til selv, men det burde være lige til at omskrive det til Object Pascal. :)
Avatar billede preppydude Nybegynder
19. august 2010 - 01:42 #12
Kan se at dansk også understøttes. Så brug miLANG_DANISH i stedet for miLANG_ENGLISH hvis du vil have det. :)
Avatar billede hrc Mester
19. august 2010 - 09:56 #13
Preppydude: Det kodeeksempel vil jeg straks kaste mig over. Jeg har masser af tekstskanninger i mine databaser. Det må kunne bruges hos en eller anden kunde (håber det virker)
Avatar billede preppydude Nybegynder
19. august 2010 - 10:04 #14
Ellers må vi jo bare få det til at virke. :)
Avatar billede preppydude Nybegynder
20. august 2010 - 09:26 #15
... fik du det til at virke?
20. august 2010 - 10:04 #16
Hej,

En gang i mellem er det godt at være programmør - andre gange ikke. I går var det. Løste en parallel haste-opgave uden om tids-kodeproblematikken, og så var chefen bare lykkelig...

Men det var på bekostning af samme tidskode-problem.

Jeg vil se på det i dag - her i formiddag hvis der ikke kommer andre forstyrrelser eller hasteopgaver.

KR
20. august 2010 - 16:07 #17
HEJ,

HAr nu prøvet koden ..

Compileren kommer ud med fejlmeddelelsen :

[Fatal Error] Unit1.pas(7): File not found: 'MODI_TLB.dcu'

så jeg søgte i import-type libray for at finde MODI-unit'en men uden det ønskede resultat.

Prøvede så Import Active-X control -- samme resultat.

Kan du give mig et hint om hvor jeg finder denne komponent ?

TAK.

KR
20. august 2010 - 17:18 #18
HEJ,

Gik ind på wikipedia for at lære lidt mer om mode...
Fandt følgende:

http://en.wikipedia.org/wiki/Microsoft_Office_Document_Imaging

Dette er "sakset fra Wiki.. " :

Programmability

Via COM, MODI provides an object model based on 'document' and 'image' (page) objects. One feature that has elicited particular interest on the Web is MODI's ability to convert scanned images to text under program control, using its built-in OCR engine.

The MODI object model is accessible from development tools that support the Component Object Model (COM) by using a reference to the Microsoft Office Document Imaging 11.0 Type Library. The MODI Viewer control is accessible from any development tool that supports ActiveX controls by adding Microsoft Office Document Imaging Viewer Control 11.0 or 12.0 (MDIVWCTL.DLL) to the application project. These folders are usually located in C:\Program Files\Common Files\Microsoft Shared\MODI.

The MODI control became accessible in the Office 2003 release; while the associated programs were included in earlier Office XP, the object model was not exposed to programmatic control.


KR
20. august 2010 - 17:22 #19
HEJ

Prøvede derefter at indlæse MDIVWCTL.DLL som import, men jeg har den overhovedet ikke på PC'en.

Fandt senere ud af at det er fordi den er i forbindelse med Word 2003 (og senere). Jeg "kører" Word 2000 og der er 'Dll'en ikke tilgængelig under programkontrol.

Heller ikke i OFFICE 10 bib'et...

KR
Avatar billede preppydude Nybegynder
20. august 2010 - 20:14 #20
Jeg må lige selv prøve her senere. De laver ikke dokumentation på et objekt man ikke har kunnet udnytte. :)
Avatar billede preppydude Nybegynder
25. august 2010 - 10:15 #21
MODI findes IKKE i Microsoft Office 2010, men alle tidligere versioner.

Jeg har testet funktionen jeg gav dig, og den virker altså fint her - sikker på du har gjort det rigtigt?
25. august 2010 - 12:19 #22
HEJ,

Jeg skal ikke kunne sige, om jeg har lavet en fejl, mne jeg kopierede hele blokken fra dit indlæg # 11 (se ovenfor), satte det ind i min (test-)kode som en function og kompilerede .

Det gav den fejl, som jeg beskrev i indlæg # 17 .

Jeg har siden søgt efter den beskrevne DLL'er men har endnu ikke fundet den nogen steder. (Mmen måske har jeg ledt de forkerte steder..)

Jeg finder IKKE MODI_TLB nogen steder. Har som sagt prøvet om jeg kunne TYPE_IMPORTERE den, men det har ikke lykkedes. Har du nogen anelse om hvilket TYPE-BIB den (kan) ligge(r) i ?

KR
Avatar billede preppydude Nybegynder
25. august 2010 - 12:26 #23
Da jeg testede importerede jeg et Type Library kaldet "Microsoft Office Document Imaging". Alt fungerede som det skulle, udover at jeg skulle omdøbe en class kaldet "TImage" til "TModiImage" i stedet. Jeg kan uploade en package med det hvis det er. :)
25. august 2010 - 13:52 #24
HEJ

BINGO...

Der var det. Har nu MODI_TLB inde.

Skal til møde nu her om lidt (14:30) så du har det overordnede svar en gang i løbet af i morgen.

(Det er godt du kendte den fidus. Jeg gjorde ikke.

Skal osse gøre det på min hjemme PC... )

KR
Avatar billede preppydude Nybegynder
25. august 2010 - 14:33 #25
Super at du fik det til at spille. Jeg er hjemme senere i dag - så skal jeg nok hjælpe dig videre hvis det er at du mangler lidt hjælp.
25. august 2010 - 23:55 #26
HEJ,

Efter et godt resultat på jobben kommer jeg glad og fro hjem og vil installere MODI_TLB på egen maskine....

Og så kan jeg ikke finde 'Microsoft Office's "Document Imaging" ' -  altså selve MODI-objektet på min maskine --- NEDTUR ..
(FAN(Censur)S osse !) 

Jobben har MS office 11 og jeg har office 10 .

Kan du give mig et LINK hvor jeg kan downloade de relevante filer.

Ved du om det err muligt at "snubbe" MODI-TLB'en (og *.dcu'en ) og kopiere til min maskine og så få det til at funke ?

KR
Avatar billede preppydude Nybegynder
26. august 2010 - 00:12 #27
Jeg havde selv 2010 installeret, og måtte nedgradere til 2007. Tror desværre ikke der er nogen anden udvej lige umiddelbart.
26. august 2010 - 12:25 #28
HEj,

Tak for svar.

Noget godt er der imidlertid kommet ud af dette. Chefen har fået øjnene op for denne problemstilling og vil rette en henvendelse op i systemet således at vi "dødelige" kan få det vi har brug for i vores job-funktioner. Hvordan det bliver vil tiden vise, men det skulle være maskinlæsbart og så kan vi bare skille det ikke ønskede fra via software.

Under alle omstændigheder siger jeg dig tak for hjælpen. Den har være uvurderlig (på flere planer).

Jeg arbejder i hvertfald videre med MODI_TLB her på jobben og ser hvad det kan udvikle sig til. Også mange tak for det ini'tiv.  I samme åndedrag er en opgradering til MS-Off 2003 under kraftig vurdering på hjemmefronten.

Og så vender jeg frygtelig tilbage .. 

("I'll be back."  Citat Arnold Schwartzenegger / Terminator )..

PS:

HE  HE



KR
19. september 2010 - 01:18 #29
LUKKER LINK
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Kurser inden for grundlæggende programmering

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester