Bezmaksas referāti skolai: Lietotāja-datora interfeisa uzlabošana, strādājot ar Oracle Forms 4.5

Latvijas Universitāte

Fizikas un matemātikas fakultāte

Datorikas nodaļa

Lietotāja-datora interfeisa uzlabošana,

strādājot ar Oracle Forms 4.5

Kursa darbs

Autors : Ivo Ālmanis

st. apl. Nr. DatZ M 96007

Darba vadītājs : Dr. dat. Andrejs Auziņš

Rīga, 1997

Anotācija

Šajā darbā tiek aplūkots kā labāk veidot vienotu, vienkāršu un intuitīvi saprotamu lietotāja-datora interfeisu, strādājot ar Oracle Forms 4.5, produktu, kura vājākā vieta, salīdzinot ar citām 4 paaudzes valodām (4GL), ir tieši lietotāja-datora interfeiss. Bez tam darbā tiek apkopoti un izanalizēti vairāki raksti žurnālos un Internetā par tēmu “aplikāciju lietotāja-datora interfeisa uzlabošana” darbam ar Oracle Forms 4.5 tieši MS Windows vidē. Darba beigās doti programmu kodu piemēri visiem darbā minētajiem problēmu risinājumiem.

Abstract

This written work describes the best ways of creating of a simple and easy-to-understand graphic user interface for operating Oracle Forms 4.5. If compare with other 4GL, this interface is the main drawback of the product. This work also contains an analysis of several articles from different magazines and the Internet resources dealing with “an improvement of applications of the graphic user interface” for Oracle Forms 4.5 based on MS Windows. In the conclusion the author offers the solutions of all the problems mentioned in this written work.

Аннотация

В данной работе рассмотрены возможности разработки простого и легко воспринимаемого графического интерфейса пользователя для работы с Oracle Forms 4.5 - продуктом, самым слабым местом которого, по сравнению с другими языками 4-го поколения (4GL), является именно данный интерфейс. В работе собраны и проанализированы несколько статьей из журналов и интернета о “улучшении графического интерфейса пользователя аппликаций” по работе с Oracle Forms 4.5 в среде MS Windows. В заключении данной работы даны примеры решений в работе упомянутых проблем.

Saturs

Ievads ...……................................................................................................……......... 6 1. Grafiskā lietotāja-datora interfeisa pamatprincipi ………………………………… 8 2. Šablonformu izmantošana formu ģenerācijai…………………………….……….. 9 3. Preferences kā ģeneratora parametri………………………………..…………… 14 4. Padomi interfeisa uzlabošanai ……….…………….………….…………………. 16

4.1. Rīku josla ……….……………………………………….……….…… 16 4.2. rīku padomi (Tooltips) - spiedpogu nozīmju aprakstīšana ……..……. 17 4.3. standartizvēlnes …………………….………………………………….. 17 4.4. ievadlauku krāsu nozīme …………..……………………………..…… 18 4.5. logu virsraksti ……………………..………………………………..…. 19 4.6. resursu pārbaude pirms aplikācijas palaišanas ……………….………. 20 4.7. par - ātra informācija par jūsu aplikāciju ………..……………….…… 20 4.8. paroles maiņa …………………………………..……….……………... 21 4.9. progresa rādītājs ……………………………….…………..…….……. 22 4.10. aplikācijas palaišana …….……………………....…………………… 23 4.11. MS Windows palīdzības logi ……………………………….…….…… 24 4.12. nodaļlapas (Tabbed pages) - jauns interfeisa standarts ……………….. 25

Nobeigums .................................................................................…………..………. 26 Literatūra ......................................................................................................……….. 27 Pielikums ......................................................................................………..………… 28 bn

Ievads

Salīdzinot ar neseno pagātni, tagad ir tendence veidot lielas sistēmas, kur datu apjoms sasniedz desmitus un pat simtus megabaitus. Uz personāliem datoriem bāzētās datu bāzu vadības sistēmās, kā Fox Pro, Access un citās, palielinoties datu apjomiem, krasi samazinās darbības ātrums.

Drīz tiek sasniegta robeža, kad palielināt apjomu vairs nav iespējams. Bez tam nav iespējama vienlaicīga datu lietošana vairākiem lietotājiem, t.i. vienlaicīgi vairāki lietotāji nevar ievadīt datus, tajā pašā laikā nodrošinot šo datu unikalitāti. Nolasot datus parasti visus resursus aizņem viens lietotājs, pārējiem tikmēr ir jāgaida. Šādu ierobežojumu dēļ, ar laiku sistēmas nav funkcionēt spējīgas. Tās jāveido no jauna un tāpēc ir vajadzīgas DBVS, kurām nav šādu ierobežojumu. Lielās datu bāzu vadības sistēmās (Oracle, DB2 un citas) visas šīs problēmas ir novērstas, lielāku uzmanību pievēršot arī datu aizsardzībai un drošumam. Oracle piedāvātā tehnoloģija sistēmu izstrādei spēj nodrošināt vieglāku un ātrāku sistēmu izstrādi, izmantojot grafiskos līdzekļus un ģeneratorus, kas aizvieto monotonu programmu rakstīšanu.

Tādēļ aizvien vairāk lielu datu bāzu vadības sistēmu izstrādātāji sāk izstrādāt savas sistēmas tieši Oracle, DB2 un citās vidēs, kas spēj nodrošināt labu produktu izstrādi un kas ir orientētas tieši uz lielām datu bāzēm.

Taču bieži vien ar labu sistēmas funkcionalitāti vien ir par maz. Lietotājs galvenokārt vienmēr īpašu uzmanību pievērš sistēmas interfeisam, cik veigli ir ar to strādāt un cik intuitīvi viņš var strādāt. Tas parasti tiek aizmirsts, izstrādājot lielas sistēmas, kā rezultātā lietotāji nav apmierināti un vienmēr uzskata, ka vecā sistēmas, kas piemēram bija veidota uz FoxPro bāzes, bija krietni labāka, kaut arī šad tad pazuda dati, sistēma uz lieliem datu apjomiem strādāja lēni, šad tad jāgaida uz kādu, kamēr tas pabeigs savu darbību ar datiem, lai tiem vispār varētu tikt klāt.

Bez tam, ja tirgū ir pieejami vairāki vienādas kvalitātes produkti produkti, klients vienmēr izvēlēsies to, kas ir vieglāk saprotams, apgūstams un kuru strādājot var gūt lielāku darba effektivitāti. Citiem vārdiem sakot, klients izvēlēsies to produktu, kam būs labāks lietotāja-datora interfeiss.

Taču, lai izveidotu labu lietotāja-datora interfeisu, vienmēr rodas zināmas problēmas. Palielinoties projektu apjomiem, parasti tos vairs nerisina viens cilvēks kā tas ir FoxPro un citu mazu DBVS gadījumā, bet gan 2, 3 un pat vairāk cilvēku. Tā kā katram cilvēkam ir sava gaumes un stila izjūta, katrs programmētājs veido savu lietotāja-datora interfeisu, tādu, kādu tas uztver par vairāk tīkamu. Bet lietotājs vēlas, lai projekta ietvaros visas datu ievadformas un citi datu logu būtu vienota stila. To parasti panāk, izstrādātājiem vienojoties par kopēju lietotāja-datora interfeisu. Tā kā Oracle CASE rīki atļauj ģenerēt formas no iepriekš aprakstītiem moduļiem, tad izstrādātāji vēlētos, lai visas ģenerētās formas, jau saturētu interfeisa standartu, par kuru izstrādes grupa ir vienojusies. To panāk aprakstot formu šablonus (template), kas tiek izmantoti ģenerācijas procesā kā arī sistēmas, atsevišķu moduļu un atsevišķu tabulu preferences (preference), kas tiek izmantotas ģenerācijas procesā.

Šajā darbā tiek aplūkots kā veidot vienotu lietotāja-datora interfeisu strādājot ar Oracle Forms Designer 4.5, produktu, kura visvājākā vieta, salīdzinot ar citām 4 paaudzes valodām (4GL), ir tieši lietotāja-datora interfeiss. Kā vienu no tā iemesliem varu minēt Oracle produktu pieejamību uz vairākām operētājsistēmu platformām, kā rezultātā visi Oracle produkti jebkurā operētājsistēmā izskatās vienādi. Tas panākts ieviešot savus standartus. Tas protams pārāk daudz neattiecas uz grafisko izpildījumu, bet gan terminoloģiju. Lietotājs nespēj strādāt intuitīvi, kā ar jebkuru citu jaunu produktu, jo tiek lietots daudz jaunu terminu. Lietotājs parasti pirmajā brīdī ir samulsis.

Bez tam tiek apkopoti vairāki raksti žurnālos un Internetā par tēmu kā labāk veidot savu aplikāciju lietotāja-datora interfeisu, strādājot ar Oracle formām MS Windows vidē.

Angliskie nosaukumi ir tulkoti izmantojot LZA terminoloģijas komisijas informātikas apakškomitejas apstiprinātos angļu terminu latviskojumus. Maz pazīstamiem un nezināmiem terminiem, kuriem iepriekšminētajā vārdnīcā nebija dots tulkojums, ir doti darba autora tulkojumi, iekavās dodot orģinālnosaukumu angliski.

1. Grafiskā lietotāja-datora interfeisa pamatprincipi

Labu grafisko lietotāja-datora interfeisu raksturo faktors, cik viegli lietotājs to apgūst un cik viegli to ir lietot. Runājot par lietošanu, vienmēr būs domstarpības, jo katrs cilvēks ir individualitāte un katram patīk kaut kas cits, kas nepatīk citiem. Labu lietotāja-datora interfeisu definē 3 pamatprincipi [7]:

1) Vienkāršība (Simplicity) - jo vienkāršāks ir sistēmas interfeiss, jo vieglāk lietotājs var iemācītes lietot sistēmu;

2) konsekvence, saskaņa (Consistency) - konsekvence raksturo sistēmas izmaiņas, cik viegli lietotājs varēs apgūt sistēmas jaunās komponentes. Lietotājs parasti vēlas, lai sistēmas jaunā komponente darbotos tāpat kā vecā, lai pārāk daudz laika nebūtu japavada apgūstot jaunās sistēmas interfeisa īpatnības;

3) efektivitāte (Efficiency) - jo mazāk soļu jāveic lietotājam, lai izpildītu kādu operāciju, jo lielāka ir sistēmas efektivitāte šo operāciju izpildei. Lai izveidotu efektīvu lietotāja-datora interfeisu izstrādātājam ir jāzin, kuras ir visbiežāk lietotās operācijas un kā tās tiks kombinētas.

Lietotāja-datora interfeiss neraksturo cik krāšņs un elementu bagāts būs datu ievades logs, bet gan izstrādātāja profesionālismu un radošo potenciālu. Pirmo divu pamatprincipu izveide prasa izstrādes grupai izveidot interfeisa standartus. Bez šādiem standartiem sistēmu interfeisa izstrāde būs haotiska (katra izstrādātāja stilam atbilstoša) un lietotājam grūti apgūstama. Trešā pamatprincipa izveide ir pati grūtākā. Tas ir atkarīgs no sistēmas biznesa modeļa. Tas jāveido sadarbībā ar lietotāju, jo sistēma tiek veidota, lai viņam palīdzētu.

Sīkāk par lietotāja-datora interfeisa uzlabošanu pēc šiem pamatprincipiem aprakstīts nākošajās trīs nodaļās.

2. Šablonformu izmantošana formu ģenerācijai

Kā jau tika minēts, lai nodrošinātu vienota lietotāja-datora interfeisa izveidi, atbilstoši izstrādājamā projekta vajadzībām, lietojot Oracle formu ģeneratoru (Oracle Forms Generator), tiek lietotas šablonformas (templates), kurās tiek aprakstīti visi kontroles bloki, rīku joslas, vizuālie objekti, to īpašības. Lai varētu izveidot šādu šablonformu ir jāsaprot, kā savā starpā saistās objekti šablonformā ar objektiem izstrādājamajā formā.

Designer/2000 lieto šablonformas, kurās ir visa nepieciešamā informācija ģenerētai formai - vizuālie atribūti, rīku josla, kontroles bloki un vienības, kas tiks ievietotas jebkurā ģenerētajā formā. Taču, ievietojot šablonformās daudz izpildāmo bloku, rodas problēmas, jo šie programmu kodi tiek ierakstīti visās sistēmas ģenerētajās formās. Ja kādas izmaiņas tiek izdarītas šablonformās, tad jāveic viens no sekojošiem uzdevumiem:

1) Jāpārģenerē visas iepriekš ģenerētās formas;

2) izmaiņas jāveic ar roku katrā noģenerētajā formā.

Lai izvairītos no šadām problēmām, tiek ieteikts pēc iespējas vairāk lietot atsauksmju formas (Reference form) un bibliotēkas (Libraries) šablonformu izstrādē [8]. Ja šablonformās vizuālie atribūti un datu vienības tiek veidotas kā atsauksmes uz citā formā aprakstītiem objektiem, un PL/SQL procedūras, paketes un funkcijas tiek saistītas ar bibliotēkām(tiek apkopotas bibliotēkās), tad ģenerētā forma pārmantos šīs atsauksmes un saistības. Tas atvieglos sistēmas izstrādi, kad vajadzēs labot vai papildināt šablonformu kodu, jo nebūs jāpārģenerē visas iepriekš veidotās formas.

1. attēls. Šablonformu, bibliotēku, atsauksmju formu

un noģenerēto formu saistība.

Piemēram, ja visa rīku josla (kanva (canvas), kontroles bloks un vienības) ir veidota kā atsauksme uz atsauksmju formu, tad papildus pogas var tikt pieliktas rīku joslai arī vēlāk, pēc formu ģenerācijas, nepārģenerējot šīs formas no jauna. Šīs papildus pogas tikai jāpievieno atsauksmu formai un jāpārraksta PL/SQL kods bibliotēkā, lai jaunā poga strādātu. Tālāk pārkompilējot visas ģenerētās formas, jaunā poga tiek iekļauta ģenerētajā formā.

Atsauksmju formā būtu jāiekļauj sekojoši objekti:

1) Visu lietoto kanvu informācija;

2) visi vizuālie atribūti;

3) visi kontroles bloki;

4) rīku joslas kanva un bloks (ieskaitot visas pogas, uz kurām atsauksme tiek veidota automātiski).

Sakarā ar to, ka uz formas līmeņa trigeriem nevar veidot atsauksmes tieši (jo Designer/2000 formu ģenerators pats pārraksta trigerus), visi PL/SQL kodi būtu jāievieto bibliotēkā, kas saistīta ar šablonformu [5]. Tāpēc formas līmeņa trigeriem vajadzētu izsaukt procedūras no bibliotēkas. Bez tam gadījumā, ja jāmaina kāda formas līmeņa trigera kods, to nākas izdarīt tikai vienā vietā - bibliotēkā, kurā aprakstīts trigera kods. Piemēram, ja šablonformā ir WHEN-NEW-FORM-INSTANCE trigeris, tam vajadzētu izskatīties šādi:

/* WHEN-NEW-FORM-INSTANCE */

BEGIN

WHEN_NEW_FORM_INSTANCE;

END;

Kur WHEN_NEW_FORM_INSTANCE ir procedūra no bibliotēkas. Ja ģenerators pārrakstīs kāda trigera kodu, tad jauno funkciju izsaukums tiks ierakstīts aiz šī koda, nebojājot izstrādātāja rakstīto kodu.

Šeit jāpiemin, ka veidojot atsauksmi uz objektu no citas formas, šo divu formu koordinātu sistēmas nesakrīt Oracle Forms Designer 4.5 neveic automātisku koordi-nātu maiņu. Par to jārūpējas izstrādātājam pašam.

Lai visās formās panāktu vienādu lietotāja-datora interfeisu, visiem tās objektiem jābūt vienādiem, t.i. vienādiem vizuāliem atribūtiem (fonts, fonta izmērs, krāsas, garums, platums u.t.t). Visvieglāk to var panākt veidojot vizuālos atribūtus (Visual attributes) un īpašību klases (Property classes) atsauksmju formā. Vizuālie atribūti ir fonts un tā īpašības (fonta vārds, izmērs, stils, platums, garums), kā arī objekta krāsas (priekšplāns, fons, aizkrāsošanas modelis). Piesaistot visiem vienāda tipa objektiem konkrētu vizuālo atribūtu, ir atvieglota šī tipa objektu vizuālās informācijas maiņa. Tā jādara tikai vienā vietā - tur kur tiek definēts vizuālais atribūts.

Katram objektam formās tiek piesaistīts vai nu noklusētais vizuālais atribūts (default), kas ir atkarīgs no attiecīgās platformas, kurā tiek ekspluatēta forma, vai arī definētais vizuālais atribūts (named). Ja objekta vizuālās īpašības tiek mainītas ar roku, tas iegūst lietotāja vizuālā atribūta (custom) statusu, kas nozīmē, ka lai izmainītu šāda objekta vizuālos attribūtus, tie jāmaina, katram konkrētam objektam, jo tie nav saistīti savā starpā ar kādu no definētiem atribūtiem.

Vizuālā atribūta vārds nosaka objektu, kuram tas tiks pievienots ģenerācijas procesa laikā. Piemēram, ikvienam teksta objektam piek piešķirts CG$ITEM vizuālā atribūta vārds, ja šis atribūts ir definēts šablonformā. Eksistē liels skaits šādu speciālo vizuālo atribūtu vārdu, kurus aprakstot var viegli veidot ģenerētās formas izskatu. Piemēram, CG$PUSH_BUTTON vizuālais atribūts nosaka jebkuras ģenerētās spiedpogas izskatu, CG$MANDATORY_ITEM - obligātā ievadlauka vizuālos atribūtus u.t.t. Visus šos vizuālo attribūtu vārdus var atrast Oracle palīdzības failā C:\ORAWIN95\DES2_60\HLP\CGEN45.hlp.

Savukārt īpašību klases ir spēcīgs līdzeklis, kas atļauj veidot vienotu lietotāja-datora interfeisu un funkcionalitātes standartus. Īpašību klase ir objekts, kas satur īpašību kopu, kas var tikt veidota pēc izstrādātāja vēlmes, un to vērtībām. Piemēram, var veidot atsevišķas īpašību klases ievadāmiem neobligātiem ievadlaukiem, ievadāmiem obligātiem ievadlaukiem un informācijas laukiem, spiedpogām, izvēles sarakstiem (LOV) u.t.t.

2. attēls. Īpašību klašu un vizuālo atribūtu definēšana šablonformā.

Šādu īpašības klašu skaits nav ierobežots un vienas klases īpašības var tikt piešķirtas dažādu tipu objektiem. Tas, pamatojoties uz iepriekš minēto, dod iespēju mainīt šo objektu definīcijas tikai vienā vietā, tādējādi mainot to visā izstrādājamajā aplikācijā veicot tikai vienu operāciju - formu pārkompilāciju. Visi vizuālie atribūti un īpašību klases, kas aprakstīti šablonformā, tiek iekļauti ģenerētajā formā, neatkarīgi no tā vai eksistē objekts, kas izmanto šo atribūtu vai īpašību klasi, vai nē. Tas dod iespēju jebkurā izstrādes procesa laikā veidot jaunus interfeisa objektus, tos aprakstot ar esošiem vizuāliem atribūtiem vai īpašību klasēm.

Ja darba laikā tiek izveidots jauns vizuālais objekts vai īpašību klase, tā jāpiesaista šablonformai, lai tā tiktu ieģenerēta visās jaunajās formās. Lai šie jaunie atribūti būtu arī jau ģenerētajās formās ir jāveido atsauce uz tiem no katras formas atsevišķi. Taču arī to var automatizēt, veidojot objektu grupas (Object groups), kurās pievieno jaunos vizuālos atribūtus. Tālāk veido atsauces jau uz objektu grupām.

Lai vieglāk būtu apkopot objektus, uz kuriem tiks veidotas atsauksmes, Oracle formās pastāv jēdziens objektu grupas (Object groups). Tas dod iespēju vienkopus apkopot vairāku tipu objektus (logus, blokus, kanvas, vizuālos attibūtus), kas paredzami kā atsauksmju objektu avots.

3. attēls. Objektu grupas.

Reāli veidojot objektu grupas, jauni objekti netiek veidoti, tiek veidota tikai atsauce uz šiem objektiem formas ietvaros. Veidojot objektu grupas jāievēro :

1) Ievietojot objektu grupā bloku, automātiski tiek ievietoti arī visi tā objekti (vienības, trigeri, relācijas), kaut arī tie objektu grupas kokā netiek rādīti;

2) programmu vienības (procedūras, funkcijas) nevar tikt iekļautas objektu grupās;

3) bloku objekti, vieni paši nevar tikt iekļauti objektu grupā, jo tie nevar pastāvēt neatkarīgi bez bloka;

4) objektu grupas objektiem jābūt definētiem tajā pašā formā, tie nevar būt no citas formas;

5) objektu grupa nevar saturēt objektu grupu;

6) dzēšot objektu tas automātiski tiek dzēsts no objektu grupas;

7) dzēšot objektu grupu, no formas moduļa netiek dzēsti paši objekti.

Tālāk aplūkosim kā apvienot programmu kodu, kas nepieciešams vairākās formās. Procedūras un funkcijas, kas tiek lietotas vairākkārt no dažādām formām ieteicams apvienot vienā vietā - bibliotēkās. Savukārt procedūras un funkcijas, kuru izsaukšana neprasa vizuālās informācijas parādīšanu, ietiecams izvietot datu bāzē (Stored procedures), tādējādi samazinot formas izmērus. Lai arī pārējās aplikācijas formās būtu pieejamas šīs procedūras atliek tikai piesaistīt attiecīgo bibliotēku.

4. attēls. Piesaistītās bibliotēkas.

Lai visas vajadzīgās bibliotēkas automātiski tiktu piesaistītas jebkurai ģenerētai fromai, šīs bibliotēkas tikai jāpiesaista konkrētai šablonformai, kas tiek izmantota ģenerācijas procesā. Jebkuras izmaiņas, kas tiek veiktas bibliotēkas procedurās vai funkcijās formās ir pieejamas uzreiz pēc to atvēršanas un pārkompilēšanas.

Ja jāpievieno jauna biblotēka, tā pirmkārt jāpievieno šablonformai, lai tā tiktu pievienota visām jaunajām formām. Formai drīkst pievienot neierobežotu skaitu bibliotēkas, pie kam tas nepalielina formas izmērus, jo bibliotēkas tiek glabātas atsevišķos *.pll failos, un netiek iekompilētas programmas kodā. Visām jau ģenerētajām formām bibliotēkas jāpiesaista ar roku, jo nav iespējams bibliotēku aprakstīt objektu grupās, kā tika minēts iepriekš. Bez tam pastāv iespēja piesaistīt bibliotēku bibliotēkai, ko varētu izmantot kā risinājumu. Piemēram, kādai no galvenajām bibliotēkām, kas ir visās formās piesaistam klāt jauno bibliotēku, kas pēc formu pārkompilēšanas būs visās formās.

Vislielākās problēmas veidojot šablonformas tomēr ir un paliek dokumentācijas trūkums. Oracle nenodrošina ar labu dokumentāciju (principā tās nav vispār) šablonformu veidošanai, ja neskaita dažus piemērus, kas doti Oracle palīdzībā (Help).

3. Preferences kā ģeneratora parametri

Ne visu var aprakstīt šablonformās. Izrādās, ka objektu, kas nav iekļauti kontrolblokos, un citu īpašības un reakcija uz lietotāja darbību, kā arī visi pārējie ģeneratora parametri, tiek aprakstītas ar preferencēm (preference), izmantojot preferenču pārlūkprogramu (preference navigator). Parasti tie ir datu bloki, kas tiek iekļauti formās no moduļa datu diagrammas, logi, ritjosla (scrollbar), un citi objekti.

Preferences ir parametri, kas kontrolē ģenerētās aplikācijas izskatu un uzvedību [2]. Preference var būt vai nu obligāta vai neobligāta. Obligātai preferencei vienmēr jābūt uzdotai vērtībai. Katrai preferencei eksistē noklusētā vērtība, kas tiek izmantota gadījumos, ja dotās preferences vērtība nav definēta.

Preferenču pārlūkprogramma ir grafisks rīks, kas atļauj mainīt preferenču vērtības, kuras izmanto ģeneratori ģenerācijas procesā, kas nosaka ģenerētās aplikācijas izskatu un uzvedību. Preferences var tikt piesaistītas pie konkrēta objekta (domeins, forma, modulis, aplikāciju sistēma) aplikāciju sistēmā.

3. attēls. Preferenču vērtību ievadīšana lietojot preferenču pārlūkprogrammu.

Ģenerācijas procesa laikā ģenerātors pārbauda, kuras preferences, kas iespaido ģenerēto aplikāciju, ja vispār kāda, ir uzstādīta. Ja vajadzīgā preference nav uzstādīta, ģenerātors lieto noklusēto.

Katra preferences vērtība var būt mantota (iedzimta), vai uzstādīta tikai konkrētam aplikācijas līmenim. Preferenču pārlūkprogramma nosaka šo preferences īpašību, to apzīmējot ar dažādām ikonām preferenču kokā, vai dažādām krāsām kopējā preferenču izvēlnē. Šī iespēja ļauj viegli kontrolēt, piemēram, konkrēta datu bloka vai moduļa uzvedību, vai tas būs tāds pats kā pārējos moduļos vai atsevišķs, konkrēts tikai šim modelim.

Kad tiek ģenerētas aplikācijas, attiecīgajam ģeneratoram ir jāzin, kuras preferenču vērtības ir uzstādītas. Ģenerācijas procesa laikā ģenerators pārlūko visu preferenču hierarhiju katrai preferencei, kas nepieciešama ģenerācijas procesā. Meklēšana notiek no zemākā aplikācijas līmeņa virzienā uz augstāko.

1. tabulā doti, manuprāt, svarīgāko preferenču (preference) apkopojums, kas nosaka ģenerētās formas izskatu un reakciju uz lietotāja darbību.

1. tabula. Svarīgākie formu ģeneratora parametri.

Kategorija	Parametra nosaukums	Apraksts	Iespējamās vērtības
END USER LEVEL	AUTOHP	Vai parādīt HINT lauka vērtību, kad lietotājs aktivizē ievadlauku	Y, N
	DELWRN	Vai brīdināt lietotāju, ka dzēšot rakstu tiek dzēsti arī raksti no citām tabulām (formas ietvaros)	Y, N
LAYOUT-BLOCK	BLKSBP	Bloka scrolbara atrašanās vieta	LEFT, RIGHT
	BLKVSB	Vai tiek ģenerēts bloka vertikālais scrolbars	Y, N
LAYOUT-TEXT ITEM	TXTBEV	Teksta vienību slīpums	None, Raised, Lowered
	TXTDDF	Teksta lauku noklusētais datuma formāta tips	Datuma formāts
	TXTDHT	Teksta lauku noklusētais augstums	1-9
	TXTDNF	Teksta lauku noklusētais skaitļu formāts	Skaitļu formāts
LAYOUT	WIN???	Visi šie parametri nosaka logu noklusētās īpašības
LIST OF VALUES	LOVBUT	Vai laukam, kam iespējams LOV blakus rādīt LOV pogu	Y, N
	LOVVAL	Vai pārbaudīt lauka vērtību LOV’ā	Y, N
TEMPLATE	STFFMB	Šablonformas vārds
GENERATE OPTIONS	VLDTFK	Kad pārbaudīt ārējās atslēgas korektumu	B, C, F, N
	VLDTPK	Kad pābaudīt primārās atslēgas korektumu	B, C. F, N

Vislielākās problēmas, aprakstot preferences, ir to apjoms, izmantotie saīsinājumi un ļoti mazais dokumentācijas apjoms. Lai saprastu katras preferences būtību no tās saīsinājuma, vai arī, lai atrastu kura preference apraksta konkrēto īpašību, vajadzīgs laiks. Visa palīdzības informācija pieejama tikai izmantojot Oracle palīdzību (Online Documentation) [3].

4. Padomi interfeisa uzlabošanai

Oracle Developer/2000 ir attīstījies daudzu gadu laikā, no simbolu bāzētas vides uz grafisko vidi, tomēr vēl joprojām patērējams daudz laika, lai izveidotu Oracle aplikāciju ar labu lietotāja-datora interfeisu.

Kā piemēru aplūkosim izvēlni. Oracle izvēlne pēc noklusēšanas satur: darbība (Action), bloks (Block), lauks (Field) u.t.t., bet MS Windows vidē noklusētā izvēlne ir fails (File), labot (Edit), skats (View). Veidojot aplikācijas Oracle vidē, to galvenā priekšrocība ir tā, ka tās var izpildīt arī citās platformās, tādās kā Macintosh, Motif u.c. Šis varētu būt iemesls kāpēc aizkavējās labu lietotāja-datora applikāciju izstrāde speciāli MS Windows videi, kurā strādā lielākā daļa datoru.

Lasot vairākus literatūras izdevumus un informācijas lappuses Internetā tika apkopoti un izanalizēti vajadzīgākie un labākie 12 padomi, kā labāk veidot profesionālākas, vieglāk lietojamas un intuitīvi saprotamas Oracle aplikācijas MS Windows videi, tādā veido laužot Oracle standarta aplikāciju iezīmi [1], [8]. Kā rāda pieredze, lietotājiem, kas strādā MS Windows vidē ir ļoti grūti pārslēgties uz Oracle piedāvāto stilu un terminoloģiju.

4.1. Rīku josla

Šodien jebkura grafikās vides aplikācija liekas nepilnīga, ja tajā nav rīku joslas. Parasti uz rīku joslas krāsainu spiedpogu veidā tiek attēloti visbiežāk lietoto funkciju izsaukumi. Bieži lietojamās funkcijas tiek attēlotas grafiski vieglākai informācijas uztverei un izpildei.

Visbiežāk lietojamās funkcijas Oracle formās, kuras vajadzētu ievietot rīku joslā ir - saglabāt (Commit or Save), nākošais ieraksts (Next record), iepriekšējais ieraksts (Previous record), attīrīt formu (Clear form), attīrīt rakstu (Clear record), beigt (Exit), meklēt (Enter Query), atlasīt rakstus (Execute Query) un citas atkarībā no uzdevuma.

4. attēls. Rīku josla.

Funkcijas, kuras var apvienot grupās arī rīku joslā vajadzētu attēlot grupās, tādējādi atdalot funkcijas pēc to nozīmes. Piemēram, vienā grupā likt funkcijas nākošais ieraksts (Next record), iepriekšējais ieraksts (Previous record), un otrā izveidot ierakstu (Create record), dzēst ierakstu (Delete record), attīrīt ierakstu (Clear record). Vienas grupas spiedpogas ir jānovieto blakus vienu otrai, bet grupas savstarpēji jāatdala ar 6-10 punktu tukšu joslu.

Bez tam daudz lietotāju vēlas rīku joslu atvērt atsevišķā logā, kuru var novietot jebkurā vietā pēc izvēlas. Arī to iespējams izveidot, nedaudz mainot programmas kodu, tikai ar vienu piebildi, ka rīku josla būs vai nu atsevišķā logā, vai pamatlogā zem izvēlnes. Lietotājs to nevar pārnest no viena stāvokļa uz otru kā tas iespējams MS Word vidē.

4.2. Rīku padomi (Tooltips) - spiedpogu nozīmju aprakstīšana

Rīku padomi (Tooltips) ir palīdzības teksts, kas apraksta spiedpogas nozīmi un parādās, kad pele kādu laiku nekustīgi tiek novietota virs spiedpogas. Kā zināms lielākā daļa MS Windows aplikāciju satur šos rīku padomus. Tas palīdz saprast spiedpogas nozīmi, ja tās ideju nevar uztvert pēc grafiskās interpretācijas.

5. attēls. Oracle standarta rīka padoms.

Oracle noklusētais rīka padoms tāpat kā visi citi interfeisa objekti, atšķiras no MS Windows standarta rīka padoma, skatīt 5. attēlu. Tam ir standarta izmērs, un tas vienmēr parādās blakus spiedpogai, tādējādi aizsedzot pārējās. Nedaudz pielabojot esošo programmkodu, vai arī izmantojot no Oracle corp. saņemto hint.dll failu, rīku padomu var pārveidot par MS Windows standartam līdzīgu kā parādīts 6. attēlā, kas neaizsedz citas spiedpogas un kuras izmērs ir atkarīgs no teksta garuma.

6. attēls. Rīka padoms, kas līdzīgs MS Windows standartam.

4.3. Standartizvēlnes

Izvēlne ir viena no galvenajām komponentēm aplikācijas interfeisā [6]. Diemžēl noklusētā Oracle Forms 4.5 izvēlne krasi atšķiras no pieņemtās MS Windows standarta izvēlnes. Tajā ietverti tādi termini kā darbība (Action), labot (Edit), bloks (Block), lauks (Field), ieraksts (Record), pieprasījums (Query). Tie ir datu bāzu vadības sistēmu pamatjēdzieni, taču to lietošana izvēlnēs samulsina lietotājus, jo tie ir pieraduši pie izvēlņu standartjēdzieniem - fails (File), labot (Edit) u.t.t. Bez tam diez vai lietotāju interesē programmas skaņošanas režīms (Debug).

7. attēls. Oracle standarta izvēlne.

Lai nerastos problēmas ar to lietošanu, vairāki autori neiesaka to lietot. Tā vietā izstrādātājam pašam vajadzētu izveidot izvēlni, kas līdzinātos standarta MS Windows izvēlnei. Tad arī lietotājiem neradīsies problēmas atrast to ko viņi meklē, jo tie intuitīvi zinās, zem kuras izvēlnes punkta atrodas viņu meklējamā funkcija.

Vispirms izvēlnei ir jādod iespēja piekļūt visiem sistēmas moduļiem. Var pastāvēt arī citi veidi un ceļi kā izsaukt kādu citu modeli, taču izvēlnei jābūt vispilnīgākajai. Izstrādājot izvēlni kā piemēru var aplūkot jebkuru MS Windows produkta izvēlni. Pirmajiem diviem izvēlnes punktiem no kreisās puses jābūt fails (File) un labot (Edit). Pēdējiem diviem jabūt logi (Windows), kam seko palīdzība (Help). Palīdzības izvēlnes parasti satur šādas standarta iespējas kā palīdzības izsaukšana, informāciju par aplikāciju un citas, skatīt 8. attēlu. Tas protams labi noder, kad runa iet par konkrētu datu ievades formu. Bet kā veidot izvēlnes galvenajai formai, kas izsauc citus moduļus, no kuriem tālāk tiek izsauktas datu ievades un redigēšanas formas? Tā laikam ir katra izstrādātāja un pasūtītāja gaumes un norunas lieta.

8. attēls. Sistēmas izvēlne, kas līdzīga MS Windows izvēlnei.

Izvēlnes var tikt veidotas, kā nemainīgas visas aplikācijas darbības gaitā, kā arī tādas, kas mainās atkarībā no konteksta. Iecienītākā pieeja šajā gadījumā ir lietot standarta nemainīgas izvēlnes, ar papildus iespēju aizliegt izvēlnes punktus, kad tie nav vajadzīgi, atkarībā no konteksta. Tādējādi lietotājs vienmēr zinās izvēlnes izkārtojumu, neatkarīgi no konteksta, kas otrajā gadījumā būtu daudz grūtāk, ja izvēlne mainās atkarībā no konteksta.

4.4. Ievadlauku krāsu nozīme

Strādājot ar datu bāžu vadības sistēmām, datu ievades formās ievadāmie raksti parasti satur obligātos laukus (not null, mandatory), laukus, kas var būt arī tukši (optional) un laukus, kas tiek izmantoti tikai informācijas rādīšanai (kur informāciju nedrīkst ievadīt vai mainīt). Tas palīdz lietotājam visuāli ātrāk atšķirt informatīvos laukus no laukiem, kuros dati ir jāievada. Daži autori iesaka katram no šiem trim tipiem lietot savu krāsu, taču kā rāda pieredze, pārāk krāsainas datu formas biedē lietotājus, jo tie apjūk šajā krāsu gammā. Bet ir lietas, ko vajadzētu izšķirt vienmēr - laukus datu ievadei un laukus informācijas pasniegšanai. Tāpat kā standarta MS Windows aplikācijās, arī Oracle formās būtu ieteicams informācijas laukus rādīt vienkārši kā tekstu vai kā pelēku ievadlauku, kurā nav iespējama informācijas maiņa.

9. attēls. Ievadlauku attēlošana, atkarībā no informācijas.

Taču neatšķirot obligātos (mandatory) laukus no neobligātiem (optional), lietotājs bieži vien, saglabājot datus, saņem kļūdas paziņojumu, ka laukā obligāti jāievada informācija (“field must be entered !”) vai lauks nevar tikt mainīts (“field is protect to update against !”). Vai šos laukus veidot atškirīgus vai nē pilnā mērā atkarīgs no izstrādātāja un lietotāja vienošanās.

4.5. Logu virsraksti

Strādājot ar Oracle Forms 4.5, to izpildāmais modulis (Oracle Forms Runtime) kā logu virsrakstu vienmēr lieto tekstu “Developer/2000 Forms Runtime for Windows 95/NT - [module]“.

10.attēls. Oracle Forms Runtime noklusētais logu virsraksts.

Jebkura professionāli izstrādāta aplikācija vienmēr satur savu nosaukumu, kas papildināts ar tekošā moduļa nosaukumu. Pamatlogs, kurā tiek startēta aplikācija, tiek saukts par FORMS_MDI_WINDOW. Šī loga parametri nevar tikt mainīti izstrādes laikā, tāpēc tie jāmaina programmātiski. Galvenās formas WHEN-NEW-FORM-INSTANCE trigerī ir jānomaina šī loga virsraksts lietojot komandu:

Set_Window_Property(Forms_MDI_Window, Title, “Mana

applikācija”);

11. attēls. Lietotāja definēts logu virsraksts.

Katrai formai aplikācijā, tās galvenā moduļa logam ir jāievada tā virsraksts, aprakstot to loga “Title” īpašībā. Tādējādi visas aplikācijas darbības laikā jūsu aplikācijas virsraksts būs - “Mana aplikācija [modulis]”.

Ja aplikācija satur vairākus moduļus (formas), tad katra moduļa nosaukums jāpievieno cieši klāt visas aplikācijas nosaukumam, izmantojot to pašu funkciju.

Šad tad ir ļoti vajadzīgi loga virsrakstā ievietot informāciju par aktīvo rakstu, bloku, piemēram, tāpāt kā MS Word attēlo tekoša dokumenta nosaukumu. To, tāpat kā iepriekš tika aprakstīts var mainīt tikai programmātiski aplikācijas darbības laikā.

Bez loga virsraksta maiņas vēl var mainīt katra loga ikonu, tādējādi arī grafiski raksturojot moduli, kuram pieder konkrētā forma. To var izdarīt jebkuram formas logam, gan formu dizainerī, gan programmātiski formas darbības laikā, izņemot pašu galveno logu - FORMS_MDI_WINDOW. Kāpēc Oracle nav devusi iespēju labot arī šo loga ikonu, nav saprotams, taču paliek cerība, ka tas būs realizēts nākošajā Oracle Forms 5.0.

4.6. Resursu pārbaude pirms aplikācijas palaišanas

Developer/2000 vide savai darbībai prasa ļoti daudz resursu, it sevišķi, ja formā tiek lietots daudz spiedpogu, izvēles sarakstu, izvēles rūtiņas (check box) un citi [4]. Iztērējot visus sistēmas resursus, Windows 3.1 vidē tika izraisīta atmiņas kļūda (GPF - General Protection Fault or “insufficient memory to run this application”). Šāda tipa kļūdas ir raksturīgas arī Windows95/NT vidē. Ja tiek izstrādātas ļoti liela apjoma aplikācijas, tad šāda tipa kļūdas var būt ļoti biežas, it sevišķi, ja lietotāja datoram ir maz resursu.

Viens no veidiem kā izvairīties no šāda tipa kļūdām, ielasot kārtējo formu, ir resursu pārbaude pirms formas ielādes. Ja tas ir zem minimālās robežas, tad izdod brīdinājuma signālu. Viena no Oracle Forms 4.5 demostrācijām dod piemēru kā noteikt brīvos resursus MS Windows 3.1 vidē. Lai to pašu veiktu MS Windows95 vidē, var izmantot to pašu algoritmu, tikai jāpārraksta *.DLL fails, lai varētu nolasīt sistēmas un atmiņas resursus MS Windows95 vidē.

Expermentāli tika pārbaudīts, ka uz datora ar pastāvīgu virtuālās atmiņas apgabalu, gadījumā ja atmiņas resursi ir zem 10% no iespējamā (runa ir tikai par atmiņu - brīvās atmiņas attiecība pret visu atmiņas apjomu), Oracle Forms Runtime 4.5 nestartējas, paziņot par atmiņas trūkumu dažādu bibliotēku ielādei. Tādējādi var uzskatīt, ka kritiskā robeža formas ielādei ir šie 10%.

Kā kritiskā robeža jaunas formas ielādei ekspermentāli tika noteiks - 1% no atmiņas resursiem.

Programmas koda piemēru, aplikācijas atvēršanai ar atmiņas resursu pārbaudi MS Windows95 videi, var aplūkot pielikumā, darba beigās.

4.7. Par - ātra informācija par jūsu aplikāciju

Kā viens no MS Windows aplikāciju interfeisa standartiem ir parādīt galveno informāciju par aplikāciju atsevišķā logā (About box).

Šādā logā attēlo vajadzīgo un nepieciešamo informāciju par jūsu aplikāciju. Piemēram, šādā logā var attēlot šādu informāciju par jūsu aplikāciju kā: aplikācijas nosaukums, tekošās versijas numurs, izlaišanas datums, kā arī lietotāja “login” vārds, tekošās formas nosaukums, Oracle datubāzes nosaukumu un pat sistēmas brīvo resursu apjoms. Tas var lieliski palīdzēt lietotājam aprakstīt sistēmas tekošo stāvokli, ziņojot par sistēmas kļūdām.

Kā arī, ja gribas izteikt atzinību projekta komandai, šeit ir īstā vieta kur ievietot viņu vārdus.

12. attēls. Par - ātra informācija par jūsu aplikāciju.

Lai izveidotu šādu formu Developer/2000 vidē, atliek tikai izveidot parastu formu, kurā pirms datu parādīšanas no datubāzes vai teksta faila, tiek nolasīta informācija par sistēmas versiju, izstrādes datumu u.t.t. Pārējo informāciju, kā lietotāju, sistēmas resursus un citus, var iegūt no sistēmas mainīgajiem, vai izmanojot ORA_FFI funkcijas kā tika minēts iepriekš.

4.8. Paroles maiņa

Laiku pa laikam sistēmas drošības nolūkos lietotājam ir jāmaina sava parole un visdraudzīgākais veids kā to veikt ir veidot savu formu ar labu interfeisu, jo Oracle Forms 4.5 to nepiedāvā kā standarta iespēju. Visparastākais un vienīgais veids kā to lietotājs var veikt ir izpildīt dažas komandas SQL*Plus vidē. Bet, tā kā lielākā daļa lietotāju nav pazīstami ar SQL*Plus (un vispār nezin kādam nolūkam tas paredzēts), ir vajadzīga vienkāršāka iespēja.

12. attēls. Paroles maiņa.

Lai nomainītu lietotāja paroli, ir jāizveido maza forma, kas pārprasa lietotāja veco paroli, lūdz ievadīt jauno paroli un pēc tam to nomaina. Lietotāja vārdu un tekošo paroli var uzzināt izmantojot Get_Application_Property funkciju [4]. Savukārt lai nomainītu lietotāja paroli ir jāizpilda sekojoša komanda:

Forms_DDL(‘ALTER USER ‘|| :block.name ||’ IDENTIFIED

BY ‘|| :block.new_password);

Ja paroles maiņa bijusi veiksmīga, tad tikai atliek aizvērt esošo savienojumu (disconnect) ar Oracle datu bāzi un atkal atjaunot savienojumu (reconnect), izmantojot komandas:

LOGOUT;

LOGON(:block.user, :block.new_password || ‘@’||

ConnectString, TRUE);

4.9. Progresa rādītājs

Salīdzinoši ar citām DBVS sistēmām, tādām kā MS Fox Pro, MS Access un citām, Oracle strādā salīdzinoši lēnāk vairāku iemeslu dēļ. Pirmkārt jau grafiskā interfeisa vide, kas salīdzinoši ar teksta vidi ir lēnāka. Otrkārt, nodrošinot lielu datu drošumu, tiek zaudēts daudz laika, kaut vai veicot visparastākās ierakstīšanas vai labošanas operācijas datu bāzē. Taču lietotājs parasti vērojot ilgus procesus, kas tiek īsi aprakstīti ar frāzi “Mazliet uzgaidiet…” vai “Working…” ir ne pārāk apmierināts, jo nezin, cik ilgi vēl mazliet būs jāgaida. Tāpēc gadījumos, kad operācijas ar datiem varētu ievilkties ilgāk par 20-30 sekundēm, būtu ieteicams lietot progresa rādītāju, kas parāda cik ātri noris process un cik ilgi tas vēl iespējams turpināsies.

13. attēls. Progresa rādītājs.

Oracle Forms to nepiedāvā kā daļu no sava interfeisa, bet to viegli var izveidot kā *.dll failu kādā citā programēšanas vidē (C++, Delphi). Piemēru kā to veikt, var aplūkot pielikumā, darba beigās.

4.10. Aplikācijas palaišana

Viens no parastākajiem veidiem kā startēt Developer/2000 aplikāciju ir izpildīt komandrindu, kas startē Oracle Runforms, kā parametru saņemot izpildāmās formas vārdu:

c:\orawin\bin\f45run.exe c:\mydir\myapp.fmx

Taču tas izskatītos daudz labāk, ja applikācija tiktu startēta, piemēram šādi:

c:\mydir\myapp.exe

Tādējādi tiks atvieglota sistēmas palaišanas problēma un konfigurēšana. Lielākais vairums liela apjoma aplikāciju, kas startējas zināmu laiku, izmanto pagaidu (Splash) ekrānus, kas tiek rādīti, kamēr ielādējas sistēma, parādot, ka notiek sistēmas ielāde. Tas ir labāk nekā skatīties kā deg diska aktivitātes lampiņa, un domāt vai notiek sistēmas ielāde, vai atmiņas pārnešana uz disku. Tam ir liela nozīme gadījumos, ja sistēma startējas ilgu laiku, kas ilgāks par 4-5 sekundēm, it sevišķi kā tas ir Developer/2000 gadījumā (Oracle Runform ielāde uz Pentium 133MHz datora ar 16Mb atmiņu aizņem 15-25s). Pagaidu (Splash) ekrāns var tikt iekļauts .exe failā, kas arī startē aplikāciju. Programmas piemēru var aplūkot pielikumā, darba beigās.

14. attēls. Pagaidu ekrāns programmas startēšanas laikā.

Tādu .exe moduli var izveidot, lietojot daudzus programmēšanas rīkus, kā C, Delphi, Visual Basic. Startējot programmu no šīs vides, tiek parādīts grafisks attēls, un pēc tam tiek ielādēta Oracle aplikācija izpildot sekojošu komandu rindu:

c:\orawin\bin\f45run.exe c:\mydir\myapp.fmx

Lai programma varētu izpildīties no jebkuras mašīnas, pirms Oracle aplikācijas startēšanas no sistēmas reģistrija jānolasa Oracle instalācijas katalogs, lai zinātu, kur atrodas formu startēšanas programma f45run.exe. Oracle instalācijas katalogs sistēmas reģistrijā atrodas zem atslēgas -

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\ORACLE_HOME

4.11. MS Windows palīdzības logi

Ja darbam ar aplikāciju nepieciešama labi organizēta palīdzība un visas applikācijas tiek izstrādātas MS Windows vidē, tad šeit it tikai viens veids kā to panākt - MS Help. MS Help ir lielisks līdzeklis sistēmas palīdzības aprakstīšanai, pie kam lietotājs papildus nav jāapmāca ar to rīkoties, kā tas ir gadījumā ar Oracle Book 2.2 (programma Oracle palīdzības failu lasīšanai), kas bez tam prasa laiku un datora resursus, lai to lietotu. Lai to veiktu, var izmantot jebkuru MS Windows palīdzības tekstu veidotāj-aplikāciju. Tās ir viegli lietojamas, kas ļauj ātri veidot palīdzības failus. Kad palīdzības faili ir gatavi, tos var integrēt Developer/2000 aplikāciju vidē.

No Oracle vides standarta palīdzību var izsaukt, izmantojot ORA_FFI (Oracle Foreign Function Interface) paketi [4], kas atļauj izsaukt standarta palīdzības funkcijas no Developer/2000 aplikāciju vides. Tādējādi iespējams izveidot kontekst-jūtīgu palīdzību jebkurai Oracle aplikācijai.

4.12. Nodaļlapas (Tabbed pages) - jauns interfeisa standarts

Nodaļu lapu (tabbed pages) interfeiss kļuva ļoti populārs tūlīt pēc MS Windows95 iznākšanas. Nodaļu lapas ir viegli saprotams veids informācijas grupēšanai un pasniegšanai aplikācijā. Šāda veida informācijas attēlošana, ļauj lietotājam viegli apskatīt visu informāciju aplikācijā.

Oracle Forms 4.5-ās nodaļlapas var izveidot lietojot vizuālos pamatelementus VBX (Visual Basic Control) [4]. Lai šādas lapas izveidotu Oracle Forms 4.5 vidē, ir nepieciešams uzrakstīt programmas kodu, taču kā informē Oracle corp., nodaļlapas kā interfeisa objekts būs iekļautas jaunajā Oracle Forms 5.0 versijā (Developer/2000 2.0).

Bez tam eksistē dažas nianses, ko daži autori iesaka ievērot, veidojot nodaļlapas. Katru nodaļu vajag nosaukt īsi, parasti vienā vārdā un tam ir jābūt saportamam, kā arī viennozīmīgi jāraksturo zem tā esošās lapas ideja. Bez tam, nav ieteicams veidot vairāk par 7 nodaļām vienlaikus, jo cilvēka vizuālās informācijas uztveres spējas ir ierobežotas.

Nobeigums

Tā kā Oracle formu veidošanas rīks vēl ir ļoti jauns, vēl nav pieejams pietiekoši daudz literatūras par dažādiem izstrādes aspektiem, nemaz nerunājot, ka literatūra latviešu valodā par Oracle nav pieejama vispār. Rakstot šo darbu, tika atklāts daudz vērtīgas informācijas, kas lasot grāmatas iepriekš, bija palaists garām, tieši apgūstamās informācijas lielā apjoma dēļ. Gūtās iemaņas jau ir palīdzējušas vieglāk un efektīvāk veidot Oracle formas un formu šablonformas, kas ietvertu visu nepieciešamos objektus turpmākai izstrādei. Ļoti liels ieguvums bija 2. nodaļā aprakstītā šablonformu izmantošana formu ģenerācijā. Arī līdz šim tika lietotas šablonformas, taču bez atsaucēm uz objektiem. Tas radīja lielu laika patēriņu sistēmas izstrādes gaitā, kad atklājās, ka vajadzīgs jauns objekts vai jālabo kāda vizuālā atribūta īpašības (visbiežāk krāsas), jo izrādās, ka citos datoros, ar citu izšķirtspēju un krāsu paleti, to nav iespējams redzēt. Nepieciešamo objektu aprakstīšana šablonformā, izmantojot atsauces, to minimizēja līdz minimumam, jo izmaiņas tagad bija jāveic tikai vienā vietā - formā no kuras tiek veidota objektu atsauce. 4. nodaļā aprakstītie piemēri novērš dažus Oracle formu lietotāja-datora interfeisa trūkumus. Daži no tiem tika apkopoti no rakstiem žurnālos un internetā, daži manis doti, kas kļuva aktuāli pēc sarunām ar lietotājiem vai vienkārši iedomājoties sevi lietotāja vietā.

Kā tika minēts darbā, jaunajā produkta versijā Forms 5.0 ir paredzami uzlabojumi un papildinājumi lietotāja-datora interfeisa jomā - vairāki jauni interfeisa objekti, kas tagad ir standarta interfeisa objekti MS Windows vidē.

Darbā ar piemēriem nav ilustrēti 4 nodaļas pēdējie divi punkti. Tas pamatojams ar to, ka vēl nav skaidrs, kā reāli tos realizēt praktiski, kaut gan to algoritmi jau ir zināmi. Ceru to izpētīt un prakstiski realizēt tuvākajā laikā.

Literatūra

1. Oracle Informant, March 1997, vol.2. #3, “Your Game Face - Tips for Developing a Quality User Interface” p. 8-13, An Informant Communications Group Publication 1997

2. Oracle Designer/2000 A Guide to Developer/2000 Generation, ORACLE 1995

3. Oracle Designer/2000 Online Documentation

4. Oracle Developer/2000 Forms 4.5 Reference Manual vol.1/ vol. 2, ORACLE 1994

5. Oracle Developer/2000 Forms 4.5 Advanced Techniques Manual, ORACLE 1994

6. Oracle Developer/2000 Forms 4.5 Getting Started Manual, ORACLE 1994

7. http://www.oracle.com

8. http://www.cco.net/~katkins/oratip

Pielikums

Programmu teksti

----------------------------

-- RĪKU JOSLAS DARBĪBAS --

----------------------------

/ PROCEDURE TOOLBAR_ACTIONS /

-- This procedure implements the toolbar functionality.

-- The logic reads the pressed button name and then calls

-- the appropriate function. If you want to change the

-- toolbar then make sure the if statement below has one

-- entry for each button.

----------------------------------------------

-- Standart from ORACLE FORMS GENERATOR

-- Modified by me, May 1997

----------------------------------------------

PROCEDURE TOOLBAR_ACTIONS IS

button_name varchar2(61);

button varchar2(31);

BEGIN

show_window(get_view_property(get_item_property(

name_in('SYSTEM.CURSOR_ITEM'), item_canvas), window_name));

button_name := name_in('SYSTEM.TRIGGER_ITEM');

button := substr(button_name, instr(button_name, '.')+1);

if (button = 'SAVE') then

do_key('COMMIT_FORM');

elsif (button = 'PRINT') then

do_key('PRINT');

elsif (button = 'CLEAR_FORM') then

do_key('CLEAR_FORM');

elsif (button = 'QUERY_FIND') then

if (name_in('SYSTEM.MODE') != 'ENTER-QUERY') then

do_key('ENTER_QUERY');

else

do_key('EXECUTE_QUERY');

end if;

ELSIF (button = 'INSERT_RECORD') THEN

do_key('CREATE_RECORD');

ELSIF (button = 'DELETE_RECORD') THEN

do_key('DELETE_RECORD');

ELSIF (button = 'CLEAR_RECORD') THEN

do_key('CLEAR_RECORD');

ELSIF (button = 'LIST') THEN

do_key('LIST_VALUES');

ELSIF (button = 'EDIT') THEN

do_key('EDIT_FIELD');

ELSIF (button = 'HELP') THEN

do_key('HELP');

ELSIF (button = 'OPNAME' ) THEN

-- Operators name who changed this record

get_operator_name ;

ELSIF (button = 'SWITCH' ) THEN

-- Change layout mode from BROWSE to RECORD

change_layout_mode ;

ELSIF (button = 'HISTORY' ) THEN

-- Record’s update history

Hist.History_Show ;

ELSIF (button = 'EXIT') THEN

do_key('EXIT_FORM');

END IF ;

END;

/PROCEDURE Change_Layout_Style/

PROCEDURE change_layout_mode IS

-- Blocks need always end '1' and '2'

-- blockname1 and blockname2

l_Block_Name VARCHAR2(30) := Name_In(':SYSTEM.CURRENT_BLOCK') ;

l_block_name_head VARCHAR2(30) := SUBSTR( RTRIM( l_Block_Name ), 1,

LENGTH( RTRIM( l_Block_Name ) ) - 1 );

l_block_name_tail VARCHAR2(1) := SUBSTR( RTRIM( l_Block_Name ),-1,1);

l_go_block_name VARCHAR2(30) ;

l_go_block BLOCK ;

BEGIN

-- Change to………

IF l_block_name_tail = '1' THEN

l_go_block_name := l_block_name_head || '2' ;

ELSE

l_go_block_name := l_block_name_head || '1' ;

END IF ;

-- Block’s ID

l_go_block := FIND_BLOCK( l_go_block_name ) ;

IF ID_NULL( l_go_block ) THEN

-- Block not found -> go to the same block

l_go_block_name := l_block_name_head ;

l_go_block := FIND_BLOCK( l_go_block_name ) ;

END IF ;

IF NOT ID_NULL( l_go_block )THEN

BEGIN

GO_BLOCK( l_go_block_name ) ;

EXCEPTION

WHEN OTHERS THEN

MESSAGE( 'Unable change layout :' ||

ERROR_TEXT ) ;

END ;

END IF ;

END;

----------------

-- TOOLTIPS --

----------------

-- Uses: Hint.pll -- From ORACLE Corp.

-- Shwhnt32.dll

/ PACKAGE HINT.pll /

PACKAGE HINT IS

PROCEDURE ShowButtonHelp( timedelay NUMBER := 500);

PROCEDURE ShowButtonHelpHandler;

PROCEDURE HideButtonHelp;

END HINT;

/ WHEN-TIMER-EXPIRED TRIGGER /

BEGIN

-- Shows tootip

hint.ShowButtonHelpHandler;

END;

/ WHEN-MOUSE-UP TRIGGER /

/ WHEN-MOUSE-LEAVE TRIGGER /

/ WHEN-MOUSE-DOWN TRIGGER /

/ WHEN-NEW-BLOCK-INSTANCE TRIGGER /

/ WHEN-WINDOW-CLOSED TRIGGER /

/ WHEN-WINDOW-ACTIVATED TRIGGER /

/ WHEN-WINDOW-DEACTIVATED TRIGGER /

BEGIN

-- Hides tootip

hint.HideButtonHelp;

END;

/ WHEN-MOUSE-ENTER TRIGGER /

BEGIN

-- Creates timer for tooltip

hint.ShowButtonHelp;

END;

-------------------------------------

-- IEVADLAUKU KRĀSU APRAKSTĪŠANA --

-------------------------------------

/ WHEN-NEW-FORM TRIGGER /

Set_Field_DSPL_Property(‘BLOCK_NAME’, ‘FIELD_NAME’, Property);

-- Property : 0 - DISABLED

1 - ENABLED, Optional

2 - ENABLED, Mandatory

/PROCEDURE Set_Field_DSPL_Property/

PROCEDURE Set_Field_DSPL_Property( block_name IN CHAR,

field_name IN CHAR,

value IN CHAR) IS

can_update VarChar2(10);

BEGIN

IF value = '0' Then

-- DISABLED Item