Witam,
mam listview i potrzebuję rozszerzyć troszkę zakres informacji jakie przechowują listitem'y. W tej chwili wygląda to tak że mam tablicę rekordów z potrzebnymi mi zmiennnymi, którą staram się aktualizować "równolegle" do danych w listview. Aplikacja korzysta z baz danych i chcę w tabeli dać te informacje które są naprawdę potrzebne, a takie w stylu id (primary key, potrzebne tylko bazie do działania) schować i nie zawracać nimi głowy użytkownikowi.
Dałoby się w jakiś prosty sposób poszerzyć listitem o niewidoczne, dodatkowe zmienne?
- Rejestracja:około 14 lat
- Ostatnio:prawie 12 lat
- Postów:59
0
Delphi 
- Rejestracja:prawie 17 lat
- Ostatnio:około 3 lata
- Lokalizacja:Szczecin
- Postów:4191
1
Komponenty przechowujące TStrings mają jeszcze własność Objects i metodę AddObject. Natomiast TListView ma własność Data i Metodę AddItem. Możesz dzięki nim przechowywać tworzone konstruktorem obiekty klasy TObject. Przykład dodawania i wyświetlenia poniżej:
//...
type
TCosik = class(Tobject)
Tekst : string;
Liczba : integer;
end;
type
TForm1 = class(TForm)
Button1 : TButton;
ListView1 : TListView;
procedure Button1Click(Sender : TObject);
procedure ListView1Click(Sender : TObject);
private
public
Cosik : TCosik;
end;
var
Form1 : TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender : TObject);
var
LI : TListItem;
begin
Cosik := TCosik.Create;
Cosik.Liczba := 58;
Cosik.Tekst := 'test';
LI := ListView1.Items.Add;
LI.Caption := 'bleble';
LI.Data := Cosik;
end;
procedure TForm1.ListView1Click(Sender : TObject);
var
LI : TListItem;
begin
LI := ListView1.Items[ListView1.ItemIndex];
if LI <> nil then
begin
Cosik := TCosik(Li.Data);
ShowMessage(Cosik.Tekst + #13#10 + IntToStr(Cosik.Liczba));
end;
end;
Edit: O_o mnie ubiegł. Można oczywiście wykorzystać Tag, ale ja preferuje obiekty tak, jak pokazałem powyżej.
edytowany 2x, ostatnio: olesio
O_o
Gdy robiłem w Delphi to bardzo agresywnie molestowałem Tag, robiłem dziadowski obiekt Data i pakowałem tam jego wskaźnik, nie jest to dobra praktyka bo trudno dbać o zwolnienie pamięci ale robiłem to zazwyczaj w takich małych dziadostwach które miały tylko coś zrobić i zdechnąć więc się tym nie przejmowałem ;)
- Rejestracja:około 14 lat
- Ostatnio:prawie 12 lat
- Postów:59
0
no z dziedziczeniem też myślałem, ale tak przerobić dziedzica tlistview'a żeby korzystał z dziedziców tlistitem'ów to jednak jeszcze zbyt trudne dla mnie. za to pomysł O_o i kod olesia bardzo mi się podobają. Tylko jedno pytanko: jak przerzucę Cosik:TCosik; do var procedury która tego listitem'a dodaje, to coś się zmieni? Bo w tej chwili wydaje mi się że utworzy się obiekt TCosik, w zmiennej Cosik będzie jego wskaźnik który potem będzie co prawda skopiowany do LI.Data, ale w zmiennej Cosik dalej zostanie wskaźnik, i próba utworzenia kolejnego obiektu w tym miejscu zakończy się Accessem Violationem? Takie moje przypuszczenia po przykrych praktykach, zaraz sprawdzę w praktyce. :)
Delphi się nie włącza po ostatnim braku prądu. Pociąć się czy od razu powiesić...
już ok na chwilę tylko zaniemógł. kod jednak działa ;) jak śmiałem wątpić... a czy Cosiki trzeba potem ręcznie .Free? Czy znikną same?
Mój sposób zignoruj ;) Olesiowy daje to samo co mój a jest lepszy ;)
- Rejestracja:prawie 17 lat
- Ostatnio:około 3 lata
- Lokalizacja:Szczecin
- Postów:4191
0
O ile się orientuje to będzie fizycznie obiekt dodany do TListItem. Zobacz sobie w działaniu taki kod jak poniżej i poklikaj na elementy TListView. Nie będzie żadnego AV i wszystko powinno być ok.
var
I : integer;
LI : TListItem;
begin
for I := 1 to 10 do
begin
Cosik := TCosik.Create;
Cosik.Liczba := I;
Cosik.Tekst := 'test ' + IntToStr(I);
LI := ListView1.Items.Add;
LI.Caption := IntToStr(I);
LI.Data := Cosik;
end;
end;
A nie trzeba będzie przy usunięciu elementu z listy usunąć cosika? Dawno nie robiłem w Delphi ale pamiętam jak mi wywaliło kiedyś błąd brzmiący jakoś tak: "za mało miejsca w magazynie na wykonanie operacji" bo przy 30fps tworzyłem TImage w każdym obrocie pętli i zapomniałem go usunąć ;)
- Rejestracja:prawie 19 lat
- Ostatnio:około 22 godziny
- Postów:819
0
The TStrings object does not own the objects in the Objects array. Objects added to the Objects array still exist even if the TStrings object is destroyed. They must be explicitly destroyed by the application.
edytowany 1x, ostatnio: pelsta
- Rejestracja:prawie 17 lat
- Ostatnio:około 3 lata
- Lokalizacja:Szczecin
- Postów:4191
0
No fakt, do TStrings nie miałem pewości, bo w przypadku TList należy zwolnić obiekty przez zniszczeniem TList, ale widac, że w przypadku TStrings jest tak samo.
Ten mój post był nie za bardzo na temat, bo Wy piszecie o TListItem.Data:Pointer a ja o TStrings.Objects:TObject
- Rejestracja:prawie 17 lat
- Ostatnio:około 3 lata
- Lokalizacja:Szczecin
- Postów:4191
0
Poproszę Miśkad aby wypowiedzial się - jak znajdzie czas w tym temacie, bo w helpie do Delphi 7 widzę tylko taki zapis o własności Data:
Specifies any application-specific data associated with the list item.
Delphi syntax:
property Data: Pointer;
C++ syntax:
__property void * Data = {read=FData, write=SetData};
Description
Use Data to associate arbitrary data structure with the list item. When the user selects or deletes the list item, Data allows the application to quickly access information about the meaning of the list item to implement the appropriate response.
Natomiast ze źródel ComCtrls.pas nie umiem sam wywnioskować, bo na pewno destruktor TListView zwalnia niepublicznie dostępną zmienną dla listy Itemów, ale jak jest przy usuwaniu to pewności nie mam, bo z kodu nie umiem tego sam za bardzo wywnioskować. Ponieważ z kodu wynika, że element jest usuwany i chyba tyle. Wiem, że na pewno dla TList należy przed jej zwolnieniem zwolnić pamięć jej elementów, bo destruktor tego nie robi, a o czym poinformował mnie kiedyś właśnie Misiekd. Bo przyznam, że mam może zly nawyk, ale dotychczas w swoich aplikacjach jak korzystałem z Objects w TStrings czy Data w TListView to nie zwalniałem osobno ów obiektów, a TList tylko przez destructor. Wiem, że to nie za dobry nawyk, ale do tej pory przechowywane dane nie były jakimiś wielkimi typami, chociaż należy wszystko przewidzieć, że u kogoś może program się wywalić z błędem o braku pamięci, jeśli takich pozornie niewielkich danych będzie dużo.
edytowany 2x, ostatnio: olesio
- Rejestracja:ponad 21 lat
- Ostatnio:ponad 12 lat
- Postów:7923
1
Data to tylko Pointer. Skąd kompilator ma wiedzieć czy jest tam wskaźnik utworzony przez New i trzeba go zwolnić przez Dispose, czy pamięć zaalokowana przez GetMem i trzeba ją zwolnić przez FreeMem czy jest to obiekt i trzeba go zwolnić przez .Free a może programista odwołuje się do tych obiektów i wręcz nie wolno go zwalniać. Zasada jest bardzo prosta - cokolwiek sam stworzyłeś powinieneś także sam zwolnić. Nie stosuje się tego min. do form, które mają ustawiane w OnClose Action := caFree, do wątków, które mają ustawione FreeOnTerminate := True oraz do komponentów, które mają ustawionego Ownera (w momencie niszczenia owner sprawdza, czy ma coś do niszczenia i to niszczy). Wyjątkiem tutaj jest jedynie lista TObjectList z ustawioną własnością OwnsObject na True i wszystkie listy po niej dziedziczące.
edit
Wszystkim, którzy używają Delphi < 2006 polecam ściągnąć sobie FastMM i dodać go na początku sekcji uses w pliku projektu (.dpr) oraz w ustawieniach (plik inc) odblokować raportowanie wycieków pamięci. W Delphi >= 2006 to samo robi ustawienia zmiennej ReportMemoryLeaksOnShutdown na True.
Tutaj pokrótce jak się tego używa i co to daje
edytowany 3x, ostatnio: Misiekd
- Rejestracja:ponad 19 lat
- Ostatnio:2 miesiące
0
... cokolwiek sam stworzyłeś powinieneś także sam zwolnić ...
Zasada bardzo prosta i bardzo przydatna. Lecz w Delphi ma pewne wyjątki, jeżeli dynamicznie stworzyłeś jakiś komponent to nie musisz go sam zwalniać, ponieważ za zwolnienie odpowiada AOwner przekazywany jako parametr konstruktora.
a potrafisz przeczytać więcej niż 7 słów wytłuszczoną czcionką czy przekracza to twoje możliwości intelektualne???
heh, wygląda na to że nie potrafię, ale mam usprawiedliwienie jestem wciąż na zwolnieniu lekarskim i mam gorączkę ;P