hej hvordan for jeg delphi til at skubbe cd slæden ud

Jeg har ikke selv prøvet, men disse burde kunne gøre det:

<SNIP>
function IsDriveCD(Drive : char) : longbool;
var
  DrivePath : string;
begin
  DrivePath := Drive + \':\\\';
  result := LongBool(GetDriveType(PChar(DrivePath)) and DRIVE_CDROM);
end;



function EjectCD(Drive : char) : bool;
var
  mp : TMediaPlayer;
begin
  result := false;
  Application.ProcessMessages;
  if not IsDriveCD(Drive) then exit;
  mp := TMediaPlayer.Create(nil);
  mp.Visible := false;
  mp.Parent := Application.MainForm;
  mp.Shareable := true;
  mp.DeviceType := dtCDAudio;
  mp.FileName := Drive + \':\';
  mp.Open;
  Application.ProcessMessages;
  mp.Eject;
  Application.ProcessMessages;
  mp.Close;
  Application.ProcessMessages;
  mp.free;
  result := true;
end;
</SNIP>

hvor skal jeg sætte det ind i min form

Sæt dem ind i den unit hvor du har brug for dem og lad så en knap eller lign på din form styre det:

<SNIP>
procedure TFormTabelDefinitions.BitBtn1Click(Sender: TObject);
begin
  EjectCD(\'D\');
end;
</SNIP>

Husk at \"use\" mplayer

Pelle > Hvordan ville du have gjort i C++ ?

Noget alla det her ?

#include <winioctl.h>

void __fastcall Open()
{
  DWORD bytes;
  HANDLE hDevice = CreateFile(\"\\\\\\\\.\\\\D:\",  GENERIC_READ, FILE_SHARE_READ , NULL, OPEN_EXISTING, FILE_ATTRIBUTE_READONLY, NULL);
  DeviceIoControl(hDevice,IOCTL_DISK_EJECT_MEDIA,NULL,0, NULL, 0, &bytes, (LPOVERLAPPED) NULL);
  CloseHandle(hDevice);
}

void __fastcall Close()
{
  DWORD bytes;
  HANDLE hDevice = CreateFile(\"\\\\\\\\.\\\\D:\",  GENERIC_READ, FILE_SHARE_READ , NULL, OPEN_EXISTING, FILE_ATTRIBUTE_READONLY, NULL);
  DeviceIoControl(hDevice,IOCTL_DISK_LOAD_MEDIA,NULL,0, NULL, 0, &bytes, (LPOVERLAPPED) NULL);
  CloseHandle(hDevice);
}

ikke ....

Hvorfor så ikke gøre det samme i Delphi ?

altså sådan her :

const
  GENERIC_READ            = DWORD($80000000);
  {$EXTERNALSYM GENERIC_READ}
  IOCTL_DISK_LOAD_MEDIA = ((($00000007) shl 16) or ((($0001)) shl 14) or (($0203) shl 2) or (0));

procedure Open;
var
  hDevice : THANDLE;
begin
  hDevice := CreateFile(\'\\\\.\\E:\',  GENERIC_READ, FILE_SHARE_READ , nil, OPEN_EXISTING, FILE_ATTRIBUTE_READONLY, 0);
  CloseHandle(hDevice);
end;


procedure Close();
var
  hDevice : THANDLE;
  bytes : DWORD;
begin
  hDevice := CreateFile(\'\\\\.\\E:\',  GENERIC_READ, FILE_SHARE_READ , nil, OPEN_EXISTING, FILE_ATTRIBUTE_READONLY, 0);
  DeviceIoControl(hDevice,IOCTL_DISK_LOAD_MEDIA,nil,0, nil, 0, bytes, nil);
  CloseHandle(hDevice);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  open();
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  close();
end;



jens B

Jeg har i øvrigt en winioctl.h portet til Delphi hvis det har interesse ?

Jens B

borrisholt> Nu skal du passe på du ikke over driver med det der \"sprog\". Læg du hellere din C:=C+1; lidt på hylden :-)

IO-Control: hmmm hvad kan den ?

pellelil>Hvad er der nu i vejen med C++ ? Nå men i winioctl.h ligger der en masse konstanter som du skal bruge når du skal have fat i IO enhederne under win32
Eller som de (MickySoft) formulerer sig i headderen :

Abstract:

    This module defines the 32-Bit Windows Device I/O control codes.

Jens B

borrisholt> Der er såmænd ikke noget galt med C:=C+1; da jeg i sin tid kiggede på C++ var Pascal stadig \"bagud\" når vi taler OOP, men gabet (sprogmæssigt) er da blevet mindre med årene

Ooooh Ja, men vi mangler stadig flere ting i OOP, som C++ har haft længe :

Multibel nedarving og Templates for blot at nævne de to mest fatale ....

Jo jeg ved godt hvordan man laver en slags multibel nedarving i Delphi ... Men der er noget fusk, eller som de siger i Sønderjylland noget klyt ! Og Klyt kode giver klyt programmer !

JEns B

Ja og nu hvor du er i gang hvad med \"Operator Overloaded Functions\" ?

Det kom i Delphi 4  Pellelil !

Jens B

Hov nej ikke  \"Operator Overloaded Functions\" undskyld det var kun med \"Overloaded Functions\"

jens B

De to eneste ting jeg umiddelbart kan komme i tanke om, der evt. mangler i Delphi i forhold til C++ er:
- Muligheden for at kunne lave Kernel mode drivers.  Det er, så vidt jeg ved, kun muligt med MSVC.
- Operator Overload kan i mine øjne være rigtig smart, men kan dog forholdsvist nemt omgås med properties og metoder.  Når alt kommer til alt, så er der ikke den store forskel på A = A+B; og A.Add(B);

Hvad jeg har bemærket ved C++ (i hvertfald MSVC, som bruges her i firmaet), så er det at alt ting er MEGET nemmere i Delphi.  Eg. placerer man på sin form en TEdit (i Delphi, ik!), så har man øjeblikkeligt adgang til alle objectets properties, selvfølgeligt incl. dens Text.  I C++ skal man først placere EditBox på dialogen/formen.  Så skal man oprette en member variabel, som skal knyttes til editboxen.  Derefter skal man kalde UpdateData() - og iforbifarten huske om parameteren nu skal være TRUE eller FALSE (Ikke True eller False(suk!)) før man så kan aflæse hvad brugeren egentligt har indtastet....  Hvis man så også vil kunne flytte på objectet, ændre Font, farve mv, så....
Det er se\'følig ikke umiddelbart C++ skyld, men mere måden hvorpå MS har valgt at implementere C++, men jeg mener altså at Delphi er langt mere produktivt.

NiP

Delphi> Vedr. din kommentar om at det ikke \"ikke umiddelbart C++ skyld, men mere måden hvorpå MS har valgt at implementere C++\" kan kort og godt understøttes med \"BCB\" :-)

delphi  > Spørgsmålet var vist ikke om Delphi var mere eller mindere effiktiv end VC++, det var vist mere en form for fillosoferen fra undertegnedes side om ting man kunne ønske sig i en kommende Delphi versioner.


Du har da så evig ret i at der der med operator overloaded funktioner kan omgås med properties, men ærligtalt det er da noget klyt at skulle lave en add funktion i stedet for en plus operator, som var mere naturlig ....

En direkte fejl i VC++ er deres håndtering af properties. Man kan ganske som i Delphi pakke sine klasse ind i properties, dog er problemet blot at sådan en property typisk kalder en get og en set funktion .. Disse skal være public i VC++ for ellers kan man ikke tilgå dem ... pinligt !

Jens B

Jeg startede med at kommentere to af de 3-4 ønsker.  Jeg mener fx. ikke at multible nedarvning er noget der er værd at savne.  Bruger man noget sådan, så burde man istedet genoverveje opbygningen at sit class\' hiraki. - Lidt i retning af den gamle diskusion om Goto vs. Procedure kald.  Bagefter kom min galde til at flyde lidt over mht MS implementering....

Vedr. Properties:
Det er så hudt jeg visker en COM ting, er det ikke?  Jeg mener at huske at under COM, så skal alle properties, dvs. som du siger: de bagved liggende metoder/member functions, være public.  Det har noget at gøre med, at ikke alle sprog kan håndtere properties, så for at disse sprog skal kunne håndtere COM, så skal de altså være lavet med public metoder.

Delphi.

Delphi > Nej properties er ikke en com tind. Det er en del C++. Et lille eksempel :

class TCar
{
    private:
        int fWheels;
    public:
        void SetWheels(int value){fWheels = value;}
        int GetWheels(){return fWheels;}
        __declspec( property( get=GetWheels, put=SetWheels ) ) int Wheels;
}Car, *pCar;

void main()
{
  Car.Wheels = 5;

}
Den her den virker mens det følgende giver en compiler fejl :

class TCar
{
    private:
        int fWheels;
        void SetWheels(int value){fWheels = value;}
        int GetWheels(){return fWheels;}
    public:
        __declspec( property( get=GetWheels, put=SetWheels ) ) int Wheels;
}Car, *pCar;


void main()
{
  Car.Wheels = 5;
}


Og det var det jeg var ude med snøren efter ....


Jens B

delphi> Jeg vil til enhver tid give borrisholt ret i at \"A:=A+B;\" er væsentligt nemmere at læse end \"A.Add(B);\" eller \"Imorgen := Idag + 1;\" frem for \"Imorgen.Assign(Idag); Imorgen.Add(1);\".

At sammenligne multibel arv med goto er noget pjat. Som Delphi programmør vender man sig til at leve uden multibel arv for du har ikke andre muligheder (jeg \"glemmer\" her at Inteface kan bruges). Der er mange sammenhænge hvor jeg gerne ville have brugt multibel arv, men i stedet må man lade en class \"indeholde en variabel\" af sammen type som den man måske ellers ville have arvet af.

Borris: Jeg er fint med på implementationen af properties under C++ - det jeg mener er: I Com benytter man den samme form for implementation (også under Delphi).  Jeg aner bare en sammenhæng...

pellelil: Jeg vil ikke give dig ret i jeg som Delphi programmør bare er blevet vandt til at undvære Multibel Nedarv (MN).  Da jeg i sin tid lærte om OOP var det med SmallTalk.  Selv dengang benyttede jeg aldrig MN.  Jeg mener, at MN i langt de fleste tilfælde er unødvendigt og at det kan give anledning til misforståelser.  Det er også hvad jeg har set i de fleste lære bøger om emnet.  Men i sidste ende er det vel et spørgsmål om smag: Man kan benytte det hvis man vil - jeg vil ikke.

Delphi

I øvrigt jeg sagde også at en af de to ting jeg finder smart i C++/savner i Delphi netop er operator overload functions.