Asadar, vom suprascrie metodele getOsnapPoints si intersectWith pentru a explica AutoCAD-ului care sīnt regulile pentru capturarea punctelor relevante īn modul OSNAP. Motivul pentru care metoda intersectWith este implementata separat si nu īn cadrul metodei getOsnapPoints este urmatorul: īn multe situatii dorim sa apelam explicit masina de calcul a intersectiei dintre obiectul Custom si alte obiecte geometrice, ori metoda getOsnapPoints este apelata automat de catre AutoCAD si nu avem acces direct la aceasta metoda. Observam ca īn fisierul header s-au introdus si trei metode private care ajuta la calculul si determinarea punctelor. Este normal ca aceste metode sa fie private deoarece sīnt folosite numai de catre getOsnapPoints si niciodata nu le vom apela explicit ca metode publice. Daca se iveste aceasta necesitate, este usor sa le mutam īn sectiunea publica, fara sa perturbam mecanismul de baza. Oricum, este bine sa folosim īncapsularea oferita de C++ si sa nu scriem īn stil BASIC (oricine acceseaza orice de oriunde), deoarece, īn cazul aplicatiilor mari, fluxul de date poate sa ne scape de sub control.
Observam ca AutoCAD-ul ne ofera ca parametri de intrare toate datele necesare calculului oricaror puncte OSNAP. Sarcina noastra se reduce la a calcula punctele cu pricina si a le aseza īn lista de retur. Pentru a calcula cel mai apropiat punct (modul NEAREST), folosim obiectul AcGeCircArc3d. Acesta face parte dintr-o familie diferita de cercul persistent, respectiv AcDbCircle. Īn familia AcGe avem obiecte geometrice care nu sīnt persistente (si deci nu apar ca elemente grafice pe ecran), dar care sīnt folosite īn engin-urile de calcul vectorial. Am calculat parametrii celor doua cercuri si am creat doua obiecte geometrice pe care le distrugem cu delete la iesirea din metoda. Motivul pentru care am folosit aceste obiecte este existenta metodei projClosestPointTo, care ne va da cel mai apropiat punct de pe cerc, fata de un punct dat. Asta si urmaream de fapt. Pentru OSNAP CENTER, lucrurile sīnt evidente. Modul QUAD se reduce la a calcula cele patru puncte aflate īn pozitii predefinite si a determina care punct ne trebuie. Subliniez din nou ca entitatea noastra este eminamente plana, lucru dedus din valoarea cablata a normalei obiectului Custom. Daca doriti, un exercitiu util ar fi implementarea modului TANGENT, folosindu-va de argumentul lastPoint, care nu a fost folosit pīna acum. Se poate calcula tangenta la unul din cercuri definind un segment al carui capat este lastPoint iar celalalt capat este punctul curent, respectiv pickPoint si punīnd conditiile corespunzatoare de tangenta.
Pentru a implementa modul OSNAP INT vom face cīteva operatii preliminare. Īn principiu va trebui sa explicam AutoCAD-ului cum se calculeaza intersectia dintre obiectul Custom si segment, arc, cerc, polilinia plana, cea īn spatiu si intersectia dintre doua obiecte Custom. Exemplul nostru contine doar implementarea intersectiei dintre obiectul Custom si segment, celelalte tipuri de intersectii implementīndu-se īn mod similar.
Daca analizam cu atentie sursele vom observa ca ne lipseste o metoda pe care am substituit-o īn diverse zone ale codului; este vorba de calculul centrelor celor doua cercuri. Ceea ce va recomand este ca īn anumite momente ale dezvoltarii si anume atunci cīnd apar asemenea disfunctionalitati sa reproiectati obiectul. Nu īntotdeauna se pot anticipa toate metodele si datele membre necesare unui obiect īn momentul conceptiei acestuia. De aceea este util ca īn anumite momente sa fie revizuita arhitectura interna a obiectelor si sa se treaca la reengineering. Numai prin cīteva asemenea cicluri se poate obtine un obiect robust si fara cod redundant. Eu, personal, am implementat un obiect ceva mai complex si abia cīnd am ajuns la versiunea a sasea m-am putut declara multumit de ceea ce am facut.
Aici se īncheie aceasta serie de articole īn care ati vazut cīt de puternica este scula ARX īn dezvoltarea aplicatiilor AutoCAD. Trecerea de la setul saracacios de functii de interfata ADS la ierarhia de clase ARX va duce la dezvoltarea unor aplicatii care vor face parte dintr-o cu totul alta generatie. Pe de alta parte, anticipez ca va apune era diletantilor care "surubaresc" surse Lisp pentru a scrie aplicatii, interpretorul ramīnīnd apanajul desenatorilor mai dezghetati, dornici sa faca mici optimizari "in-house" pentru mediul AutoCAD. Spun acest lucru deoarece exista si o alta zona total neexplorata si anume MFC, tehnologie cu ajutorul careia ferestrele de dialog (si nu numai) vor avea complexitate si functionalitate asemanatoare cu orice aplicatie nativa Windows, imposibil de atins cu batrīnul si desuetul DCL. Acest subiect poate va fi tratat īntr-o alta serie de articole.