TVirtualStringTree - błąd przy OnGetText

TVirtualStringTree - błąd przy OnGetText
AM
  • Rejestracja:prawie 10 lat
  • Ostatnio:8 miesięcy
  • Postów:64
0

Witam, przy ładowaniu danych do komponentu TVirtualStringTree w procedurze OnGetText dostaję błąd
Invalid pointer operation

Procedura wygląda jak poniżej - dodam że identyczne rozwiązanie mam w innych miejscach i problem nie występuje.

Kopiuj
DataVSTPozycjeFVWz:=Sender.GetNodeData(Node);

  case Column of
    0:CellText:=IntToStr(DataVSTPozycjeFVWz^.Lp);
    1:CellText:=DataVSTPozycjeFVWz^.PKWIU;
    2:CellText:=DataVSTPozycjeFVWz^.NazwaArt;
    3:CellText:=Form1.PoprawZaokraglenie(CurrToStr(DataVSTPozycjeFVWz^.Ilosc));
    4:CellText:=DataVSTPozycjeFVWz^.JednMiary;
    5:CellText:=Form1.PoprawZaokraglenie(CurrToStr(DataVSTPozycjeFVWz^.CenaJednNetto));
    6:CellText:=Form1.PoprawZaokraglenie(CurrToStr(DataVSTPozycjeFVWz^.WartoscNetto));
    7:CellText:=IntToStr(DataVSTPozycjeFVWz^.Vat);
    8:CellText:=Form1.PoprawZaokraglenie(CurrToStr(DataVSTPozycjeFVWz^.WartoscVat));
    9:CellText:=Form1.PoprawZaokraglenie(CurrToStr(DataVSTPozycjeFVWz^.WartoscBrutto));
  end;                            

Globalny wskaźnik do rekordu

Kopiuj
DataVSTPozycjeFVWz:P_VirtualRecordPozycjeFVWz;

jest w sekcji public formy.

Jeżeli wezmę w komentarz to co w case Column of - problem znika. Może coś w samych ustawieniach komponentu ?

flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około godziny
  • Lokalizacja:Tuchów
  • Postów:12175
1

Zrób jakiś mały program testowy, tak abym mógł go skompilować i sprawdzić u siebie.

Na ten moment powodu problemów nie widzę.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 1x, ostatnio: flowCRANE
cerrato
Moderator Kariera
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 11 godzin
  • Lokalizacja:Poznań
  • Postów:8807
1

Tak, jak napisał @furious programming - daj trochę więcej kodu, bo na razie to jest bardziej zgadywanie niż realna pomoc.

Możesz jeszcze zrobić jedną rzecz, która mi przyszła do głowy tak na szybko: skoro piszesz, że wykomentowanie case powoduje, że problem znika, to możesz sobie to zakomentować, a następnie linia po linii "oddawać" - w ten sposób będziesz wiedział przynajmniej, czy każda z nich powoduje błąd (czyli pewnie wskaźnik do obiektu/rekordu jest pusty/niepoprawny), czy w jakiejś jednej konkretnej następuje naruszenie pamięci. Zajmie Ci to 3 minuty i od razu będziesz wiedział coś więcej.


edytowany 2x, ostatnio: cerrato
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około godziny
  • Lokalizacja:Tuchów
  • Postów:12175
0
cerrato napisał(a):

[…] skoro piszesz, że wykomentowanie case powoduje, że problem znika, to możesz sobie to zakomentować, a następnie linia po linii "oddawać" - w ten sposób będziesz wiedział przynajmniej, czy każda z nich powoduje błąd […]

Daję plusa za te słowa. Programowanie randomowe w czasach, w których mamy w bród funkcji do podglądania pamięci i analizy przepływu sterowania, to czysta głupota (albo lenistwo). A najgorsze jest to, że masa ludzi tak robi – nawet sam też czasem tak szukam problemów… :/

Trzeba użyć debuggera i sprawdzić co jest nie tak. No ale bez kodu choćby testowej aplikacji tego nie zrobię. Obstawiam, że kod komponentu działa prawidłowo, a wyjątek leci we własnych metodach.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 2x, ostatnio: flowCRANE
cerrato
Moderator Kariera
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 11 godzin
  • Lokalizacja:Poznań
  • Postów:8807
0

Daję plusa za te słowa. Programowanie randomowe w czasach, w których mamy w bród funkcji do podglądania pamięci i analizy przepływu sterowania, to czysta głupota (albo lenistwo).

Szczerze mówiąc to się pogubiłem. Najpierw piszesz, że dajesz plusa, a potem jakby sam temu zaprzeczasz - odwołujesz się do debugerów i innych narzędzi, o których ani słowem nie wspomniałem, za to "tradycyjne metody" nazywasz lenistwem czy głupotą. To, co zaproponowałem to zaiste odmiana dupa debugging, ale bardzo prosta, szybka i skuteczna w realizacji :D Owszem, można walić debugerami i podglądać co się dzieje, ale nie wiem, czy w tym przypadku nie będzie to nadmierne. Jeśli uda się ustalić która linia powoduje awarię, to pewnie kolejny rzut oka temat rozwiąże (coś w stylu aaaa.. no tak, nie zmieniłem wartości wskaźnika zanim przepisałem wartość zmiennej).


edytowany 2x, ostatnio: flowCRANE
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około godziny
  • Lokalizacja:Tuchów
  • Postów:12175
0
cerrato napisał(a):

Szczerze mówiąc to się pogubiłem. Najpierw piszesz, że dajesz plusa, a potem jakby sam temu zaprzeczasz […]

Daję plusa, bo przypomniałeś mi w jak głupi sposób sam czasem postępuję. :]

To, co zaproponowałem to zaiste odmiana dupa debugging, ale bardzo prosta, szybka i skuteczna w realizacji :D

No dokładnie. Choć równie szybkie jest postawienie w danym miejscu break-pointa i sprawdzenie zmiennych.

Przez bardzo długi czas (ze dwa-trzy lata) stroniłem od debuggera, stosując różne prymitywne praktyki analizy przepływu sterowania czy sprawdzania danych siedzących w zmiennych. A jak w końcu zaznajomiłem się z debuggerem i nim pobawiłem, to własnym oczom nie wierzyłem – i było to w Delphi 7. Od tamtej pory starałem się używać go do sprawdzania wszystkiego co potrzebowałem, jednocześnie próbując pozbyć się złych nawyków. Uważam, że wyszło mi to na dobre.


No, wracając do tematu – bez przykładowej aplikacji z kompilowalnym kodem nie pomogę.


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.
edytowany 4x, ostatnio: flowCRANE
Marius.Maximus
  • Rejestracja:ponad 14 lat
  • Ostatnio:około 7 godzin
  • Postów:2105
0

Czasami debugger jest bezsilny ale to zazwyczaj znak że problem jest gdzieś wcześniej np.

  • zapis do pamięci gdzieś gdzie pisać nie powinno
  • użycie zewnętrznych DLL i korzystanie ze złego API (zły call conversion albo nie takie typy parametrów)
    Wtedy błędy mogą są "ciekawe" i gwarantują wiele godzin "przyjemnej zabawy"

A wracając do tematu:
ustawił bym breakpoint na pierwszej linii i oglądał kod linia po linii debuggerem.
Bo kod sam s sobie jest OK , ale jak gdzieś będzie NULL (albo kosmos) to pojawi się taki wyjątek


--
Nie przyjmuję reklamacji za moje rady, używasz na własną odpowiedzialność.
Programowanie bez formatowania to jak chodzenie ze spodniami spuszczonymi na kostki. Owszem da się ale po pierwsze nie wygodne, po drugie nieprzyzwoicie wygląda.
Przed zaczęciem nowego wątku przeczytam problem XY
flowCRANE
Moderator Delphi/Pascal
  • Rejestracja:ponad 13 lat
  • Ostatnio:około godziny
  • Lokalizacja:Tuchów
  • Postów:12175
0
Adamek Adam napisał(a):

[…] zły call conversion albo nie takie typy parametrów) […]

Jak już coś to zły call convention, bo to o konwencję wywołania chodzi, a nie o jakąś konwersję. ;)


Pracuję nad własną, arcade'ową, docelowo komercyjną grą z gatunku action/adventure w stylu retro (pixel art), programując silnik i powłokę gry od zupełnych podstaw, przy użyciu Free Pascala i SDL3. Więcej informacji znajdziesz na moim mikroblogu.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.