Mam problemik natury technicznej z Delphi 7 na Win XP. Nie jest to może coś, co wybitnie utrudnia pracę, ale po pewnym czasie robi się wkurzające. Raz na jakiś czas w edytorze kodu zdarza mi się coś takiego, że gdy zaznaczę fragment kodu, aby go np. podmienić innym, lub usunąć jednym wciśnięciem klawisza Del lub BkSpace, edytor kodu, zachowuje się tak, jakby tekst nie był zaznaczony. Np. wciśnięcie Del kasuje jeden znak bezpośrednio za pozycją kursora, BkSpace jeden znak przed, próba podmiany tekstu skutkuje wprowadzaniem nowego w miejscu, w którym jest kursor. Z samym zaznaczeniem zasadniczo nic się nie dzieje, tzn. zaznaczenie jest, nie znika, ew. zmienia swój rozmiar w miarę pracy nad zaznaczonym teksem. Jest to troszkę wkurzające, bo np. usunięcie kilku linijek kodu w takim stanie rzeczy staje się dość czasochłonną operacją.
Czy ktoś z was spotkał się z czymś takim w Delphi i ew. wie, jak (poza restartem Delphi, który sprawę czasowo rozwiązuje) zwalczyć ten dziwny efekt?
Z góry dziękuję za pomoc.
Ja nigdy takiego efektu nie miałem w żadnej wersji, a używam Delphi od ponad 10 lat. Może używasz jakiejś dziwnej kombinacji klawiszy przed usunięciem tekstu, która "zawiesza" edytor IDE?
Ja najczęściej poruszam się po edytorze klawiszami funkcyjnymi. Dzieje się tak od niedawna czy od zawsze? Zmieniałeś klawiaturę? Głupie rozwiązanie, ale może reinstalacja by coś pomogła...
jak (poza restartem Delphi, który sprawę czasowo rozwiązuje) zwalczyć ten dziwny efekt?
www.lazarus.freepascal.org - darmowy odpowiednik Delphi który Delphi7 wyprzedził dawno temu.
szopenfx napisał(a):
Ja nigdy takiego efektu nie miałem w żadnej wersji, a używam Delphi od ponad 10 lat. Może używasz jakiejś dziwnej kombinacji klawiszy przed usunięciem tekstu, która "zawiesza" edytor IDE?
Ja najczęściej poruszam się po edytorze klawiszami funkcyjnymi. Dzieje się tak od niedawna czy od zawsze? Zmieniałeś klawiaturę? Głupie rozwiązanie, ale może reinstalacja by coś pomogła...
To się dzieje od niedawna. A konkretnie, od kiedy użytkuję D7 na tym konkretnie komputerze. Wcześniej nie miewałem takich problemów ani w D7, ani w żadnej z wcześniej używanych przeze mnie wersji. Nie tylko klawiatura, ale cały komputer jest stosunkowo nowy. Przypuszczalnie to jest jakiś problem IDE. Albo gryzie mi się z jakimś innym oprogramowaniem, albo już sam nie wiem co. Tak czy inaczej, jeśli ktoś jeszcze się spotkał z takim problemem, to może przypadkiem wpadł na jego rozwiązanie...
Miałem kiedyś problem z IDE w D7, ale polegał na czymś innym - przesuwając suwak pionowy kod zostawał rozmazany i nie odświeżony, co całkowicie uniemożliwiło dalszą pracę - (Save All i) reboot konieczny; Nie działo się to od razu, ale po jakichś kilku(nastu) godzinach kodzenia; W końcu wkurwiłem się i przeinstalowałem aplikację, co pomogło, ale do czasu; Potem wyskakiwało mi okienko z jakimiś informacjami (zawsze wyskakuje niedługo po uruchomieniu aplikacji), ale parser najwidoczniej nie potrafił poprawnie zdekodować jej, przez co okienko wyglądało jak śmietnik;
Jeżeli dalej nie wiesz co jest tego przyczyną (i raczej się nie dowiesz - są to pewnie bugi IDE) to przeinstaluj aplikację; Tylko nie odinstaluj wszystkiego, bo utracisz ustawienia i niestandardowe komponenty (jeśli takie masz zainstalowane); Zawsze uruchamiając instalator możesz wybrać opcję Repair - teoretycznie usunie błędy po stronie aplikacji;
Jeśli nie chcesz się dalej użerać z 10 letnim kompilatorem to pobierz i zainstaluj sobie Lazarus'a - aktualne środowisko, w którym projektuje się aplikacje bardzo podobnie do BD7; Ma oczywiście niewielkie różnice, ale także zawiera dużo elementów, których nie ma w D7;
Ja kilka dni temu pobrałem i zainstalowałem to środowisko (wersja 0.9.30.4 (z RC na razie poczekam)) - pierwsze wrażenie jest jak najbardziej pozytywne; Rozmiar czystej aplikacji (sam pusty formularz) mnie trochę przeraził (ponad 13Mb), ale UPX pakuje do 2Mb; Za to bardzo podoba mi się pole edytora kodu z możliwością zwijania danych bloków kodu (czego w D7 nie ma), wspieranie stylów okien w edytorze wizualnym i bradzo bogata standardowa lista kontrolek - w tym TChart, którego także nie ma w D7, a kiedyś bardzo go potrzebowałem;
Mam nadzieję, że w niedługim czasie całkowicie przeniosę się na Lazarus'a (muszę jeszcze skończyć stary projekt w D7) bo według mnie już czas najwyższy pozbyć się 10 letniego dziadziusia i korzystać z aktualnych rozwiązań; Wszystkim tym, którzy dalej pracują na BD7 polecam przechadzkę na Lazarusa, bo warto;
Rozmiar czystej aplikacji (sam pusty formularz) mnie trochę przeraził (ponad 13Mb)
Narzędzia strip użyj to wywalisz wszystkie informacje debuggujące, powinno zejść do 1mb. Jest chyba też przełącznik kompilatora żeby nie generował debug info.
etam napisał(a):
(..) że gdy zaznaczę fragment kodu, aby go np. podmienić innym, lub usunąć jednym wciśnięciem klawisza Del lub BkSpace, edytor kodu, zachowuje się tak, jakby tekst nie był zaznaczony. Np. wciśnięcie Del kasuje jeden znak bezpośrednio za pozycją kursora, BkSpace jeden znak przed, próba podmiany tekstu skutkuje wprowadzaniem nowego w miejscu, w którym jest kursor. Z samym zaznaczeniem zasadniczo nic się nie dzieje, tzn. zaznaczenie jest, nie znika, ew. zmienia swój rozmiar w miarę pracy nad zaznaczonym teksem.(..)
A może masz zaznaczoną opcję: Tools -> Editor Options -> Zakładka General -> Persistent blocks? Jak się ją zaznaczy, to efekt jest właśnie taki, jak opisujesz.
-123oho napisał(a):
Rozmiar czystej aplikacji (sam pusty formularz) mnie trochę przeraził (ponad 13Mb)
Narzędzia strip użyj to wywalisz wszystkie informacje debuggujące, powinno zejść do 1mb. Jest chyba też przełącznik kompilatora żeby nie generował debug info.
Najwięcej zyskuje się przez:
Project -> Project Options... -> Compiler Options -> Linking trzeba zaznaczyć "Use external gdb debug symbols file (-Xg)"
ale pewnie można by uzyskać jeszcze mniejszy exe więcej gdyby jeszcze pownikać. Oczywiście mam na myśli bez użycia zewnętrznych narzędzi.
a jak wypada lazarus w starciu z xe2?
Najwięcej zyskuje się przez:
Project -> Project Options... -> Compiler Options -> Linking trzeba zaznaczyć "Use external gdb debug symbols file (-Xg)"
ale pewnie można by uzyskać jeszcze mniejszy exe więcej gdyby jeszcze pownikać. Oczywiście mam na myśli bez użycia zewnętrznych narzędzi.
Mi wyszło lepiej bez -Xg, ale z strip --strip-all (309kb, z -Xg 310kb).
Żeby uzyskać symbole debuggera w oddzielnym pliku można też użyć jakiejś komendy GDB.
a jak wypada lazarus w starciu z xe2?
To zależy co bierzesz pod uwagę. Jeżeli ilość platform to żadne Delphi się nie równa z FPC ani Lazarusem.
kAzek napisał(a)
Najwięcej zyskuje się przez:
Project -> Project Options... -> Compiler Options -> Linking trzeba zaznaczyć "Use external gdb debug symbols file (-Xg)"
Po zaznaczeniu tej opcji plik wykonywalny zmniejszył się do 1,56Mb, bez użycia strip.exe; Co jeszcze polecacie ustawić w opcjach projektu?
sdsd napisał(a):
a jak wypada lazarus w starciu z xe2?
Nigdy Lazarusa nie używałem więc nie porównam. Jednak ostatnio(od kilkiu miesięcy) pracuję nad systemem pisanym w XE2(aplikacja VCL) i praca do najprzyjemniejszych nie należy:P IDE średnio nadaje się do pracy. Wymienię kilka najbardziej irytujących mnie bugów, które do dziś(Update 4) nie zostały poprawione:
- Źle działa podkreślanie błędów na czerwono(podkreśla cały unit na czerwono pomimo prawidłowego kodu) - wyłączyłem pierwszego dnia
- Ctrl + shift + C(generowanie definicji metody) nie działa, jeżeli gdziekolwiek pod deklaracją metody jest deklaracja zagnieżdżonego rekordu
- Zdarza się, że podczas pisania dany unit zostaje zaznaczony jako "Read only", po odznaczeniu chwilę można pisać jednak po paru chwilach zaznacza się znowu i już się nie da odznaczyć (enabled = false) i trzeba zamknąć zakładkę i uruchomić ją jeszcze raz
- Narzędzia refaktoringu działają strasznie słabo:
- zmiana nazwy pola/metody często się nie powodzi
- Zmiana argumentów metody ani razu się jeszcze nie powiodła(zwykle EOutOfMemory)
- Find unit kiepsko działa(EOutOfMemory)
- Wyszukiwanie(ctrl+shift+F) nie zawsze znajduje wystąpienia - do tego używamy gexperts
- Podpowiadanie unitów podczas dodawania do uses działa tylko do 2. poziomu tj piszesz System.Generics. i musisz wpisać unit ręcznie bo dalej nie podpowie
- Okno "Structure" ma wszystkie klasy domyślnie rozwinięte i nie znalazłem opcji aby to naprawić - jest to bardzo uciążliwe, gdy w unicie jest więcej niż 3, 4 klasy
- Nie działa pauza podczas uruchomienia programu(w D7 działała na pewno)
- Bardzo często nie działa przejście między deklaracją a definicją metody i na odwrót - ląduje w randomowych miejscach i trzeba używać ctrl+F
I pewnie wiele innych o których w obecnej chwili nie pamiętam.
Po zaznaczeniu tej opcji plik wykonywalny zmniejszył się do 1,56Mb, bez użycia strip.exe; Co jeszcze polecacie ustawić w opcjach projektu?
Generalnie to -XX -CX się przydają. Jak chodzi o optymalizacje to -O3 -Ou -Or -OpPENTIUM4. Jak chcesz debugować to -gl powinien wystarczyć, ew. -Ci -Cr -Co -Ct -CR. Jak usuwanie memleaków: -gh.
Gdy tworzysz aplikację finalną to polecam użyć zestawu maksymalnej optymalizacji i skompilować plik z -gl, a potem skopiować plik, wyjąć symbole i użyć stripa który daje pewność że symbole zostaną usunięte (najlepiej --strip-all). Dzięki temu można też potem analizować stacktrace używając symboli z oryginalnego pliku z symbolami, osobiście -Xg nie ufam, zwłaszcza że -Xg nie usuwa bodaj całkowicie symboli ale zostawia odnośniki do pliku ze zrzutem.
po co tracisz czas na „upewnianie się” by nie zostawić ani śladu symboli?
Bo symbole bardzo przydają się przy RE zwłaszcza że moje programy są anti-RE. Zresztą, symbole zapychają miejsce w gotowym exeku, bo dla przeciętnego użyszkodnika są nieprzydatne. Marnowanie łącza, dysku konsumentów etc. etc. . Gdyby FPC był domyślnie kompilowany z symbolami to zajmowałby 250Mb, bez 140Mb (mówimy o wersji z SVN). Różnica?
I nie mówię że od razu trzeba popadać w jakąś gorączkę żeby tylko symbole wyczyścić, ale jeżeli nie potrzeba to warto w swoim batchu budującym dodać stripowanie, bo to oszczędza łącze i dysk. A tracę tyle czasu co napisanie "strip --strip-all projectx.exe" do pliku budującego.