Makroverhalten zwischen Excel07 und Excel16 unterschiedlich - vgl. protect/unprotect

[Schachspieler]

Hallo Makro-Spezialisten,

ein Freund von mir hat folgenden Code in Modul1. Dieser wird durch ein Doppelklick-Event in Tabelle1 ausgelöst (Datei auch anbei).
Unter Excel 2007 und Excel 2016 ergibt sich jeweils ein unterschiedliches Verhalten am Ende nach Ausführen/Starten des Codes:

Excel07
a) Doppelklick Tabelle1: am Ende ist Tabelle1 aktiviert
b) Start Makro direkt im VBA-Editor: am Ende ist Tabelle, aus der das Makro gestartet wird, aktiviert

Excel16
a) Doppelklick Tabelle1: am Ende ist Tabelle2 (nächste Tabelle) aktiviert - zusätzlich wundert mich, dass nicht Tabelle3 aktiviert ist
b) Start Makro direkt im VBA-Editor: am Ende Tabelle, aus der das Makro gestartet wird, aktiviert

Wieso ist das Verhalten unter a) unterschiedlich?Mir geht es weniger um eine Lösung (am Ende wieder Tabelle1 aktivieren), sondern Ist dieser Unterschied und die Ursache bekannt?

PHP-Code:

Modul1

Sub manuell()

Call entSperren
Call Sperren

End Sub
Sub entSperren()
Dim x As Integer
x = 0
For x = 1 To Worksheets.Count
    Worksheets(x).Unprotect
    If x = 3 Then: MsgBox ("aktives Blatt:" & ActiveSheet.Name & Chr(10) & "Blatt x " & Worksheets(x).Name & Chr(10) & "x: " & x)
Next x
End Sub
Sub Sperren()
Dim x As Integer
x = 0
For x = 1 To Worksheets.Count
    Worksheets(x).Protect
Next x

End Sub

Private Sub Worksheet_BeforeDoubleClick(ByVal Target As Range, Cancel As Boolean)

Call entSperren
Call Sperren
Cancel = True

End Sub 


Bin schon mal auf die Lösung gespannt
Danke

Andreas

[schauan]

Hallo Andreas,

seltsam.
Das passiert aber erst beim zweiten Durchlauf, wenn das Blatt 3 zuerst noch keinen Blattschutz hat.
Blattschutz manuell aufheben
1. Doppelklick in Tabelle1 - ist ok
2. Doppelklick in Tabelle1 - springt in Tabelle2

[Schachspieler]

Hallo André,

danke für deine Antwort. Ich nehme mal an, du beziehst dein Beispiel auf Excel16. Ich muss morgen mal testen, was beim 3. Doppelklick passiert.
Was mich wundert ist, dass es sich bei Doppelklick anders verhält als bei Start aus VBA-Editor. und bei Excel07 nochmals anders. Bevor ich die Frage ins Forum gestellt habe, habe ich auch mal ein bisschen Dr. Google befragt. Jetzt mag die Umstellung von Excel07 auf Excel13/Excel16 schon etwas länger her sein, aber dass ich nichts gefunden habe, finde ich ungewöhnlich. Denn so selten ist Blattschutz ja nun auch nicht.

Ich hoffe noch, dass Anderen im Forum das Problem (und noch wichtiger das Ausmaß) bekannt ist. Mein Freund muss jetzt wohl einige Datei-Makrios umschreiben. :22: Und die Ungewissheit, welch weiteren unerfindlichen Unwägbarkeiten bei der Umstellung noch lauern ist furchterregend.

[schauan]

Hallo Andreas,

das ist m.E. eindeutig ein Bug und ein ganz schön gefährlicher. Wenn man die Blattangabe bzw. Blattobjekte nicht fortwährend programmiert, weil man der Auffassung ist, das man sich auf einem bestimmten Blatt befinden muss, dann kommt sonstwas raus. Deine Frage könnte übrigens für mich ein Lösungsansatz bei einem anderen Problem sein. Ich suche schon seit Anfang Dezember in einer Anwendung die Ursache für das Löschen von Daten auf einem Blatt, wo ich gar nichts programmiert habe. Auch hier sind alle Blätter der Datei geschützt ... Bislang hatte ich mir mangels Ursachenfindung so geholfen, dass ich die Daten dort neu eingetragen habe.

Springt übrigens bei jedem weiteren Klick auch auf Tabelle2, so lange, bis Du wieder manuell den Blattschutz auf Tabelle3 rausnimmst. Dann beginnt das Spiel von neuem.

[Schachspieler]

Hallo André,

genau das war das Problem meines Freundes. Seine ganze Procedure lief daneben. Und bis man dies daraufals Ursache eingegrenzt hat.
Ich hatte gehofft, dass es irgendwo eine Übersichtsseite mit den wichtigsten/häufigsten Bugs gibt - und da hätte dieser m.E. auch aufgelistet werden müssen. Bin leider nicht fündig geworden.

Ich lasse den Thread noch offen, weil mich schon interessieren würde, ob dein anderes Problem damit zusammenhängt.

[schauan]

Hallo Andreas,

habe heute getestet und erst mal festgestellt, dass meine Projektdatei ziemlich verkorkst sein muss.

In dem Projekt habe ich einem Blatt manuell ein Passwort aaa zugewiesen. Im Code hebe ich das Passwort mit bbb auf und setze es später wieder auf bbb.
Beim ersten Durchlauf bekomme ich beim Aufheben des Passwortes durch meinen errorhandler die Fehlermeldung, dass das Passwort falsch wäre. Logisch, ist ja aaa. Im errorhandler wird neben anderen Aktionen das Passwort bbb wieder gesetzt.
Beim zweiten Durchlauf bekomme ich keine Fehlermeldung. Das Passwort wird aber gesetzt! Manuell aaa probiert - falsches Passwort! bbb probiert - klappt!

Ich habe daraufhin den Vorgang mit einer neuen Datei getestet, hier klappt alles. Da war ich zumindest "allgemein" beruhigt - wenn das ein Excel-Bug gewesen wäre - nicht auszudenken ...

Andererseits hab ich nun gelernt, dass man sogar den Passwortschutz beim Programmieren noch genauer im Auge behalten muss ... es fällt ja nicht unbedingt gleich auf, ob es Macken im Projekt gibt ...

[DbSam]

Hallo zusammen,

irgendwie hatte ich mal was ähnliches ....

Versucht es mal damit und ersetzt den Code in Modul1 durch diesen hier:

Code:

Option Explicit
Option Private Module

Public Enum eProtect
   Sperren
   entSperren
End Enum

Private Sub manuell()
   ProtectMyWorkbook entSperren
   ProtectMyWorkbook Sperren
End Sub

Public Sub ProtectMyWorkbook(ByVal p As eProtect)
On Error GoTo Er
   Dim i As Integer, sh As Worksheet
   
   Application.ScreenUpdating = False
   Set sh = ActiveSheet
   For i = 1 To Worksheets.Count
       Select Case p
           Case entSperren
               Worksheets(i).Unprotect
           Case Else
               Worksheets(i).Protect
       End Select
   Next i
Ex:
    On Error Resume Next
    sh.Activate
    Application.ScreenUpdating = True
    Set sh = Nothing
   Exit Sub
Er:
   Application.ScreenUpdating = True
   MsgBox CreateErrorMsgText(Err.Number, Err.Description), vbCritical, "Sub: ProtectMyWorkbook in Modul1"
   Resume Ex
   'For debug:
   Resume
End Sub

Public Function CreateErrorMsgText(ByVal ErrNumber As Long, ErrDescription As String) As String
On Error GoTo Er
   Dim s As String
   s = "Fehlermeldung/Information..." & vbCrLf & vbCrLf
   s = s & "Fehlernummer: " & vbTab & ErrNumber & vbCrLf & vbCrLf
   s = s & "Beschreibung: " & vbCrLf & ErrDescription
   CreateErrorMsgText = s
   
Ex:
   Exit Function
Er:
   Dim strErr As String
   Select Case Err.Number
       Case Else
           strErr = "Fehlermeldung/Information..." & vbCrLf
           strErr = strErr & "Fehlernummer: " & Err.Number & vbCrLf & vbCrLf
           strErr = strErr & "Beschreibung: " & vbCrLf & Err.Description
           MsgBox strErr, vbCritical + vbOKOnly, "Sub: CreateErrorMsgText in mdlCreateErrorMessage"
           Resume Ex
   End Select
   'for Debug:
   Resume
End Function

Gruß Carsten