W niniejszym artykule przedstawię zagadnienie udostępnienia technologii MarcoBASE w Okienkach. Celowo używam tutaj polskiego słowa "Okienka". Termin "Windows" kojarzy się dzisiaj z marką handlową okienkowego systemu operacyjnego firmy Microsoft: MS-Windows - najpopularniejszego na świecie. Zapewne dlatego nie wszyscy zdają sobie sprawę, że systemów operacyjnych prowadzących dialog w okienkach jest więcej. Wystarczy wspomnieć chociażby OS/2 czy X-Windows w systemie operacyjnym Unix.

Warto nadmienić, że wysiłkiem wielu informatyków stworzono standard logiki konwersacji okienkowej, czyli tzw. Wspólnego Dostępu Użytkownika zwaną często skrótem angielskiego pochodzenia CUA (Common User Access).

Przeniesienie narzędzi programowych firmy MacroSoft na platformę MS-Windows jest szczególnym przypadkiem "wyglądania przez Okienka". Jest to tylko pierwszy krok. Dlatego firma MacroSoft zdecydowała się wybrać, jako docelową, metodę konwersacji CUA, zalecaną przez komitety standaryzacyjne producentom systemów operacyjnych, platform projektowych i wykonawczych oraz oprogramowania użytkowego. Metoda ta została opisana w publikacji System Application Architecture w woluminie "Common User Access - Advanced Interface Desing Guide" wydanej przez IBM (wydanie pierwsze, lipiec 1989, dokument nr SY0 328-300-R00-1089).

Podstawy CUA

Aby nieco przybliżyć podstawowe zasady Wspólnego Dostępu Użytkownika (CUA) zatrzymam się chwilę, by przedstawić zarys koncepcji. Nie jest moim zamiarem opowiadać, jak działają okienka. Chcę podkreślić, że system okienkowy jest niejako składem standardowych narzędzi i materiałów, z którymi trzeba umieć pstępować.

Gdybyśmy budowali dom, moglibyśmy je porównać do standardowych cegieł, futryn okien i drzwi, belek stropowych, betoniarek itp. Taki (lub podobny) zestaw jest niezbędny do budowy domu, lecz nie każdy potrafi sensowny dom zaprojektować i zbudować. Projektant (architekt, budowniczy) nie umieści okna w miejscu drzwi bo i wchodzić będzie niewygodnie i nie każdy gość domyśli się od razu, że tutaj wchodzi się przez okno. Budowniczy wie, co do czego służy i używa elementów zgodnie z przeznaczeniem. Dom buduje się przecież dla wygody mieszkańców, a nie projektantów.

W wypadku oprogramowania powyższe uwagi nie są już tak oczywiste. Na rynku oglądamy wiele "radosnej twórczości" domorosłych programistów. Ktoś, kto umie programować wydaje się tak mądry i wykształcony, że do głowy nam nie przychodzi porównywać go z murarzem. Tymczasem jest to często najwłaściwsze porównanie. A murarzowi niezbędny jest projekt architekta, za którym z kolei stoi jego wykształcenie, na które składają się lata badań i doświadczeń wielu pokoleń. Oni męczyli się po to, byśmy do domu wchodzili wygodnie przez drzwi.

Dobiegają końca czasy radosnej twórczości programistów tak, jak kiedyś skończyły się czasy kurnych chat. Dzisiaj programiście zaczyna już być potrzebny dobry projektant, za którym stać będzie doświadczenie wielu pokoleń użytkowników i informatyków.

Stąd potrzeba, która jak wiemy jest matką wynalazku, doprowadziła do powstania standardu CUA.

Zasady projektowania CUA

Oto dwie fundamentalne zasady projektowania zastosowań CUA:

* Koncepcyjny model konwersacji kształtowany przez użytkownika.

Użytkownicy decydują, jak zastosowanie ma działać. Interfejs użytkownika powinien odpowiadać modelowi koncepcyjnemu, poprzez wyjście naprzeciw oczekiwaniom użytkownika, co do czynności, które będzie potrzebował wykonywać.

* Użytkownicy mogą i powinni sterować dialogiem.

Należy pozwolić użytkownikom sterować dialogiem. Tradycyjne zastosowania, będąc w swojej naturze sekwencyjnymi nie spełniają tej zasady. Oddać użytkownikom sterowanie, oznacza umożliwić im wykonywanie dowolnych czynności w dowolnej kolejności, jaka jest im potrzebna, by wykonać swoje zadania.

Techniki tworzące i wzbogacające model koncepcyjny interfejsu użytkownika to: używanie metafor, interfejs sterowany przez użytkownika, spójny interfejs, unikanie trybów, przezroczystość interfejsu.

Używanie metafor

Metafory (przenośnie, analogie) łączą rzeczy bez nich niezależne. Pisarz używa metafor aby pomóc czytelnikowi stworzyć koncepcyjny model lub obraz przedmiotu. Ta sama zasada odnosi się do zastosowań. Używanie metafor jest metodą na kształtowanie modelu zastosowania zgodnego z koncepcjami użytkownika. Jeśli użyjemy przyjaznych metafor czerpanych ze świata rzeczywistego, użytkownik może opierać konwersację na posiadanej wiedzy o dotychczasowym środowisku swojej pracy. Metafory należy dobierać ostrożnie, upewniając się, że wychodzą one naprzeciw doświadczeniom użytkownika z pracy w świecie rzeczywistym. Często zastosowanie opiera się na jednej metaforze. Na przykład można odwzorować formularze, do których użytkownik przywykł podczas pracy na papierze.

Interfejs sterowany przez użytkownika

Innym sposobem tworzenia i wzbogacania modelu koncepcyjnego jest zaprojektowanie interfejsu sterowanego przez użytkownika. Najczęściej użytkownik sięga po komputer, by zautomatyzować swoją dotychczasową pracę. Dlatego ważnym etapem projektowania zastosowania jest zbadanie, coi jak użytkownik chce robić , a następnie udostępnić mu takie czynności, jakich będzie potrzebował.

Spójny interfejs

Zastosowanie powinno być spójne z otoczeniem sprzętowym i programowym, a także samo w sobie. Spójność ze sprzętem może polegać np. na wytłuszczeniu liter poleceń odpowiadających poszczególnym klawiszom klawiatury komputera. Spójność z otoczeniem programowym sprowadza się do używania komponentów dostarczanych przez system tak, by prezentowały się podobnie we wszystkich zastosowaniach. Aby zastosowanie było wewnętrznie spójne należy uzyskać:

* Spójność prezentacji: co użytkownik widzi.

Użytkownik zaprzyjaźnia się z komponentami interfejsu kiedy ich wygląd (a czasami i położenie) jest spójne. Na przykład tytuł okienka jest zawsze tak samo umieszczony czy przycisk zawsze tak samo wygląda.

* Spójność interakcji: jak użytkownik konwersuje z komponentami.

Po rozpoznaniu komponentów użytkownik zaprzyjaźnia się z technikami konwersacji z tymi obiektami, o ile metody konwersacji są spójne.

* Spójność kolejności przetwarzania: jak użytkownik i komputer komunikują się ze sobą.

CUA opiera komunikację między użytkownikiem a komputerem na kolejności przetwarzania: obiekt-czynność. Użytkownik wybiera obiekt (przy przetwarzaniu dokumentów takim obiektem jest często niezależne okienko zawierające dokument, taka technika okienkowa nazywana jest MDI - Multiple-Document Interface - interfejs wielodokumentowy) a następnie czynność, która ma być wykonana w stosunku do tego obiektu.

(Różnica między wybieraniem obiektów i czynności polega na tym, że po wyborze obiektu nic się nie zdarzy poza wizualnym potwierdzeniem wyboru, natomiast wybór czynności powoduje poza wizualnym potwierdzeniem jej natychmiastowe wykonanie). Użytkownik szybko zaprzyjaźni się z taką kolejnością przetwarzania, jeśli będziemy ją spójnie stosować. Szybko też przywyknie do sposobu reakcji komputera. Na przykład użytkownik wybiera obiekt w oknie i rozwija menu. Niedostępne czynności są oznaczone na szaro i użytkownik uczy się, które czynności może stosować do których obiektów. Jeżeli zastosowanie wykona czynność natychmiast po wybraniu obiektu, model koncepcyjny użytkownika zostanie naruszony.

* Spójność czynności: podobne czynności są implementowane w podobny sposób.

CUA określa czynności o specyficznym znaczeniu. (Na przykład CUA definiuje czynności File, Edit, View, Options i Help jako wspólne czynności ponieważ występują one w wielu zastosowaniach. Mówi także, że jeżeli występują one w konkretnym zastosowaniu powinny występować właśnie w tej kolejności. Definiuje także dla wielu wspólnych czynności standardowe okna dialogowe np. dla Open i Save as... w File). Spójność czynności jest takim językiem między użytkownikiem a komputerem polegającym na tym, że użytkownik może zrozumieć znaczenie i wynik czynności. Dla przykładu naciśnięcie guzika OK oznacza koniec pracy z konkretnym okienkiem i kontynuację pracy z zastosowaniem (aplikacją).

Unikanie trybów

Użytkownik jest w trybie, jeśli musi skasować pracę dotychczasową by zrobić coś innego lub gdy te same czynności dają różne wyniki w różnych sytuacjach. Tryby przymuszają użytkownika do koncentrowania się na sposobie pracy zastosowania, zamiast na zadaniu, które ma do wykonania. Tak więc tryby interferują z umożliwieniem użytkownikowi korzystania z jego modelu koncepcyjnego. Nie zawsze możliwe jest skonstruowanie zastosowania beztrybowego jakkolwiek tryby powinny być traktowane jako wyjątki ograniczane do niezbędnego minimum. Jeżeli użytkownik jest w trybie - powinno to być mu uwidocznione. Metoda zakończenia trybu powinna być łatwa do nauczania i zapamiętania. Oto niektóre typy trybów są zalecane przez CUA:

* Dialogi trybowe (Modal Dialogs). Czasami zastosowanie potrzebuje specyficznych informacji, jak np. nazwa pliku w którym użytkownik chce coś zapisać. Gdy wystąpi błąd, użytkownik może potrzebować wykonać jakieś czynności przed kontynuacją zadania. Wizualizacją dialogów trybowych jest barwna obwódka dookoła okna dialogowego. (Poza dialogami trybowymi, które wymagają aby użytkownik skończył dialog przed kontynuowaniem pracy używane są też dialogi beztrybowe (modeless), które funkcjonują równolegle z całym zastosowaniem jako niezależne okienka).

* Tryby przelotne. Użytkownik jest w trybie przelotnym (spring-loaded mode), kiedy ciągłe wykonywanie czynności utrzymuje go w tym trybie. Na przykład podczas przeciągania tekstu myszą z przyciśniętym guzikiem (drag) tryb wizualizowany jest podświetleniem tekstu.

* Tryby narzędziowe. W niektórych zastosowaniach (szczególnie graficznych) użytkownik może wybrać narzędzie (ołówek, pędzel). Kursor myszy zmienia wtedy kształt. Użytkownik jest w trybie (tego narzędzia), ale tym razem nie zakłóca to jego pracy gdyż zmieniony kształt kursora ciągle mu o tym przypomina.

Przezroczystość interfejsu

Użytkownik nie musi wiedzieć, jak działa zastosowanie wykonując jego zadanie tak, jak nie musi wiedzieć, jak działa silnik samochodu podczas jazdy. Celem projektowania interfejsu użytkownika jest uczynić interakcję z komputerem tak prostą i naturalną, jak to tylko będzie możliwe.

* Prostota interfejsu. Interfejs użytkownika powinien być na tyle prosty, by użytkownicy nie byli świadomi narzędzi i mechanizmów wykonujących zastosowanie. Aplikacje stają się coraz bardziej skomplikowane, toteż użytkownicy muszą mieć prosty interfejs by łatwiej nauczyć się nowych aplikacji. Dzisiejsze silniki samochodowe są na tyle skomplikowane, że wymagają komputerów pokładowych i wyrafinowanej elektroniki. Tymczasem interfejs kierowcy pozostał prosty: kierowca potrzebuje jedynie kierownicy oraz pedałów gazu i hamulca. Nie musi wiedzieć i rozumieć, co jest pod maską, nawet jeśli jest tego świadomy - ponieważ interfejs kierowcy jest ciągle prosty. Taką samą prostotę w stosunku do użytkownika powinny przewidywać zastosowania.

* Naturalność interfejsu. Interfejs powinien być na tyle intuicyjny by użytkownik mógł odgadywać czynności, które ma wykonać posługując się zdobytą wiedzą na temat pracy z komputerem. Tak więc zastosowanie powinno odzwierciedlać cele i zadania niezbędne do osiągnięcia tych celów ze świata rzeczywistego. Jedną z dróg uzyskania intuicyjnego interfejsu jest użycie (jak już wspominaliśmy) metafor.

Zezwolenie użytkownikowi na sterowanie dialogiem

Druga zasada projektowania mówi, że użytkownik chce i powinien sterować dialogiem. Dawniejsze projekty zastosowań ustawiały zastosowanie na pozycji sterowania dialogiem. Umieszczenie na tej pozycji użytkownika wymaga fundamentalnych zmian w metodzie projektowania zastosowań. Tutaj powinniśmy mieć spójne, zintegrowane powiązania między interfejsem użytkownika, zastosowaniem i użytkownikiem.

Użytkownik steruje dialogiem, gdy ma możliwość przełączania się z jednej czynności na drugą, łatwo zmieniając to w swojej pamięci oraz gdy ma możliwość zatrzymania czynności, której nie chce już kontynuować. Użytkownik powinien mieć możliwość odłożenia na później lub zarzucenia pracochłonnych czynności bez narażania wyników.

Techniki, które pozostawiają sterowanie dialogiem w rękach użytkownika to interfejs pamiętający, interfejs wizualny oraz bezpośrednie sprzężenie zwrotne.

Interfejs pamiętający

Interfejs użytkownika powinien pamiętać wykonywane czynności aby możliwe było odwrócenie biegu rzeczy. Użytkownik sterujący dialogiem powinien mieć możliwość eksploracji bez ryzyka popełnienia nieodwracalnej pomyłki. W nauce poprzez badania zakłada się próbowanie i błądzenie, więc użytkownik powinien mieć możliwość odtworzenia (wycofania) ostatniej czynności. Czynności niszczące (mogące powodować niespodziewaną utratę informacji) wymagają zatwierdzenia. Użytkownik czuje się pewniej z komputerem, kiedy jego pomyłki nie powodują poważnych, nieodwracalnych rezultatów.

Interfejs wizualny

Interfejs powinien być wysoce wizualny aby użytkownik mógł widzieć (a nie przywoływać) to, co zrobił. Zarówno prezentacja komponentów interfejsu, jak i interakcja z tymi komponentami powinna być wizualizowana. Tam, gdzie jest to możliwe, należy dać użytkownikowi szanse wyboru z listy zamiast oczekiwać, że będzie pamiętał prawidłowe odpowiedzi. Komponenty dostarczane poprzez systemy okienkowe spełniają zwykle to wymaganie.

Bezpośrednie sprzężenie zwrotne

Zawsze należy zapewnić interakcji użytkownika sprzężenie zwrotne. Użytkownik po każdym naciśnięciu klawisza lub wybraniu czynności powinien natychmiast odebrać wizualne lub dźwiękowe sprzężenie zwrotne. Podczas wyboru (np. menu) możliwość dokonania takowego jest natychmiast wizualizowana jakimś wyróżnieniem (kolorem, podświetleniem itp.).

Wybieramy CUA, dlaczego?

Konwersacja użytkownika z okienkami rozłożonymi na ekranie, jak żywe dokumenty na pulpicie stołu zdobyła sobie uznanie na całym świecie. Można szukać przyczyn, które to spowodowały, ale fakty są faktami. CUA jest więc najlepszym wyborem, gdyż prawie wszyscy go chcą.

Skoro tak wielu używa CUA - cenną jego właściwością jest to, że użytkownicy albo już są do niego przyzwyczajeni, albo chętniej niż do jakiegokolwiek innego sposobu konwersacji się przyzwyczajają. Tak więc do obsługi programu realizującego CUA nie trzeba specjalnie szkolić użytkownika. Chętniej też zakupi on program konwersujący w tym standardzie, by nie ponosić kosztów szkolenia.

Trzeba też wspomnieć o starannym opracowaniu standardu CUA. Pracowało nad nim wielu fachowców informatyków, psychologów, socjologów, grafików... aby interfejs był dalece sprawny, intuicyjny, ergonomiczny i ładny.

CUA jest już dzisiaj paradygmatem. Funkcjonuje podobnie jak pedały w samochodzie. Żadnemu z producentów nie przyjdzie do głowy wypuścić samochodu, w którym hamulec będzie pod lewą nogą, gaz pod lewą ręką, a sprzęgło pod przyciskiem na tablicy rozdzielczej.

Czy CUA to znaczy MS-Windows?

Wielu nie odróżnia CUA od Windows. Często używanym hasłem marketingowym jest okrzyk: "Program jakiś tam dla Windows!" Niestety, wiele programów, szczególnie robionych w Polsce, ma z CUA niewiele wspólnego chociaż są "dla Windows". Jest taki program, mocno reklamowy (i sprzedawany!?), który rozpoczyna swoją pracę wyświetlając trybowe okno dialogowe. Z tego okna za pomocą przycisków wybierany jest dział firmy, który program ma obsługiwać. Gdyby takie użycie okna dialogowego pokazać autorom CUA, zdziwiliby się niepomiernie. Autorzy programu widać nie mieli zielonego pojęcia o przeznaczeniu okna dialogowego. Można powiedzieć, że użyli pedału sprzęgła do otwierania bagażnika.

MS-Windows jest jednym z systemów oferujących użytkownikom gotowe elementy CUA, a projektantom narzędzia do ich wykorzystania. Narzędzia te zwane Interfejsem Programisty Aplikacyjnego, w skrócie API (Application Programmers Interface) realizują tzw. Wspólny Interfejs Pogramowania, w skrócie CPI (Common Programming Interface). Są to jednak tylko elementy, z których murarz ma zbudować dom. MS-Windows nie zabrania (i nie może zabronić) robienia fundamentów z dachówek a stropu z eternitu. Aby zbudować dom nie wystarczy pracować kielnią. Trzeba mieć jakieś pojęcie o przeznaczeniu elementów i o techologii budowy.

Czy CUA to wszystko?

Oczywiście, że nie! CUA to tylko pewne podstawowe zasady i elementy konwersacji. Świat idzie do przodu i niektóre apetyty nie są przez ten standart zaspokajane wprost. Przykładem może być dialog z arkuszem kalkulacyjnym, który odbywać się musi na płaszczyźnie okienka, gdyż wybieranie z niego elementów do dialogu w oddzielnym okienku zaciemnia obraz. Niemniej zadaniem projektanta jest tutaj jedynie dopracowanie mechanizmu nawigacji. Kiedy zadanie staje się popularnym, producenci mający w swoich rękach znaczną część rynku narzucają standardy metodą de facto. W grę jednak wchodzą jedynie doprecyzowania i jeżeli projektanci szukają rozwiązań "w duchu" CUA, są one zwykle bardzo podobne i szybko stają się identyczne.

Czy MS-Windows oferuje kompletne CUA?

Też niekoniecznie. Standard definiuje głównie zasady projektowania interfejsu z użytkownikiem. Mechanizmy nawigowania okienkami są już własnością platformy systemowej. Wiadomo np., że okienko powinno być wyposażone w mechanizm zmniejszania go do ikony i że w zasadzie funkcję tę powinien spełniać w okienku specjalny przycisk w prawym górnym rogu. Jednak niektóre systemy wykonują to inaczej (ale potrafią to wykonać).

Innym przykładem może być tzw. MDI (Multiple Document Interface) realizujący zasadę grupowania informacji powiązanych ze sobą. W MS-Windows jest on zrealizowany poprzez umieszczenie wielu dokumentów aplikacji (i ich ikon) w jednym okienku wspólnym (takie mini-biurko). Niestety mechanizm ten daje się zastosować tylko do prostych zadań. Aby w zgodzie z tą zasadą zrealizować poważną wielodokumentową aplikację, należy oprogramować jej mechanizm "na piechotę" korzystając nierzadko z nieudokumentowanych funkcji systemu.

Niemniej CUA zrealizowano w MS-Windows w stopniu prawie dostatecznym a i wyboru za bardzo nie ma. Na co dzień musimy się z MS-Windows pogodzić.

Skala problemu przejścia

Tytuł tego rozdziału jest nieprzypadkowy. Scala to z łaciny schody. Jeżeli z klasycznego przykładu strukturalnego pisanego np. dla DOS-u przechodzimy na CUA, to szybko dostrzegamy, że "zaczęły się schody". Jakie więc są różnice między tymi podejściami?

Podejście klasyczne

W tym podejściu sterowanie jest przez cały czas "w rękach" programu poczynając od punktu wejścia (zawsze jednego, np. main) do zakończenia lub przerwania. W tym czasie program decyduje, jakich wyborów może użytkownik dokonać i program oczekuje na czynność użytkownika np. w funkcji systemowej oczekiwania na naciśnięcie klawisza. Nie jest istotne, jak to oczekiwanie realizuje system operacyjny. Może on wchodzić w pętlę badającą stan klawiatury (DOS) lub usypiać zadanie w oczekiwaniu na sygnał (Unix). Ale to program decyduje, kiedy czekać na klawisz i w jaki sposób, a kiedy wykonywać inne operacje. W szczególności takie oczekiwania mogą być rozproszone po kodzie programu.

Programowanie jest wtedy łatwiejsze. Programista, gdy chce dialogować z użytkownikiem, woła funkcję wybierz z menu i czeka na wynik. Gdy jest czas na reakcję danej, pobiera znak po znaku i wędruje po polu "pętląc się" w zupełnie innym miejscu. Użytkownik jest prowadzony przez obsługę programu "za rączkę" i jak mu programista da szansę wycofać się z rozpoczętej czynności, to dobrze a jeśli nie, to też musi być dobrze. Użytkownik jest w gruncie rzeczy na usługach programu.

Projekt i program jest tutaj ciągły i spójny. Programujemy więc strukturalnie.

Podejście CUA

Tutaj użytkownik jest szefem, który wydaje programowi różne polecenia w ustalonej przez niego kolejności, a program ma za zadanie jak najszybciej wykonać polecenie i być "na rozkazy". Użytkownik bywa "kapryśny" i może chcieć się wycofać lub przez chwilę "porozmawiać" z innym programem. Na dodatek dialog może odbywać się na przemian różnymi urządzeniami wejściowymi, jak mysz, pióro czy klawiatura.

Jeżeli w jakimś momencie program potrzebuje uzupełnić swoją wiedzę o oczekiwaniach użytkownika co do sposobu wykonania polecenia, to jawnie i na krótko zmienia tryb dialogu (wyświetlając tzw. Trybowe Okno Dialogowe). Użytkownik musi mieć możliwość przeprowadzenia dialogu lub wycofania się z niego.

Jeżeli zlecona przez niego czynność ma być dłuższa lub urozmaicona, to program monitoruje ją w oddzielnym oknie nie zmieniając trybu wydawania poleceń (dialog beztrybowy - modeless). Wtedy użytkownik nie związany na siłę ze specyficznym trybem dialogu może wybierać, z którym elementem "rozmawia".

Wszystkie działania użytkownika są uwidaczniane na ekranie w taki sposób, że użytkownik wie gdzie jest i co robi (przynajmniej może i powinien wiedzieć, chociaż nigdy tego do końca nie wiadomo).

Typowe elementy dialogu, jak redakcja danej czy wybór z listy są ustandaryzowane i we wszystkich miejscach programu wyglądają oraz działają podobnie. Wspólne czynności użytkownik powinien zawsze znaleźć w tym samym miejscu (File, Edit) i powinny one działać podobnie, jak w innych programach.

Krótko mówiąc program jest tutaj na usługi użytkownika. Program ma więc nie jeden, lecz wiele punktów wejścia i nigdy nie powinien czekać aktywnie na jakiekolwiek zdarzenie.

Takie programowanie zwiemy zdarzeniowym (event driven). Poszczególne usługi są jakby żyjącymi swoim życiem i współpracującymi ze sobą miniprogramami, toteż jedynym sensownym podejściem jest programowanie obiektowe. Projekt i program jest tutaj rozproszony. Programujemy zdarzeniowo i obiektowo.

Podsumowanie

Trudno w tak krótkim materiale przedstawić całość koncepcji przeniesienia oprogramowania firmy MacroSoft na platformy CUA. Można jedynie opowiedzieć o tym w telegraficznym skrócie i mieć nadzieję, że podstawowe elementy koncepcji przejścia przedstawiono w miarę jasno.

Na koniec dodajmy, że moduł dialogowy zrealizowany w rozszerzonym modelu MDI jest już przygotowany do testów międzymodułowych, a przewidywany termin oddania do testów międzymodułowych modułu drukującego, to koniec października 1994. Tak więc, wersji MacroBASE dla Windows można oczekiwać już w pierwszych miesiącach roku 1995.

Konwersja MacroSoftu do CUA

Firma MacroSoft zdecydowała się obecnie na zmianę konstrkcji warstwy dialogowej i podporządkowanie jej reszcie oprogramowania. Większość zagadnień dało się rozwiązać bez naruszania zasad opisywania zastosowania. Niektórych jednak zagadnień nie można było rozwiązać bez zmian definicji elementów systemu pomocniczego MacroGEN. Oto podstawowe z nich.

Menu z inicjatywy pogramu

Pozostałością po projektach DOS-owych była funkcja języka FORMULA SelectFromMenu. W języku FORMULA+, który rozszerzony o elementy obiektowości jest następcą języka FORMULA taka funkcja nie ma racji bytu, gdyż CUA nie dopuszcza możliwości zmuszania użytkownika do wybierania czynności z pewnego lokalnego menu. Problem rozwiązano następująco:

* tam, gdzie funkcji tej używano w zastosowaniach do wyboru opcji, udostępnia się funkcję SelectFromList otwierając trybowe okno dialogowe z jednym elementem listowym

* natomiast tam, gdzie używano tej funkcji do wyboru czynności (a miejsc tych jest niewiele) zastąpiono ją dwiema innymi: ConnecToMenu i DisconnectFromMenu. Autor zastosowania będzie więc mógł dynamicznie podłączyć swoje menu do menu okna, a potem je odłączyć.

Zaznaczenie rekordu do kopiowania itp.

Operacja ta realizowana będzie z użyciem tzw. Clipboardu i dobrze określonych przez CUA mechanizmów posługiwania się nim. Wszystkie operacje redakcyjne, jak Copy, Cut czy Paste zostaną udostępnione w menu pod pozycją Edit.

Dynamiczne okna dialogowe

Wypracowane mechanizmy okien dialogowych wymagały ingerencji programu w ich treść lub chwilowe opuszczenie dialogu. Sprowadzało się to do pozostawiania okna na ekranie na czas przeprowadzenia akcji, by później doń powracać bez zbędnych błysków ekranu powodowanego ich zwijaniem i rozwijaniem. Takie okna dialogowe zrealizowano w logice CUA jako beztrybowe.

Wydruki

Tutaj problem jest poważniejszy, gdyż CUA preferuje rzetelną wizualizację danych drukowanych w trybie graficznym. Dotychczas składem strony wydruku zajmował się interpretator języka Report, przy czym zakładał, że urządzeniem drukującym jest znakowa drukarka wierszowa. Aby możliwa była sensowna praca w trybie graficznym z elementami składu drukarskiego, pismem proporcjonalnym, przyjęto następujące założenia projektowe:

* Dla zgodności z istniejącymi definicjami sprawozdań zdecydowano wydzielić funkcje składu strony z interpretatora języka Report i przenieść je do modułu drukującego, któremu rozkazy zmiany kroju czy wielkości pisma, a także definicje pagin będą przekazywane na bieżąco wraz ze strumieniem danych do złożenia. Natomiast moduł drukujący będzie dokonywał składu strony.

Niesie to ze sobą pewne ograniczenia, gdyż definicja pagin będzie musiała być interpretowana w momencie napotkania jej w definicji, a nie w momencie umieszczenia jej na stronie. Jeżeli jakaś pagina ma być żywa (np. numer strony), to będzie musiała być deklarowana ponownie za każdym razem, gdy jej treść ulega zmianie. Dotychczas można było opisać paginę raz w języku Report, a iterpretator umieszczając ją na stronie interpretował każdorazowo jej algorytm. Moduł drukujący nie będzie mógł dokonać interpretowania, gdyż dostawać ma jedynie strumień tekstu do składu.

* Dla platform CUA dysponujących grafiką utworzy się moduł drukujący realizujący skład pismami dostępnymi w systemie, przy czym pozycje umieszczanych na wydruku pól będą ustalane w przeliczeniu pozycji znaku nieproporcjonalnego, na układ współrzędnych strony, poprzez współczynnik tzw. średniej szerokości znaku. Jeżeli więc użytkownik zdecyduje się drukować pismem nieproporcjonalnym, to wszystko będzie po staremu. Jeżeli jednak wybierze pismo proporcjonalne, zostanie zachowane jedynie położenie kolumn i ich dosunięcie.

* W jednej z kolejnych wersji zostanie przygotowany alternatywny moduł drukujący, który będzie akceptował strumień tekstu w formacie RTF (Rich Text Format). Dzięki temu definicje będzie można przygotować w dowolnym procesorze tekstu z wykorzystaniem jego możliwości składania akapitów, tabel itp. Interpretator języka Report będzie podłączał wtedy moduł drukujący odpowiedni do formatu, w którym została przygotowana definicja sprawozdania. Dla definicji przygotowanych w formacie RTF będzie można posługiwać się całym bogactwem środków prezentacji graficznej, którymi dysponuje platforma wykonawcza.

Kiedy z zachwytem się nadmienia

w pismach Warszawy, Kielc czy Łodzi

o wierszu, że zmusza do myślenia!

o filmie, że zmusza do myślenia!

o sztuce, że zmusza do myślenia!

znaczy: nikt nie wie, o co chodzi.

"Wyznania Humorysty"

Marian Załucki

Wtedy, przepraszam, wciągam kalosze

odchodzę, przymusu nie znoszę!

Tę bowiem myśl wyznając oto

jużem i wzrósł i podtatusiał:

autor ma męczyć się tak długo

żeby czytelnik już nie musiał!

"Wyznania Humorysty"

Marian Załucki

O, najzawilsze z przeżyć!

Klawisz, którego nie ma

odnaleźć i weń uderzyć

zabłysnąć, kiedy trzeba

gromem z jasnego nieba

i zapuściwszy się w nagie pustkowie

skarb odkryć w pustce tej...

w głowie...

"Wyznania Humorysty"

Marian Załucki

Niewielka pociecha

że gdzieś tam jeden krytyk się uśmiecha...

Uśmiechnięty krytyk, to złudne nadzieje.

On cieszy się, że nikt się nie śmieje!

"Wyznania Humorysty"

Marian Załucki

Natchnienie! Oczywiście natchnienie!

Kiedy mam natchnienie, wzruszam się szalenie.

Gdy mam chwilę natchnienia

chłonę niebo i ciszę...

A jak nie mam?... to trudno.

Wtedy siadam i piszę!

"Wyznania Humorysty"

Marian Załucki