vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
TOP-Angebot: 17 bzw. 24 Entwickler-Vollversionen zum unschlagbaren Preis!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB.NET - Ein- und Umsteiger
Re: Hierarchie im TreeView 
Autor: ErfinderDesRades
Datum: 20.05.14 13:55

Manfred X schrieb:
Zitat:

Es gibt keine "überlegenen" Methoden.
naja, eine im Objekt selbst angelegte Objekt-Methode, die am Objekt etwas leistet, was ansonsten in einem externen Modul angelegt werden müsste, nenne ich "überlegen" im Sinne von objektorientierter Architektur und Code-Design.

Derlei Objekt-Methoden empfehle ich zu bevorzugen.

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Hierarchie im TreeView 
Autor: stefanbla80
Datum: 19.05.14 16:28

Hallo zusammen,

mit dem unten genannten Code erstelle ich eine Art Explorer auf meinem Form.
Ich verwende hierfür ein TreeView.

Meine Frage: „path2“ ist der übergeordnete Pfad, und dieser soll auch im TreeView so erscheinen.
Bisher hat dieser Pfad/Knoten die selbe Hierarchie wie z. B. „path_engineering“.

Könnte Ihr mir helfen?!

Private Sub PopulateTreeView()
 
        Dim Project As String = ""
        Dim folder As String = ""
        Dim Laufwerk As String = "Z:\INT\Data\CustomerSolutions\CS\"
        Dim rootNode As TreeNode
 
        TreeView_Explorer.Nodes.Clear()
        Project = Me.ComboBox_Projektnummer.Text
        If Microsoft.VisualBasic.Len(Project) = 7 Then
            folder = Microsoft.VisualBasic.Left(Project, 5) + "xx"
            path_engineering = Laufwerk + "\" + Me.ComboBox_Land.Text + "\" + _
              folder + "\" + Project + "\" + Me.ComboBox_Version.Text + "\" + _
              Laufwerk_engineering
            path_design = Laufwerk + "\" + Me.ComboBox_Land.Text + "\" + folder _
            + "\" + Project + "\" + Me.ComboBox_Version.Text + "\" + _
            Laufwerk_design
            path_assembly = Laufwerk + "\" + Me.ComboBox_Land.Text + "\" + _
            folder + "\" + Project + "\" + Me.ComboBox_Version.Text + "\" + _
            Laufwerk_assembly
            path_aftersales = Laufwerk + "\" + Me.ComboBox_Land.Text + "\" + _
            folder + "\" + Project + "\" + Me.ComboBox_Version.Text + "\" + _
            Laufwerk_aftersales
            path_pictures = Laufwerk + "\" + Me.ComboBox_Land.Text + "\" + _
            folder + "\" + Project + "\" + Me.ComboBox_Version.Text + "\" + _
            Laufwerk_pictures
            path2 = Laufwerk + Me.ComboBox_Land.Text + "\" + folder + "\" + _
            Project + "\" + Me.ComboBox_Version.Text
 
            TreeView_Explorer.Nodes.Add(path2)
 
            Dim info_engineering As New DirectoryInfo(path_engineering)
            If info_engineering.Exists Then
                rootNode = New TreeNode(info_engineering.Name)
                rootNode.Tag = info_engineering
                GetDirectories(info_engineering.GetDirectories(), rootNode)
                TreeView_Explorer.Nodes.Add(rootNode)
                rootNode.Expand()
            End If
 
            Dim info_design As New DirectoryInfo(path_design)
            If info_design.Exists Then
                rootNode = New TreeNode(info_design.Name)
                rootNode.Tag = info_design
                GetDirectories(info_design.GetDirectories(), rootNode)
                TreeView_Explorer.Nodes.Add(rootNode)
                rootNode.Expand()
            End If
 
            Dim info_assembly As New DirectoryInfo(path_assembly)
            If info_assembly.Exists Then
                rootNode = New TreeNode(info_assembly.Name)
                rootNode.Tag = info_assembly
                GetDirectories(info_assembly.GetDirectories(), rootNode)
                TreeView_Explorer.Nodes.Add(rootNode)
                rootNode.Expand()
            End If
 
            Dim info_aftersales As New DirectoryInfo(path_aftersales)
            If info_aftersales.Exists Then
                rootNode = New TreeNode(info_aftersales.Name)
                rootNode.Tag = info_aftersales
                GetDirectories(info_aftersales.GetDirectories(), rootNode)
                TreeView_Explorer.Nodes.Add(rootNode)
                rootNode.Expand()
            End If
 
            Dim info_pictures As New DirectoryInfo(path_pictures)
            If info_pictures.Exists Then
                rootNode = New TreeNode(info_pictures.Name)
                rootNode.Tag = info_pictures
                GetDirectories(info_pictures.GetDirectories(), rootNode)
                TreeView_Explorer.Nodes.Add(rootNode)
                rootNode.Expand()
            End If
 
        End If
 
    End Sub
Grüße
Stefan
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: Manfred X
Datum: 19.05.14 16:52

Hallo!

Wenn Du "SubNodes" erstellen willst, mußt Du selbige
der Nodes-Auflistung des jeweils übergeordneten Knotens hinzufügen.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: stefanbla80
Datum: 20.05.14 06:52

Hallo Manfred,

theoretisch weiß ich schon was Du meinst.
Jedoch wie kann ich in meinem Code das relativ einfach durchführen?!

Wie kann ich sagen: TreeView_Explorer.Nodes.Add(path2) wird parent bzw. die subnodes.

Grüße
Stefan
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: ErfinderDesRades
Datum: 20.05.14 10:29

probier mal das hier aus:
   Private Sub PopulateTreeView()
      Dim Laufwerk As String = "Z:\INT\Data\CustomerSolutions\CS\"
      TreeView1.Nodes.Clear()
      Dim Project = Me.ComboBox_Projektnummer.Text
      If Project.length = 7 Then
         Dim folder = Project.substring(0, 5) + "xx"
         Dim rootPath = Laufwerk + "\" + Me.ComboBox_Land.Text + "\" + _
           folder + "\" + Project + "\" + Me.ComboBox_Version.Text
         Dim ndRoot = TreeView1.Nodes.Add(rootPath)
         ndRoot.Nodes.Add(Laufwerk_engineering)
         ndRoot.Nodes.Add(Laufwerk_design)
         ndRoot.Nodes.Add(Laufwerk_assembly)
         ndRoot.Nodes.Add(Laufwerk_aftersales)
         ndRoot.Nodes.Add(Laufwerk_pictures)
         ndRoot.Nodes.Add(Laufwerk_engineering)
      End If
      For Each nd As TreeNode In TreeView1.Nodes(0).Nodes
         MessageBox.Show(nd.FullPath)
      Next
   End Sub
Beachte auch, dass die Microsoft.VisualBasic - String-Verarbeitungs-Funktionen samtnsonders obsolet sind, wenn man sich nur mit der String-Klasse selbst vertraut macht - etwa, indem man sie mal im ObjectBrowser ausführlich untersucht.

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: Manfred X
Datum: 20.05.14 12:12

[I]Beachte auch, dass die Microsoft.VisualBasic - String-Verarbeitungs-Funktionen
samtnsonders obsolet sind,[/I]

Könntest Du bitte mit diesem Unsinn aufhören!!!!

Die VB-spezifischen Methoden (z.B. für Stringverarbeitung) setzen auf der
Net-Framework-String-Klasse auf und bieten alternative Parameterlisten an
(die man sonst z.T. selbst programmieren müßte).


Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: ErfinderDesRades
Datum: 20.05.14 12:26

also ich kann nicht alle Funktionen durchgehen, aber mein Beispiel von 10:29 zeigt doch wohl eindeutig, dass Len und Left obsolet sind, und dass StrDup obsolet ist, hatten wir bereits an anderer Stelle.

Also ich muss relativieren: Evtl. gibts dort tatsächlich String-Verarbeitungs-Methoden, für die es inne String-Klasse keine überlegene Entsprechung gibt, aber mir ist keine bekannt.

ah ja - zB Exoten wie StrReverse - dass man die Reihenfolge der Zeichen umkehrt - braucht man halt nicht ganz so häufig.

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: Manfred X
Datum: 20.05.14 12:35

Es gibt keine "überlegenen" Methoden.

Das Framework ist eine Entwicklung unabhängig von VB.

So weit es für bekannte VB-Methoden keine direkte Entsprechung im
Net-Framework gibt, sind sie zusätzlich implementiert worden -
unter Verwendung der korrespondierenden Framework-Klassen.





Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: Manfred X
Datum: 20.05.14 14:34

[I]naja, eine im Objekt selbst angelegte Objekt-Methode, die am Objekt etwas leistet,
was ansonsten in einem externen Modul angelegt werden müsste, nenne ich "überlegen"
im Sinne von objektorientierter Architektur und Code-Design[/I]

Das stimmt wieder nicht.
Die VB-spezifischen Methoden verwenden die Framework-Klassen.
Es wird nichts in einem "externen Modul" zusätzlich angelegt - nur der notwendige
Code für die Verarbeitung der zusätzlichen oder geänderten Aufrufparameter.
(Die Erstellung von Bibliotheken für Parameter-Anpassungen oder Klassen-
Kapselungen im Rahmen spezifischer Programmier-aufgaben oder -stile ist üblich.)

Im übrigen ist die Art der Implementierung der String-Klasse im Net- Framework
"im Sinne von objektorientierter Architektur" vermutlich zu "hinterfragen".
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: ErfinderDesRades
Datum: 20.05.14 19:30

Manfred X schrieb:
Zitat:

[I]naja, eine im Objekt selbst angelegte Objekt-Methode, die
am Objekt etwas leistet,
was ansonsten in einem externen Modul angelegt werden müsste,
nenne ich "überlegen"
im Sinne von objektorientierter Architektur und Code-Design[/I]

Das stimmt wieder nicht.
Die VB-spezifischen Methoden verwenden die Framework-Klassen.
Es wird nichts in einem "externen Modul" zusätzlich
angelegt - nur der notwendige
Code für die Verarbeitung der zusätzlichen oder geänderten
Aufrufparameter.
(Die Erstellung von Bibliotheken für Parameter-Anpassungen
oder Klassen-
Kapselungen im Rahmen spezifischer Programmier-aufgaben oder
-stile ist üblich.)

Im übrigen ist die Art der Implementierung der String-Klasse
im Net- Framework
"im Sinne von objektorientierter Architektur"
vermutlich zu "hinterfragen".
Sorry - ich komme mit deiner Argumentier-Weise überhaupt nicht klar. Ich sag: Ich nenne ObjektMethoden überlegen im Sinne von OOP gegenüber Methoden, die in Modulen angelegt sind, und du sagst das stimmt nicht?
Aber du siehst doch, dass ich sie überlegen nenne, wie kannst du sagen, das stimmt nicht?

Und was haben Framwork-Klassen, die verwendet werden, überhaupt mit dem Thema zu tun?
Es ist einfach Fakt, dass Objekt-Methoden objekt-orientierten Design-Paradigmen folgen (deswegen heißen sie Objekt-Methode), und Modul-Methoden folgen diesem nicht, sondern bestenfalls prozeduralen Paradigmen.
Hab ich jetzt extra nochmal auf Wikipedia nachgelesen, diese beiden Begriffe.

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: Manfred X
Datum: 20.05.14 20:40

Hallo!

Der Begriff "überlegen" ist in diesem Zusammenhang nicht anwendbar.

Auch Deine formale Überlegungen (Paradigma o.ä.) spielen in der Praxis
kaum eine Rolle. Im Framework arbeiten Klassen-Module (Objekte)
und Standard-Module ergänzend zusammen - z.B. bei den Extension-Methods.

Auf Klassen, die in Form von Shared-Methoden allgemein verwendbare Routinen
zusammenfassen (= "prozedurales Konzept") ist neulich bereits am
Beispiel "System.Math" hingewiesen worden.

Und die VB-Entwickler sehen die Sache wohl ohnehin locker.
Das Strings-Modul wird nämlich in der MSDN einfach als Klasse bezeichnet.
http://msdn.microsoft.com/de-de/library/vstudio/microsoft.visualbasic.strings%28v=vs.100%29.aspx















Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: ErfinderDesRades
Datum: 21.05.14 04:36

Zitat:

Der Begriff "überlegen" ist in diesem Zusammenhang nicht anwendbar.
dann nenne es "besser", weil objektorientiert, meist aber auch von der Funktionalität her - vermutlich oft auch hinsichtlich der Performance - aber da hab ich keine Tests gemacht.
Also etwa die String.Substring()-Objekt-Methode ist überlegen aufgrund ihrer Objekt-orientiertheit, aber sie ist auch design-mäßig besser durchdacht, und macht so vb.Left, .Mid, .Right mit nur einer Methode obsolet - es ist mir unerfindlich, wie du zu der Behauptung kommst, der Begriff "Überlegenheit" sei nicht anwendbar.

Zitat:

Auch Deine formale Überlegungen (Paradigma o.ä.) spielen in der Praxis kaum eine Rolle.
In deiner Praxis vlt. nicht, in meiner aber ganz sicherlich, und darin bin ich bestimmt kein Exot. Also ich bemühe mich sehr (bzw. finde es einfach natürlicher), Methoden, die bestimmte Klassen betreffen, auch in diesen Klassen anzulegen.
Und mit Klassen meine ich Klassen, aus denen man Objekte erstellen kann, deine Begriffs-Verwässerung mit den Modul-Klassen, Klassen-Modulen, Standard-Module finde ich etwas unglücklich
Ich finde meine Überlegungen (es sind ja eher Feststellungen) auch nicht "formal", sondern es hat ja direkte praktische Auswirkung: Bei einer Objektmethode kann Intellisense mir ganz konkret genau die Member anbieten, die das Objekt verfügbar macht, was ich grad am Wickel habe. Anders sind diese Methoden gar nicht sichtbar (Kapselung).
Das ist das eine - das andere ist: ich weiß, wo ich die Methoden suchen muss, um ein Objekt zu manipulieren - nämlich in der Klassen-Definition des Objektes - ich verwende dafür vorzugsweise den ObjectBrowser
Zitat:

Im Framework arbeiten Klassen-Module (Objekte) und Standard-Module ergänzend zusammen
Klar braucht man gelegentlich auch mal ein Modul (bzw Shared Class, um c# zu sprechen). Aber zähl einfach mal die Klassen und die Module, dann siehst du, dass auch das Framework den ganz starken Schwerpunkt auf Objektorientierung legt - oh wunder was.
Zitat:

- z.B. bei den Extension-Methods...
Ja, die Extensions sind interessant. Die kann man nämlich als Modul-Methoden auffassen, die so tun als ob ... sie Objekt-Methoden wären. Sie heissen auch "Extension" - "Erweiterung", und sind ein 2008 eingeführtes neues OOP-Instrument neben der Vererbung, um Klassen zu erweitern.
Die Methoden hingegen, die im Microsoft.Visualbasic - Namespace rumfahren, sind samtnsonders keine Extension-Methods, wie denn auch.
Zitat:

Und die VB-Entwickler sehen die Sache wohl ohnehin locker.
Da gibts wohl auch verschiedene.
Die mir bekannten VB-Entwickler jedenfalls legen - soweit ich weiß (mit einer Ausnahme ;) ) großen Wert auf OOP, und daraus folgt für sie, Modul-Methoden nur zu verwenden, wenn geeignete Objekt-Methoden nicht verfügbar sind.

(Rechtschreibfehler urheberrechtlich geschützt)

Beitrag wurde zuletzt am 21.05.14 um 04:54:51 editiert.

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: Manfred X
Datum: 21.05.14 08:08

Die "String.Substring"-Methode stellt eine Funktionalität anders
zur Verfügung als "Strings.Mid" oder "Strings.Right".
Bei Parameter-Werten, die auf Indizes außerhalb der aktuellen Zeichenfolge
verweisen, wird bei "Substring" jeweils eine Ausnahme geworfen.
Die Strings-Methoden "Left", "Mid", "Right" sind auf diese "Substring"-Methode
aufgesetzt. Sie werfen aber keine Ausnahmen, sondern geben bei Index-Überschreitungen
in den Parametern die jeweils verfügbare (Teil-)Zeichenfolge zurück.
Das sind also Varianten, von denen keine der anderen "überlegen" oder relativ
besser durchdacht ist.

In der MSDN wird sowohl das Begriffspaar "Klasse - Modul" wie auch
das Begriffspaar "Klassenmodul - Standardmodul" verwendet. Man muß deshalb
beide Bezeichnungsweisen kennen.

Sowohl für Methoden in Klassen-Modulen als auch für Routinen in Standard-Modulen existiert
die Intellisense-Unterstützung. (Bei gekapselten Klassen ist sie nicht erforderlich.)
Das gilt auch für den Objektbrowser.

[I]Das ist das eine - das andere ist: ich weiß, wo ich die Methoden suchen muss, um ein
Objekt zu manipulieren - nämlich in der Klassen-Definition des Objektes[/I]
Das trifft auf die String-Klasse nur z.T. zu, weil Zeichenfolgen-Methoden auch in der
Stringbuilder-Klasse angesiedelt sind, die Zeichenfolgen als dynamische Liste verwaltet.

Erweiterungsmethoden sind kein Bestandteil von Objekten.
Das sind "prozedurale" Konstruktionen, die nur "locker" über eine Aufrufkonvention mit
dem Objekt im ersten Parameter verknüpft werden können.

(Wären die oben angesprochenen Methoden der MSVB.Strings-Klasse in einem Modul deklariert
und mit dem Extension-Attribut versehen, könnten sie direkt auch als Erweiterungsmethoden
der System.String-Klasse fungieren.)

Module modStringExtensions
 
    <System.Runtime.CompilerServices.Extension()> _
    Public Function mid(ByVal value As String, ByVal startindex As Integer, _
    ByVal length As Integer) As String
        Return Microsoft.VisualBasic.Mid(value, startindex, length)
    End Function
 
    <System.Runtime.CompilerServices.Extension()> _
    Public Function left(ByVal value As String, ByVal length As Integer) As _
    String
        Return Microsoft.VisualBasic.Left(value, length)
    End Function
 
    <System.Runtime.CompilerServices.Extension()> _
    Public Function right(ByVal value As String, ByVal length As Integer) As _
    String
        Return Microsoft.VisualBasic.Right(value, length)
    End Function
End Module


Beitrag wurde zuletzt am 21.05.14 um 08:34:22 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: ErfinderDesRades
Datum: 21.05.14 11:15

nanu?
Also das ist alles richtig, und ist mir bekannt, was du jetzt sagst, und ich denke, weißt du auch, dasses mir bereits bekannt ist - also ich stimme dir ganz zu.
Zur Modul-Klasse-Begrifflichkeit: Ich bezeichne hier mit "Modul", was in vb.Net mit dem Schlüsselwoert "Module" deklariert wird (c#: "shared class"), und als "Klasse" bezeichne ich, was im Code als "Class" deklariert wird. Anderes gelagerte Begriffsverwendungen finde ich unglücklich, weil sie genau den Punkt "Objektorientierung" verwaschen: Aus einer Class kann man ein Objekt instanzieren, aus einem Module nicht.
Nun werden die Begriffe halt auch anders verwendet, das führst du richtig aus, aber für den strittigen Punkt bringt das nur Irritation.

Strittig zwischen uns ist ja meine Feststellung, dass das mvb-Strings-Modul weniger objektorientiert ist als die String-Klasse - es ist halt ein Modul, und kann man kein Objekt draus erstellen.
Das ist dir ja auch bekannt, nur zu meiner Verwunderung widersprichst du mir so energisch, wenn ich sage, die mvb-Methoden seien obsolet, weil in der String-Klasse ist besser geeignetes und desingnetes (eben OOP), und nennst es "Unsinn".
Dabei weißt du es so gut wie ich.

Nur wenn ich es sage - zu stefanbla80, der es nicht weiß - dann kommt dein eigentümlicher energischer Widerspruch - ich finde zum Schaden von stefanBla80, der sich aus diesem Wortgefecht raushält, und am Ende dann auch zu keiner Entscheidung gelangt.
Ich versuche ihn auf das Kern-OOP-Prinzip "Objektmethode" hinzuweisen am ganz praktischen Beispiel, und zu motivieren, sich mit der String-Klasse intensiv auseinander zu setzen, und mit Klassen überhaupt - vorzugsweise mittels ObjectBrowser.
Aber durch dieses mir aufgezwungene Gefachsimpel, machst du es zunichte, und ich frag mich, was von diesem Verhalten das Ziel ist.
Ebenso verhielt es sich ja bei sloorgs Thread - hier: http://www.vbarchiv.net/forum/id22_i95571t95543_subroutine-schreiben.html

Aber auf das hier kann ich noch eingehen, weil das argumentiert ja für mich:
Zitat:

(Wären die oben angesprochenen Methoden der MSVB.Strings-Klasse in einem Modul deklariert und mit dem Extension-Attribut versehen, könnten sie direkt auch als Erweiterungsmethoden der System.String-Klasse fungieren.)
Wie gesagt: du kennst dich so gut aus wie ich, und daher weißt du so gut wie ich:
Wären Len, Mid, StrDup, Left, Format, Instr, LTrim, RTrim, LSet, RSet, StrComp, UCase, LCase Extension-Methods, dann wäre all diese Funktionalität nicht nur (wie jetzt) doppelt verfügbar, sondern die Redundanz wäre nun auch noch direkt sichtbar inne Intellisense.
Also das (historisch bedingte) unglückliche Design wäre ja wohl ins Groteske getrieben, wenn alles doppelt angeboten würde, unter jeweils 2 verschiedenen Namen.

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: Manfred X
Datum: 21.05.14 15:40

[I]... zu meiner Verwunderung widersprichst du mir so energisch, wenn ich sage,
die mvb-Methoden seien obsolet, weil in der String-Klasse ist besser geeignetes
und desingnetes (eben OOP), und nennst es "Unsinn".[/I]

Du machst drei Fehler:
- Du stellst die Framework-Methoden den korrespondierenden MSVB-Methoden gegenüber,
obwohl MSVB auf die Framework-Methoden aufsetzt.
- Du nimmst die Besonderheiten von Methoden in den MSVB-Klassen nicht zur Kenntnis.
- Aus diesen beiden Fehlern resultiert der dritte Fehler:
Deine Beurteilung von MSVB als obsolet, als schwaches Design usw.

Korrekt wäre es, den konzeptionellen Hintergrund der einzelnen MSVB-Klassen darzulegen
und so dem Nutzer die (qualifizierte) Entscheidung zu überlassen, ob er einzelne Klassen
verwenden oder ob er vielleicht sogar grundsätzlich auf einen Import/Verweis
verzichten möchte.

MSVB: Namespace Microsoft.Visualbasic







Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Hierarchie im TreeView 
Autor: ErfinderDesRades
Datum: 21.05.14 16:30

Ich mache drei Richtigkeiten:
- Ich stelle die Framework-Methoden den korrespondierenden MSVB-Methoden gegenüber (wieso auch nicht?)
Dann konstantiere redundant implementierte Funktionalität, und sage: wenn etwas doppelt gemoppelt ist, dann kann eins davon weg. Ich schlage vor, die im OOP-Design angelegte Funktionalität zu bevorzugen
- Ich nehme die Besonderheiten von Methoden in den MSVB-Klassen zur Kenntnis - wenn sie denn besteht. Häufig fällt die Besonderheit auch noch zu Ungunsten der MSVB-Funktionalität aus, wie etwa die 1-basiertheit der Instr - Methode.
- Aus diesen beiden Richtigkeiten resultiert die dritte Richtigkeit:
Meine Beurteilung von MSVB als obsolet, als schwaches Design usw.

Zitat:

Korrekt wäre es, den konzeptionellen Hintergrund der einzelnen MSVB-Klassen darzulegen
Du weisst so gut wie ich, dass der MSVB für so eine Titanen-Arbeit zu umfangreich ist

Zitat:

und so dem Nutzer die (qualifizierte) Entscheidung zu überlassen, ob er einzelne Klassen
verwenden oder ob er vielleicht sogar grundsätzlich auf einen Import/Verweis verzichten möchte.
Ich überlasse jedem die Entscheidung, ob er den MSVB nutzen will, so qualifiziert, wie er halt ist.
Ich beurteile nur den MSVB in der von dir abgelehnten Weise - und begründe das sowohl mit allgemeinen Feststellungen als auch an konkreten Beispielen.
Aufgrund meiner Beurteilung empfehle ich, den MSVB aus den GeneralImporten zu entfernen - das ist alles.
Damit ist ja nichts an Funktionalität deaktiviert, lediglich die vielen Codenamen der meist redundanten Methoden fahren nicht mehr in jedem aktuellen Namespace herum.
Weiters empfehle ich generell, objektorientierte Methoden zu bevorzugen, und auch bei Recherchen nach objektorientierter Logik vorzugehen - also vorrangig in den Klassen-Definitionen der Objekte zu suchen, und findet sich dort nichts geeignetes, erst dann in nachrangigen Resourcen, wie etwa der Convert-Klasse oder halt im MSVB.

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

ManfredX.Strings 
Autor: Manfred X
Datum: 21.05.14 19:17

Wie "speziell" müssen Methoden eigentlich sein, damit sie von Dir nicht
als "obsolet" eingestuft werden?
Kann eine dieser Routinen Dein "Kriterium für Nicht-Obsoletheit" erfüllen?
Namespace ManfredX
           ''' <summary>Spezielle String-Methoden (Ausnahmen werden 
           ' geworfen)</summary>
        Public Class Strings
 
            ''' <summary>Rückgabe des hinteren/rechten Teils eines String</summary>
            ''' <param name="value">String, dessen rechter Teil 
            ' zurückgegeben wird</param>
            ''' <param name="length">Länge des Teilstrings</param>
            Public Shared Function RightPart(ByVal value As String, _
                            ByVal length As Integer) As String
                With value
                    Return .Substring(.Length - length, length)
                End With
            End Function
 
 
            ''' <summary>Bestimmung der Anzahl Zeichen, die Buchstaben etc. 
            ' sind</summary>
            ''' <param name="IncludeDigits">auch Zahlen zählen?=</param>
            ''' <param name="IncludePunctuation">auch Satzzeichen zählen?</param>
            ''' <param name="IncludeSymbols">auch Math-, Currency-, 
            ' Modifier-, Other-Symbole zählen?</param>
            ''' <param name="IncludeWhitespaces">auch Spaces, Tabs, 
            ' Line-/Paragraph-Seps zählen?</param>
            Public Shared Function CountCharTypes(ByVal text As String, _
                         Optional ByVal IncludeDigits As Boolean = False, _
                         Optional ByVal IncludePunctuation As Boolean = False, _
                         Optional ByVal IncludeSymbols As Boolean = False, _
                         Optional ByVal IncludeWhitespaces As Boolean = False) _
                         As Integer
 
                If String.IsNullOrEmpty(text) Then Return 0
 
                Dim sum As Integer = 0
                For i As Integer = 0 To text.Length - 1
                    Dim c As Char = text(i)
                    If Char.IsLetter(c) Then
                        sum += 1
                    ElseIf IncludeDigits AndAlso Char.IsNumber(c) Then
                        sum += 1
                    ElseIf IncludePunctuation AndAlso Char.IsPunctuation(c) Then
                        sum += 1
                    ElseIf IncludeSymbols AndAlso Char.IsSymbol(c) Then
                        sum += 1
                    ElseIf IncludeWhitespaces AndAlso Char.IsWhiteSpace(c) Then
                        sum += 1
                    End If
                Next i
                Return sum
            End Function
 
 
            ''' <summary>Ersetzung der Steuerzeichen</summary>
            ''' <param name="Replacement">Zeichenfolge für die Ersetzung der 
            ' Steuerzeichen</param>
            Public Shared Function ReplaceControls(ByVal text As String, _
                            Optional ByVal Replacement As String = "") As String
 
                If String.IsNullOrEmpty(text) Then Return String.Empty
                Dim stb As New StringBuilder(text.Length)
                For i As Integer = 0 To text.Length - 1
                    Dim c As Char = text(i)
                    If Char.IsControl(c) Then
                        If Not String.IsNullOrEmpty(Replacement) Then
                            stb.Append(Replacement)
                        End If
                    Else
                        stb.Append(c)
                    End If
                Next i
                Return stb.ToString
            End Function
 
 
            ''' <summary>Entfernung von Zeichen-Wiederholungen</summary>
            ''' <param name="repeatingcharacter">das Zeichen, dessen 
            ' Wiederholungen entfernt werden</param>
            Public Shared Function RemoveRepeatingCharacter_
                                  (ByVal text As String, _
                                   ByVal repeatingcharacter As Char) As String
 
                If String.IsNullOrEmpty(text) Then Return String.Empty
                Dim stb As New StringBuilder(text.Length)
                Dim repeating As Boolean
                For i As Integer = 0 To text.Length - 1
                    Dim c As Char = text(i)
                    If Not c = repeatingcharacter Then
                        stb.Append(c)
                        repeating = False
                    ElseIf Not repeating Then
                        stb.Append(c)
                        repeating = True
                    End If
                Next i
                Return stb.ToString
            End Function
 
        End Class
    End Namespace
End Namespace


Beitrag wurde zuletzt am 21.05.14 um 19:19:16 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: ManfredX.Strings 
Autor: ErfinderDesRades
Datum: 21.05.14 19:55

Obsolet würde ich allenfalls die RightPart-Methode nennen, weil die doch exakt macht, was bereits die MSVB.Right-Methode tut. Zu den anneren Methoden ist mir nix bekannt im Framework, was die hier gezeigte Funktionalität komfortabel ersetzen würde.

Aber strittig zwischen uns ist doch nicht deine Strings-Klasse, sondern das MSVB.Strings-Modul.
Und strittig ist die Frage, obs sinnvoll ist, den GeneralImport auf MSVB drinne zu lassen, angesichts des stark überwiegenden Anteils obsoleter Methoden, die da drin rumfahren.

Ist übrigens interessant, dass deine RightPart-Methode **nicht** auf der (obsoleten) Microsoft.Visualbasic.Strings.Right() - Methode basiert, sondern auf der objektorientierten System.String.SubString()-Methode.
Überhaupt finde ich in deiner ganzen Klasse keine einzige Verwendung des MSVB.Strings-Moduls - ausschließlich objektorientiert designete Methoden finden Verwendung.

Was mich ja die ganze Zeit so irritiert:
Du selbst weißt es doch besser, und du selbst gibst ebenso wie ich den oop-designeten Methoden den Vorrang, aber wenn ich stefanbla80 auf dasselbe aufmerksam mache - nämlich dass die MSVB-String-Verarbeitung obsolet ist, und er sich besser die Verarbeitung angugge soll, die in der String-Klasse selbst angelegt ist - dann nennst du es "Unsinn".

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: ManfredX.Strings 
Autor: Manfred X
Datum: 21.05.14 20:46

Meine Klasse ist genauso gebaut, wie die MSVB.Strings -
sie baut direkt auf den Framework-Klassen auf.

Du beantwortest Fragen, die nicht gestellt worden sind.
Ob Methoden in einem Namespace als "gutes Design" gemäß irgendwelcher
OOP-Regeln gelten können, wird jeder, der sich mit solchen Inhalten
auskennt, selbst beurteilen können.

Für einen Einsteiger sind Deine Aussagen nicht einzuordnen.
Er stellt Vermutungen darüber an, welche (negativen) Folgen es möglicherweise
haben könnte, wenn diese Klassen verwendet werden.
Er fragt sich: Sind diese Verfahren ineffizient, fehlerhaft, verwirft Microsoft
sie in einer späteren VB-Version????

Ich wäre zufrieden, wenn Du für Einsteiger nachvollziehbare Informationen
liefern würdest, z.B.
- unterschiedliche Index-Basierung; deshalb nicht in einem
Code-Modul mischen, wegen Verwechslungsgefahr (z.B. bei Loops)
- unterschiedliche Fehlertoleranz; zu beachten bei der Gestaltung der
Ausnahmenverarbeitung und der erforderlichen Wertüberprüfungen
- usw.




Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: ManfredX.Strings 
Autor: ErfinderDesRades
Datum: 21.05.14 21:18

Manfred X schrieb:
Zitat:

Für einen Einsteiger sind Deine Aussagen nicht einzuordnen. Er stellt Vermutungen darüber an, welche (negativen) Folgen es möglicherweise haben könnte, wenn diese Klassen verwendet werden.
Er fragt sich: Sind diese Verfahren ineffizient, fehlerhaft, verwirft Microsoft sie in einer späteren VB-Version????

Ich wäre zufrieden, wenn Du für Einsteiger nachvollziehbare Informationen liefern würdest...
Sorry, aber was redest du da für Zeug?
lies doch nochmal nach, was ich auf stefanbla80 geantwortet habe: http://www.vbarchiv.net/forum/id22_i95667t95661_hierarchie-im-treeview.html
Zunächst gab ich ihm ein Beispiel, und dazu nur eine kleine Anmerkung bezüglich bestimmter obsoleter Methoden - ich war es nicht, der ihn überfordert mit endlosen und eigenartigen Grundsatzdiskussionen.

Meine kleine Anmerkung ist direkt am Beispiel nachvollziehbar, denn im Code kann er ja nachgucken, wie ich sein umständliches MSVB.Len durch die String.Length-Objekt-Property ausgetauscht hab, und sein umständliches MSVB.Left durch String.Substring-Objektmethode.
Was kann man da nicht einordnen - man braucht doch nur hinzugucken?

Auch ist die Bezeichnung "Obsolet" ganz klar, da wird niemand, der der deutschen Sprache so leidlich mächtig ist, iwelche abstrusen Vermutungen anstellen: Obsolet bezeichnet ganz eindeutig etwas, was zwar funktioniert, was man aber üblicherweise nicht mehr benutzt wird, weils inzwischen besseres gibt.

Wie gesagt: zur Untermauerung habe ich das Beispiel gegeben, zu abwegigen Vermutungen keinen Anlass, und wenn doch Fragen entstünden, oder Interesse, ist er automatisch aufgefordert, solch zu äussern, um tiefer gehende Infos zu erhalten. Dir antworte und erläutere ich ja auch alles haarklein - sogar obwohl ich weiß, dass du es selbst weißt.

Du hingegen gibst ihm schlicht eine Falsch-Information, wenn du meine Aussage wider besseres Wissen als "Unsinn" hinstellst, mit dem ich aufhören soll: http://www.vbarchiv.net/forum/id22_i95671t95661_hierarchie-im-treeview.html
Damit entwertest du auch meine Tipps, nämlich oop-Design zu bevorzugen, die String-Klasse zu untersuchen, den ObjectBrowser zu benutzen.

Ich weiß einfach nicht, was es ist, was dich so treibt, mir unbedingt widersprechen zu müssen, gegen dein eigenes besseres Wissen, und gegen deine eigene Code-Praxis, und auch ohne Rücksicht darauf, dass du stefanbla80 dadurch ein Stück weit behinderst, von seinem Anfänger-Niveau herunterzukommen.

(Rechtschreibfehler urheberrechtlich geschützt)

Beitrag wurde zuletzt am 21.05.14 um 21:34:08 editiert.

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: ManfredX.Strings 
Autor: Manfred X
Datum: 21.05.14 22:52

Und warum postest Du nicht verständliche Infos, wie z.B.:

Bei Verwendung von "MSVB.Left" muß man nicht beachten, daß auf Zeichen
im System.String null-basiert zuzugreifen ist. Es ergibt sich aber
ggf. ein Benennungs-/Verwechslungs-Problem wegen der "Control.Left"-Methode.
(Da "MSVB.Left" intern die "String.Substring" verwendet, kann es nichts
"besseres" geben. Du stellst Geschmacksfragen als Qualitätsurteile dar.)








Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: ManfredX.Strings 
Autor: ErfinderDesRades
Datum: 21.05.14 23:05

Zitat:

(Da "MSVB.Left" intern die "String.Substring" verwendet, kann es nichts "besseres" geben. Du stellst Geschmacksfragen als Qualitätsurteile dar.)
Es ist völlig egal, was MSVB.Left intern verwendet - die String.Substring-Methode als Objekt-Methode ist besser **designed** - schon vergessen?

(Rechtschreibfehler urheberrechtlich geschützt)

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel