[Delphi] Listbox

[DaFearLess]

Ik wil een listbox maken in mijn programmatje

Nu heb ik de listbox gevult met data uit een txt file ik zie alles netje staat.
Maar als ik nu op button1 druk wil ik eigenlijk dat hij een showmessage doet met
de value die geselecteerd staat in de listbox.

dus ik wil eigenlijk alleen het zelfde berijken met mijn listbox als je met een combobox doet combobox1.text

ik hoop dat ik een beetje duidelijk ben.

[Reptile209]

Delphi:

try
  ShowMessage('Selectie: '+Listbox1.Items[Listbox1.ItemIndex]);
except
  ShowMessage('Geen selectie gemaakt');
end;

Zie ook Help van TCustomListBox.ItemIndex, met name voor het MultiSelect onderdeel...

[ Voor 21% gewijzigd door Reptile209 op 10-01-2003 16:43 ]

[DeoDupke]

code:

showmessage(listbox1.items.Strings[listbox1.itemindex]);

moet je alleen nog afvangen als hij -1 is ( niet geselecteerd)
ik weet ook niet wat er gebeurd als je meerdere items selecteerd

edit:

bleh, net te laat!

[ Voor 10% gewijzigd door DeoDupke op 10-01-2003 16:44 ]

[DaFearLess]

tnx dat is hem

[Reptile209]

DeoDupke schreef op 10 January 2003 @ 16:43:

edit:

bleh, net te laat!

Ik roeleer
_{Ik deed 'm uit m'n hoofd, en ging toen zelf maar eens F1-en}

[Verwijderd]

Vind die oplossing niet echt fraai, je gaat een exception als mechanisme gebruiken, niet echt fraai imo.

Beter:

Delphi:

With listbox1 do
  If Itemindex=-1 then 
      showmessage ('sukkel je hebt niets geselecteerd!!') 
    else
      showmessage(items.strings[itemindex]);

1 goede reden om niet van die exceptions gebruik te maken: stel je wilt later een wat generiekere methode om fouten af te handelen, eventueel met log. Je gaat dan bv. gebruikmaken van de onerror van je tapplication. Dan krijg je ook dit soort errors om je oren.

[Reptile209]

Verwijderd schreef op 10 januari 2003 @ 16:50:
Vind die oplossing niet echt fraai, je gaat een exception als mechanisme gebruiken, niet echt fraai imo.

Heb je wel gelijk in ja, vooral qua generiekheid. Ik bedacht de uitzondering dus net te laat en had toen geen zin om veel bij te typen. De leercurve moet ook een beetje steil blijven he

[mjax]

Verwijderd schreef op 10 January 2003 @ 16:50:

1 goede reden om niet van die exceptions gebruik te maken: stel je wilt later een wat generiekere methode om fouten af te handelen, eventueel met log. Je gaat dan bv. gebruikmaken van de onerror van je tapplication. Dan krijg je ook dit soort errors om je oren.

Niet echt ontopic, maar toch. Hoewel ik het helemaal met je eens ben dat een try..except block hier niet voor gebruikt moet worden, klopt jouw uitleg niet. Alleen niet-afgehandelde Exceptions komen terecht bij het OnError event van TApplication als je daar gebruik van maakt. Dus zodra je een except..end block onder je try hebt, komt OnError nooit in het spel (tenzij je in het except..end block weer een nieuwe Exception genereert natuurlijk).

[whoami]

mjax schreef op 10 januari 2003 @ 16:54:
[...]

Dus zodra je een except..end block onder je try hebt, komt OnError nooit in het spel (tenzij je in het except..end block weer een nieuwe Exception genereert natuurlijk).

Niet helemaal juist...
Als er een bepaalde exceptie gegooid wordt, die je niet afhandeld, dan zal je dan toch in de OnError komen.

Stel:

code:

try
except
  on EDatabaseError do begin
  end;
end;

Hier zullen enkel database-error's opgevangen worden. Stel dat er een DivByZero Exception gegooid wordt binnen dat try block, dan wordt die niet door het except statement opgevangen.

dafearless: gebruik in het vervolg eerst eens de help van Delphi. Deze is behoorlijk uitgebreid, en je had de oplossing er zeker kunnen in vinden.

[Tomatoman]

Zo langzamerhand begint de interessante discussie behoorlijk af te wijken van titel van de thread, maar nood breekt wet . Volledig offtopic dus:

Verwijderd schreef op 10 januari 2003 @ 16:50:
Vind die oplossing niet echt fraai, je gaat een exception als mechanisme gebruiken, niet echt fraai imo.

In het gebruikte voorbeeld geef ik je gelijk, maar in het algemeen vind ik het gebruik van exceptions wél echt fraai. Speciaal voor dat doel is in Delphi de EAbort exception ingevoerd, die je eenvoudig kunt raisen met de procedure Abort.

Zie het volgende voorbeeld dat uit de unit ScktComp.pas afkomstig is. Op regel 39 staat Abort. Zie dit voorbeeld maar eens te herschrijven zonder een exception te raisen. Dat lukt ongetwijfeld, maar de code wordt er bepaald niet leesbaarder door. In dit geval vind ik het creëren van een exception absoluut de beste oplossing.

Delphi:

function TCustomWinSocket.SendStreamPiece: Boolean;
var
  Buffer: array[0..4095] of Byte;
  StartPos: Integer;
  AmountInBuf: Integer;
  AmountSent: Integer;
  ErrorCode: Integer;

  procedure DropStream;
  begin
    if FDropAfterSend then Disconnect(FSocket);
    FDropAfterSend := False;
    FSendStream.Free;
    FSendStream := nil;
  end;

begin
  Lock;
  try
    Result := False;
    if FSendStream <> nil then
    begin
      if (FSocket = INVALID_SOCKET) or (not FConnected) then exit;
      while True do
      begin
        StartPos := FSendStream.Position;
        AmountInBuf := FSendStream.Read(Buffer, SizeOf(Buffer));
        if AmountInBuf > 0 then
        begin
          AmountSent := send(FSocket, Buffer, AmountInBuf, 0);
          if AmountSent = SOCKET_ERROR then
          begin
            ErrorCode := WSAGetLastError;
            if ErrorCode <> WSAEWOULDBLOCK then
            begin
              Error(Self, eeSend, ErrorCode);
              Disconnect(FSocket);
              DropStream;
              if FAsyncStyles <> [] then Abort;
              Break;
            end else
            begin
              FSendStream.Position := StartPos;
              Break;
            end;
          end else if AmountInBuf > AmountSent then
            FSendStream.Position := StartPos + AmountSent
          else if FSendStream.Position = FSendStream.Size then
          begin
            DropStream;
            Break;
          end;
        end else
        begin
          DropStream;
          Break;
        end;
      end;
      Result := True;
    end;
  finally
    Unlock;
  end;
end;

[LordLarry]

Die is makkelijk

Delphi:

// regel 39
if FAsyncStyles <> [] then Abort;
// vervangen door
if FAsyncStyles <> [] then Exit;

Excpeties hebben als nadeel dat het relatief veel processor tijd kost om een excpetie te gooien en weer af te vangen, maar heel soms kan het handig zijn idd.

[ Voor 40% gewijzigd door LordLarry op 10-01-2003 21:19 ]

[Verwijderd]

Zie het volgende voorbeeld dat uit de unit ScktComp.pas afkomstig is. Op regel 39 staat Abort. Zie dit voorbeeld maar eens te herschrijven zonder een exception te raisen. Dat lukt ongetwijfeld, maar de code wordt er bepaald niet leesbaarder door. In dit geval vind ik het creëren van een exception absoluut de beste oplossing.

Ik weet het niet. Volgens mij is dit best te herschrijven zodat al die breaks en die abort niet nodig zijn - ga er niet aan beginnen, wel iets beters te doen.

Ik persoonlijk ben _erg_ tegen het gebruiken van break en abort, of het anders gebruiken van een exception dan waar ie echt voor bedoeld is.

Hoewel ik best zie dat alle drie ook constructief te gebruiken zijn, zie ik ze het meest terug in code van mensen die het niet begrepen hebben. Als ze wisten dat goto nog werkt, dan zouden ze goto gebruiken, dat type programmeur.

//edit

ga er toch eens aan zitten prutsen, puur om te laten zien wat ik bedoel. Als opwarmertje alvast de eerste exit gekilled:

niet:

Delphi:

 if FSendStream <> nil then
    begin
      if (FSocket = INVALID_SOCKET) or (not FConnected) then exit;
      while True do
      begin

maar:

Delphi:

if (FSendStream <> nil) then
      if (FSocket <> INVALID_SOCKET) and (FConnected) then
        begin
          while True do
            begin  

waarom ik het toch even ga proberen: ik zie hier een schoolvoorbeeld van het 'waarom niet'. Kijk bv. eens hoevaak de opdracht 'dropstream' terugkomt, sowieso al een procedure in een procedure, een fenomeen wat de handel toch al niet leesbaarder maakt.

//edit2
ik zit de code wat langer te bekijken, en zie dat ie echt stukken fraaier kan. Er is sowieso maar 1 conditie waarop niet de 'break' komt. Maar anderzijds zie ik ook dat ik onmogelijk anders kan dan je gelijk geven, in dit voorbeeld is een exceptie het best.

Echter: ik zeg nergens dat je geen excepties mag gebruiken, juist wel. Alleen dan wel voor iets waarvoor ze bedoeld zijn: nl als er iets mis gaat. Niet omdat je condities niet volledig zijn.

[ Voor 56% gewijzigd door Verwijderd op 10-01-2003 21:49 ]

[jvdmeer]

LordLarry schreef op 10 januari 2003 @ 21:17:
Die is makkelijk

Delphi:

// regel 39
if FAsyncStyles <> [] then Abort;
// vervangen door
if FAsyncStyles <> [] then Exit;

Excpeties hebben als nadeel dat het relatief veel processor tijd kost om een excpetie te gooien en weer af te vangen, maar heel soms kan het handig zijn idd.

Door Exit te gebruiken, wordt de Unlock uit regel 62 nooit meer aangeroepn, terwijl die wel wordt aangeroepen bij Abort. Functioneel dus niet gelijk,

U gaat niet door voor de wasmachine

[curry684]

tomatoman schreef op 10 January 2003 @ 20:45:
Zie het volgende voorbeeld dat uit de unit ScktComp.pas afkomstig is. Op regel 39 staat Abort. Zie dit voorbeeld maar eens te herschrijven zonder een exception te raisen. Dat lukt ongetwijfeld, maar de code wordt er bepaald niet leesbaarder door. In dit geval vind ik het creëren van een exception absoluut de beste oplossing.

Nou ben ik geen Delphiheld maar wat is hier het probleem mee:

Delphi:

            if FAsyncStyles <> [] then Unlock();
              return;
            end else

De VCL-coders hebben daar die Abort gewoon gebruikt omdat ze *zelf* te lui waren om fatsoenlijke error checking in the bouwen gok ik zo.

[whoami]

[nohtml]

Verwijderd schreef op 10 januari 2003 @ 21:24:
[...]


Ik persoonlijk ben _erg_ tegen het gebruiken van break en abort, of het anders gebruiken van een exception dan waar ie echt voor bedoeld is.

Ik denk dat we deze discussie al eens gevoerd hebben (over die break dan), en wat is daar eigenlijk mis mee? Een break is geen exceptie. Tuurlijk kun je altijd je code zo schrijven dat een break niet nodig is, maar maakt dat je code leesbaarder?
Ik heb niets tegen break, en ook niet zo tegen die Abort. Waar je die Abort bv kunt gebruiken is in het checken of alle verplichte velden ingevuld zijn.

code:

if TextBox1.Text = '' then begin
   MessageDlg ('Vul dat veld in', mtWarning, [mbOk], 0);
   TextBox1.SetFocus();
   Abort();  // raise hier een Abort
end;

BTW, hier staat de 'break' discussie : [rml][ alg] breaks handig of lelijk?[/rml]

Hoewel ik best zie dat alle drie ook constructief te gebruiken zijn, zie ik ze het meest terug in code van mensen die het niet begrepen hebben. Als ze wisten dat goto nog werkt, dan zouden ze goto gebruiken, dat type programmeur.

Wat is de derde? break, Abort en .....
Verder geef ik je hier geen geljk in.

[LordLarry]

jvdmeer schreef op 10 January 2003 @ 22:23:
Door Exit te gebruiken, wordt de Unlock uit regel 62 nooit meer aangeroepn, terwijl die wel wordt aangeroepen bij Abort. Functioneel dus niet gelijk,

Jawel hoor, die wordt zeker aangeroepen. Het staat namelijk in een grote try...finally en de Unlock staat in de finally. Zodra je in de try...finally stapt wordt hoe dan ook de finally aangeroepen, daar is geen ontsnappen aan. Ook als ik met Exit uit de procedure wil springen. Als het een try...except geweest was had je wel gelijk.

U gaat niet door voor de wasmachine

Het blijkt dat ik toch doorga en de jury wordt ontslagen wegens onterechte diskwalifikatie