Ez az írás segíthet a Linuxszal történő ismerkedés során. Sok olyan embernek segítettem Linux telepítésével, akik azelőtt csak Windowst használtak. Ez az írás főleg az általuk feltett kérdéseken alapul. Rengeteg írás, információ fellelhető az interneten, mindenféle szempont szerint kategorizálva. Ez a leírás nem tartalmaz minden érdekes információt, de igyekszem amennyire lehet tömören összefoglalni (így is jó hosszú lesz), azokat a válaszokat, amiket az évek során a nekem feltett kérdésekre volt alkalmam adni.

Ennek a cikknek az előzménye: https://linuxmint.hu/blog/2022/02/windows-vs-linux-tudorka-3-parancsok-meg-egyebek

Ezúttal egy neuralgikus pontot érintek, ami sokakat nem érint, de éppen elegen vannak, akiknek ez igenis számít – mármint, ha elég sok makrót leprogramoztak pl. Excelhez, az bőven elegendő ok lehet a Windowshoz (és Microsoft Office-hoz) való ragaszkodáshoz.

De, hogy ne legyen kizárva a nagy többség, előbb jöjjön egy kis ismertető, hogy mindenki értse, miről is van szó. Történelem jön megint, de remélem nem lesz unalmas…

A személyi számítógépes idők hajnalán alig voltak általánosan elterjedt alkalmazások, aminek egyik oka az volt, hogy nem igazán volt ötlet arra nézve, hogy mire és miként lehetne használni a gépet. Mármint a lehetőségek ismertek voltak, de a megvalósítás mikéntje az kérdéseket vetet fel. Az első IBM gépek BIOS-a ezért tartalmazta a BASIC interpretert is, és ha nem volt merevlemezük, vagy flopi a meghajtóban, vagy volt, de nem volt operációs rendszer egyiken sem, akkor a ROM BASIC-ot töltötte be. Az AT klónok persze ezt nem tartalmazhatták, mert az amúgy szabaddá tett ipari licenc (ami lehetővé tette az AT klónok elterjedését) - ezt nem engedte meg.

A BASIC (Beginners' All-purpose Symbolic Instruction Code) egy interpreteres program nyelv volt, amit a mikroszámítógépek használtak, egy egyik fő érdekessége az volt, hogy a sorokat számozni kellett, a futás közben hibákat a rendszer úgy jelezte, hogy kiírta a sor számát, így lehetett tudni, hogy melyik kódsort kell vizsgálni (nem mondta meg, hogy mi a hiba, csak kiírta, hogy ERROR AT <szám>). A Sinclair ZX Spectrum gépe a sorok számozását automatikusan megoldotta, a felületén a bal oldalon egy oszlopban előre fel voltak sorolva a számok, mint egy táblázatkezelőben, azokat nem is lehetett módosítani, csak mögéjük írni az utasításokat. A BASIC programnyelvet Kemény János György fejlesztette ki Thomas Eugene Kurtz kollégájával. Ezt csak ezért említem meg, mert a magyarok végig ott voltak a számítástechnika fejlődése mentén, Neumann János (aki kidolgozta az elvet, ami alapján a mai gépek működnek) mondhatni „csak” a kezdet volt.

Intermezzo: Amikor kisiskolás voltam, egyik osztálytársammal hazafele bandukolva elénk toppant a matematika tanárunk, és behívott a közelben levő lakásába. Előkapott egy Sinclair ZX Spectrumot, amit egy Svédországba disszidált kollégája küldött neki, fogalmam sincs, hogy hogyan jött át annyi határon. Bedugta a TV-be, bekapcsolta, és feltárult a mennyország. Vagyis olyasmi élmény volt. Megbabonázva néztük, ahogy mutatta, hogy parancsokat lehet begépelni, és a gép válaszolt! Sőt, betöltött programokat, amik úgy viselkedtek, ahogy azt vezéreltük. Már tök sötét volt, mire hazaindultunk. Megbeszéltük, hogy mehetünk hozzá minden héten kétszer, és használhatjuk a gépet. Karácsonyra a szüleimtől egy BASIC tankönyvet kértem. Amikor apám elképedve mesélte az ismerősöknek, hogy mit kértem, akkor a többiek, mint ha a világ legtermészetesebb dolga volna, annyit mondtak, hogy

„Végül is, a következő generáció (azaz, az én generációm) általános műveltségi követelményeihez hozzá fog tartozni az egy idegen nyelv ismerete mellett egy programozási nyelv ismerete is.”

És ezt nekem komolyan kellett venni. Nem tudom hogy sikerült apámnak, de valahogy szerzett külföldről egy BASIC könyvet. Ezt rongysora olvastuk az osztálytársammal, nem tudom hány kockás füzetet írtunk tele programokkal. Ötödikesek voltunk, amikor egyik iskolatársunk, akiről nem is tudtuk, hogy ebben is utazik, írt egy Holdra szálló programot -azaz vezérelni kellett a leszálló egységet miközben a gravitáció vonzotta lefelé (fogalmam sincs, hogy honnan voltak meg neki a parabola és pályaszámítás képletei :-)) //Ez a játék valahogy aztán bekerült a Windows 3.1-be is Lander néven.//

Azt gondoltam, hogy ha majd nagy leszek, akkor kb. 5 évig kell csak kenyeret, és krumplit enni, így talán össze lehet spórolni annyit, amennyibe egy ZX Spectrum került akkor. Persze színes TV is kellett volna, de erre már ötletem sem volt, hogy miből, mert akkor az még annyiba került, hogy egy élet alatt sem lehetett volna annyit összespórolni.

Szóval, akkoriban az elképzelés kb. az volt, hogy számítógépeket az emberek a jövőben úgy használják majd, hogy megírják azon maguknak a számukra szükséges programokat.

És ez az elképzelés végigvonult a későbbi alkalmazások mentén is. A DOS tartalmazta a QBASIC-et, a BASIC egy változatát, meg két BASIC játékot is, mintának, a dBase adatbázis kezelő az alapvető funkció mellett biztosította a programozás lehetőségét is, később a FOXPRO meg konkrét fordítót is, amivel binárist lehetett előállítani, az IBM programszerkesztője meg makrókat tudott futtatni, amiket billentyű kombinációkhoz lehetett rendelni, stb.

A szövegszerkesztés (karakteres) és az adatbázis kezelés volt a korabeli gépek fő alkalmazási területe (no meg a játékok, persze). És egyszer csak megjelent a Visicalc. Pontosabban már volt mikroszámítógépre is, de amikor megjelent a DOS változat, na akkor az nagyot ütött. Ugyan a felhasználói kézikönyve egy A4-es lap fele méretű karton volt, de ezzel is igencsak sokoldalúan lehetett használni. Fel is vásárolta a Lotus, aki ezt továbbfejlesztve kiadta a Lotus 1-2-3 programját.

Ez az időszak olyan volt, hogy ha erről filmsorozatot kellene készíteni, akkor az igencsak hosszú lenne. Cégek alakultak, darabolódtak, felvásárolták egymást, pereltek, licenctrollkodtak, mindegyik igyekezte lenyomni a másikat. Ebben az időszakban már „el dőlt”, hogy nem kell az embereknek maguknak otthon megírni a saját programjukat, jó lesz az úgyis, ha cégek írják, és ezzel pénzt keresnek. És ugyanakkor kialakult egy válság is. Talán programozói válságnak, vagy minek lehetne nevezni. A dolog lényege, hogy a technika olyan ütemben fejlődött, hogy azt képtelenség volt programozás oldalon lekövetni. Mármint, az akkori monolitikus programozással egyszerűen nem volt elég programozó, hogy a programokat megírják, még végtelen idő alatt sem. Másképpen mondva, túl sokáig tartott egy program megírása, mire elkészült, a hardver, amin futott volna, már régen elavult lett. És a verseny is szigorú határidőket szabott, olyan szűköset, hogy esély sem volt annyi idő alatt befejezni normálisan egy programot. (Tényleg volt alapja annak, hogy mindenki otthon megírja saját programját, mert így elég jól eloszlott volna a programozási feladat, miközben a „valamennyi cég + valamennyi programozó szaki” modell az egyszerűen befulladt).

Ám megjelent a NeXT (nem, nem a divatmárka, hanem az objektum modell, ami az objektum orientált paradigmára építve konkrét megoldást kínált a krízisre. Az objektum orientált paradigma egyes elemei már elég korán megjelentek, az 1950-es évek végén 1960 elején, ami folyamatosan kristályosodott, de életképes modellek csak az 1980-as évek közepén láttak napvilágot)

És jött a Borland inc a Quattro pro-val. Erről tényleg lehetne egy film, mert nagyon érdekes történet. A dolog úgy kezdődött, hogy három kelet-európai, melyek közül csak Frank Lajos neve ismert, kifejlesztett egy táblázat kezelő programot, amit Quattro-nak hívtak- állította egy cikk a Byte magazinban, és azt is tudni, hogy a Borland akkoriban nem foglalkozott ilyen programmal. Frank Lajos neve is csak azért ismert, mert később felhappolta a Microsoft (és hogy-hogy nem, lett Excelje). A Borlandnál is olvasták a cikket, ekkor mintegy viccként felmerült, hogy tényleg jó lenne egy táblázatkezelő, amivel lenyomnák a Lotust. És végül felvették a kapcsolatot Stein Róberttel, az Adromeda Software-tól. … És elindult a Quattro fejlesztése (Frank Lajossal a csapatban). A Borland irodáját földrengés kár érte, a tűzvédelmi locsolók elárasztották a gépeket, amiket kivittek a teniszpályára és hajszárítókkal szárították. Ami beindult, azzal dolgoztak odakint a teniszpályán, késő őszig, és meglett a Quattro pro. És nem mellesleg kidolgozták az objektum orientált programozást is az alkalmazásukhoz!

Egyszerűen hihetetlen alkalmazás volt Quattro Pro, egy millió sort 18 276 oszloppal kezelt minden munkalapján, DOS alatt (miközben az Excel csak 65 536 sort és 256 oszlopot kezelt sokáig). A Quattro Pro felülete elegáns, szép grafikával készült – és teljes körű programozási lehetősége volt, akár teljesen más kinézetű adatkezelő alkalmazássá is át lehetett alakítani. Ugyanakkor, a menüi, billentyű kombinációi a Lotus 1-2-3-ra hajaztak, hogy ne legyen nagy gondja az áttérőknek. Ezt a Lotus nehezményezte, perelt. A Borland azzal védekezett, hogy az autókat is azonos módon kell vezetni, attól függetlenül, hogy azokat többen gyártják. A legfelsőbb bíróságra került az ügy, ekkor, és emiatt lettek szétdarabolva a jogvédelmi kategóriák, végül a Borland nyert, de azóta lehet dizájnt is levédetni. (Ennek köszönhetően tudta levédeni az Apple a téglalap formát)

Persze, sok idő eltelt, mire döntött a bíróság, ekkora a Borland már eladta a Quattro Pro-t, aminek már a Windowsos verzióján dolgoztak (a csapatban Cseri Istvánnal) .

A Quattro Pro-t a Novell vette meg, de közben kijött a Windows 95 új Office csomaggal, és a Quattro pro nem működött alatta, rossz nyelvek szerint direkt gátolva volt, mármint a Windows 95-be be lett építve a Quattro Pro akadályozása, hogy ne legyen konkurense az Excelnek. Végül a Novell táblázatkezelője, és szövegszerkesztője a Corel-nél kötött ki. Aki összecsomagolta saját grafikai alkalmazásával egy Corel Office csomagba, immáron 32 bites változatban. De mindezt már csak angol nyelvi támogatással, miközben a Microsoft lefordította 14 nyelvre az Office csomag felületét, (naná, hogy köztük volt a magyar nyelv is, már a kezdetektől)

Tehát, amíg a per zajlott, addig is a Borland fejlesztette a Quattro pro-t. 1985-ban megjelent az első 16 bites Windows de az még elég kezdetleges átdolgozása volt a DOSSHELL-nek.)

Viszont volt 16 bites grafikus felülete, ami standard elemekből építkezett, amit a programok is használhattak. (Az első verziókban az ablakokat nem lehetett egymás felé mozgatni, méretezni, minimalizálni.) A Borland elkészítette a Quattro pro windowsos (16 bites) változatát is. Aminek a kinézete semmiben sem különbözött a DOS verziótól. Ezt úgy kell érteni, hogy a DOS verziója olyan fejlett grafikai felültetet használt, hogy a windowsos verzióban sem lehetett többet kihozni. A Borland először a két változatot egy csomagban árulta, két program korrekt áráért, mivel ténylegesen két program volt a pakkban. Az emberek viszont a teljesen egyforma felületek miatt azt gondolták, hogy egyazon programról van szó, egyszerűen a DOS-os program fut Windows alatt is, és átverést sejtettek. A Borland ezért gyorsan ketté választotta a csomagot, külön egyenként lehetett megvásárolni a változatokat, aminek így igen jutányos ára volt.

Az Excel ez idő tájt a 4-es verziónál tartott, aminek a képességei elmaradtak a Quattro Pro-hoz képest, minden területen (programozási lehetőségeket is ideértve). Mindenképpen lépni kellett valamit, így ki lett adva az 5-ös verzió, ami már a Visual Basic programszerkesztőjét (VBE / Visual Basic Editor) tartalmazta, és ki lett dolgozva egy Visual Basic-like környezet is (értsd: alkalmazáshoz kapcsolódó objektumok, osztályok, és utasítások), ami a VBA nevet kapta (Visual Basic for Applications) .

Aztán eldőlt, hogy innentől minden újabb Office verzió megkapja az aktuálist megelőző Visual Basic környezetet (a VB saját + alkalmazáshoz kapcsolódó elemeivel). A 6-os verzió (az utolsó 16 bites változat) már így jelent meg, és innentől számítanak veszélyesnek a makrók, mert már egy dokumentum olyan kódot is tartalmazhat, ami nem csak az adott alkalmazás (Word, Excel) objektumait tudja elérni, hanem bármit, ami rendszer szinten elérhető).

A Visual Basic már objektum orientált nyelvnek tekinthető, ha szigorú definíció szerint nézzük.

A 90-es években tornádóként söpört végig az objektum orientált paradigma a programfejlesztés minden területén, mert ez az egyik lehetőség volt a már említett programozási válság leküzdésére. Egyre másra jelentek meg a klasszikus nyelvek objektum orientált változatai. Amelyik nem tért át, az háttérbe szorult. Bár, a „nyelvtant és stilisztikát” betartva lehet objektum orientáltan programozni akármelyik nyelv alatt, létre lehet hozni objektumokat, stb. ám egy dologban eltérnek a monolitikus nyelvek a konkrétan objektum orientált nyelvtől, mégpedig abban, hogy nem tudják, azaz nem támogatják az öröklődést. Az objektum orientált nyelvben az öröklődés biztosítja az elemek újra felhasználását, nem kell mindent mindig újra leprogramozni, meglévő objektumról lehet „másolatot” készíteni, aminek kevés tulajdonságát is elegendő megadni, mert a többit „örökli az előzőtől”.

A Visual Basic szintaktikája megfelel az objektum orientált nyelveknek, támogatja az öröklődést, ám mégis fele más nyelvként jellemzik, olyan monolitikus nyelvnek, ami tartalmaz objektum orientált elemeket is. Mondjuk az biztos, hogy POSIX szabványnak nem felel meg. Nem kötelező a változatokat a kód elején definiálni. Ennek megítélése felemás, vannak nyelvek, amelyekben a változókat kötelező előre definiálni, és sokan ragaszkodnak ehhez, de az is tény, hogy igen kényelmes akárhol a kód közepén felkapni egy új változót. Meg aztán, az az érv is megdől, miszerint az jó, ha már kód elején fel vannak sorolva a változók, így azokat könnyen át lehet tekinteni, mivel a mai programok esetében a változók felsorolása akár több oldalnyi szöveget is jelenthet, hát ember legyen a talpán, aki ezt áttekinti, és fejben tartja végig. Biztos létezik ilyen, de én még nem találkoztam senkivel, aki erre képes lenne.

A Visual Basic jelenleg már nem egy kurrens programnyelv, ám már indulásakor pfujoltak rá az öreg szakik, „mégis milyen dolog az már, hogy egerészve kell programozni?” - mondták. (VBE alatt a képernyőelemeket /párbeszéd ablakokat, beviteli mezőket, stb. előregyártott elemekből lehet úgy létrehozni, hogy az eszköztárról odahúzzuk ahová kell, egérrel lehet átméretezni, áthelyezni, másolgatni – mindezt az addigi nyelvekben sok sok hosszú sorral kellett leírni, szövegesen, számokkal megadni a méreteket, pozíciókat, stb.) Továbbá az is baj volt, hogy a VBE okoskodik, azaz gépelés közben prediktív módon javaslatokat tesz a további szöveget illetően…

Mára mondhatni a VBE elavult, azaz, a mai modern programszerkesztők már jóval több mindent tudnak, bár az egyetlen fájó hiányossága a VBE-nek az, hogy az If … End If esetén nem jelöli, hogy melyik If melyik End If-nél ér véget, ami egymásba ágyazott szekvenciák esetén igen csak jól jönne, és ugyanez igaz a ciklusokra is.

A Visual Basic-ról az általános vélekedés az, hogy hát Basic-nak nem mondható (ez igaz, eléggé tág nyelv), de ugyanakkor nem is annyira kiterjed mint mondjuk a C++. (Általában nem indokolják, hogy mégis mi szükség lenne erre). „Mert C /C++ alatt látni rendesen, hogy mit csinál igazából a gép” – hát ha úgy vesszük, akkor ehhez leginkább a GÉPI KÓD kellene. A GÉPI KÓD még a mikroszámítógépek esetén lehetőség volt. Azt még át lehetett tekinteni, ha nem is fejből tudni az egészet, de könyvből, nyomtatott listából ki lehetett böngészni, hogy mi mit jelent. A mai gépek esetén az Intelnél / AMD-nél van erre kapacitás….

Ugyanakkor a Visual Basic a legvérmesebb lenézői is elismerik, hogy az Office-hoz kapcsolva kiemelkedő a jelentősége. Mert az a helyzet, hogy mind MS Office mind LO esetén „gyártói szemszögből” a makrók szerepét abban látják, hogy a gyakran ismételt feladatokat ezzel automatizálni lehet, a gyakorlatban viszont ennél több lehetőséget is biztosít pl. céges környezetben. A mai gyorsan változó világban a céges alkalmazások fejlesztése nem elég gyors ahhoz, hogy a változásokat lekövesse. Nagyon sokszor bizonyul hasznosnak a makrózási lehetőség konkrétan teljes folyamatok támogatására is.

Személy szerint én pl. már sok éve észrevettem, hogy már 6 MB makró kódot összepötyörésztem. Ez irdatlan mennyiséget jelent (kb, 6 millió karaktert). És ez sok éve volt. Azóta már nem is számolom. Van sok, ami már kiváltásra került, és mindig lesz szükség újabbakra.

No, ennyi rizsa után lássunk akkor némi konkrétumot is a mai állásról. (Tudom, úgy sem olvassa el senki, azért rizsálok ennyit).

Mind MS Office mind LibreOffice esetén a makrózhatóság kiterjed az összes alkalmazásra ami a csomagban van, de mind közül az Excel / Calc a legérdekesebb, a táblázatkezelő esetén van a legtöbbször szükség makrókra, ezért most a fókusz ezeken van.

LO makró felülete az implementált BASIC. Ez a neve, hogy BASIC, és kódoló felülete tökre ZX Spectrum feeling, bal oldalon a sorok számozása adott. A program szerkesztőjének neve BASIC IDE.

Talán nem lövöm le túl hamar a poént, hisz azt sejteni lehet, az MS Office a VB támogatással alig überelhető programozási lehetőséget és kényelmet biztosít, ehhez hasonlót nagyon nehéz megvalósítani egy olyan projekt keretén belül mint amilyen a LibreOffice. De nézzük, hogy mink is van:

Kereszt-kompatibilitás / átjárhatóság:

- Mondjuk úgy, hogy az utasítások, amennyiben nem konkrét objektumra vonatkoznak, azok teljesen ugyanazok. De LO BASIC nem támogatja az Unicode kódot, vagy valami alap karakter kódolás probléma lehet. Mert pl. az ő és ű karakterekkel nincs baja, de a többi ékezetes karakterrel igen. (Most előttem van a kép, amikor még a DOS-os időkben nagy egóval és felsőbbrendűségi nüansszal megáldott kolléga kifakad, hogy ki az az istenbarma dilettáns idióta, aki ékezetes karaktert használ változó definiáláskor…) Igen, a DOS kódlapokat használt, amit cserélgetni lehetett, ez meg problémát okozott a programok szempontjából ha azok nem angol karakterekkel voltak kódolva. És tény, hogy ma az Unicode világában sem indokolja semmi az ékezetes karakterek használatát. Hacsak az nem, hogy pl. a függvény nevek és paramétereik megjelennek az Excel vagy Calc felületén is, Függvény varázsló felületen, Tündér felületen (itt alapból nem jelennek meg a saját függvények, de a szerkesztőlécen igen)… És nagyon rondán néz ki az ékezetmentesen írt szöveg. Az Excel makrókban nincs gond ezzel, és a felületen is ugyanúgy néz ki, ahogy a kódban. LO alatt a gyári függvényeknek nincs gondja az ékezetekkel, a saját BASIC kód esetén viszont igen. A felületen továbbá nagybetűsen jelennek meg a függvény nevek és paramétereik. (akkor is ha kisbetűsen vagy vegyesen voltak kódolva).

- Amíg VB alatt egy függvényen belül, vagy egy makrón belül minden további nélkül meghívhatunk másik függvényt, makrót, LO alatt ez sokkal bonyolultabb. Még a LO saját függvényeinek a meghívásához is külön szolgáltatás betöltésére, annak átadva a kérést (paramétereket tömbbe foglalva) kell átadni, hogy a LO függvény visszaadja a kívánt értéket.

https://ask.libreoffice.org/t/how-to-call-lo-calc-functions-from-a-lo-basic-function-macro/40389/2

- A Formok kis eséllyel importálhatók, mert egyfelől a VB a Formokhoz kapcsolva kezeli az elemeihez kapcsolt kódot is, LO BASIC ezeket a kódokat űrlapként kezeli, ezért különválasztja a kódot. LO több vezérlő elemet is tud, mint a VB, de van amit VB támogat, de LO nem. Pl. a füleket úgy néz ki, hogy nem. (Ami MS Office alatt a Form, az LO alatt a Dialog) Ha Excel fájlban egy nagyon bonyolult Formot megnyitunk BASIC IDE-vel, a LO össze is omlik. (Keretbe foglalt, azaz összekapcsolt rádiógombok már elég bonyolultak)

Magyarul, ha az a tervünk, hogy az Excel makrókat könnyen átvihetjük LO alá, hát ez nem jön össze. Ha kevés a kód, akkor járható út az átjavítása importálás után, de mindenképpen szükség lesz további kódolásra, mert LO BASIC alatt az objektumokat külön könyvtárakon keresztül lehet elérni, amiket be kell tölteni, megírni az objektumokra a hivatkozásokat, stb.

Hogy ne legyen egyértelmű a dolog: LO telepíthető Windowsra is. Ha ugyanezen a gépen telepítve van MS Office is, akkor LO támogatja annak az objektumainak az elérését is egy bizonyos szintig, tud kezelni egy csomó mindent az áthozott makrónk kódjából, amit Linux alatt nem, mert arra nincs MS Office.

-Az Excel alapból betölti a szükséges könyvtárakat, osztályokat, modulokat, így azok rendelkezésre állnak. Pl. Cella objektum: Excel esetén beírjuk a kódba hogy Cells(1,1).value=”Minta”, akkor ennyi elég, és beírja az A1 cellába, hogy Minta. LO esetén ehhez először be kell tölteni a megfelelő könyvtárakat (library) , definiálni (örököltetni) az objektumokat, tehát jellemzően több szubrutinból áll egy ilyen művelet leprogramozása.

- LO biztosít API felületet külső alkalmazások számára, tehát kívülről vezérelhető. Magyarul bármilyen programnyelven is programozható, a megfelelő API-kon keresztül. Alapból régebben Python, JAVA makrózást támogatott, ma már BeanShell-t is, de akármivel is lehet, ami fel van készítve az API-k kezelésére. Linux alatt értelemszűrűen azzal, amit telepíteni lehet.

MS Office is elérhető valamilyen szinten kívülről, a VB objektumokon keresztül.

- MS Office alatt a makróinkat, függvényeinket elmenthetjük bővítményként (Add-In) is, csak simán mentés másként opcióval, LO alatt erre nincs könnyű lehetőség, csak bonyolult, C++ kell hozzá:

https://wiki.openoffice.org/wiki/SimpleCalcAddIn

(A bővítményeknek az a lényege, hogy azokat betöltve azonnal rendelkezésre állanak a függvények, funkciók, bekerülnek a tételek LO függvény tündér listájába, stb.)

 

Segítség, dokumentáció, leírások:

MS Office esetében az alap telepítő készletben a Makró dokumentáció és súgó telepítéskor alapból nincs kijelölve, a terjedelme miatt nem szokták a gépre telepíteni. Ki lehet jelölni, hogy települjön, de, ha van internet elérés, akkor nincs erre feltétlenül szükség. (Nem tudom, hogy a mai Office esetében egyáltalán van-e helyi dokumentáció a telepítőben, régebben volt, nagyon szépen ki volt dolgozva benne minden) VBE felületen ki kell jelölni egy szövegrészt (parancsot, vagy annak egy részét), megnyomni az F1-et, feltárult a kijelölt paranccsal kapcsolatos súgó, vagy weboldal.

LO esetében ilyen nincs, az F1 a helyi gépre telepített HTML makró leírásokat nyitja meg a böngészőben. Itt találhatunk hasznos információkat, csak kissé nehézkes a navigáció / keresés. Az sem segít, hogy félig-meddig lefordított, magyarul és angolul jelennek meg a szövegek. Ettől függetlenül érdemes olvasni, adhat tippeket. Webes megfelelő:

https://help.libreoffice.org/6.1/en-US/text/sbasic/shared/01000000.html

MS Office makrózásról rengeteg fórum van, információkat könnyű szerezni. Még magyar oldalakon is, de lehet számos könyvet is vásárolni.

LO esetében meg ébredezik a helyzet. Van sok infó, de pl. fórumok tekintetében még elég kevés az infó, nehéz a konkrét kérdésre választ találni.

Példák:

https://www.debugpoint.com/libreoffice-basic-macro-tutorial-index/

https://documentation.libreoffice.org/en/english-documentation/macro/

PDF könyv: https://www.pitonyak.org/OOME_3_0.pdf (a 4. kiadás még készül, itt lehet nyomon követni, ill. további anyagokat, példákat letölteni: https://www.pitonyak.org/oo.php

És persze lehet kérdezni (angolul, mert magyar szekció még nincs) itt is: https://ask.libreoffice.org/

 

No, de lássunk konkrét példákat, képeket, kódokat!

Íme az Excel függvény segédje, ezen a nyilakkal jelölt szövegeket a kódból veszi, úgy mutatja, ahogy meg lett adva:

 

LO Calc felületen a „Tündér” ugyanezt csak akkor tudná, ha a függvényt bővítményként töltené be, ilyen képet most nem tudok mutatni. Magyarul be kell rendszeresíteni egy noteszt amibe felírjuk a függvényeinket, és használatuk módját, hogy szükség esetén tudjuk mit kell beírni :-).  Simán csak makróba ágyazva a LO ugyanezt a függvényt ékezet mentesen fogadja el, és nagybetűsre konvertálja a nevét:

 

 

Íme a függvény kódja VBE felületen. A felső nyilak jelölik a függvény nevet, és paraméter változók nevét, ami fentebbi Excel felületen is megjelennek. Alsó nyíl: a függvény meghívja a Nettóértéke() függvényt a számításhoz. Ilyesmit a LO BASIC így alapból nem támogat.

 

Ha LO BASIC alatt így adjuk meg, másik függvény meghívásával a számítás kódját:

Akkor ezt kapjuk a felületen:

Íme a LO BASIC IDE felülete, alul az eszköztár a támogatott vezérlő elemekkel:

 

Alább a VBE felülete. Jobbra az eszköztár, ennyi vezérlő közül lehet választani. Az előtérben egy lapfüleket tartalmazó párbeszéd ablak, na ilyent a LO BASIC nem tud.

 

VB alatt a vezérlő eseményvezérlése egyszerű: Jobb egérgombbal adott elem felett, kód megjelenítést választva feltárul a hozzárendelt kód.. (Jelen esetben, amennyiben változik az értéke, akkor vastag betűs lesz, az összes többi meg vékony betűs.

Jobb oldalon a nyíllal jelölt mező az legördülő, a listából lehet kiválasztani, hogy melyik eseményhez rendeljük az azt követően beírt kódot.

 

LO BASIC ide alatt előbb a kódot (makrót) kell megírni, majd az alábbi ábrán mutatott lépésekkel hozzárendelni:

 

Elnézve a LO BASIC-ot, azt kell mondanom, lassan fejlődik. Ha makrók írására vetemedünk, akkor tartsuk szem előtt azt, hogy a LO makrók futtatásánál a következő módon keresi a makrókat: Saját gyári moduljai (LibreOffice-makrók), aztán a Saját makrók és párbeszédablakok alatt a STANDARD modulban. Ennyi, és slussz / passz. Ha további modulokat hozunk létre, akkor azokat csak úgy tudjuk futtatni, hogy a STANDARD modulunkban létre hozunk hozzá indító/betöltő makrókat. Érdemes úgy szervezni a dolgokat, hogy a STANDARD modul csak erre legyen használva, mivel amúgy limitáltak a modulok méretei (ami, ha jól emlékszem, valami 256 kB-t jelent, ez elég sok, de azért véges)

Nem vagyok egy LO BASIC guru (kipróbáláshoz / teszteléshez használtam csak eddig), de eddigi eszmecserék során azokkal, akik ezzel foglalkoznak, általános nézet volt, hogy inkább Python. Azaz, előbb-utóbb mindenki a Python-nál kötött ki, ki azért, mert megunta a LO BASIC-ot, ki meg azért, mert olyanba futott bele, ami csak így volt megoldható.

= A negyedik rész vége =

A következő rész általánosan a rendszerekről, telepítésekről...