Diskussion:Visual Basic 6

Invitation to Visual Basic Class in English

I am editing the Visual Basic Classic WikiBook at http://en.wikibooks.org/wiki/Programming:Visual_Basic_Classic. Are you interested in writing anything there too? Or perhaps there is something there that you could translate and use in this book. [Kwhitefoot] 137.133.163.142 10:56, 19. Sep 2005 (UTC)

No, sorry, I can't write on your book, because my English is too bad for such things :( --85.212.16.158 18:17, 19. Sep 2005 (UTC)

If that's the only reason then don't let it hold you back. It can always be fixed up by someone else. The big problem with all the VB books on WikiBooks is lack of contributors not poor grammar. Besides my German is a thousand time worse :-)

Wenn der der einzige Grund dann ist, lassen Sie ihn nicht Sie zurück halten. Er kann von jemand anderes immer oben geregelt werden. Das grosse Problem mit allen VB-Büchern auf WikiBooks ist Mangel an schlechter Grammatik der Mitwirkenden nicht. Außer meinem Deutschen tausendist mal schlechter. By http://translate.google.com/translate_t. --137.133.163.142 07:54, 22. Sep 2005 (UTC)

I have read the first two pages of the English book... It has a completly other structure than my.... But maybee I'll try to write some paragraphs if I have enough time, at the moment I even haven't enough time for my German book :( --213.54.173.34 09:57, 24. Sep 2005 (UTC)

Notation

Da es sich doch um ein Buch für Anfänger handeln soll würde ich vorschlagen gleich eine lesbare Notation zu verwenden. Ich habe mich mitlerweile ans "ungarische" gewöhnt, will sagen vor die sprechenden Namen einen dreistelligen Suffix zu setzen der bei Variablen den Datentyp anzeigt. Ich nutze diese Notation auch bei Objekten und den Dateinamen (Beispiel: frmSplash), lediglich externe Objekte sowie Variable in öffentlichen Schnittstellen nehme ich davon aus. Auch Leerzeilen und Einrückungen tragen zur Lesbarkeit bei, was das Lernen erleichtert und einen interessierten "Schüler" evtl. gleich beibringt lesbareren Code zu produzieren. Nur ein Vorschlag zur Diskussion. --True 12:34, 22. Nov 2005 (UTC)

Hab das auch schon auf der Einführungs-Disk. geschrieben, grade eben allerdings diesen Beitrag gelesen, also hierher verschoben und ergänzt:

Also ich kenn das ganze System unter dem Namen Reddik-Namenskonvention. Ich hab da bei mir daheim ein PDF rumliegen, das alle Standard-Steuerelemente und einen Haufen der Zusatzsteuerelemente mit solchen Kürzeln versieht. Außerdem hat es noch Präfixe für globale und private Variablen, Arrays, ...

Ich find das System sehr gut, vor allem, weil es einfach Ordnung schafft und den Code auch für andere lesbar macht. Ich zumindest weiß manchmal selber nicht mehr, was ich mir damals gedacht hab, als ich dieses oder jenes Codestück geschrieben hab und dann helfen diese Präfixe schon sehr.

Allerdings denke ich nicht, dass wir alle Präfixe, die in besagtem PDF erwähnt werden, hier auflisten sollten, denn ein Anfänger fühlt sich dadurch vielleicht belästigt (einige sind recht unverständlich, zum Beispiel r für Parameter und manche auch recht sinnlos, zum Beispiel h für Fensterhandles).

Also meine Auswahl wäre folgendes:

• Präfixe der Datentypen und ein einheitliches für benutzerdefinierte (das PDF sagt udt: User Defined Type). Für Konstanten halte ich ein Kürzel für überflüssig. Da sollte der Name allein aussagekräftig genug sein (PI, E, ...).
• Präfixe für globale (g), private (das PDF sagt hier m, wegen modulglobal) und statische (s) Variablen, sowie Arrays (a)
• Präfixe der Standard-Steuerelemente, sowie von Formular, MDI-Form und Menü
• Bei den Zusatzsteuerelementen vielleicht noch die häufigsten, wie Common Dialog, etc.

Außerdem finde ich, dass wir für lokale Zähler eine Ausnahme machen sollten und dort stattdessen kleinbuchstaben verwenden sollten, solange es sich nur um wenige benötigte handelt, da es sehr umständlich und teils auch verwirrend sein kann, wenn man in einem Array noch eine lange Variable á la lngZähler stehen hat. Also einfach die Standards: x, y, i, n, a, ...

Ich fände es auch sinnvoll, diese Notation nicht in einem eigenen Kapitel abzuhandeln, sondern sie einfach im Laufe des Buches mit einzuführen, jeweils dann, wenn das entsprechende Objekt/der entsprechende Datentyp erklärt wird (Kann man ja schön in die Tabellen mit integrieren), denn alles auf einem Haufen kann sich ja kaum jemand merken.

Soweit mal meine Meinung ;) --Karottenreibe^bla 20:08, 10. Mär 2006 (UTC)

Ich würde schon versuchen das strikt einzuhalten, man denke nur an verschachtelte Schleifenkonstrukte (abgesehen davon das man etwas falsch macht wenn es zu solchen Konstrukten kommt). Allerdings würde ich jetzt keine großangelegte Diskussion vom Zaun brechen bevor es losgeht da der Einwand durchaus für sich spricht.

-- True 11:29, 4. Mai 2006 (UTC)

Struktur

Ich habe damit begonnen eine Struktur aufzubauen, bisher noch ohne eine Idee wie am Ende das Buch in seiner Gesamtheit aufgebaut sein sollte. Mir fällt das leichter wenn bereits eine Menge Informationen vorliegen, wodurch natürlich später eine Menge zusätzlicher Aufwand bei Änderungen ansteht. Sollte bereits jemand eine Struktur vor Augen haben - Redet drüber ;) --True 13:35, 23. Nov 2005 (UTC)

Ich habe einfach mal angefangen eine Struktur für ein Buch aufzubauen. Nach meinem Verständnis ist die erste Seite (können auch mehrere sein) für die Einleitung bzw. die Grundlagen da. Für mich gehört dazu zunächst mal über Kommentierungen und Notation zu sprechen. Ein Anfänger muss sicher nichts über Messageing wissen, da aber alle Aspekte abgedeckt werden sollen, sehe ich auch die einleitende Beschreibung dazu auf der ersten Seite. Die weitere Strukturierung in Kapitel hängt natürlich auch davon ab welches Material wir verfügbar machen können.

--True 14:57, 24. Nov 2005 (UTC)

Wie soll denn die Seitenstruktur sein: Alles auf einer Seite wie z.B. bei BlitzBasic-Community-Tutorial oder die Kapitel auf eigenen Seiten? --Karottenreibe^bla 19:45, 10. Mär 2006 (UTC)

Man sollte von einem Kapitel ins nächste kommen können, ohne ins Inhaltsverzeichnis zu wechseln. Also Kapitel auf extra Seiten, würde ich vorschlagen. --BlackIsle 17:45, 16. Apr 2006 (UTC)

Ich würde auch Kapitel bevorzugen. Navigationsleisten habe ich bereits angefangen.. macht aber erst wirklich Sinn wenn sich eine Reihenfolge abzeichnet (blättern wie in einem Buch)

-- True 11:18, 4. Mai 2006 (UTC)

Alles unterhalb von Kapitel ist noch unstrukturiert und nirgends einzusortieren, auf diese Weise bleibt aber der Überblick erhalten. Ich habe auch Statusgrafiken hinzugefügt, natürlich kann und soll jeder Autor für die Bereiche an denen er arbeitet diese selbst verändern. Ich hoffe das dient nicht nur der Übersicht, sondern erleichtert neuen Autoren auch den Einstieg. --True 23:05, 5. Mai 2006 (UTC)

Verweise und Komponenten

Inwieweit soll das Projekt denn externe Komponenten behandeln? Ich denke da an so Dinge wie Common Dialog o.ä. und z.B. die Scripting Runtime (Die File System Objects sind für Datei-Operationen sehr praktisch, mmn). --Karottenreibe^bla 18:11, 9. Mär 2006 (UTC)

Als eigenes Kapitel? Und Unterkapitel? --85.212.29.184 20:46, 1. Mai 2006 (UTC)

Hier bitte daran denken das durchaus auch andere Bücher (vielleicht auch noch zu schreibende) betroffen sein können, oder es sogar sinnvoll sein kann ein eigenes daraus zu erstellen. Ich denke dabei vor allem an den Windows Scripting Host wenn das FSO Objekt angesprochen wird. Bei der API sieht das natürlich anders aus. Zunächst einmal sind ja eigene Seiten zu erstellen. Je nach Umfang lassen sich diese dann als Kapitel nutzen oder als eigene Bücher einbinden. Das FSO macht warscheinlich als Kapitel sowohl für VBScript/WSH als auch bei diversen Programmiersprachen Sinn.

-- True 11:50, 4. Mai 2006 (UTC)

Referenz

Ich schreibe grad an einer Referenz zu Steuerelementen und ihren Ereignisen und Eigenschaften. Also was sie bedeuten und bewirken. Ich würde diese hier gerne mit einbinden, aber ich weiß nicht wie und wo. Außerdem wär doch eine API-Referenz nicht schlecht, oder?

Ist bereits vorgesehen, siehe Steuerelemente

--True 12:33, 4. Mai 2006 (UTC)