W procedurze podczas kompilacji występuje błąd przy Height jako Error: Duplicate identifier "Height"
protected
procedure MeasureItem(Index: Integer; var Height: Integer); virtual;
procedure TL_ListBox.MeasureItem(Index: Integer; var Height: Integer);
begin
if Assigned(FOnMeasureItem) then FOnMeasureItem(Self, Index, Height)
end;
@furious programming L_Listbox.pas kompiluje się jednak w dalszym ciągu nie mogę podświetlić items :-( kod ze strony https://github.com/project-jedi/jvcl/blob/master/jvcl/run/JvColorCombo.pas
function ItemStateToOwnerDrawState(const AState: Word): TOwnerDrawState;
begin
Result := [];
if AState and ODS_CHECKED <> 0 then Result += [odChecked];
if AState and ODS_COMBOBOXEDIT <> 0 then Result += [odComboBoxEdit];
if AState and ODS_DEFAULT <> 0 then Result += [odDefault];
if AState and ODS_DISABLED <> 0 then Result += [odDisabled];
if AState and ODS_FOCUS <> 0 then Result += [odFocused];
if AState and ODS_GRAYED <> 0 then Result += [odGrayed];
if AState and ODS_HOTLIGHT <> 0 then Result += [odHotLight];
if AState and ODS_INACTIVE <> 0 then Result += [odInactive];
if AState and ODS_NOACCEL <> 0 then Result += [odNoAccel];
if AState and ODS_NOFOCUSRECT <> 0 then Result += [odNoFocusRect];
if AState and ODS_SELECTED <> 0 then Result += [odSelected];
end;
procedure TL_ListBox.CNDrawItem(var Message: TWMDrawItem);
var
State: TOwnerDrawState;
begin
with Message.DrawItemStruct^ do
begin
State := ItemStateToOwnerDrawState(itemState);
FCanvas.Handle := hDC;
FCanvas.Font := Font;
FCanvas.Brush := Brush;
if (Integer(itemID) >= 0) and (odSelected in State) then
begin
FCanvas.Brush.Color := clHighlight;
FCanvas.Font.Color := clHighlightText
end;
if Integer(itemID) >= 0 then
DrawItem(itemID, rcItem, State) else
FCanvas.FillRect(rcItem);
if odFocused in State then DrawFocusRect(hDC, rcItem);
FCanvas.Handle := 0;
end;
end;
Kolejna wskazówka komponent zachowuje się jakby na niego był nałożony ReadOnly := True;
Nie mogę na MultiSelect ani zastosować True lub False; Kiedy dodam poniższy kod co do tej pory w kontrolce L_LISTBOX nie było nic nie uzyskuję tym ...
{ReadOnly}
TL_ListBox = class(TListBox)
private
FReadOnly : Boolean;
protected
property ReadOnly: Boolean Read FReadOnly Write FReadOnly Default False;
constructor L_LISTBOX.Create(AOwner: TComponent);
Begin
FReadOnly := False;
{MultiSelect}
TL_ListBox = class(TListBox)
private
FMultiSelect: Boolean;
procedure SetMultiSelect(Value: Boolean);
protected
property MultiSelect: Boolean read FMultiSelect write SetMultiSelect default False;
published
property MultiSelect;
procedure TL_ListBox.SetMultiSelect(Value: Boolean);
begin
if FMultiSelect <> Value then
FMultiSelect := Value;
end;
Kolejny komponent, który da się bez problemu skompilować w lazarusie. Można wybrać items w przenośni bo to nie items.strings. Wadą jest, że o kilka sekund dłużej mysle, że lo 1/2 dłużej łądują się dane z pliku niż przy TListBox delphi. No i kiedy dane są w milionach w kontrolce suwak nie działa płynnie. Jakby było brak odświeżania kontrolki. Kod https://github.com/USEPA/EPANET-legacy-user-interface/blob/master/components/VirtList.pas
Wywolanie Posiada VirtualListBox1.Count := MyList.Count;
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, VirtualListBox, Buttons, Grids;
type
TForm1 = class(TForm)
Button1: TButton;
VirtualListBox1: TVirtualListBox;
procedure VirtualListBox1GetItem(Sender: TObject; Index: Integer;
var Value: String; var aColor: TColor);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
MyList : TStringlist;
TimeA,TimeB: TDateTime;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
begin
MyList := TStringlist.Create;
TimeA := StrtoDateTime(FormatDateTime('yyyy-mm-dd hh:nn:ss', Now));
MyList.LoadFromFile('ex.txt');
VirtualListBox1.Count := MyList.Count;
TimeB := StrtoDateTime(FormatDateTime('yyyy-mm-dd hh:nn:ss', Now));
Caption := TimeToStr(TimeB-TimeA);
end;
procedure TForm1.VirtualListBox1GetItem(Sender: TObject; Index: Integer;
var Value: String; var aColor: TColor);
begin
Value := Mylist[index];
end;
procedure TForm1.FormDestroy(Sender: TObject);
begin
MyList.Free;
end;
Mariusz Bruniewski napisał(a):
Wadą jest, że o kilka sekund dłużej mysle, że lo 1/2 dłużej łądują się dane z pliku niż przy TListBox delphi. No i kiedy dane są w milionach w kontrolce suwak nie działa płynnie. Jakby było brak odświeżania kontrolki. Kod https://github.com/USEPA/EPANET-legacy-user-interface/blob/master/components/VirtList.pas
Skoro przy takiej ilości danych (co w sumie jest bez sensu, ponieważ powinieneś mieć proxy na te dane, jeśli chcesz mieć super wydajnie i responsywnie) masz dziwne problemu, to dlaczego nie użyjesz czegoś co zostało specjalnie do tego napisane?
O tego (dla FPC i oczywiście do zawsze jest wersja dla Delphi):
https://github.com/blikblum/VirtualTreeView-Lazarus
I po temacie.
Chociaż nie do końca, jeżeli dalej będziesz ładował te dane do StringListy :D
Mariusz Bruniewski napisał(a):
@furious programming L_Listbox.pas kompiluje się jednak w dalszym ciągu nie mogę podświetlić items :-(
Sprawdź pod debuggerem jak wygląda słowo z Lo i czy bit dotyczący stanu ODS_SELECTED jest zapalony. Jeśli nie, to problemem nie jest konwersja, a dane dostarczane przez komunikat. A że całością steruje widgetset, to znalezienie przyczyny problemu może być bardzo trudne.
wloochacz napisał(a):
O tego (dla FPC i oczywiście do zawsze jest wersja dla Delphi):
https://github.com/blikblum/VirtualTreeView-Lazarus
Sugerowaliśmy to już kilka razy, ale OP jest uparty i na siłę chce wykorzystać ListBoxa.
@wloochacz Wyobraź sobie ostatnie losowanie Lotto (Duży Lotek) z dnia 25-03-2021 r. To liczby: 2021-03-25 05 19 34 43 44 46
Przedstawie Tobie filtry w postaci screenów :-) Jak widzisz na obraz ex2 dane nie są ładowane do listy. Obraz ex3 to 3 parzyste 3 nieparzyste. Kolejny filtr np. Dalej wyobraź sobie, że z rozkładu normalnego Gaussa potrafisz wskazać, że w tym losowaniu wypadnie liczba np. 46 - obraz ex4 Obraz ex5 2 niskie 4 wysokie. Obraz ex6 przedstawia prawdopodobieństwo :-) Mogę dalsze filtry stosować. Zatem o czym ty do mnie mówisz :-) To jest błędem stosowania znacznej ilości do TListBox? Jesteś w błędzie. To samo o czym pisałeś ja stosuje.
@Szalony Programista to z populacji. Przy rozkładzie z próby x prób np. 100 rozkład normalny gaussa zostanie zachowany ;-)
@szatkus jeśli nie umiesz czytać statystyk to nic nie wyniknie dla ciebie. Dla mnie ten np. wykres dużo mówi (stanowi) w populacji jakie liczby stosować. Następnie odnoszę to do próby danego trendu.
Myślę, że Pan @Adam Boduch admin zna konwersję. Od początku brnął od delphi 6.
No dobrze przedstawcie kod, w którym odczytam dane w 6s z pliku txt 14 mln linii. Kod ma działać w lazarusie! Pytanie poprzez negację. Nikt takiego kodu nie wystawił Ja wystawiłem. Czekam ... nie na kody lecz na demo... I zostałem skrytykowany po co te linie ładować do kontrolki? Chyba programiści zadając mi te pytanie jeszcze działają na systemie Windows XP i z systemem pamięci poniżej 2GB.
Jeśli chodzi o optymalizacje, to można powiedzieć że jestem jaroszem.
Wczytać cały plik do pamięci i później do kontrolki listbox, prawdopodobnie będzie wyglądało tak, że system wczyta plik z opóźnieniem(hdd/ssd/internet) do pamięci ram, a później całą tą pamięć znaki ASCII wyrenderuje w buferze zastosowując określoną czcionkę, która będzie przekopiowywana do listboxa w zależności od ustawienia scrollbara.
Można też wczytywać plik w partiach lub zastosować mapowanie pliku wtedy system zajmie się wczytywaniem(zwykle opóźnionym do czasu próby odczytu) z dysku.
Te dane można wyświetlić w sumie na takie powiedzmy 3 sposoby.
Pierwszy to cały plik do listboxa.
Drugi załadować pierwsze 1-10 tys linijek i jeśli scrollbar dojdzie do 90-100% końca to doładować kolejne 1-10 tys linijek dodając do już istniejących append. Nazwa tego to infinite loading.
Trzeci to dodać buttony < >, załadować pierwszą stronę np. 1 tyś linijek i po kliknięciu przycisku next, załadować do listboxa następną stronę, nadpisując zawartość listboxa.
Można by było też popatrzeć na profilerze jak wypada nasz program i co go mocno spowalnia.
Ciekawe statystyki i wnioski można uzyskać na temat naszego programu.
Nie żyjemy w czasach WXP - po prostu to jest głupie co robisz. Właśnie przez prędkość odczytywania nie ma sensu ramu zaśmiecać... Ale Twoja sprawa. Nie jest też wyczynem zrobienie takiego kodu jak proponujesz bo to wymaga raptem 180MB/s odczyty z dysku przy unicode a przy ANSI czy formacie binarnym jeszcze mniej. Zresztą do takich rzeczy wybrałeś źle narzędzie. Do analizy takich danych to ja bym użył SASsa Matlaba, Octave... A nie kompilowany język do robienia apel z GUI miedzyplatformowo... O ile w ogóle analiza statystyczna gry losowej ma jakikolwiek cel. Juz mądrzejsze jest analizowanie trwałości żarówek celem odkrycia wzorca spisku.
Wskazuje kod ze strony https://github.com/alrieckert/lazarus/blob/master/lcl/lcltype.pp
// ToDo: move this to StdCtrls
TOwnerDrawStateType = (
odSelected, odGrayed, odDisabled, odChecked,
odFocused, odDefault, odHotLight, odInactive, odNoAccel,
odNoFocusRect, odReserved1, odReserved2, odComboBoxEdit,
odPainted // item already painted
);
TOwnerDrawState = set of TOwnerDrawStateType;
@furious programming Wygląda na to, że cały czas broi state
Sprawdzałem na delphi 7
//State := TOwnerDrawState(LongRec(itemState).Lo); {jeśli wykluczę w d7 to załącznik ex podczas kliknięcia na items wygląda to tak jak na obrazku.
W lazarusie mam wrażenie, że na kontrolkę jest nałożony Readonly.
Kiedy modyfikuje za Twoją pomocą state lub, gdy go w ogóle nie zastosuje mam taki efekt sam jak w d7}
State := TOwnerDrawState(LongRec(itemState).Lo); {jeśli zastosuję to załącznik ex1}
@pragmaticdev załadowane do kontrolki 2 miliardy linii. Jak myślisz, czy pamięć *.exe wzrosła? W żaden sposób :-) Gdybyś chciał dokonać zrzutu tego co jest w kontrolce dysku by Tobie zabrakło. Czas utworzenia danych w kontrolce poniżej jednej sekundy :-) Zatem to nie problem kontrolki, lecz Ty odpowiedz znasz :-) Ja również :-) Po drugie są programy do odzyskiwania danych po sektorowych z dysku. Potrafią dane np. 1TG odczytać w kontrolce jak te dane wyglądają dla oka :-)
https://www.filmweb.pl/film/Rain+Man-1988-1008 ten film pasuje mi do tego wątku - czy ktoś ma podobne odczucia?
Mi się wydaje, że ktoś zbliżył się za bardzo do czarnej dziury i zajrzał poza horyzont zdarzeń. Miliardy alokacji pamięci, nie zwiększające pamięci procesu. Dane wczytywane ze strumienia świadomości bo nie z dysku - nie ma takich dysków twardych co by to zmieściły. Mistycznie odczytywane Tera Gajty danych z kontrolek, które zaczytały tylko miliardy linii (chyba jakiejś świadomości). Hemoglobina przez negację ;-). Ta łamana polszczyzna, to wyciek czasu z przyszłości, która łączy się z przeszłością 12 lat temu kiedy to się zaczęło. Ten program już istniał i nie istniał i jest w tym wszystkim doskonały. Billy uderzaj, uderzaj, uderzaj. Wybaczcie ale ten post nie wnosi do tematu mniej niż poprzednie posty autora. Ewakuuje się na Xandar, bo Borg trzyma dla mnie portal. Żyjcie w pokoju na tym ziemskim padole i uważajcie ze wczytywaniem miliardów danych bez alokacji bo naruszycie spójność wszechrzeczy. Pokój i TStringLista z Wami.
A jaśniej?
Powracam do wątku, gdyż nie dawał mi spokoju. Kod okroiłem do State, aby zobaczyć, gdzie w jakim uses znajduje się State nawiązując do https://bugs.freepascal.org/view.php?id=19958 StdCtrls następnie Windows Miałem tak i wywalał error, gdy Windows jest na końcu po LCL kompiluje się.
unit L_LISTBOX;
{$mode objfpc}{$H+}
interface
// do tej pory miałem tak : L_ListBox.pas Error: Illegal type conversion: "Word" to "TOwnerDrawState"
{uses Math, StdCtrls, Controls, Classes, Forms, Graphics, Messages, Windows, SysUtils, Commctrl, Types,
LResources, LCLType, LCLIntf, LMessages, LCLClasses;}
// gdy zrobilem tak: Kompilacja pakietu LLB 0.0: Zakończony powodzeniem, Podpowiedzi: 1
uses Math, StdCtrls, Controls, Classes, Forms, Graphics, Messages{, Windows}, SysUtils, Commctrl, Types,
LResources, LCLType, LCLIntf, LMessages, LCLClasses, Windows;
type
TL_ListBox = class(TlistBox)
private
procedure CNDrawItem(var Message: TWMDrawItem); message CN_DRAWITEM;
protected
public
published
end;
procedure Register;
implementation
uses RTLConsts;
procedure Register;
begin
RegisterComponents('ex',[TL_ListBox]);
end;
{ TL_ListBox }
procedure TL_ListBox.CNDrawItem(var Message: TWMDrawItem);
var
State: TOwnerDrawState;
begin
with Message.DrawItemStruct^ do
begin
...
State := TOwnerDrawState(LongRec(itemState).Lo); //delphi i lazarus
...
end;
end;
end.
W pliku StdCtrls.pp jest
type
TOwnerDrawState = LCLType.TOwnerDrawState;
W pliku: LCLType.pp
// ToDo: move this to StdCtrls
TOwnerDrawStateType = (
odSelected, odGrayed, odDisabled, odChecked,
odFocused, odDefault, odHotLight, odInactive, odNoAccel,
odNoFocusRect, odReserved1, odReserved2, odComboBoxEdit,
odPainted // item already painted
);
TOwnerDrawState = set of TOwnerDrawStateType;
Jak połączyć typy z Delphi ?
Vcl.StdCtrls.TOwnerDrawState
type TOwnerDrawState = set of (
odSelected, odGrayed, odDisabled, odChecked,
odFocused, odDefault, odHotLight, odInactive,
odNoAccel, odNoFocusRect, odReserved1, odReserved2, odComboBoxEdit);
// w Lazarusie 14 typów w delphi 13
type
TOwnerDrawState = Vcl.StdCtrls.TOwnerDrawState = LCLType.TOwnerDrawState =
set
@furious programming funkcja przedstawiona przez Ciebie zawiera 11 stanów:
function ItemStateToOwnerDrawState(const AState: Word): TOwnerDrawState;
begin
Result := [];
if AState and ODS_CHECKED <> 0 then Result += [odChecked];
if AState and ODS_COMBOBOXEDIT <> 0 then Result += [odComboBoxEdit];
if AState and ODS_DEFAULT <> 0 then Result += [odDefault];
if AState and ODS_DISABLED <> 0 then Result += [odDisabled];
if AState and ODS_FOCUS <> 0 then Result += [odFocused];
if AState and ODS_GRAYED <> 0 then Result += [odGrayed];
if AState and ODS_HOTLIGHT <> 0 then Result += [odHotLight];
if AState and ODS_INACTIVE <> 0 then Result += [odInactive];
if AState and ODS_NOACCEL <> 0 then Result += [odNoAccel];
if AState and ODS_NOFOCUSRECT <> 0 then Result += [odNoFocusRect];
if AState and ODS_SELECTED <> 0 then Result += [odSelected];
end;
LCLType.pp
//itemState
ODS_SELECTED = $0001;
ODS_GRAYED = $0002;
ODS_DISABLED = $0004;
ODS_CHECKED = $0008;
ODS_FOCUS = $0010;
ODS_DEFAULT = $0020;
ODS_HOTLIGHT = $0040;
ODS_INACTIVE = $0080;
ODS_NOACCEL = $0100;
ODS_NOFOCUSRECT = $0200;
ODS_COMBOBOXEDIT = $1000;
O ile pamiętam w uses w Delphi ładowanie nie jest skomplikowane. W lazarusie dowiaduje się, że to co zamieszczamy w uses musi być uporządkowane w architekturze projektu. Dla starszych wersji delphi obojętne było czy Windows będzie na początku czy na końcu.
furious programming napisał(a):
No to źle pamiętasz.
Nie, no bez przesady.
Rozumiem że OP jest konsekwentnie irytujący i nie warto mu odpowiadać, ale...
W Delphi to faktycznie nie ma znaczenia, co do zasady.
Oczywiście są wyjątki, jak menadżer pamięci albo zabawy z subclassing lub też przy fikołkowym kodzie w sekcji initialization danego modułu.
Tak wtedy ta kolejność ma (menadżer pamięci) i może (nie ma reguły, ale może) mieć znaczenie.
Zawsze zakładałem że w FPC jest dokładnie tak samo.
Nie jest?
wloochacz napisał(a):
Zawsze zakładałem że w FPC jest dokładnie tak samo.
Nie jest?
W tym przypadku (wątku) chodzi o to, że typ danych o nazwie TOwnerDrawState jest zadeklarowany osobno w co najmniej dwóch modułach, co powoduje, że są to różne typy danych z punktu widzenia kompilatora (zresztą nawet różnią się liczbą enumów). Dlatego bardzo istotne jest to, który moduł będzie w uses zadeklarowany jako pierwszy.
To jest standardowy konflikt identyfikatorów typów, i bez skonkretyzowania o który chodzi (prefiksując go nazwą modułu źródłowego), kompilator nie ma innej opcji jak skorzystać po prostu z pierwszego napotkanego. Myślę, że w Delphi też tak było i jest.
OP niestety nadal nie próbuje zrozumieć dlaczego jego kod się nie kompiluje i nadal nie próbuje znaleźć odpowiednich informacji w dokumentacji. Bo zamiast to zrobić, woli pisać dziwne posty, w dodatku w taki sposób, aby w nich wywyższać stare i praktycznie bezużyteczne dziś środowisko.
@pragmaticdev jak odnieść się do tego http://cc.embarcadero.com/Item/26618?
Mariusz Bruniewski