Hi,

My.FileSystem bietet einige Methodenüberladungen, die die
Windows-Shell-Spielereien mit den fliegenden Blättern nutzen
(SHFileOperation in der API). Finden sich diese Funktionen auch anderswo im
Framework 2.0 wieder? Die meisten anderen My.XXX-Funktionen lassen sich ja
direkt durch entsprechende Frameworkfunktionen ersetzen.

Gruß
Joachim

Hallo Joachim!

"Joachim Fuchs" <keine.joachim.werbung> schrieb:
> My.FileSystem bietet einige Methodenüberladungen, die die
> Windows-Shell-Spielereien mit den fliegenden Blättern nutzen
> (SHFileOperation in der API). Finden sich diese Funktionen auch anderswo
> im Framework 2.0 wieder? Die meisten anderen My.XXX-Funktionen lassen sich
> ja direkt durch entsprechende Frameworkfunktionen ersetzen.

Soweit ich sehe, nein. Die Methoden sind jedenfalls in der
"Microsoft.VisualBasic.dll" implementiert (mittels PInvoke mit
'SHFileOperation') und nicht einfach nur Wrapper um Funktionalität von
anderen Klassen des .NET Framework.

Hallo Joachim!

Joachim Fuchs schrieb:
> My.FileSystem bietet einige Methodenüberladungen, die die
> Windows-Shell-Spielereien mit den fliegenden Blättern nutzen
> (SHFileOperation in der API). Finden sich diese Funktionen auch anderswo im
> Framework 2.0 wieder? Die meisten anderen My.XXX-Funktionen lassen sich ja
> direkt durch entsprechende Frameworkfunktionen ersetzen.

Schau Dir mal im Reflector

Microsoft.VisualBasic.CompilerServices.NativeMetho ds

an:

<DllImport("shell32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
Friend Shared Function SHFileOperation( _
ByRef lpFileOp As SHFILEOPSTRUCT) As Integer

Gruß

Arne Janning

Hallo Arne,

SHFileOperation kenne ich selbst, hatte ich ja geschrieben.

Sinnvoll wäre es aber, wenn die betreffenden Klassen in System.IO auch die
genannten Möglichkeiten böten. Warum soll dass nun wieder eine
ausschließliche Kiste für My sein?

Gruß
Joachim

Hallo Herfried,

> Soweit ich sehe, nein. Die Methoden sind jedenfalls in der
> "Microsoft.VisualBasic.dll" implementiert (mittels PInvoke mit
> 'SHFileOperation') und nicht einfach nur Wrapper um Funktionalität von
> anderen Klassen des .NET Framework.

das ist aber schade. Denn diese Funktionalität gehört ins Framework.

Gruß
Joachim

Hallo Joachim!

"Joachim Fuchs" <keine.joachim.werbung> schrieb:
> Sinnvoll wäre es aber, wenn die betreffenden Klassen in System.IO auch die
> genannten Möglichkeiten böten. Warum soll dass nun wieder eine
> ausschließliche Kiste für My sein?

Nun -- es hindert nichts daran, in einem C#-Projekt einen Verweis auf
"Microsoft.VisualBasic.dll" zu setzen und die Funktionalität zum Kopieren
der Daten mit Fortschrittsdialog zu nutzen. "Microsoft.VisualBasic.dll" wird
ja mit dem .NET Framework ausgeliefert und Namen sind Schall und Rauch.
Siehe dazu auch:

The My namespace and C#
<URL:http://www.panopticoncentral.net/archive/2004/04/23/991.aspx>

<URL:http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=8#CSharp>
-> "My for C# 2.0"

Hallo Joachim!

Joachim Fuchs schrieb:
> SHFileOperation kenne ich selbst, hatte ich ja geschrieben.

Das weiss ich, so meinte ich das auch nicht. Ich wollte nur belegen,
dass die Funktionalität nicht aus dem Framework selbst kommt, sondern
aus dem Namespace Microsoft.VisualBasic.CompilerServices.NativeMetho ds
und dass die SHFileOperation dort gewrappt wird, wie man im Reflector
sehen kann.

> Sinnvoll wäre es aber, wenn die betreffenden Klassen in System.IO auch die
> genannten Möglichkeiten böten. Warum soll dass nun wieder eine
> ausschließliche Kiste für My sein?

ACK. Das verstehe ich auch nicht.

Gruß

Arne Janning

Addendum:

VB's *My* for C# Developers
<URL:http://blogs.msdn.com/danielfe/archive/2005/06/14/429092.aspx>

Hallo Arne,

> ... Ich wollte nur belegen, dass die Funktionalität nicht aus dem
> Framework selbst kommt, sondern aus dem Namespace
> Microsoft.VisualBasic.CompilerServices.NativeMetho ds und dass die
> SHFileOperation dort gewrappt wird, wie man im Reflector sehen kann.

sorry, hatte ich falsch verstanden.

>> Sinnvoll wäre es aber, wenn die betreffenden Klassen in System.IO auch
>> die genannten Möglichkeiten böten. Warum soll dass nun wieder eine
>> ausschließliche Kiste für My sein?
>
> ACK. Das verstehe ich auch nicht.

Ja, die Grüppchen bei MS sollten mal miteinander reden, statt aneinander
vorbei alles mehrfach und kreuz und quer zu programmieren.

Gruß
Joachim

Hallo Joachim,

> Ja, die Grüppchen bei MS sollten mal miteinander reden, statt aneinander
> vorbei alles mehrfach und kreuz und quer zu programmieren.

Vielleicht haben sie ja doch miteinander geredet und die Differenz zwischen
VB und C# bewusst belassen.


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de/home.aspx

Hallo Harald,

> Vielleicht haben sie ja doch miteinander geredet und die Differenz
> zwischen VB und C# bewusst belassen.


bezüglich der fliegenden Blätter glaube ich nicht, dass man seine Gedanken
ausgetauscht hat. Denn die Animation wird nicht nur von VB-Programmierern
nachgefragt. Da es sie schon seit Win95 gibt, wäre es nur konsequent, sie
ins Framework aufzunehmen.

Gruß
Joachim

Hallo Harald & Joachim


>> Ja, die Grüppchen bei MS sollten mal miteinander reden, statt aneinander
>> vorbei alles mehrfach und kreuz und quer zu programmieren.
> Vielleicht haben sie ja doch miteinander geredet und die Differenz zwischen
> VB und C# bewusst belassen.


die Tatsache,
das die My-Krücke nur im VB-Namespace/Assembly eingebaut wurde,
sagt dazu IMHO ja eigentlich schon restlos alles aus...

Ich persönlich halte die My-Krücke als
völlig missratene Kurschluss-Handlung
aufgrund unseriösem Kunden-Feedback...

(ala DAU: "...ich finde die Klassen nicht in den BCL-Namespaces")

Hallo Thomas!

"Thomas Scheidegger [MVP]" <spam.netmaster> schrieb:
>>> Ja, die Grüppchen bei MS sollten mal miteinander reden, statt aneinander
>>> vorbei alles mehrfach und kreuz und quer zu programmieren.
>> Vielleicht haben sie ja doch miteinander geredet und die Differenz
>> zwischen
>> VB und C# bewusst belassen.
>
> die Tatsache,
> das die My-Krücke nur im VB-Namespace/Assembly eingebaut wurde,
> sagt dazu IMHO ja eigentlich schon restlos alles aus...

Was denn? Und das sagst du als jemand, der auf einen meiner Beiträge
folgendes antwortete:

<URL:http://www.google.to/groups?selm=OJTgnBvVFHA.2256%40TK2MSFTNGP14.phx.gb l>

> Ich persönlich halte die My-Krücke als
> völlig missratene Kurschluss-Handlung
> aufgrund unseriösem Kunden-Feedback...
>
> (ala DAU: "...ich finde die Klassen nicht in den BCL-Namespaces")

Ich halte genau diese Erklärung für an den Haaren herbeigezogen und
unzutreffend.

Es geht m.E. weniger darum, dem DAB das Auffinden von Klassen zu
erleichtern, sondern dem professionellen Benutzer eine Möglichkeit zu
bieten, mittels eines RAD-Frameworks produktiver zu arbeiten und weniger
Fehler zu machen, da weniger Code geschrieben werden muss. Ein weiterer
Vorteil der Verwendung von 'My' könnte darin liegen, dass ein Meta-Framework
aufgebaut wird, das evtl. .NET überleben wird, änlich der bereits
bestehenden Funktionsbibliothek aus 'Microsoft.VisualBasic'.

Du steuerst schon wieder auf einen "Wochenendchat" zu ;-).

>> das die My-Krücke nur im VB-Namespace/Assembly eingebaut wurde,
>> sagt dazu IMHO ja eigentlich schon restlos alles aus...
> Was denn? Und das sagst du als jemand, der auf einen meiner Beiträge
> folgendes antwortete:
> <URL:http://www.google.to/groups?selm=OJTgnBvVFHA.2256%40TK2MSFTNGP14.phx.gb l>


alles im puren Gegenteil, erstens geht es hier _ausschliesslich_
um die My-Krücke, und da sind die Tatsachen einzig & alleine:

1.) die My-Krücke ist nicht in den offiziellen .NET BCLs,
sondern (schon wieder) eine 'private' Zusatz-Bastlerei!
(siehe Namespace & Assembly)

2.) die My-Krücke ist 100% frontal gegen das Ziel eines
(insbeso auch im Sinne der [portablen] CLI/CLS)
konsequenten .NET _Frameworks_ gerichtet!

3.) wurde die My-Krücke IMHO + AFAIK einzig auf
sturen Zwang einiger 'lern-unfähiger' Kunden hin gebaut.
(exakt 100% vergleichbar mit der kindischen,
zum Glück gestorbenen Zwängerei einer VB6-Petition !)

4.) die My-Krücke ist mit den VB6-Fn Kompat.-Krücken vergleichbar;
Noch fataler, das Problem hat sich dadurch bereits verdreifacht!...



> RAD-Frameworks produktiver zu arbeiten

ROFL, alleine diese Tabelle (nur ein Bsp aus vielen!) :

Offizielles .NET: Directory.CreateDirectory
VB6-Altlast: MkDir
VB2005: My.Computer.FileSystem.CreateDirectory

macht jede Aussage angeblicher 'Produktivität' zur absoluten Farce.

Jeder echte Profi weiss, dass solch sinnlose Redundanzen
in kurzer Zeit in ein extrem aufwändiges Chaos führt.

Bsp:
Wenn ein VB-Einsteiger fremde Code-Bsp übernehmen will,
muss er bis zu 3 Syntax-Varianten lernen und sich mit
3 unterschiedlichen Dokumentations-Abschnitten herumschlagen...

-> Die angebliche 'Leichtigkeit' von VB für Einsteiger
wird völlig ad absurdum geführt.

Thomas Scheidegger [MVP] schrieb:
> Ich persönlich halte die My-Krücke als
> völlig missratene Kurschluss-Handlung

Ausnahmsweise mal: 100% ACK

> aufgrund unseriösem Kunden-Feedback...

Das wage ich wieder zu bezweifeln. Hier liegt eher ein
Kommunkationsproblem zwischen Kunde und MSFT vor, in der Art der
stillen Post. Aus "Ich will meine VB6 Quellen nach VB.NET retten"
wurde "I want to have 'My' in VB.NET".

Thorsten Dörfler