Dziwne zachowanie kompilatora - Delphi 7

W trakcie pisania aplikacji pojawiła się dziwna sytuacja.

Nie wiem jak technicznie nazywa się ten element, ale po skompilowaniu Debugger na linijce bocznej/marginesie pokazuje niebieskie kropki obrazujące te wiersze kodu zrodlowego, na których podczas debugowania Step-By-Step użytkownik będzie mógł stanąć (kolejne kroki pracy programu).

Problem polega na tym, ze mam procedury, gdzie te kropki albo pojawiają się poza ciałem procedury (po końcowym end danej procedury) albo nie pojawiają się w ogóle (np. mam sekwencję podobnych operacji dodawania kolejnych wierszy do TStrings. Wierszy z opracją Add jest np 10, a kropki pojawiają się przy pierwszych 3.

Podczas debuggowania kursor skacze po procedurze i szcze rze przyznam, ze nie mam pojęcia o co chodzi.

To pierwszy projekt w którym spotkałem się z czymś takim - nie jest jakoś przesadnie długi, bo na chwilę obecną ma raptem ok 2000 wierszy.

co ciekawe - nie używam jakiś niekonwencjonalnych konstrukcji jezykowych - czysty, prosty kod i takie dziwne zajawki.

Albo sytuacja taka: Odwołuję się do obiektu Memo1, który jest zdefiniowany zarówno w module glownym, jak i module dolaczonym klauzula uses (aplikacja ma raptem dwa okienka). Wpisuję Memo1 daję kropkę i spodziewan się dostac listę metod i propertow obiektu memo (Memo1 nie jest zawarte w klauzuli with ... do . Zamiast tego dostaję listę metod i obiektów drugiego modulu, a metod Memo1 nie ma.

Inny dziwny przypadek: Kompiluję - kompilator pokacuje błąd Illegal character input file: } ($7D) i pokazuje wiersz np 727 kolumna 365 - ciekawostka, bo w całym projekcie (w plikach *.pas i *.dfm) nie ma ani jednego wystapienia znaku "{"

Dostaję białej gorączki, bo moduł miałem oddać wczoraj rano a tu taka du...sza.

Ktoś ma pojęcie o co tu chodzi i z czym to jeść ?

Aha. Dodam Vista + Delphi 7

U mnie też czasem kompilator się wykrzacza, a czasami cały system zamraża się w czasie pracy steb-by-step. OS niby działa ale mam wrażenie że kolejka systemowych komunikatów się posypała. Na ślepo strzelam wtedy CTRL + F2, byleby żeby debuger się zamknął. Po 5 min się zazwyczaj udaje.
Przy innych błędach restartuje Delphi i po problemie. Skąd to się bierze? U mnie najpewniej z powodu niejawnych wątków, które to ja nie uruchamiam, ale wchodzą one w skład niektórych komponentów. w ogóle to dziwna sprawa.
toyman: daj zrzut ekranu, gdzie te niebieskie kropki uciekają od rynienki.

http://img52.imageshack.us/img52/2332/bladdelphi.jpg

TO najbardziej jaskrawy przykład problemu. Górne wiersze nie mają kropek, natomiast kropki pojawiają się tak, gdzie to jest fizycznie niemożliwe - to znaczy między "end;" koncowym jednej procedury a slowem kluczowym "procedure" następnej.

U mnie też co jakiś czas Delphi się wywala, ale tylko jeżeli mam otwarte okienko Watches.

Co ciekawe - aplikacja działa i wykonuje poprawnie wszystkie operacje, które zawarte są w liniach nie oznaczonych kropkami. W sensie aplikacja działa poprawnie - problem jest tylko przy debugowaniu i tworzeniu kodu (Auto completion pokazuje property i metody, które nie należą do tego obiektu, a zamiast nich pokazuje metody, które są zawarte w drugim module).

Zdarzyło mi się też, że pokazywało błąd: Unable to invoke Code Completion due to errors in source code. okej - nic nadzwyczajnego - taki blad pojawia sie, jak pomyle nazwe obiektu lub metody. Not big deal. Wszystko fajnie, ale ja jestem pewien, ze wywolanie metody danego obiektu jest poprawna.

Zamieniam kolejnościa implementacje procedur (bylo: procedura A, procedura B - teraz jest procedura B, procedura A). Ciekawostka: Działa. Kompiluje się. program wykonuje prawidłowe operacja, a Auto completion pokazuje poprawne metody obiektu.

Nie ma problemu jak pracuje z komponentami, które znam na wylot i nie musze siegac do Auto completion. Ale akurat w tym projekcie cała forma jest obslugiwana przez kontroli, ktorych nigdy wczesniej nie uzywalem i Auto completion jest przydatnym narzedziem. Okej - da sie bez tego zyc - w ostatecznosi mam kody zrodlowe komponentow.

Ale bez debuggera nie da sie zyc. No dobra zylem bez niego przy projetowania uslug i tworzeniu logiki programow po stronie bazy danych, ale to jest pieronsko uciazliwe.

Aha. Zainstalowalem sobie Delphi na wirtualnej maszynie z XP i problem jest ten sam.

usuń pliki dcu i przebuduj projekt (project\build)

po prostu wersja skompilowana (dcu) i źródłowa (pas) różnią się - kompilator "pokazuje kropki: na podstawie pliku dcu i nie jest to błąd tylko tak się po prostu dzieje czasami

Zrobiłem tak:

1. usunąłem wszystko co nie jest *.pas, *.dfm i *.dpr
2. Zamknąłem Delphi
3. Zrestartowałem komputer (dla pewności)
4. Uruchomiłem Delphi
5. zBuildowałem projekt
6. Uruchomiłem projekt

dalej to samo - w trakcie debuggowania narzędzie step-over przeskakuje wiersze, które nie są zaznaczone kropką, ale wiersze wykonują się, bo no pomija budowanie zapytania SQL do TStrings, ale zapytanie zawiera wszystkie wiersze (nawet te pominiete).

Ostatni pomysł jaki mam, to stworzenie projektu całkiem od początku - to znaczy przekopiować zawartość DFM, a pozniej procedura po procedurze, zdarzenie po zdarzeniu przenosic funkcjonalności do nowego projektu.

Nie mam madrzejszych pomyslow :(

Za chwilę mnie szlag trafi.

Problem dotyczy tylko tego jednego projektu - otwierałem projekty innych klientów i nigdzie nie ma tego problemu.

Zrobiłem projekt od początku. Przenosiłem element po elemencie. event po evencie. Procedurę po procedurze - efekt ten sam.

Najgorsze, że projekt nie rożni się stylem ani poziomem skomplikowania, czy neistandardowymi mechanizmami od innych projektów tego typu. Jedyna różnica jaka jest, to zestaw komponentów które używam.

Problem na pewni nie jest zależny od systemu operacyjnego (świeżo postawiona wirtualka Windows XP i Hostowa Vista). Nie jest to raczej przyczyna samego projektu, bo zrobiłem go jeszcze raz i ten sam efekt. Nie jest to wina sposobu kodowania - bo jest taki sam jak w innych projektach. Nie jest to też raczej wina samego środowiska elphi, bo inne projekty nie wykazują takich zajawek.

Kompilator jak zgłasza błędy, to wskazuje linie kodu, które nie zawierają wyrażen, o które się burzy - np. Zgłasza błąd nieznanego identyfikatora, bo usunąłem deklaracje obiektu, a w kodzie odwoływałem się jeszcze do niego. tylko że wskazał na linię, która była o 5 wyżej niż faktyczna próba wywołania obiektu.

Strzelić sobie w łeb.

A najgorsze, ze mam mega presję czasu i projekt miał być oddany kilka dni temu, a ja stoję w miejscu przez idiotyczny problem :(

Na chwilę obecną pomogło wywalenie jednej procedury do osobnego modułu. Tym sposobem sytuacja unormowała się w module głównym, a w module dodatkowym moze byc gnojnik.

Co nie zmienia faktu, że sytuacja jest arcyciekawa.

Miałem podobny problem.

1. Okazało się że do projektu dodałem jakiś moduł w USES
   ale w projekcie miałem na żywca odwołanie do modułu o takiej samej nazwie tylko w innym katalogu, bo to była już któraś tam wersja z kolei. I wyglądało to tak że edytowałem i próbowałem debugować jeden plik a tak naprawdę delphi debugowało inny :( i pokazywał głupoty. Z 1,5 godziny szukałem przyczyny. :D

2. może to zależeć od ustawień debugowania w opcjach delphi

Sprawdzę to. Bo rzeczywiście w używam w tej procedurze odwołania do zewnetrznego modului rzeczywiście miałem rpzez moment na starcie projektu zamieszanie z katalogami (utworzyłem rpojekt w jednym katalogu, a pozniej go przenioslem gdzie indziej, a modul zostal wziety z innego projektu).

Dzięki za podpowiedź - to może być to.

No i koniec. Stoję.

Kompilator zgłasza mi taki błąd, że nie mam całkiem konceptu o co chodzi.

"Identifier expected but END found"

A wali tym błędem w miejscu i procedurze, gdzie robię tylko Add do TStrings.

Nie pomaga wywalenie procedury do osobnego modulu. Zamiana kolejnosci procedur.

Tam nie ma NIC, co mogloby powodowac taki błąd. Komentuję ciało procki (między begin, a end) - kompiluje się.

Czy znalazłby się jakiś mądry człowiek, który mógłby popatrzeć na ten kod ? Mogę zrobić zdalny dostęp do wirtualnego komputera, na ktorym można poklikać ten projekt.

Nie mam już kompletnie pomyslow :(

Hmmm ... wczoraj napisałem dość długą prockę, któa wykonuje sekwencję zapisów do bazy (ot puszcza w transakcji zapis danych z formy. Skleca kolejne zapytania z edytek formy i posyla do bazy)

Kiedy procedura przekroczyła ok 300 linii kompilator zaczal zglaszac abstrakcyjne bledy (do jasnej ciasnej - robilem takie operacje i w tym samym stylu kodowania setki razy !!!)

Podzieliłem więc prockę na logiczne, zamknięte całosci i powkładałem do osobnych pocedur. JEdnak na ostatniej częsci kompilator zaczął zgłąszać od nowa dziwne błedy i utknąłem.

Teraz zrobiłem tak, że żywcem przekopiowałem kod z procedury, w której zgłąszany jest błąd do procedury, która przechodziła bez zająknięcia. O dziwo - kompiluje się, a kropki pojawiają się poprawnie.

Pytnie - czy Delphi lub system operacyjny cacheują sobie gdzies coś (nie wiem - pliki *.DCU, poszczegolne skompilowane procedury - cokolwiek), że do czasu jak walcze w ramach konkretnej procki maja gdzies zapisany jakiś babol ?

Dlaczego mam takie podejrzenie ? Otóż stworzyłem inna procke i przekopiowałem ciało procedury, któa zgłąsza błąd - kompilator owszem zacza sie drzec, ale innym bledem.

Aha. NIE mam wirusów, trojanow i innych badziewi (a przynajmniej nic, co zglosilby antywirus)

Z moich doświadczeń to co mógłbym zasugerować odnośnie błędów.

1. doinstalowywałeś dodatkowe komponenty? np. jedi? u mnie po zainstalowaniu zaczęły się dziać od czasu do czasu podobne jazdy jak opisujesz. program raz się kompiluje, innym razem nie i wyrzuca błędy, których w rzeczywistości nie ma. potem kompiluje ponownie i jest wszystko ok.
2. zobacz czy nie masz dodatkowych modułów w uses z których nie korzystasz tak jak ktoś już wcześniej wspomniał. niby nie powinno mieć to żadnego znaczenia skoro nie ma nigdzie do nich odwołania ale lepiej mieć czysty kod bez niespodzianek
3. zobacz czy nie masz gdzieś powtórzonych nazw zmiennych itp. delphi powinno zgłosić błąd ze taka zmienna już istnieje ale :) wczoraj wstawiłem część kodu w dyrektywy $ifdef i wszystko się ładnie skompilowało ale program coś mi źle działał. podczas debugowania zobaczyłem że program wchodzi mi w część dyrektywy $ifdef dla symbolu który nie był zdefiniowany, bo go wyłączyłem. nie wiedziałem o co chodzi aż sobie przypomniałem że mam dokładnie taką samą zmienną jak nazwa symbolu - delphi błędu nie wyrzuciło ale program się powalił.
4. błędna deklaracja rozmiaru tablicy. coś źle przypiszesz a błąd wyskoczy w zupełnie innej części programu, czasem w ogóle nie związanej z jakąkolwiek tablicą.

możliwości odnośnie błędu jest wiele. skoro piszesz że wyrzuca ci błąd w procedurze a po przekopiowaniu do innej procedury jest ok to sprawdź czy jest wszystko ok ze zmiennymi. a może coś nie tak z nazwą procedury.

1. Rzeczywiście mam zainstalowane komponenty JEDI i korzystam z jednego komponentu (jvMonthCalendar) - sprobuja usunac z projektu ten komponent i wszystkie uses do niego.

2. sprawdzalem

3. Akurat w tym projekcie uzywam malo zmiennych definiowanych bezposrednio przeze mnie (zarowno globalnych, jak i lokalnych) - nie ma mowy o nakladaniu sie zakresow, bo nawet jezeli ejst zmienna globalna, to ma nazwe, ktora nie ma szans powtorzyc sie lokalnie

4. nie uzywam w tym projekcie tablic dynamicznych (chyba, ze komponenty obce to robia)

5. Nie ma żadnej reguły, ale raczej nie ma takiej mozliwosci - nazwy procedur sa Polsko-Angielskie (np. SavePersonel, SaveRozliczenie itp. nazwy pochodza od nazw zapisywanych datasetow)

Zostaje do przetestowania punkt 1.

ZNALAZLEM !!!

Ha. Jestem genitalny !!! ;)

Przepraszam za emocje, ale myslalem, ze strzele sobie w glowe. Owszem - projekt posowal sie do przodu, ale o sensownym debuggowaniu (takim, do jakiego jestesmy przyzwyczajeni w Delphi nie bylo mowy. Tylko wyrzucanie kolejnych krokow do Memo lub pliku = katorga)

Doszedlem do takiego momentu, gdzie w linii, gdzie bylo doslownie 5 znakow kompilator zglosil mi blad przekroczenia dlugosci linii (1023 znaki)

Okazuje się, że edytow Delphi jest na tyle madry, ze poprawnie pokazuje znaki konca linii #13 i #13#10, ale kompilator już nie. w sensie kompilator rozroznia jedynie #13#10.

Otworzyłem plik *.pas w UltraEdit (ale w Notatniku tez to widac) i rzeczywiscie - linie tam sa porozpierdzielane.

Co ciekawe - samo srodowisko blednie wstawia te numery znaki konca linii, bo zlepilo mi linie, ktore pisalem jednym ciurkiem (ok 50 linii skladanego do kupki zapytania SQL).

Anyway. Po operacji przerofmatowania kodu zrodlowego w UltraEdit projekt sie poprawnie skompilowal i kropki sa dokladnie w tych miejscach, w ktorych sie ich spodziewam.

Mam nadzieję, że komuś przyda się ta informacja w przyszlosci i zaoszczedzi kilku garsci niewyrwanych wlosow.