frDriveNET

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ralf Jansen · Verfasst: Fr 30.06.17 19:41

Zitat:

oder Verbesserungsvorschläge vorliegen, so lasst es mich wissen.

Den Syntax wenn möglich

Es wäre schön wenn du IntPtr's verstecken könntest. Ein IntPtr sagt ja nicht wofür er steht darum liegt es nahe die immer mit einer passenden contextabhängigen Klasse zu kapseln an der man dann auch nur die entsprechenden auf diesen IntPtr möglichen Methoden kapselt.

Z.B. anstatt

markieren

C#-Quelltext

1:
2:
3:
4:

  IntPtr h = frDrive1.OpenVolume('D');  // ermittelt ein Laufwerk 
  frDrive1.EjectVolume(h);              // trennt das Laufwerk
  System.Threading.Thread.Sleep(5000);
  frDrive1.CloseVolume(h);              // nimmt das Laufwerk wieder auf und gibt das Handle frei

eher

markieren

C#-Quelltext

1:
2:
3:
4:

  Volume d = frDrive1.OpenVolume('D');
  d.Eject();
  System.Threading.Thread.Sleep(5000);
  d.Close();

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ralf Jansen · Verfasst: Fr 30.06.17 20:35

Zitat:

Man soll es als Handle identifizieren können.

Warum? Ich vermute mal das selbst bei professionellen .Net Entwicklern höchsten ein Viertel weiß was ein Handle ist bzw. mehr weiß als den Namen Handle. Auch in Winforms würdest du ja nicht eine HForm anstatt Form erwarten. Und eine Form ist letztlich auch nicht viel mehr als eine Kapsel für ein Window Handle.

Wo ich gerade sehe das ein Volume auch eine Close kennt spinne ich mal die Analogie zu Form weiter. Am besten du implementierst du in diesen Klassen auch IDisposable damit sich der arme Entwickler Fragen muss ob er nun Close oder Dispose oder beides am Ende aufrufen muss

Nein, empfehlen würde ich Close wegzulassen und nur Dispose anzubieten. Bzw. das Handle freigeben von Close zu trennen und nur in Dispose zu machen.

Edit: Vergiss den letzten Satz. Ich habe kurzzeitig Close missverstanden. Es ist nicht die gegenteilige Operation zu Eject :roll:

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

Th69 · Verfasst: Sa 01.07.17 10:01

Ich bin auch der Meinung von Ralf, daß die API objektorientierter sein könnte. Bisher ist es einfach eine große Klasse (und als Anwender weiß man nicht auf Anhieb, welche Methoden wie in Korrelation stehen).
Ich fände hier sogar eine Schnittstelle IVolume am schönsten:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

interface IVolume
{
  // Handle
  // Eject
  // Close
  // ...
}

IVolume OpenVolume(char cDrive);

So wäre dann auch der Code auf 2 kleinere Klassen aufgeteilt (frDrive, (I)Volume).

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

Th69 · Verfasst: Sa 01.07.17 11:32

Ich meine alle Methoden, die bisher den IntPtr hDrive als Parameter entgegennehmen, also auch die privaten Methoden LockVolume, UnlockVolume, d.h. diese kämen dann auch in die Implementationsklasse Volume (und dies würde dann schon den Code kleiner und übersichtlicher machen).

Und bei den anderen Methoden, welche bisher char cDrive als Parameter haben, kannst du dich ja an DriveInfo orientieren. So würde sich dann deine Komponente besser in die .NET-Infrastruktur anlehnen (umgekehrt kannst du dir ja auch für die Delphi-Komponente überlegen, ob dies nicht der bessere Designansatz wäre).

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme