Ügyfelünk dokumentumokat szeretne készíteni úgy, hogy azokat dolgozóadatokkal tölti fel. Ne kelljen az újonnan belépő dolgozónak word-ben megszerkeszteni a belépőkártya igénylő lapját, a munkaidőnyilvántartó lapját. És még sorolhatnánk…

Office dokumentumok kicsit nehézkesen kezelhetőek, célunk volt, hogy az adatok behelyettesítése után a lapok elküdhetőek legyenek a nyomtatón kívül PDF-be, vágólapra, stb. Ezért jött az ötlet, legyen RTF. Van jól használható RTF editorunk, abban a felhasználó a dokumentumait elkészíti, adatbázisban tárolhatja. Persze elhelyez benne helyettesítő maszkokat: #NEV#, #SZULDATUM#. (Ezek formátuma a régi rendszerről való átállás miatt kötött volt).

A projekt ezen része elkészült, az adatok a megfelelő algoritmus szerint cserélődtek, a #NEV# helyére bekerült a dolgozó neve és így tovább. A tesztek során kiderült, hogy átlagos felhasználás (nem programozói, azaz laboratóriumi környezetben) a maszkok kicserélése nem is megy olyan szépen, mint azt hittük. Kiderült a turpisság: Ahogy a felhasználó szerkeszti a szöveget és néha-néha visszatöröl, újra beleír, az RTF szerkesztő új szekciót nyit neki az RTF forrásban. A megjelenítést ez nem befolyásolja, de a cserénél előfordul, hogy a szöveget nem tudjuk cserélni, mert a #NEV# maszk 3 részre bomlott és #N, EV és # lett belőle. String.Replace() pedig csak nevetett rajtunk.

Normalizálnunk kellett az RTF-et. Egy teljes RTF értelmezőt (szétbontó, építő) írni nem lett vona kivitelezhető, tekintve a projekt ezen moduljának költségvetését. Azonban egy minimális korrekciós algoritmus belefért, amely az egymás után következő, egyformán formázott elemeket összevonja eggyé:

{\f1\cf0 Ar}{\f1\cf0 ra szeretnék}{\f1\cf0 rámuta}{\f1\cf0 tni}

Tervezésünket siker koronázta, végre megmozgattuk SQL parancsokban ellaposodott, algoritmikus “agyféltekénket” is.