Formy MDI - access violation przy próbie dostępu do zmiennych

Witam !

Buduję aplikacje wielookienkową i stwierdziłem, że najlepszym rozwiązaniem będzie zastosowanie okien potomnych. Wszystko fajnie ale napotkałem jeden problem. Otóż:
Główne okno czyta port szeregowy. Po otrzymaniu danego ciągu danych wyszukuje odpowiednią formę i wywołuje jej procedurę która ma utworzyć wiadomość zwrotną. Procedury z głównego okna wywołuje bezproblemowo jednak: Wywołane funkcje działają ale nie mają dostępu do zmiennych i właściwości swojej klasy. Procedury zdarzeniowe (np. kliknięcie btn) mają do nich dostęp ale gdy wywoła je główna forma to już nie.

Wyszukiwanie formy i uruchamianie procedury w danym oknie

MdiIndex := -1;

for i:=0 to MDIChildCount-1 do
  if TChildWin(MDIChildren[i]).Config.ID = SearchID then
     MdiIndex := i;

  if MdiIndex >= 0 then
     TChildWin(MDIChildren[i]).AnalyzeFrame(RecvArr,RecvStep);

Czy coś mogłem przeoczyć ?

dodanie znacznika <code class="delphi"> - furious programming

jeśli dostajesz AV to w tym przypadku albo MDIChildren[i] jest nil albo nie jest typu TChildWin. DO takich rzeczy jest debugger i jego należy użyć i zobaczyć co jest nie tak

lycon5 napisał(a):

Witam !
Buduję aplikacje wielookienkową i stwierdziłem, że najlepszym rozwiązaniem będzie zastosowanie okien potomnych.

Potomnych, jasne - ale czy na pewno MDI? Prawie w ogóle się tego dziś nie używa...
A co to w ogóle za aplikacja, czyli jakie dane będą prezentowane na tych oknach?

Wszystko fajnie ale napotkałem jeden problem. Otóż:
Główne okno czyta port szeregowy. Po otrzymaniu danego ciągu danych wyszukuje odpowiednią formę i wywołuje jej procedurę która ma utworzyć wiadomość zwrotną.

Moim zdaniem, powinieneś rejestrować te okna w strukturze TDictionary (lub podobnej, nawet w posortowanym TStringList i dodawać okna przez StringList.AddObject), po to aby mieć szybki i pewny dostęp do ich instancji. Iteracja jest OK, ale taka jakaś krzywa...

Procedury z głównego okna wywołuje bezproblemowo jednak: Wywołane funkcje działają ale nie mają dostępu do zmiennych i właściwości swojej klasy. Procedury zdarzeniowe (np. kliknięcie btn) mają do nich dostęp ale gdy wywoła je główna forma to już nie.

Wyszukiwanie formy i uruchamianie procedury w danym oknie

 MdiIndex := -1;
for i:=0 to MDIChildCount-1 do
  if TChildWin(MDIChildren[i]).Config.ID = SearchID then
     MdiIndex := i;

  if MdiIndex >= 0 then
     TChildWin(MDIChildren[i]).AnalyzeFrame(RecvArr,RecvStep);

Czy coś mogłem przeoczyć ?

Tak, nie sprawdzasz czy okna są potomkiem klasy TChildWin, a więc:

  MdiIndex := -1;
  for i:=0 to MDIChildCount-1 do
    if (MDIChildren[i] is TChildWin) and (TChildWin(MDIChildren[i]).Config.ID = SearchID) then
       MdiIndex := i;

  if MdiIndex >= 0 then
     TChildWin(MDIChildren[i]).AnalyzeFrame(RecvArr,RecvStep);

Ale nie podoba mi się ten kod, napisałbym go zupełnie inaczej.
Przede wszystkim wydzieliłbym funkcjonalność AnalyzeFrame to osobnego interfejsu, który dana klasa (okna, ale nie może być dowolna) implementowałaby go przez delegację.
Dodatkowo rejestrowałbym takie interfejsy we własnej strukturze, tak aby był szybki i pewny dostęp do danych.
Całą interakcję z oknem zrobiłbym na zasadzie kontroloera, tak aby zajął się tylko obsługa danego interfejsu i powiadamianiem odpowiednich kontrolek o zmianie stanu.
Jeśli masz dostęp do Delphi od XE2 w górę, to można to zrobić o wiele łatwiej i szybciej korzystając z System.Generic.Collections oraz LiveBindings.

Jest tylko jeden typ okna potomnego, więc nie jest konieczne aby za każdym razem sprawdzać czy to ta klasa. Błąd był w pętli for. Dopiero na drugi dzień zauważyłem, że używałem zmiennej i a nie MdiIndex, przez co rzeczywiści odwoływałem się do nie istniejącego obiektu. Przepraszam, za zamieszenie :P Nie zgodzę się natomiast co do jakości kodu. Specjalnie (a wręcz z premedytacją) umieściłem wszystkie funkcje obróbki danych w klasie potomnej aby kod by jak najbardziej przejrzysty. Po prostu nie chciałem śmiecić w klasie głównej :)

lycon5 napisał(a):

Jest tylko jeden typ okna potomnego, więc nie jest konieczne aby za każdym razem sprawdzać czy to ta klasa. Błąd był w pętli for. Dopiero na drugi dzień zauważyłem, że używałem zmiennej i a nie MdiIndex, przez co rzeczywiści odwoływałem się do nie istniejącego obiektu.
Przepraszam, za zamieszenie :P

Skoro to tak ma działać, to dlaczego nie w ten sposób?

  for i:=0 to MDIChildCount-1 do
    if (MDIChildren[i] is TChildWin) and (TChildWin(MDIChildren[i]).Config.ID = SearchID) then
    begin
       TChildWin(MDIChildren[i]).AnalyzeFrame(RecvArr,RecvStep);
       Break;
    end;

Nie zgodzę się natomiast co do jakości kodu. Specjalnie (a wręcz z premedytacją) umieściłem wszystkie funkcje obróbki danych w klasie potomnej aby kod by jak najbardziej przejrzysty. Po prostu nie chciałem śmiecić w klasie głównej :)

A możesz się nie zgadzać, mówię co myślę na podstawie tego co przeczytałem.
Ale rozumiesz co to jest interfejs jego implementacja przez delegację?
Bo z tego co napisałeś można wysnuć wniosek, że raczej niekoniecznie...
Dzięki temu masz całkowita separację danych, przetwarzania i prezentacji. Ty wszystko wsadziłeś do prezentacji (forma potomna) i twierdzisz, że tak jest OK.
Niech będzie, ale dalej uważam że to gorsze podejście...