---

Hej.

For synsmæssigt skyld ønsker jeg nogle kanter / borders på enkelte
labels.

Kan det ikke lade sig gøre?

Det dur ikke med editbokse i stedet for labels af andre årsager.

På forhånd tak.

---

<ms1@skindbeni.dk> skrev i en meddelelse
news:1123484217.703177.246340@g47g2000cwa.googlegroups.com...

<For synsmæssigt skyld ønsker jeg nogle kanter / borders på enkelte
<labels.


TLabel har ikke de egenskaber som du er ude efter (BevelKind / Border) men
du kan måske bruge StaticText komponenten (Additional palette), som har
disse properties, og som også kan bruges som label.

Alternativt kunne du lave din egen klasse, nedarvet fra TCusomLabel og
tilføje de properties som du skal bruge.


Mvh.
Poul

---

Hvad er forskellen ellers på Label og StaticText.

Her tænker jeg på, om label kan betegnes som den forældede udgave af
StaticText.

Med andre ord. Hvis StaticText er label med flere muligheder, så kan
det vel ikke svare sig at anvende label fremover.

Eller hvad er fordele/ulempler/formål ved dette.

---

<ms1@skindbeni.dk> skrev i en meddelelse
news:1123499983.438915.138990@o13g2000cwo.googlegroups.com...
<<Hvad er forskellen ellers på Label og StaticText.

TLabel er GraphicControl
TStaticText er TWinControl

Den sidstnævnte har et hwnd (handle), hvilket giver mulighed for at sende
MESSAGEs til den.

Man kan ikke sige at TLabel er forældet, den er bare mere enkel, mens
TStaticText er mere avanceret. I princippet er det to forskellige løsninger
til samme opgave - at udskive tekst på formen.

Hilsen
Poul S.

---

Poul S. wrote:

>
> <ms1@skindbeni.dk> skrev i en meddelelse
> news:1123499983.438915.138990@o13g2000cwo.googlegroups.com...
> <<Hvad er forskellen ellers på Label og StaticText.
>
> TLabel er GraphicControl
> TStaticText er TWinControl
>
> Den sidstnævnte har et hwnd (handle), hvilket giver mulighed for at sende
> MESSAGEs til den.
>
> Man kan ikke sige at TLabel er forældet, den er bare mere enkel, mens
> TStaticText er mere avanceret. I princippet er det to forskellige
> løsninger til samme opgave - at udskive tekst på formen.

Og så er der lige den tvist at en TWinControl tager betydeligt flere
resourcer. Hvis man har mange små labels på formen er det ikke helt
ligegyldigt.

--
M.V.H
Christian Iversen

---

"Christian Iversen" <chrivers@iversen-net.dk> skrev i en meddelelse
news:14804224.h3JJQF5buk@iversen-net.dk...

> Og så er der lige den tvist at en TWinControl tager betydeligt flere
> resourcer. Hvis man har mange små labels på formen er det ikke helt
> ligegyldigt.


jeg er bare lidt nysgerrig - hvordan kan man se hvilken komponent fylder
mest (selfølgelig uden at kompilere programmet og kigge på exe-størrelsen) ?
Jeg har prøvet med SizeOf men det er vist pointer-størrelsen man får på den
måde (4 bytes i begge tilfælder)

/Mvh. Poul

---

"Poul S." <nospam@hotmail.com> wrote

> jeg er bare lidt nysgerrig - hvordan kan man se hvilken komponent
> fylder mest (selfølgelig uden at kompilere programmet og kigge på
> exe-størrelsen) ?

Jeg ved det ikke. Men jeg ved at det ikke bare er hukommelsesforbruget,
der er problemet med TWinControl. Windows har en vis mængde handles,
der bruges til grafiske elementer. Løber den tør, er der problemer.
Mere RAM i maskinen hjælper ikke på dette.

Jeg har selv problemet i et program, hvor jeg laver et panel med
knapper o.l. for hvert billede der åbnes. Åbnes der 150-200 billeder,
løber Windows tør for handles og programmet låser (Windows XP Pro).

---

"Toke Eskildsen" <darkwing@daimi.au.dk> skrev i en meddelelse
news:Xns96ACA1617CD3Ctokeeskildsen@130.226.1.34...
> "Poul S." <nospam@hotmail.com> wrote
>
>> jeg er bare lidt nysgerrig - hvordan kan man se hvilken komponent
>> fylder mest (selfølgelig uden at kompilere programmet og kigge på
>> exe-størrelsen) ?
>
> Jeg ved det ikke. Men jeg ved at det ikke bare er hukommelsesforbruget,
> der er problemet med TWinControl. Windows har en vis mængde handles,
> der bruges til grafiske elementer. Løber den tør, er der problemer.
> Mere RAM i maskinen hjælper ikke på dette.
>
> Jeg har selv problemet i et program, hvor jeg laver et panel med
> knapper o.l. for hvert billede der åbnes. Åbnes der 150-200 billeder,
> løber Windows tør for handles og programmet låser (Windows XP Pro).

Man kan da hurtig lave et program der opretter f.eks. 5000 TStaticText på en
form uden at programmet går ned, programmet virker godt nok sløvt men det
går ikke ned?

/HK

---

Harald wrote:

> Man kan da hurtig lave et program der opretter f.eks. 5000
> TStaticText på en form uden at programmet går ned, programmet
> virker godt nok sløvt men det går ikke ned?

Jeg prøvede og nåede til mellem 4600 og 4700, før programmet døde og
trak Delphi 2005 PE med sig ned. Windows XP Pro SP2, 1GB RAM.

Koden var som følger:

procedure TForm1.Button1Click(Sender: TObject);
var
i: integer;
t: TStaticText;
begin
for i:= 1 to 5000 do
begin
t:= TStaticText.Create(self);
t.Caption:= 'Hello' + IntToStr(c);
t.Parent:= self;
Inc(c);
if i mod 100 = 0 then caption:= intToStr(c);
end;
caption:= intToStr(c);
end;

Jeg havde en del andre programmer åbne, så det kan være at grænsen er
lidt højere for andre.
--
Toke Eskildsen - http://ekot.dk/

---

"Toke Eskildsen" <darkwing@daimi.au.dk> skrev i en meddelelse
news:Xns96ACADEFB226Ftokeeskildsen@130.225.247.90...

> Jeg prøvede og nåede til mellem 4600 og 4700, før programmet døde og
> trak Delphi 2005 PE med sig ned. Windows XP Pro SP2, 1GB RAM.
>

Jeg har også prøvet at køre koden og det tog ca.26 sekunder at nå frem til
5000.
Har Delphi 7 Pro, XP SP2, Pentium 3 GHz 504 MB

Mon ikke det er endnu et eksempel på hvor ustabil Delphi 2005 er..


Mvh /Poul

---

Poul S. wrote:

> Jeg har også prøvet at køre koden og det tog ca.26 sekunder at nå
> frem til 5000.
> Har Delphi 7 Pro, XP SP2, Pentium 3 GHz 504 MB
>
> Mon ikke det er endnu et eksempel på hvor ustabil Delphi 2005 er..

Problemet er der også ved D6PE. Jeg tvivler også på at det skulle være
en særlig begrænsning i PE-versionerne. Hvis det var, ville den være
sat meget lavere.

Det er selvfølgelig en mulighed at det er mit system, der er lidt
underligt. Det passer bare ikke med de meldinger jeg får fra andre
brugere af mit program ( http://ekot.dk/JPEGCrops/ ): De melder at der
er en grænse omkring de 150-200 billeder, en meldte sågar den gik
omkring de 100.

Jeg har dog ikke undersøgt det systematisk, så det er selvfølgelig en
mulighed at tilbagemeldernes systemer har haft samme skavank som midt.

Det her virker relevant:
http://support.microsoft.com/?kbid=894500
--
Toke Eskildsen - http://ekot.dk/

---

"Toke Eskildsen" <darkwing@daimi.au.dk> skrev i en meddelelse
news:Xns96ACCA3479FDFtokeeskildsen@130.225.247.90...

> Problemet er der også ved D6PE. Jeg tvivler også på at det skulle være
> en særlig begrænsning i PE-versionerne. Hvis det var, ville den være
> sat meget lavere.
....
>
> Det her virker relevant:
> http://support.microsoft.com/?kbid=894500


Jeg har prøvet at undersøge "loftet" på mit system ved at øge tallet af
komponenter til 10 000. Der nåede programmet aldrig til, da debuggeren
afbrød kørslen omkring tallet 9800 og det næste var at delphi gik ned med et
brag...

Det der står på support siden er relateret til .NET, men det er jo stadig
win32 platformen som det hele bliver afviklet på, så en begrænsning på
styresystemets niveau må også gælde for frameworket. Sætning :

" Windows NT-based computers are limited to 10,000 Graphics "

passer jo meget godt som en forklaring til mit research-resultat.


Mvh
/Poul

---

"Poul S." <nospam@hotmail.com> wrote

[Poul S. nåede ca. 9800]

> " Windows NT-based computers are limited to 10,000 Graphics "
>
> passer jo meget godt som en forklaring til mit research-resultat.

Det passer rigtig godt. Når man debugger et program inde fra Delphi,
tæller det vel med i Delphis 10.000 handles? Et par hundrede handles
lyder ikke urealistisk for det udviklingsværktøj.

Der er to mysterier tilbage: Hvorfor kommer jeg ikke over de 5000 og
hvorfor kan Harald passere de 10.000?

http://weblogs.asp.net/kdente/archive/2004/06/04/148145.aspx
er interessant. Jeg har tidligere haft nogen af de problemer, der
beskrives der og det ser ud til at tallet 10.000 ikke er hugget i sten.
Jeg har dog ikke haft tid til at prøve at sætte grænsen op.

---

"Toke Eskildsen" <darkwing@daimi.au.dk> skrev i en meddelelse
news:Xns96ACADEFB226Ftokeeskildsen@130.225.247.90...
> Harald wrote:
>
>> Man kan da hurtig lave et program der opretter f.eks. 5000
>> TStaticText på en form uden at programmet går ned, programmet
>> virker godt nok sløvt men det går ikke ned?
>
> Jeg prøvede og nåede til mellem 4600 og 4700, før programmet døde og
> trak Delphi 2005 PE med sig ned. Windows XP Pro SP2, 1GB RAM.
>
> Koden var som følger:
>
> procedure TForm1.Button1Click(Sender: TObject);
> var
> i: integer;
> t: TStaticText;
> begin
> for i:= 1 to 5000 do
> begin
> t:= TStaticText.Create(self);
> t.Caption:= 'Hello' + IntToStr(c);
> t.Parent:= self;
> Inc(c);
> if i mod 100 = 0 then caption:= intToStr(c);
> end;
> caption:= intToStr(c);
> end;
>
> Jeg havde en del andre programmer åbne, så det kan være at grænsen er
> lidt højere for andre.

Jeg kørte til 10000 uden problemer, Delphi 7 pro, windows XP pro SP2, 640MB
RAM. 1.2GHz

Kode er:

procedure TForm1.Button1Click(Sender: TObject);
var
i : integer;
begin
for i:=0 to 10000 do
with TStaticText.Create(self) do
begin
if (i mod 100)=0 then
self.caption:=inttostr(i);
left:=(i mod 50)*10;
top:=(i div 50)*10;
Caption:='Hello '+inttostr(i);
Parent:=Self;
end;
end;

Ja den er go nok med de (kun) 1.2 GHz så det tager laaaaaaaaaag til at nå de
10000, men den gør det

/HK

---

Poul S. wrote:

>
> "Christian Iversen" <chrivers@iversen-net.dk> skrev i en meddelelse
> news:14804224.h3JJQF5buk@iversen-net.dk...
>
>> Og så er der lige den tvist at en TWinControl tager betydeligt flere
>> resourcer. Hvis man har mange små labels på formen er det ikke helt
>> ligegyldigt.
>
>
> jeg er bare lidt nysgerrig - hvordan kan man se hvilken komponent fylder
> mest (selfølgelig uden at kompilere programmet og kigge på exe-størrelsen)

Exe-størrelsen og lager-størrelsen er to helt forskellige tal. Du kan
sagtens have et lille program der lægger systemet ned resourcemæssigt,
eller et stort der ikke belaster det sønderligt.



> ? Jeg har prøvet med SizeOf men det er vist pointer-størrelsen man får på
> den måde (4 bytes i begge tilfælder)

Det er fordi alle objekter er pointere, så det passer faktisk alt sammen

Hvis du vil se lagerstørrelsen af et objekt, bruger du .InstanceSize. Den
hedder muligvis noget andet, lignende.

Vær opmærksom på at det kun giver dig størrelsen af objektet set ud fra dit
programs synspunkt. For eksempel allokeres der et window handle til
TStaticText, som ikke allokeres til TLabel. Det betyder ikke at
InstanceSize nødvendigvis er forskellige, men de gør alligevel vidt
forskellige brug af resourcerne på maskinen. (mere præcist: windows
allokerer lager til dit handle, hvilket tager en ikke-specificeret mængde
plads)

--
M.V.H
Christian Iversen

---

"Christian Iversen" <chrivers@iversen-net.dk> skrev i en meddelelse
news:1275862.KEm7d97vd9@iversen-net.dk...

> Hvis du vil se lagerstørrelsen af et objekt, bruger du .InstanceSize. Den
> hedder muligvis noget andet, lignende.


Det er også rigtigt. Sjovt at størrelsen ikke ændrer sig, hvis man gør
caption-strengen længere.


>Exe-størrelsen og lager-størrelsen er to helt forskellige tal. Du kan
>sagtens have et lille program der lægger systemet ned resourcemæssigt,
>eller et stort der ikke belaster det sønderligt.


ok, betyder det så at der allokeres to forkellige hukommelse-bid til
programmets kode og resourcer? Så vidt jeg kan huske er der ikke noget
begrænsning på hvor meget kode et program kan indeholde (ok, slå mig hvis
jeg tager fejl :)- ), men resourcer styres af windows, som sætter et loft på
10 000 HWNDs (på NT systemer). Man sku tro at resourcer og kode placeres 2
forskellige steder i hukommeslen..

/poul

---

"Poul S." <nospam@hotmail.com> wrote in message
news:42f7bd0f$0$7372$ba624c82@nntp02.dk.telia.net...
>
> Det er også rigtigt. Sjovt at størrelsen ikke ændrer sig, hvis man gør
> caption-strengen længere.

Det er fordi strengen oprettes dynamisk og dermed kun tæller med i
instancesize som en pointer (4 bytes).

hilsen
Uffe