Pytanie :
PS: W jakim języku pisałeś kompilator itd.
oraz może dodasz nowy typ danych np. coś podobnego do enum ...
1.Istnieje else:
if (warunek)
{
instrukcje;
} else
{
inne instrukcje;
}
lub
if (warunek)
instrukcja; else
inna_instrukcja;
2.Chodzi Ci o short-circuit evaluation - póki co nie jest zaimplementowane, lecz jest w planach (najpewniej będzie już w RC1).
3.Kompilator, maszyna wirtualna oraz edytor napisane są w Lazarusie - tj.Object Pascal.
4.Myślałem nad enumami - być może też będą w RC1.
Moim zdaniem na pewno przyda się else if
Mam kolejne pytanie odnośnie języka ;)
Jestem na etapie przed-implementowania enum-ów (typów enumerycznych/jakkolwiek) i nie jestem w stanie zdecydować się na konkretną składnię; mam dwie idee:
1.type<enum> nazwa_enuma = {costam1, costam2, costam3};
oraz coś pokroju C++:
2.enum<nazwa_enuma> {costam1, costam2, costam3};
Przy czym pomijając taki wariant: enum nazwa_enuma { costam1, costam2, costam3 }; - który z tych dwóch powyżej jest najlepsze (czytelność, etc., etc.); ew.jak mogłoby zostać to inaczej napisane?
C++:
enum nazwa { cos-tam, cos-tam2 };
http://msdn.microsoft.com/en-us/library/2dzy4k6e%28v=vs.71%29.aspx
Pascal:
type nazwa = (cos-tam, cos-tam2);
http://www.freepascal.org/docs-html/ref/refsu5.html#dx27-29001
Obie wersje w tej postaci są równie czytelne.
Wersja C++ odrobinę łatwiejsza do parsowania.
Zarówno C++ i Pascal umożliwia (jak wiesz lub nie) podawanie wartości integer dla poszczególnych cos-tam.
Typ zwykły enum (nie-class) w C++ jest kompatybilny z integer.
W Pascal trochę bardziej elegancko - też kompatybilny, ale wymaga Ord.
Ok, czyli type<enum> nazwa_enuma = { ... }; będzie dobrym wyborem pod względem czytelności składni (ew.trudności implementacyjne nie mają większego znaczenia), tak? ;>
+oczywiście podawanie poszczególnych wartości dla każdego enuma standardowo: type<enum> asdf = { a=1, b=512, c, d, e=-3 }; [c=513, d=514]
Typ zwykły enum (nie-class) w C++ jest kompatybilny z integer.
U mnie planuję zrobić podobnie - de facto te typy i tak będą internalsowo zwykłymi int-ami, więc nie widzę przeciwieństw w bezpośrednim przypisywaniu do siebie takich wartości ;P
Patryk27 napisał(a):
Ok, czyli
type<enum> nazwa_enuma = { ... };będzie dobrym wyborem pod względem czytelności składni (ew.trudności implementacyjne nie mają większego znaczenia), tak? ;>
Tak, nie widzę z tym problemu.
Inne typy też definiujesz z tym szablonem?
type<cos> nazwa...
?
Tak - np.: type<int[]> int_2d; bądź type<function<void>()> func_ptr; (Pascalowe: type func_ptr = procedure;)
Kolejna wersja ;)
Kompilator - 2.2.1
VM-ka - 0.3.1
Edytor - 0.3.1
Pełny changelog jak zwykle: http://sscriptwiki.xorg.pl/wiki/Changelog
Jedynie z ważniejszych zmian:
short-circuit evaluation
var (przekazywanie przez referencję): function<void> foo(var int x) (C++owy odpowiednik czegoś w stylu: int modify_param(int& ref))function<void> foo(int x, int y = 100) (tyczy się to również deklaracji typu funkcyjnego: type<function<void>(int, int=100))--remove-unreachable (póki co ma mało możliwości, ponieważ działa jedynie w ifach, lecz planuję to znacznie bardziej rozwinąć).Staram się jak najwięcej ze składni itp. opisywać na Wiki - prosiłbym również o ocenę tamtych artykułów* ;>
* tak, tak - darmowy serwer, reklamy, czasami nie wczytuje nawet strony, bywa ;C
- dodanie konwencji przekazywania parametrów var: function<void> foo(var int x) (C++owy odpowiednik czegoś w stylu: int modify_param(int& ref)), czyli że funkcja może modyfikować zmienną podaną w parametrze
Nie wiesz, że "takie coś" nazywa się przekazywaniem zmiennych przez referencję?
Nie wiesz, że "takie coś" nazywa się przekazywaniem zmiennych przez referencję?
Od rana dopieszczam całość i jestem padnięty, przez co wyleciało mi z głowy jak to się nazywało, dzięki za sprostowanie ;)
Zgodnie z radą @Coldpeera zmieniłem serwer SScript Wiki, od dzisiaj jest to: http://sscript.4programmers.net/ (bądź precyzyjniej: http://sscript.4programmers.net/wiki/ - jakby htaccess nawalił ;P)
Bez reklam, niepotrzebnych zacięć i wszystkich innych uprzykrzających życie rzeczy ;)
Jeszcze nie wszystkie artykuły są napisane, lecz te najważniejsze już są (pozostało parę opisów funkcji do napisania).
Podziękowania dla @Rev za udostępnienie serwera, Monkowi za domenę oraz paru innym osobom, które pomogły ;>
Da się wreszcie embedować ten język? Jakieś API C?
Jeśli nie, to jest generalnie mało użyteczny.
Jestem w trakcie przepisywania VM-ki tak, by była użyteczna jako DLL-ka oraz pochodne, niezależnie od języka bazowego aplikacji (w ten sposób działa np.Lua).
Interfejs pomiędzy kodem a VM-ką istnieje poprzez opcode icall:
Od strony maszyny wirtualnej wygląda to przykładowo tak:
Program UnicornPower;
Uses Machine;
Procedure Unicorn(VM: TMachine; Params: TCallValues; var Result: TCallValue);
Begin
{
Params[x].Typ to może być cpBool, cpChar, cpInt, cpFloat, cpString
Params[x].Value to Variant
}
Writeln('Unicorn called with argument: `', Params[0].Value, '`');
End;
Var VM: TMachine;
Begin
VM := TMachine.Create('plik_ze_skompilowanym_kodem.ssc');
Try
VM.AddInternalCall('my_package', 'unicorn', 1, @Unicorn); // TMachine.AddInternalCall(nazwa pakietu, nazwa funkcji, ilość parametrów, wskaźnik do handlera);
VM.Run;
Finally
VM.Free;
End;
End;
A od strony kodu SScript:
function<void> call_unicorn(string param)
{
:CODE
{
push(%param) // wrzucamy zmienną na stos
icall("my_package.unicorn") // wywołujemy "internal call"; nad tą częścią interfejsu muszę pomyśleć - wygląda brzydko ;P
}
}
function<int> main()
{
call_unicorn("Hello!");
return 0;
}
I... po miesiącu pracy następna wersja już jest! ;)
Najważniejsza zmiana: control flow graph!
Znaczy to ni mniej ni więcej, że kompilator dla każdej funkcji generuje graf przepływu sterowania (en.control flow graph), wykonuje na nim parę magicznych sztuczek optymalizacyjnych (jeżeli jakieś są włączone ofc.), po czym dopiero pod koniec generuje bajtkod - czyli identycznie jak "zwykłe" kompilatory; (dla przypomnienia dodam, że wcześniej dane trzymane były po prostu w tablicy występujących po sobie wyrażeń (patrz pierwszy post w tym temacie), więc widać postęp ;]):
W związku z zaimplementowaniem CFG, doszło też parę nowych optymalizacji:
-propagacja stałych (włączane wraz z optymalizacjami -O2)
-usuwanie (już) nieużywanych zmiennych oraz szeroko pojętego 'martwego kodu' (-O2)
-optymalizacja rozgałęzień (if-ów) (-O3)
Dla przykładu wszystkich trzech optymalizacji przedstawionych powyżej weźmy np.taki kod:
@("stdlib/stdio.ss")
use std;
function<int> main()
{
var<int> x = 6;
if (x%2 == 0)
{
if (x%3 == 0)
{
if (x%5 == 0)
println("2, 3, 5"); else
println("2, 3");
} else
println("2");
} else
{
if (x%3 == 0)
println("3"); else
println("neither");
}
return 0;
}
Sprawdza on, czy liczba x jest podzielna przez 2, 3 oraz 5.
Graf przed optymalizacjami:
Graf po optymalizacjach:
Straciłem 3 dni na napisanie samego algorytmu optymalizacji branchy (ponieważ zawsze jak zaczął działać w jednym wypadku, crashował kompilator w innym), ale ostatecznie działa, co widać i można sprawdzić ;)
Inny przykład prosto z Wikipedii:
function<int> main()
{
var<int> a = 30,
b = 9 - a / 5,
c;
c = b * 4;
if (c > 10) {
c = c - 10;
}
return c * (60 / a);
}
Przed:
mniejsza o zbyt dużą ilość nawiasów, procedurka zamieniająca drzewko na string została napisana "na kolanie" w ciągu pięciu minut :P
Po:
Napisane przeze mnie algorytmy nie są idealne i nie wychwytują wszystkiego, co można zoptymalizować, np.:
var<int> i=5;
i++;
return i;
Pozostanie w takiej formie, a nie zostanie zoptymalizowane do return 6; (jeszcze ;> Bo ofc.potem planuję to zaimplementować).
Podobnie, jak nie działają żadne optymalizacje w przypadku tablic, ale to i tak mały pikuś - w wolnym czasie wszystko się napisze ;)
Ulepszyłem ponadto nieco register-allocator; od teraz najczęściej używane wewnątrz funkcji zmienne lądują w rejestrach, a cała reszta na stosie. To jest wciąż lamerskie rozwiązanie, ponieważ np.w takim wypadku:
var<int> a=10;
foo(a);
var<int> b=0;
foo(b);
Zmienne a oraz b wylądują w dwóch osobnych rejestrach, chociaż właściwie mogłyby (ba! powinny) znajdować się w jednym; by to osiągnąć czeka mnie zabawa z kolorowaniem grafów ;P
Pobrałem sobie dziś edytorek by sprawdzić jak wygląda nowa wersja (ostatnią jaką widziałem była bodajże z lutego); Co do kodu nie mam żadnych zastrzeżeń (cały czas nad nim pracujesz), jednak GUI według mnie dalej stoi w miejscu... Przede wszystkim menu główne programu oraz menu kontekstowe śmierdzi pustką - mało różnych opcji i co ważne - zakładka Edit ma strasznie mało opcji (kontekstowe menu edytora kodu także); Jeśli o dizajn chodzi - bardzo proste (aż za bardzo);
Z racji tej, że zawsze zwracam uwagę na wygląd interfejsu i rozmieszczenie jego elementów byłbym za tym, by je delikatnie "upiększyć" - zastosować większe itemy, dobrać lepsze ikonki, ustawić własnoręczne rysowanie itemów oraz przede wszystkim dorobić więcej różnych przydatnych opcji, które przydałyby się podczas pisania kodu;
Brakuje też paska narzędziowego z najprzydatniejszymi funkcjami, np. dotyczącymi projektu (zakładka File), opcje do edycji kodu (zakładka Edit), opcje kompilacji (zakładka Run) oraz przycisk łączący z ustawieniami środowiska (opcjonalnie); Toolbar oczywiście z możliwością ukrywania, ale niekoniecznie z kastomizacją "sub-pasków" dla poszczególnych grup tak, jak to jest np. w Delphi7;
@Patryk27 - interfejs także trzeba rozwijać, bo przecież to najważniejszy element programu pośredniczący komukacji użytkownika z komputerem; Do przerobienia menu głównego i kontekstowego nie potrzeba wiele czasu;
Jeśli chcesz, mogę popracować nad delikatnym dopieszczeniem interfejsu w wolnym czasie; Nie chodzi mi o nie wiadomo jakie odpicowanie GUI - chodzi o to, by było po prostu nieco ciekawsze i bogatsze; Dawniej dużo czasu spędzałem na ulepszanie wyglądu menu (bo bez własnych kontrolek to jeden z niewielu komponentów, które są wykorzystywane w większości programów i można je prawie całkowicie przerabiać) i jakąś tam wprawę mam; Jedno z moich najciekawszych menu zastosowałem w programie, którego nigdy nie udostępniałem i nie zamierzam - efekt poniżej:
Z lewej menu kontekstowe TMemo, pozostałe to listy różnych menu głównych;
Tak więc poświęcając kilka godzin można nawet takie cudo wykombinować (a nawet lepsze); Mechanizm takiego menu jest bardzo prosty, a itemy zarówno w menu głównym jak i kontekstowym rysuje jedynie jedno zdarzenie podpięte we wszystkich menu w całym programie - wystarczy odpowiednio poklikać w OI;
Oczywiście nie namawiam Cię do zaimplementowania takiego cudoka - chodzi mi o coś nieskomplikowanego graficznie, ale ładniejszego od wyglądu menu narzuconego przez system; Jeśli chcesz - mogę coś w wolnym czasie zadziałać :]
Tak btw, zastanawiam się nad wprowadzeniem do edytora systemu pluginów - pisanych oczywiście w SScriptcie :D
Co myślicie o tym pomyśle?
(ofc.wprowadzone zostałoby to po tym, jak zacznie on już przypominać prawdziwy edytor, a nie jedynie SynEdit z zakładkami ;P).
Patryk27 napisał(a):
Tak btw, zastanawiam się nad wprowadzeniem do edytora systemu pluginów - pisanych oczywiście w SScriptcie :D
Co myślicie o tym pomyśle?(ofc.wprowadzone zostałoby to po tym, jak zacznie on już przypominać prawdziwy edytor, a nie jedynie SynEdit z zakładkami ;P).
Jeśli robisz to z pełną świadomością, że nie zawojujesz tym świata, to możesz dorobić pluginy, wersję portable / U3, wersję na Linuxa i Androida, bitmapkę w tle i odtwarzanie DivX gdy ktoś popełni błąd składniowy
;-)
A doczego te pluginy miały być? Rozszerzające funkcjonalność edytora, czy jakieś dodatkowe fiuczery?
Najpierw to proponowałbym skończenie obecnych prac nad rozwojem języka, refaktoryzacji kodu, o której wspominałeś oraz rozszerzenie funkcjonalności edytora kodu; Jeśli już najpotrzebniejsze funkcje będą gotowe - wtedy można działać z pluginami; Myślę, że mowa o planach na przyszłość, wcale nie tak bliską :]
A do czego te pluginy miały być?
Jakieś malutkie rzeczy podobne do tych z Code::Blocks typu statystyka kodu, szybki tester wyrażeń regularnych itd. itd. - parę malutkich rzeczy, których nie opłacałoby mi się bezpośrednio tworzyć w edytorze... chociaż jak tak patrzę na to z innej perspektywy, rzeczywiście może się to wydawać jedynie zbędnym obciążeniem ;P
Najpierw to proponowałbym skończenie obecnych prac nad rozwojem języka, refaktoryzacji kodu, o której wspominałeś oraz rozszerzenie funkcjonalności edytora kodu;
To oczywiście to wszystko mam na pierwszym miejscu - ta ewentualna implementacja pluginów gdzieś na samym końcu długiej listy TODO ;)
Patryk27 napisał(a):
A do czego te pluginy miały być?
Jakieś malutkie rzeczy podobne do tych z Code::Blocks typu statystyka kodu, szybki tester wyrażeń regularnych itd. itd. - parę malutkich rzeczy, których nie opłacałoby mi się bezpośrednio tworzyć w edytorze... chociaż jak tak patrzę na to z innej perspektywy, rzeczywiście może się to wydawać jedynie zbędnym obciążeniem ;P
Weź pod uwagę, że pluginy z definicji robią ludzie, którzy nie mają dostępu do kodów źródłowych głównego narzędzia i nie mogą go dowolnie rozszerzać.
A do tego baza użytkowników jest tak duża że autor / firma nie nadąża z obsługą wszystkich życzeń i zażaleń.
Aktualnie nie widzę powodu, dla którego taką statystykę nie miałbyś po prostu wbudować w edytor (IDE?).
Ostatnimi czasy pracowałem nad samym edytorem odkładając w kąt kompilator oraz VM-kę.
Efekty:
(potem planuję dodać, aby to okienko Intellisense dodatkowo pokazywało parametry funkcji etc.)
Wrzucam Wam tutaj wydanie pre-alpha (:P): http://speedy.sh/4gkpf/Win32.zip
(wybaczcie, że na Speedyshare, lecz 3 MB to za dużo, jak na załącznik (:|)).
* jedyną nieobsługiwaną aktualnie rzeczą są circular-references pomiędzy funkcjami. Tzn.taki kod jest poprawny w SScripcie i zostanie bezproblemowo skompilowany:
function<void> a()
{
b();
}
function<void> b()
{
a();
}
Lecz póki co edytor nie będzie poprawnie rozpoznawał wywołania b();. To jest jednym z pierwszych rzeczy na mojej liście TODO.
Interfejs coraz bardziej przypomina edytor kodu z prawdziwego zdarzenia :]
Ta skórka jest własna, czy narzucona przez system - Win8? Przyjemna, bez przepychu, który w tym wypadku byłby zbędny;
(potem planuję dodać, aby to okienko Intellisense dodatkowo pokazywało parametry funkcji etc.)
Nie zapomnij o hincie funkcji, która nie mieści się w okienku - jest to bardzo pomocna rzecz;
Ogólnie widać duży postęp jeśli chodzi o sam edytor;
(wybaczcie, że na Speedyshare, lecz 3 MB to za dużo, jak na załącznik (:|)).
Nie, maksymalny rozmiar załącznika to 20MB - powinno dać się dodać bez problemu;
EDIT: zepsułem edytor :]
Kicha... Uruchomiłem edytor, zamknąłem wszystkie trzy okienka przez ten miniaturowy przycisk w rogu (hint Close); Myślałem, że to służy do dokowania okienek, ale jak je zamknąłem i potem wybrałem je z menu Window to już nie były zadokowane i nie udało mi się ich z powrotem "złączyć" z głównym oknem aplikacji; Program zaknąłem i uruchomiłem ponownie i boom - komunikat;
Co do skórki - teraz już wiem - u mnie jest taka sama, jak okna systemowe; Jeśli chodzi o drzewko identyfikatorów - przydałyby się miniaturowe ikonki dla poszczególnych elementów - podobnie jak w Lazarusie w Object Inspector (ale to tylko sugestia);
Jeszcze jedna wskazówka dotycząca Intellisense - jeśli ustawię kursor przed identyfikatorem to strzałkami w lewo/prawo powinno się dać przesunąć kursor w oknie edytora, przez co w okienku uzupełniania powinne być odsiane te identyfikatory, które nie rozpoczynają się ciągiem przed kursorem (tak, jak jest to w Lazarusie czy Delphi):
i tak jak na obrazku - jeśli wcisnę strzałkę w prawo - powinny pozostać tylko te elementy, których identyfikator rozpoczyna się na literę p, jeszcze raz wcisnę - pozostają na liście tylko te, które zaczynają się ciągiem pr, i tak dalej; Póki co można jedynie strzałkami w górę/dół wybierać.
Ta skórka jest własna, czy narzucona przez system - Win8? Przyjemna, bez przepychu, który w tym wypadku byłby zbędny;
Wszystko systemowe, niezbyt wiele mogę działać jeżeli chodzi o skórki as-is, ponieważ chcę, aby edytor był przenośny pomiędzy platformami (aktualnie na pewno skompiluje się i będzie działać na Windowsie oraz Linuxie, nie wiem jak na Maczku).
Nie zapomnij o hincie funkcji, która nie mieści się w okienku - jest to bardzo pomocna rzecz;
To okienko Intellisense to wbudowana część SynEdita (z dokładnie tego samego korzysta Lazarus; szkoda, że dodatkowo samo nie parsuje kodu, tylko wyświetla wyniki ;P), afair tam jest to wbudowane, lecz będę musiał jeszcze sprawdzić.
Nie, maksymalny rozmiar załącznika to 20MB - powinno dać się dodać bez problemu;
That's the point...
@Patryk27 - chodzi mi o to (okienko zmniejszyłem, żeby nie wrzucać "ciężkich" zrzutów):
2. Po zamknięciu zadokowanych okienek (patrz - tytuł formularza jest już inny)
3. Po ponownym pokazaniu okienek
Niestety już nie mogę z powrotem zadokować tych okienek (maksymalizacja daje zupełnie inny efekt); Na dodatek - widać na załączniku - tytuł głównego okna zmienia się na "Identifier list".
Kicha... Uruchomiłem edytor, zamknąłem wszystkie trzy okienka przez ten miniaturowy przycisk w rogu (hint Close); Myślałem, że to służy do dokowania okienek, ale jak je zamknąłem i potem wybrałem je z menu Window to już nie były zadokowane i nie udało mi się ich z powrotem "złączyć" z głównym oknem aplikacji; Program zaknąłem i uruchomiłem ponownie i boom - komunikat;
Hm - dziwne. Cóż, AnchorDocking to pakiet, z którego korzystam do tworzenia dockowalnych okien i najwyraźniej autor coś zepsuł :P Będę musiał sprawdzić kod z najnowszego brancha.
przydałyby się miniaturowe ikonki dla poszczególnych elementów - podobnie jak w Lazarusie w Object Inspector (ale to tylko sugestia);
To jest jedna z tych rzeczy, które będą już w następnej alpha ;)
jeśli ustawię kursor przed identyfikatorem to strzałkami w lewo/prawo powinno się dać przesunąć kursor w oknie edytora
Damnit, przysiągłbym, że to zaimplementowałem ._.''
Niestety już nie mogę z powrotem zadokować tych okienek (maksymalizacja daje zupełnie inny efekt);
W ogóle coś ten AnchorDocking jest upośledzony, albo ja nie potrafię się nim posługiwać... będę miał więcej pracy, niż myślałem.
Btw, spróbuj przeciągnąć najpierw Code Editor na główną formę, a potem resztę okienek dołączaj do tego Code Editor. Powinno zadziałać.
Na dodatek - widać na załączniku - tytuł głównego okna zmienia się na "Identifier list".
Cztery bite godziny się z tym męczyłem w kodzie AnchorDocking: nie wykombinowałem, jak właśnie tego "efektu" się pozbyć :P
Też nad tym rozmyślałem; ostatecznie wybrałem dokowalne okna, ale chyba jednak to zmienię właśnie na rozwiązanie Lazarusowo-Delfiowe ;P
Imho będzie to dużo lepsze rozwiązanie, niż dokowanie okien, które na dodatek przysparza wielu problemów;
Ja osobiście wolę mieć wszystkie okna "rozdokowane" i pokazywać/ukrywać te, których w danej chwili nie potrzebuję; W moim przypadku sam edytor kodu jest rozciągnięty na prawie cały ekran, dzięki temu podczas pisania mam dużą wygodę; Jeśli natomiast potrzeba coś ustawić w OI - wciskam F11 (pod Delphi) i ustawiam;
Delphi daje dodatkowo możliwość zapisu dowolnej ilości schematów z ustawieniem i rozmiarem wszystkich okien środowiska, co bardzo cenię; Obecnie mam dwa schematy - jeden dla notebooka i jeden dla dodatkowego monitora; Dzięki temu jeśli potrzebuję przenieść wszystkie okna środowiska na monitor czy z powrotem na laptopa - wybieram odpowiednią pozycję z menu i gotowe; Niestety Lazarus jeszcze się tego nie dorobił i muszę ręcznie przesuwać wszystkie okna... Poza tym Lazarus skutecznie utrudnia debugowanie, bo nie pozwala na trzymanie okna Watches na wierzchu i jeśli potrzebuję obserwować jakąś zmienną przez dłuższą chwilę to muszę albo zmniejszyć rozmiar edytora kodu, albo ciągle przełączać się między oknami, co mnie niesamowicie denerwuje;
Tak więc dobrze by było, jakby i Twój edytor miał możliwość zapisu takich schematów - jest to naprawdę bardzo przydatna funkcja.
Podejście #2:
.png)
Tak więc dobrze by było, jakby i Twój edytor miał możliwość zapisu takich schematów - jest to naprawdę bardzo przydatna funkcja.
Takie cuś?
Jest dostępne z menu Okna -> Menedżer układów okien lub skrótem F11.
Jeśli chodzi o okienka to jest bardzo dobrze; Co do "Layout manager" - jest jeden błąd; Mianowicie - jeśli okno główne aplikacji (czyli to z menu i toolbarem) ustawię jako niezmaksymalizowane i zapiszę schemat, to po restarcie programu formularz ten jest maksymalizowany z automatu; Po wciśnięciu systemowego przycisku "Przywróć" - okno ląduje w zupełnie innym miejscu, niż zostało to ustawione wcześniej;
Druga sprawa to zapis schematu - nie mogę nadpisać schematu... Zamiast wyświetlać ten błąd:
sugeruję wyświetlić okienko z potwierdzeniem czy na pewno chce się nadpisać istniejący schemat; Tak jest w Delphi7 i przydaje się :]