| |
| Die 10 hitzebeständigsten Materialien für den 3D-Druck, ein Fachartikel
|
Autor
|
Thema: Privat Sub vs. Sup (10226 mal gelesen)
|
Bernd P Ehrenmitglied V.I.P. h.c. cook-general
Beiträge: 3424 Registriert: 07.06.2001
|
erstellt am: 08. Sep. 2006 08:54 <-- editieren / zitieren --> Unities abgeben:
Hi Mir ist aufgefallen das es 2 Verschieden Befehlsaufrufe in Excel gibt. Privat Sub und Sub Was ist der Unterschied zwischen den 2? Hintergrund ist das ich mit Makroaufzeichnung diverse Makros aufzeichne, diese funktionieren unter Sub nicht aber unter Privat Sub. ------------------ "Warum Einfach es geht auch kompliziert". Schöne Grüsse aus der Steiermark Bernd P. Bitte Supportangaben eintragen, warum siehst du hier Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
runkelruebe Moderator Straßen- / Tiefbau
Beiträge: 8086 Registriert: 09.03.2006 MS-Office 365 ProPlus x86 WIN7(x64)
|
erstellt am: 08. Sep. 2006 09:06 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Meine Meinung: unterstützt von wer-weiß-was Sub = Public Sub Private Sub: Variablen, Anweisungen usw. sind nur innerhalb dieser Sub zu sehen, von außerhalb kann man nicht drauf zugreifen. Public Sub: alles was hier steht kann auch von woanders verwendet werden. deshalb auch Dein Fehler bei Private Sub. Gruß, Nicole [e] btw haste mal die Hilfe von Excel VBA dazu befragt?
Code: Syntax[Private | Public] [Static] Sub Name [(ArgListe)] Public: Optional. Auf die Sub-Prozedur kann von allen anderen Prozeduren in allen Modulen zugegriffen werden. Bei Verwendung in einem Modul (mit einer Option Private-Anweisung) kann auf die Prozedur nur innerhalb des Projekts zugegriffen werden.
Private: Optional. Auf die Sub-Prozedur kann nur durch andere Prozeduren aus dem Modul zugegriffen werden, in dem sie deklariert wurde. Static: Optional. Die lokalen Variablen der Sub-Prozedur bleiben zwischen Aufrufen erhalten. Das Attribut Static wirkt sich nicht auf Variablen aus, die außerhalb der Sub-Prozedur deklariert wurden, auch wenn sie in der Prozedur verwendet werden.
[/e] ------------------ Herr Kann-ich-nich wohnt in der Will-ich-nich-Straße... ---------------- Erfinnder-Gilden-Lehrling Stufe: 0,5 [Diese Nachricht wurde von runkelruebe am 08. Sep. 2006 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Bernd P Ehrenmitglied V.I.P. h.c. cook-general
Beiträge: 3424 Registriert: 07.06.2001
|
erstellt am: 08. Sep. 2006 09:27 <-- editieren / zitieren --> Unities abgeben:
THX Also Privat Sub funkt nur in der XLS in der es ist. (soweit ich das verstehe) ------------------ "Warum Einfach es geht auch kompliziert". Schöne Grüsse aus der Steiermark Bernd P. Bitte Supportangaben eintragen, warum siehst du hier Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
runkelruebe Moderator Straßen- / Tiefbau
Beiträge: 8086 Registriert: 09.03.2006 MS-Office 365 ProPlus x86 WIN7(x64)
|
erstellt am: 08. Sep. 2006 09:57 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
|
okl Mitglied Wirtsch-Ing (Maschbau)
Beiträge: 157 Registriert: 21.04.2006 3,6 GHz, 2 GB RAM, NVIDIA Quadro FX 1300, Delmia V5R16 SP1, Win XP Prof SP2, Office 2003, VS 2005, VB 6
|
erstellt am: 08. Sep. 2006 10:12 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Hallo! Sub oder Function ohne vorangestelltes Public, Private etc ist IMHO kein guter Programmierstil. Man sollte immer alles richtig deklarieren. Wie zB die Variablen, die man unter VBA auch einfach mit Code: Dim a
oder auch gar nicht deklarieren kann/muss. Kostet unnötig Speicherplatz und nimmt Performance. Vielleicht merkt man es bei der - Entschuldigung, möchte niemandem zu Nahe treten - "Hausgebrauch-Programmierung" nicht, aber bei größeren, komplexeren Anwendungen wird es sehr schnell sehr interessant. Ist nur ein gutgemeinter Tipp, da ich früher auch nicht alles deklariert habe und jetzt durch meine Arbeit merke, wie wichtig das sein kann (nicht muss). Grüße, oklEine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Paulchen Mitglied Bauing./SW-Entwickler
Beiträge: 1227 Registriert: 19.08.2004 Büro: Win10 Enterprise 64bit, Office Professional Plus 2013 - Privat: Linux Mint 15, LibreOffice
|
erstellt am: 08. Sep. 2006 10:23 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Hallo zusammen! @okl: Richtig, sehe ich genauso. Dazu fällt mir noch unter "Extras-Optionen-Variablendeklaration erforderlich" im VBA-Editor ein: Option Explicit. Hat ECHT Vorteile, auch wenn´s manchmal (bei "mal schnell..." echt nerven kann:-) @Nicole: Gute Arbeit! @Bernd: Nur ´ne Kleinigkeit: Du schreibts wiederholt "Privat", es heißt jedoch "Private", mit "e" am Ende, englisch. Könnte Dir sonst auch ´ne Fehlermeldung bescheren bzw. den Text im Editor rot färben - rot = ungut. Apropos: Nix für ungut! Gruß Frederik Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
runkelruebe Moderator Straßen- / Tiefbau
Beiträge: 8086 Registriert: 09.03.2006 MS-Office 365 ProPlus x86 WIN7(x64)
|
erstellt am: 08. Sep. 2006 10:26 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
|
Paulchen Mitglied Bauing./SW-Entwickler
Beiträge: 1227 Registriert: 19.08.2004 Büro: Win10 Enterprise 64bit, Office Professional Plus 2013 - Privat: Linux Mint 15, LibreOffice
|
erstellt am: 08. Sep. 2006 10:46 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Jo, dazu nochmal ein Zitat aus der Hilfe zu VBA: Zitat: Sub-Prozeduren sind standardmäßig öffentlich, wenn sie nicht explizit mit Public oder Private festgelegt werden. Wird Static nicht angegeben, so bleiben die Werte lokaler Variablen zwischen den Aufrufen nicht erhalten.
Frederik Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
okl Mitglied Wirtsch-Ing (Maschbau)
Beiträge: 157 Registriert: 21.04.2006 3,6 GHz, 2 GB RAM, NVIDIA Quadro FX 1300, Delmia V5R16 SP1, Win XP Prof SP2, Office 2003, VS 2005, VB 6
|
erstellt am: 08. Sep. 2006 10:53 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Hallo Nicole, Zitat: dann bring' dem Makro-rekorder bitte bei, daß er unsauber programmiert
Du meinst sicher "sauber". Egal, ich glaube, wir meinen dasselbe. Der Recorder gibt erste Anhaltspunkte und mehr nicht. Dafür ist der gut, aber mehr kann er nicht und sollte auch IMHO nicht können. Sonst wäre ich ganz schnell ganz viel Arbeit los. Und das wäre zum ! Schüs, okl PS: Nicole, Deine Sucherfolge in der Zeit sind echt beeindruckend! -> 10U Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nepumuk Mitglied Entwicklungsleiter
Beiträge: 351 Registriert: 16.10.2004
|
erstellt am: 11. Sep. 2006 15:24 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Liebste Nicole, da muss ich aber mal einen Wiederspruch einlegen . Teste mal das: Modul1:
Code:
Private Sub test1() MsgBox "Hallo Nicole" End Sub
Modul2:
Code:
Public Sub test() Application.Run "test1" End Sub
Starte den Code in Modul2.------------------ Gruß Nepumuk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Paulchen Mitglied Bauing./SW-Entwickler
Beiträge: 1227 Registriert: 19.08.2004 Büro: Win10 Enterprise 64bit, Office Professional Plus 2013 - Privat: Linux Mint 15, LibreOffice
|
erstellt am: 11. Sep. 2006 15:56 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Hallo Nepumuk, entschuldige, daß ich mich einmische, aber Du tust Nicole unrecht. Du müßtest stattdessen Bill widersprechen. Hier nochmal das Zitat aus der Hilfe zu "Private": Zitat: Optional. Auf die Sub-Prozedur kann nur durch andere Prozeduren aus dem Modul zugegriffen werden, in dem sie deklariert wurde.
Das Dein Test funktioniert, wundert mich auch - dürfte er nämlich nach obiger Beschreibung eigentlich nicht..? Du rufst ja die Private Sub aus einem anderen Modul auf. Seltsam. Sinn? Frederik Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Paulchen Mitglied Bauing./SW-Entwickler
Beiträge: 1227 Registriert: 19.08.2004 Büro: Win10 Enterprise 64bit, Office Professional Plus 2013 - Privat: Linux Mint 15, LibreOffice
|
erstellt am: 11. Sep. 2006 16:00 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Ha! Geht doch! Es liegt an Deinem "Application.Run"!!! Laß´ mal eben dieses weg, also nur Code: Private Sub test() test1 End Sub
und ändere dann den Code im Modul1 zwischen Priv. und Public. Dein Befehl umgeht wohl diese (gelegentlich durchaus sinnvolle) Hürde.Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nepumuk Mitglied Entwicklungsleiter
Beiträge: 351 Registriert: 16.10.2004
|
erstellt am: 11. Sep. 2006 16:20 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Hi, ich wollte doch nur mal zeigen, dass der Zusatz "Private" bei einer Sub / Function nur bedingt vor einem externen Zugriff schützt. Nur in Klassen kannst du darauf nicht zugreifen. In Klassen gibt es auch noch das "halböffentliche" Friend mit dem du auf Subs / Funktions / Propertys zugreifen kannst. Das ist nicht so frei wie Public (alle können zugreifen) und weniger restriktiv wie Private (Nur Prozeduren im Modul selbst können zugreifen). Sondern lässt einen Zugriff innerhalb des Projektes, in dem sie deklariert ist, zu. ------------------ Gruß Nepumuk Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Paulchen Mitglied Bauing./SW-Entwickler
Beiträge: 1227 Registriert: 19.08.2004 Büro: Win10 Enterprise 64bit, Office Professional Plus 2013 - Privat: Linux Mint 15, LibreOffice
|
erstellt am: 11. Sep. 2006 16:27 <-- editieren / zitieren --> Unities abgeben: Nur für Bernd P
Hallo, Zitat: Ich wollte doch nur mal zeigen, dass der Zusatz "Private" bei einer Sub / Function nur bedingt vor einem externen Zugriff schützt...
Das ist Dir - zumindest was mich angeht - perfekt gelungen. Man lernt nie aus! Frederik Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |