Add-In nur mit VBA: wie erhalte ich ein onConnection-Event

[Mark Schneider]

Hallo,

wir haben leider "nur" Office 2003 Professional (kein Developer) und weder
VSTO
noch Visual Studio auf den Entwicklerworkstations. Daher versuchen wir, ein
kleines
Menü-Addin für den VBE in Access 2003 in reinem VBA zu erstellen.

Das funktioniert auch ganz gut und tut so wie wir wollen (usysreginfo wurde
aufgebaut,
mdb als mda umbenannt und wird vom Add-In-Manager erkannt), aber man muss
das Add-In
jedesmal einmal aufrufen, um die Symbolleiste aufzubauen, was auf Dauer
etwas lästig wäre.

Weder mit AddinInstance_OnConnection noch mit IDTExtensibility2_OnConnection
komme ich zu Potte, weil ich einfach nicht weiß, wie ich die ansprechen soll
bzw.
als Events für das Add-In nutzbar mache.

Gibt es da eine Möglichkeit oder weiß jemand, der mit einer Office Developer
gesegnet ist,
was Access da noch anlegt?

Natürlich kann man auf Visual Studio oder Visual Basic zurückgreifen, aber
vielleicht braucht
es die Kanone für unseren Spatzen gar nicht. Wäre klasse, wenn jemand eine
Idee oder
die richtige Erfahrung beisteuern kann...

Vielen Dank im voraus
Mark


Darf nicht alles posten, aber damit Ihr sehen könnt, was ich gerade verzapfe
---------------------------
Modul "myAddin":
Option Compare Database
Option Explicit

Dim oBtns As New Collection

Public Function myAddIn_start()
Set oBtns = Nothing
myAddIn_AddCommandBar ("myAddIn")
myAddIn_AddCommandBarButton "myAddIn", "Nummerieren", "numbering", 1553
myAddIn_AddCommandBarButton "myAddIn", "Einrücken", "indent", 2138
End Function

Function myAddIn_AddCommandBar(ByVal cCBname As String)
Dim cb As CommandBar
For Each cb In Application.VBE.CommandBars
If cb.Name = cCBname Then
myAddIn_removeCommandBar cCBname
End If
Next
Set cb = Application.VBE.CommandBars.Add(Name:=cCBname,
Position:=msoBarTop, temporary:=False)
cb.Visible = True
End Function

Function myAddIn_AddCommandBarButton(ByVal cCBname As String, _
ByVal cBtnCaption As String, _
ByVal cBtnTag As String, _
ByVal cBtnFaceID As Integer)
Dim cb As CommandBar
Dim oEvt As cls_myAddIn_ButtonEvents

Set cb = Application.VBE.CommandBars.Item(cCBname)

'Umweg über Klassenevents ist nötig, da in der VBE die Command
'Buttons nicht wirklich onaction unterstützen :(
'siehe:http://support.microsoft.com/default.aspx?scid=kb;en-us;Q280607

Set oEvt = New cls_myAddIn_ButtonEvents
Set oEvt.oBtn = cb.Controls.Add(msoControlButton)
With oEvt.oBtn
'.Style = msoButtonIconAndWrapCaption
.Style = msoButtonIconAndCaption
.Caption = cBtnCaption
.Tag = cBtnTag
.FaceId = cBtnFaceID
End With
oBtns.Add oEvt
End Function

Function myAddIn_removeCommandBar(ByVal cCBname As String)
Dim cb As CommandBar
For Each cb In Application.VBE.CommandBars
If cb.Name = cCBname Then
Application.VBE.CommandBars.Item(cCBname).Delete
Exit Function
End If
Next

End Function

Function myAddIn_buttonClick(ByVal cBtnTag As String)
MsgBox ("You clicked: " & cBtnTag)
End Function

' die wird nie aufgerufen
Public Sub AddinInstance_OnConnection(ByVal _
Application As Object, ByVal ConnectMode As _
AddInDesignerObjects.ext_ConnectMode, ByVal AddInInst _
As Object, custom() As Variant)
MsgBox ("TEST!")
End Sub
--------------------------------------
Klassenmodul 'cls_myAddIn_ButtonEvents':
--------------------------------------
Public WithEvents oBtn As CommandBarButton

Private Sub oBtn_click(ByVal ctrl As Office.CommandBarButton, CancelDefault
As Boolean)
DCode_buttonClick ctrl.Tag
End Sub

---------------------------
Tabelle uSysRegInfo:
---------------------------
Subkey;Type;ValName;Value
HKEY_CURRENT_ACCESS_PROFILE\Menu Add-ins\&myAddin;0;;
HKEY_CURRENT_ACCESS_PROFILE\Menu
Add-ins\&myAddin;1;Library;|ACCDIR\myAddin.mda
HKEY_CURRENT_ACCESS_PROFILE\Menu
Add-ins\&myAddin;1;Expression;=myAddin_start()
HKEY_CURRENT_ACCESS_PROFILE\Menu Add-ins\&myAddin;1;Version;3

---------------------------
kläglicher Versuch eines zusätzlichen Klassenmoduls, wie wird das dann
angesprochen?
---------------------------
Option Compare Database
Option Explicit
Implements AddInDesignerObjects.IDTExtensibility2
Public appHostApp As Application



Private Sub IDTExtensibility2_OnAddInsUpdate(custom() As Variant)
' not used but required by Implements.
MsgBox ("Hallohallo1")
End Sub

Private Sub IDTExtensibility2_OnBeginShutdown(custom() As Variant)
' keep this
End Sub

Private Sub IDTExtensibility2_OnConnection(ByVal Application As Object, _
ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _
ByVal AddInInst As Object, custom() As Variant)
Set appHostApp = Application
'Set ThisCAI = AddInInst
'Set ExcelEvents = New CExcelEvents
MsgBox ("Hallohallo2")
End Sub

Private Sub IDTExtensibility2_OnDisconnection(ByVal RemoveMode As
AddInDesignerObjects.ext_DisconnectMode, custom() As Variant)
Set appHostApp = Nothing
'Set ThisCAI = Nothing
'Set ExcelEvents = Nothing
MsgBox ("Hallohallo3")
End Sub

Private Sub IDTExtensibility2_OnStartupComplete(custom() As Variant)
'keep this
End Sub

[Sascha Trowitzsch]

Hi Mark,

Interessante Idee.
Nur habe ich sowas noch nie als VBA-Projekt realisiert gesehen.
Ich wüsste nicht, wie die IDTExtensibility2 bei einem *nicht*-Com-Addin genutzt
werden könnte.

Bei einem COM-Addin ist es so:
- Die Ziel-Application - bei dir VBE - muss COM-Addins unterstützen
- Die Applikation schaut beim Start in die Registry und lädt, je nach
Ladeverhaltenangaben dort, die DLL oder COM-Exe
- Sie instanziert die öffentliche Klasse des ActiveX-Teils - überlicherwiese
die Connect-Klasse
- Sie schaut, ob das Interface IDTExtensibility2 implementiert ist
- Wenn ja, dann leitet sie den entspr. Event sink an die
OnConnection-Implementation und übergibt ihr dabei ihr Application-Objekt etc.

Da ergibt sich nun die Frage, wie das alles OHNE COM gehen soll. Ein MDA-Addin
unterstützt keine COM-Interfaces in diesem Sinne.
Hab keine Idee.

Ciao, Sascha

Post by Mark Schneider
Hallo,
wir haben leider "nur" Office 2003 Professional (kein Developer) und weder
VSTO
noch Visual Studio auf den Entwicklerworkstations. Daher versuchen wir, ein
kleines
Menü-Addin für den VBE in Access 2003 in reinem VBA zu erstellen.
Das funktioniert auch ganz gut und tut so wie wir wollen (usysreginfo wurde
aufgebaut,
mdb als mda umbenannt und wird vom Add-In-Manager erkannt), aber man muss das
Add-In
jedesmal einmal aufrufen, um die Symbolleiste aufzubauen, was auf Dauer etwas
lästig wäre.
Weder mit AddinInstance_OnConnection noch mit IDTExtensibility2_OnConnection
komme ich zu Potte, weil ich einfach nicht weiß, wie ich die ansprechen soll
bzw.
als Events für das Add-In nutzbar mache.
Gibt es da eine Möglichkeit oder weiß jemand, der mit einer Office Developer
gesegnet ist,
was Access da noch anlegt?
Natürlich kann man auf Visual Studio oder Visual Basic zurückgreifen, aber
vielleicht braucht
es die Kanone für unseren Spatzen gar nicht. Wäre klasse, wenn jemand eine
Idee oder
die richtige Erfahrung beisteuern kann...
Vielen Dank im voraus
Mark
Darf nicht alles posten, aber damit Ihr sehen könnt, was ich gerade verzapfe
---------------------------
Option Compare Database
Option Explicit
Dim oBtns As New Collection
Public Function myAddIn_start()
Set oBtns = Nothing
myAddIn_AddCommandBar ("myAddIn")
myAddIn_AddCommandBarButton "myAddIn", "Nummerieren", "numbering", 1553
myAddIn_AddCommandBarButton "myAddIn", "Einrücken", "indent", 2138
End Function
Function myAddIn_AddCommandBar(ByVal cCBname As String)
Dim cb As CommandBar
For Each cb In Application.VBE.CommandBars
If cb.Name = cCBname Then
myAddIn_removeCommandBar cCBname
End If
Next
Set cb = Application.VBE.CommandBars.Add(Name:=cCBname,
Position:=msoBarTop, temporary:=False)
cb.Visible = True
End Function
Function myAddIn_AddCommandBarButton(ByVal cCBname As String, _
ByVal cBtnCaption As String, _
ByVal cBtnTag As String, _
ByVal cBtnFaceID As Integer)
Dim cb As CommandBar
Dim oEvt As cls_myAddIn_ButtonEvents
Set cb = Application.VBE.CommandBars.Item(cCBname)
'Umweg über Klassenevents ist nötig, da in der VBE die Command
'Buttons nicht wirklich onaction unterstützen :(
'siehe:http://support.microsoft.com/default.aspx?scid=kb;en-us;Q280607
Set oEvt = New cls_myAddIn_ButtonEvents
Set oEvt.oBtn = cb.Controls.Add(msoControlButton)
With oEvt.oBtn
'.Style = msoButtonIconAndWrapCaption
.Style = msoButtonIconAndCaption
.Caption = cBtnCaption
.Tag = cBtnTag
.FaceId = cBtnFaceID
End With
oBtns.Add oEvt
End Function
Function myAddIn_removeCommandBar(ByVal cCBname As String)
Dim cb As CommandBar
For Each cb In Application.VBE.CommandBars
If cb.Name = cCBname Then
Application.VBE.CommandBars.Item(cCBname).Delete
Exit Function
End If
Next
End Function
Function myAddIn_buttonClick(ByVal cBtnTag As String)
MsgBox ("You clicked: " & cBtnTag)
End Function
' die wird nie aufgerufen
Public Sub AddinInstance_OnConnection(ByVal _
Application As Object, ByVal ConnectMode As _
AddInDesignerObjects.ext_ConnectMode, ByVal AddInInst _
As Object, custom() As Variant)
MsgBox ("TEST!")
End Sub
--------------------------------------
--------------------------------------
Public WithEvents oBtn As CommandBarButton
Private Sub oBtn_click(ByVal ctrl As Office.CommandBarButton, CancelDefault As
Boolean)
DCode_buttonClick ctrl.Tag
End Sub
---------------------------
---------------------------
Subkey;Type;ValName;Value
HKEY_CURRENT_ACCESS_PROFILE\Menu Add-ins\&myAddin;0;;
HKEY_CURRENT_ACCESS_PROFILE\Menu
Add-ins\&myAddin;1;Library;|ACCDIR\myAddin.mda
HKEY_CURRENT_ACCESS_PROFILE\Menu
Add-ins\&myAddin;1;Expression;=myAddin_start()
HKEY_CURRENT_ACCESS_PROFILE\Menu Add-ins\&myAddin;1;Version;3
---------------------------
kläglicher Versuch eines zusätzlichen Klassenmoduls, wie wird das dann
angesprochen?
---------------------------
Option Compare Database
Option Explicit
Implements AddInDesignerObjects.IDTExtensibility2
Public appHostApp As Application
Private Sub IDTExtensibility2_OnAddInsUpdate(custom() As Variant)
' not used but required by Implements.
MsgBox ("Hallohallo1")
End Sub
Private Sub IDTExtensibility2_OnBeginShutdown(custom() As Variant)
' keep this
End Sub
Private Sub IDTExtensibility2_OnConnection(ByVal Application As Object, _
ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _
ByVal AddInInst As Object, custom() As Variant)
Set appHostApp = Application
'Set ThisCAI = AddInInst
'Set ExcelEvents = New CExcelEvents
MsgBox ("Hallohallo2")
End Sub
Private Sub IDTExtensibility2_OnDisconnection(ByVal RemoveMode As
AddInDesignerObjects.ext_DisconnectMode, custom() As Variant)
Set appHostApp = Nothing
'Set ThisCAI = Nothing
'Set ExcelEvents = Nothing
MsgBox ("Hallohallo3")
End Sub
Private Sub IDTExtensibility2_OnStartupComplete(custom() As Variant)
'keep this
End Sub

[Mark Schneider]

Post by Sascha Trowitzsch
[...]
Ich wüsste nicht, wie die IDTExtensibility2 bei einem *nicht*-Com-Addin
genutzt werden könnte.
- Die Ziel-Application - bei dir VBE - muss COM-Addins unterstützen
- Die Applikation schaut beim Start in die Registry und lädt, je nach
Ladeverhaltenangaben dort, die DLL oder COM-Exe
- Sie instanziert die öffentliche Klasse des ActiveX-Teils -
überlicherwiese die Connect-Klasse
- Sie schaut, ob das Interface IDTExtensibility2 implementiert ist
- Wenn ja, dann leitet sie den entspr. Event sink an die
OnConnection-Implementation und übergibt ihr dabei ihr Application-Objekt etc.
[...]

Danke für die Infos!

Hmmm, das bedeutet im Umkehrschluss dann auch, dass AddIns im
Dateiformat .mda relativ nutzlos sind, oder? Denn so kann man nichts
starten,
wenn das Add-In geladen wird, sondern erst, wenn es über das Menü
aufgerufen wird. Gibt es da wirklich keinen Workaround?

Gruß
Mark

[Klaus Oberdalhoff]

Hi,

du kannst wohl noch immer kostenfrei ein COM-Addin schreiben

Es gab mal - speziell dafür - eine abgespeckte VB5 Version - die Visual
Basic 5.0 Control Creation Edition, nur noch bei

http://www.thevbzone.com/vbcce.htm

und nicht mehr bei MS selbst zum DL ...

vielleicht hilft diese Info ja ...

[Mark Schneider]

[....]
du kannst wohl noch immer kostenfrei ein COM-Addin schreiben
Es gab mal - speziell dafür - eine abgespeckte VB5 Version - die Visual
Basic 5.0 Control Creation Edition, nur noch bei
http://www.thevbzone.com/vbcce.htm
und nicht mehr bei MS selbst zum DL ...
vielleicht hilft diese Info ja ...
[...]

Hey, was kostenlos, das gibt es noch?

Schade, dass ich nicht bei Access VBA bleiben kann, da bin
ich schon sehr routiniert. Und ich brauche für das Add-In ein
eigenes Formular mit u.a. Listboxen, die alle vorhandenen
Module anbieten, das wäre wohl zu einfach gewesen....

Vielen Dank und liebe Grüße nach Nürnberg aus Flensburg!
Mark

[Sascha Trowitzsch]

Hi,

Post by Klaus Oberdalhoff
Hi,
du kannst wohl noch immer kostenfrei ein COM-Addin schreiben
Es gab mal - speziell dafür - eine abgespeckte VB5 Version - die Visual
Basic 5.0 Control Creation Edition, nur noch bei
http://www.thevbzone.com/vbcce.htm
und nicht mehr bei MS selbst zum DL ...
vielleicht hilft diese Info ja ...

Ich bin mir nur nicht sicher, ob man mit VB5 bereits Com-Addins programmieren
konnte?
Aber auch VB6 sollte noch irgendwo aufzutreiben sein.
Gerade, wenn es um ein VBIDE-Addin geht, scheint mir eine MDA eh nicht der
ideale Weg zu sein.

Eine andere Möglichkeit ist die Developer Edition von Office. Mit der kann man
ein Standalone-VBA-Projekt erzeugen und als DLL kompilieren - analog VB. Bin
hier nur auch wieder nicht sicher, ob das mit A2003 Extensions ging - eher
nicht - oder mit MOD 2000/XP.

Ciao, Sascha

[Klaus Oberdalhoff]

Hi,

Post by Sascha Trowitzsch
Ich bin mir nur nicht sicher, ob man mit VB5 bereits Com-Addins
programmieren konnte?

Du bist ein Scherzkeks ;-) Wer lesen kann ist durchaus im Vorteil <g>

Der Name dieser speziellen VB5 Edition lautet

Visual Basic 5.0 Control Creation Edition

Man kann mit dieser speziellen Version KEINE EXE wohl aber DLLs/OCXe
erzeugen.

Im Text der vbzone-site steht:

But you ask, "Why would Microsoft simply give away a powerful tool like VB?"
The answer is simple... it's in their best interest to do so. The reason
that this version of VB was released was to give ANYONE a way to create
fully functionally ActiveX controls for use on the internet. VB CCE does
just that.

Post by Sascha Trowitzsch
Aber auch VB6 sollte noch irgendwo aufzutreiben sein.

Offiziell und kostenfrei und lizenzrechtlich OK ? <Mhmmmm>

<kopfschüttel>

[Sascha Trowitzsch]

Hi,

Post by Klaus Oberdalhoff
Hi,

Post by Sascha Trowitzsch
Ich bin mir nur nicht sicher, ob man mit VB5 bereits Com-Addins
programmieren konnte?

Du bist ein Scherzkeks ;-) Wer lesen kann ist durchaus im Vorteil <g>
Der Name dieser speziellen VB5 Edition lautet
Visual Basic 5.0 Control Creation Edition
Man kann mit dieser speziellen Version KEINE EXE wohl aber DLLs/OCXe
erzeugen.

Du hast Recht. Es ist sicherlich ein Nachteil, nicht lesen zu können. ;-)
Gelobe Besserung. Ist einem MVP nicht angemessen. ;-)

Post by Klaus Oberdalhoff

Post by Sascha Trowitzsch
Aber auch VB6 sollte noch irgendwo aufzutreiben sein.

Offiziell und kostenfrei und lizenzrechtlich OK ? <Mhmmmm>
<kopfschüttel>

Auch kopfschüttel. "Auftreiben" kann man ja evtl. auch bei Ebay.
Warum denkst du nur an das Schlechte im Menschen?!

Gruß, Sascha

[Klaus Oberdalhoff]

Hi,

Post by Sascha Trowitzsch
Du hast Recht. Es ist sicherlich ein Nachteil, nicht lesen zu können.
;-) Gelobe Besserung. Ist einem MVP nicht angemessen. ;-)

<g> mir fehlen die Worte

Post by Sascha Trowitzsch
Auch kopfschüttel. "Auftreiben" kann man ja evtl. auch bei Ebay.
Warum denkst du nur an das Schlechte im Menschen?!

Honi soit que mal y pense

;-)

[Thomas Möller]

Hallo Mark,

Post by Mark Schneider
---------------------------
---------------------------
Subkey;Type;ValName;Value
HKEY_CURRENT_ACCESS_PROFILE\Menu Add-ins\&myAddin;0;;
HKEY_CURRENT_ACCESS_PROFILE\Menu
Add-ins\&myAddin;1;Library;|ACCDIR\myAddin.mda
HKEY_CURRENT_ACCESS_PROFILE\Menu
Add-ins\&myAddin;1;Expression;=myAddin_start()
HKEY_CURRENT_ACCESS_PROFILE\Menu Add-ins\&myAddin;1;Version;3

über die Tabelle USysRegInfo kannst Du dafür sorgen, dass ein so
genannten Menü-Add-In erstellt wird. Dies wird, wenn es denn installiert
ist, an der Oberfläche von Access sichtbar. (Extras / Add-Ins / ...)
In der Funktion "myAddin_start" sorgst Du dann dafür, dass Deine
Oberfläche in Form eines Access-Formulars gestartet wird. Von hier aus
kannst Du dann die von Dir geplante Funktionalität steuern.

Zum Thema Add-Ins:
http://www.team-moeller.de/access/tiptrick/addins.html
(Link in einer Zeile)

HTH

[Michel Fouquet]

Hallo,

Post by Thomas Möller
über die Tabelle USysRegInfo kannst Du dafür sorgen, dass ein so
genannten Menü-Add-In erstellt wird. Dies wird, wenn es denn installiert
ist, an der Oberfläche von Access sichtbar. (Extras / Add-Ins / ...)
In der Funktion "myAddin_start" sorgst Du dann dafür, dass Deine
Oberfläche in Form eines Access-Formulars gestartet wird. Von hier aus
kannst Du dann die von Dir geplante Funktionalität steuern.

aber genau das ist ja die von Mark angeschnittene Problematik! Da ein
"normales" Access-AddIn eben kein OnLoad-, OnActivate, OnConnect- oder
sonstiges Ereignis bereitstellt, in welchem es seine CommandBar in die
Zielanwendung einklinken könnte, muss das AddIn zunächst aufgerufen
werden, damit es dann (z.B. über seine Startroutine) seine eigene
CommandBar generieren und positionieren kann.

Der Start des AddIns könnte, nachdem sein Vorhandensein überprüft wurde,
natürlich auch per VBA erfolgen. Ebenso könnte per VBA auf eine
CommandBar-Erstellungsroutine im AddIn zugegriffen werden. Das würde
aber bedeuten, dass ich in jeder MDB, die ich weitergebe, den -
möglicherweise völlig überflüssigen Code - mitschleifen müsste, weil
ggf. irgendwann irgendwer mein AddIn benutzen können würde.

mfg,
Michel

[Mark Schneider]

Post by Michel Fouquet

Post by Thomas Möller
über die Tabelle USysRegInfo kannst Du dafür sorgen, dass ein so
genannten Menü-Add-In erstellt wird. Dies wird, wenn es denn installiert
ist, an der Oberfläche von Access sichtbar. (Extras / Add-Ins / ...)
In der Funktion "myAddin_start" sorgst Du dann dafür, dass Deine
Oberfläche in Form eines Access-Formulars gestartet wird. Von hier aus
kannst Du dann die von Dir geplante Funktionalität steuern.

aber genau das ist ja die von Mark angeschnittene Problematik!

Genau! :,(

Post by Michel Fouquet
Da ein "normales" Access-AddIn eben kein OnLoad-, OnActivate, OnConnect-
oder sonstiges Ereignis bereitstellt, in welchem es seine CommandBar in
die Zielanwendung einklinken könnte, muss das AddIn zunächst aufgerufen
werden, damit es dann (z.B. über seine Startroutine) seine eigene
CommandBar generieren und positionieren kann.
Der Start des AddIns könnte, nachdem sein Vorhandensein überprüft wurde,
natürlich auch per VBA erfolgen. Ebenso könnte per VBA auf eine
CommandBar-Erstellungsroutine im AddIn zugegriffen werden. Das würde aber
bedeuten, dass ich in jeder MDB, die ich weitergebe, den - möglicherweise
völlig überflüssigen Code - mitschleifen müsste, weil ggf. irgendwann
irgendwer mein AddIn benutzen können würde.

Ich könnte auch beim ersten Start des Addins Modullogik hinzufügen,
welche dann beim nächsten Start der Anwendung für den entsprechenden
Effekt sorgt. Aber in Backends gibt es ja nicht zwingend Autoexec-Makros
und ausserdem ist das auch ganz schön unsportlich.
Schade, schade, wäre so gerne bei Access VBA geblieben für dieses
Anwendungsgebiet, da ich auch noch ein Formular bauen muss, welches
alle Module anzeigt und da bin ich mit VB sicherlich langsamer...

Gruß
Mark

[Thomas Möller]

Hallo Mark,

Post by Mark Schneider
Schade, schade, wäre so gerne bei Access VBA geblieben für dieses
Anwendungsgebiet, da ich auch noch ein Formular bauen muss, welches
alle Module anzeigt und da bin ich mit VB sicherlich langsamer...

wenn Du Dich mit dem Gedanken anfreunden kannst, dass Dein Add-In nicht
in der IDE sondern ("nur") in Access sichtbar wird, dann kannst Du
weiterhin die Dir bekannten Bordmittel von Access verwenden.
Dazu erstellst Du ein Access-Add-In mit der USysRegInfo-Tabelle.

CU

[Thomas Möller]

Hallo Michel,

Post by Michel Fouquet

Post by Thomas Möller
über die Tabelle USysRegInfo kannst Du dafür sorgen, dass ein so
genannten Menü-Add-In erstellt wird. Dies wird, wenn es denn
installiert ist, an der Oberfläche von Access sichtbar. (Extras /
Add-Ins / ...) In der Funktion "myAddin_start" sorgst Du dann dafür,
dass Deine
Oberfläche in Form eines Access-Formulars gestartet wird. Von hier
aus kannst Du dann die von Dir geplante Funktionalität steuern.

aber genau das ist ja die von Mark angeschnittene Problematik! Da ein
"normales" Access-AddIn eben kein OnLoad-, OnActivate, OnConnect- oder
sonstiges Ereignis bereitstellt, in welchem es seine CommandBar in die
Zielanwendung einklinken könnte, muss das AddIn zunächst aufgerufen
werden, damit es dann (z.B. über seine Startroutine) seine eigene
CommandBar generieren und positionieren kann.

Mark würde sein Add-In gern in der Menü-Struktur der *VBE* verankern.
Das geht aber so nicht. Dazu bräuchte er ein COM-Add-In. Um ein solches
zu erstellen, hat er aber nicht die richtigen Werkzeuge.

Daher schlage ich hier als Alternative vor, ein "normales" Menü-Add-In
zu verwenden. Dies ist standardmässig über die Oberfläche von *Access*
aus erreichbar. Ein weitere Vorteil dieser Vorgehensweise ist, dass er
die von Access gewohnten Steuerelemente verwenden kann.

Access ist, was die Erweiterung mit Bordmitteln angeht, nun mal in
seinen Möglichkeiten beschränkt. Ich persönlich finde, dass man damit
aber gut leben kann.
Wo ist der funktionale Unterschied, ob nun über Extras / Add-Ins der
Zugriff auf (m)ein Add-In möglich ist oder ob dies über (m)einen eigenen
Menüpunkt möglich ist?

[Michel Fouquet]

Hallo Thomas,

Post by Thomas Möller
Mark würde sein Add-In gern in der Menü-Struktur der *VBE* verankern.
Das geht aber so nicht. Dazu bräuchte er ein COM-Add-In. Um ein solches
zu erstellen, hat er aber nicht die richtigen Werkzeuge.

ja, so habe ich das ja auch verstanden.

Post by Thomas Möller
Daher schlage ich hier als Alternative vor, ein "normales" Menü-Add-In
zu verwenden. Dies ist standardmässig über die Oberfläche von *Access*
aus erreichbar. Ein weitere Vorteil dieser Vorgehensweise ist, dass er
die von Access gewohnten Steuerelemente verwenden kann.

Das hat Mark ja auch versucht. Und auf genau diesen deinen Hinweis auf
das Menü-Add-In habe ich geantwortet, dass sich Mark davon eine ganz
spezielle Funktionalität erwartet (OnConnection-Event), die er gerade in
einem Posting ja auch noch einmal bestätigt hat, welche ein (MDA-)Add-In
aber nun mal nicht bereitstellt.

Post by Thomas Möller
Access ist, was die Erweiterung mit Bordmitteln angeht, nun mal in
seinen Möglichkeiten beschränkt. Ich persönlich finde, dass man damit
aber gut leben kann.

Ich im Prinzip auch. Aber genau wie Mark würde ich mir halt auch für ein
Menü-Add-In wünschen, dass mit seiner Aktivierung (z.B. über den
Add-In-Manager) sogleich eine spezifische CommandBar des Add-Ins -
sofern vorhanden - angedockt und mit seiner Deaktivierung wieder
entfernt würde. Die dazu notwendigen Ereignisse stellt aber, wie ich
bereits schrieb und Mark selber erfahren hat, ein Menü-Add-In nicht zur
Verfügung.

Post by Thomas Möller
Wo ist der funktionale Unterschied, ob nun über Extras / Add-Ins der
Zugriff auf (m)ein Add-In möglich ist oder ob dies über (m)einen eigenen
Menüpunkt möglich ist?

<Nebenbemerkung>
Mark schrieb in seinem OP nicht von einem eigenen Menüpunkt, sondern von
einer Symbolleiste, wofür ich den allgemeineren Begriff "CommandBar"
verwendet habe. Symbolleisten können beispielsweise mit einem, dem User
bestens bekannten, Symbol bestückt werden. Ich könnte nach Wunsch,
Belieben oder Notwendigkeit auch mehrere eigene Symbolleisten für
jeweils verschiedene Add-Ins einblenden. Allein das macht schon einen
Unterschied zum Menü Extras/Add-Ins aus.
</Nebenbemerkung>

Zunächst macht es *funktional* keinen Unterschied, da hast du vermutlich
recht, wohl aber im Hinblick z.B. auf eine Benutzerführung. Ich
persönlich würde den Teufel tun, dem User das Menü Extras/Add-Ins
überhaupt zur Verfügung zu stellen! Und in einem ja nur wenige Stunden
zurückliegenden Thread warst doch gerade *du* es, der sagte, dass er den
Usern die eingebauten CommandBars sowieso abknipst. (Willst du mich
heute in den Wahnsinn treiben oder was?!)

Es wäre auch vorstellbar, dass unter *einem* eigenen Menüpunkt eben
weitere Optionen gehandhabt werden, z.B. weil - jetzt etwas holperig
formuliert - das Add-In (also die MDA-Datei) mehrere Unter-Add-Ins
beinhaltet. Oder dass das Add-In durch Übergabe von Parametern in einem
bestimmten Modus (DAU- oder Expertenmodus) gestartet würde. Oder dass
der Add-In-Aufruf zur Wahrung einer gegebenen Systematik in eine
bestehende Menüstruktur unter dem Punkt "Sonstiges" eingeklinkt werden
soll. Oder, oder...

Abgesehen von Sonderfällen: ein Menü-Add-In (samt seines Aufrufs), das
irgendwas in der IDE erledigen soll, hat IMHO auf der "normalen"
Accessoberfläche für den "normalen" Accessbenutzer nichts zu suchen.
Auch das würde für mich gegen ein Menü-Add-In sprechen. Genauso fände
ich allerdings ein entsprechendes COM-AddIn auf der GUI-Ebene deplatziert.

Gruß,
Michel

[Thomas Möller]

Hallo Michel,

Post by Michel Fouquet

Post by Thomas Möller
Mark würde sein Add-In gern in der Menü-Struktur der *VBE* verankern.
Das geht aber so nicht. Dazu bräuchte er ein COM-Add-In. Um ein
solches zu erstellen, hat er aber nicht die richtigen Werkzeuge.

ja, so habe ich das ja auch verstanden.

da sind wir uns ja einig. ;-)

Post by Michel Fouquet

Post by Thomas Möller
Access ist, was die Erweiterung mit Bordmitteln angeht, nun mal in
seinen Möglichkeiten beschränkt. Ich persönlich finde, dass man damit
aber gut leben kann.

Ich im Prinzip auch. Aber genau wie Mark würde ich mir halt auch für
ein Menü-Add-In wünschen, dass mit seiner Aktivierung (z.B. über den
Add-In-Manager) sogleich eine spezifische CommandBar des Add-Ins -
sofern vorhanden - angedockt und mit seiner Deaktivierung wieder
entfernt würde. Die dazu notwendigen Ereignisse stellt aber, wie ich
bereits schrieb und Mark selber erfahren hat, ein Menü-Add-In nicht
zur Verfügung.

Auch in diesem Punkt sind wir uns einig. Wünschen würde ich mir das
auch.

Post by Michel Fouquet
Zunächst macht es *funktional* keinen Unterschied, da hast du
vermutlich recht, wohl aber im Hinblick z.B. auf eine
Benutzerführung. Ich persönlich würde den Teufel tun, dem User das
Menü Extras/Add-Ins überhaupt zur Verfügung zu stellen! Und in einem
ja nur wenige Stunden zurückliegenden Thread warst doch gerade *du*
es, der sagte, dass er den Usern die eingebauten CommandBars sowieso
abknipst. (Willst du mich heute in den Wahnsinn treiben oder was?!)

Ich sehe da keinen Widerspruch. ;-)

Ich Unterscheide zwischen Entwicklern und Endusern.

Add-Ins sind IMHO nur etwas für Entwickler. Entwickler haben den vollen
Zugriff auf Access. Da ist auch der Aufruf über Extras / Add-Ins
zumutbar.

Einen End-User werde ich in seinen Rechten an einer von mir entwickelten
Datenbank immer soweit beschränken, dass er nichts schlimmes anstellen
kann. Da gehört das Ausblenden der Standard-Menüleisten zum
Basisprogramm.

Post by Michel Fouquet
Es wäre auch vorstellbar, dass unter *einem* eigenen Menüpunkt eben
weitere Optionen gehandhabt werden, z.B. weil - jetzt etwas holperig
formuliert - das Add-In (also die MDA-Datei) mehrere Unter-Add-Ins
beinhaltet. Oder dass das Add-In durch Übergabe von Parametern in
einem bestimmten Modus (DAU- oder Expertenmodus) gestartet würde.
Oder dass der Add-In-Aufruf zur Wahrung einer gegebenen Systematik in
eine
bestehende Menüstruktur unter dem Punkt "Sonstiges" eingeklinkt werden
soll. Oder, oder...

Wie gesagt, wünschen würde ich mir das auch. Momentan lässt sich so
etwas nur über ein Add-In lösen, dass über sein "Startformular" Zugriff
auf die verschiedenen Funktionalitäten ermöglicht. Man realisiert also
ein Hauptmenü von dem aus man auf die verschiedenen "Untermenüpunkte"
verzweigt.

Post by Michel Fouquet
Abgesehen von Sonderfällen: ein Menü-Add-In (samt seines Aufrufs), das
irgendwas in der IDE erledigen soll, hat IMHO auf der "normalen"
Accessoberfläche für den "normalen" Accessbenutzer nichts zu suchen.
Auch das würde für mich gegen ein Menü-Add-In sprechen. Genauso fände
ich allerdings ein entsprechendes COM-AddIn auf der GUI-Ebene
deplatziert.

Da sind wir uns schon wieder einig. Damit ein mit solchen Tools
"bewaffneter" User trotzdem nichts schlimmes anstellen kann liefere ich
grundsätzlich MDE-Dateien aus.


CU

[Michel Fouquet]

Hallo Thomas,

Post by Thomas Möller
Ich Unterscheide zwischen Entwicklern und Endusern.

wenn's angemessen ist, tue ich das auch.

Post by Thomas Möller
Add-Ins sind IMHO nur etwas für Entwickler.

Widerspruch, Euer Ehren!

Post by Thomas Möller
Entwickler haben den vollen
Zugriff auf Access. Da ist auch der Aufruf über Extras / Add-Ins zumutbar.

Unter deiner obigen Prämisse stimme ich zu.

Aber genauer:

1. Ich würde dir unbesehen bei Editoren/Generatoren (builder) zustimmen.
Diese sind reine Entwicklerinstrumente. Wobei ich bisher kaum einen
*wirklich sinnvollen* Einsatz eigener Editoren gesehen habe. Was Stan
Leszynski (und nach ihm Allison Balter) mit dem SpecialEffect Builder
vorgelegt hat, ist zwar eine interessante Arbeit, aber eigentlich auch
nicht mehr. Auch was von Helen Feddema beigesteuert wurde, ist zu
Lernzwecken ganz nett, aber damit hat sich's fast schon.

Zu Übungs- und Schulungszwecken habe ich mal einen
TabControl-Assistenten geschrieben. Aber im produktiven Einsatz habe ich
ihn nicht, denn da bin ich auf "normalem" Weg eigentlich schneller.
Einem DAU hingegen würde ich, dir heftig zustimmend, sowieso keinen
Zugriff auf die Entwufsansicht irgendeines Datenbankobjekts geben.

Das ist vermutlich auch der Grund, warum es im Grunde nix in dieser
Richtung gibt.

2. Bei Assistenten bin ich geteilter Meinung. Hier kann ich mir
Szenarien vorstellen, wo ich den Usern eine gewisse Interaktivität
zubillige. So könnte ich z.B. in der Registry die standardmäßigen
Abfrage- oder Berichtsassistenten abknipsen und statt dessen nur eigene
anbieten. Oder eben per eigenem Menü oder per Schaltfläche den
standardmäßigen Diagramm- oder Etiketten-Assistenten zugänglich machen
(möglicherweise allerdings mit Scheunentoren zu eigentlich verbotenen
Bereichen).

Auch Entwicklern klemme ich übrigens gerne bei der Erstellung neuer
Tabellen die erste Option bei den Assistenten ("Datenblattansicht") ab.

3. Unser momentaner Diskussionszusammenhang sind aber die Menü-Add-Ins.
Und *gerade diese* halte ich nun *gerade für Enduser* für besonders
geeignet.

Nehmen wir als einfache Beispiele einen Datenimport-/ Datenexport-
Assistenten oder einen Backend-Switcher (also ein eigener
Tabellenverknüpfungs-Manager), einen Nachbau des Etiketten-Assistenten,
die Übernahme von DIN-gerecht aufbereiteten Adressdaten in ein
Word-Dokument, die schrittweise Abarbeitung einer Projekt-ToDo-Liste,
einen ordentlichen Such-Assistenten, einen Assisten zum Data Drilldown,
das SQL Scratchpad als Abfragegenerator usw. usw.

Also im Grunde alle wiederkehrenden automatisierbaren Vorgänge, die
durch Standardwerte und/oder Benutzereingaben gesteuert werden
können/müssen. (Bzw. all die benötigten interaktiven Elemente, die in
der Runtime-Version wegfallen und nachprogrammiert werden müss(t)en.)

Ich selber habe natürlich auch einen Assistenten, der mir hilft, vor der
Auslieferung einer Datenbank in dieser eine Reihe von Eigenschaften zu
setzen, die Unterdatenblätter und die Objektnamenkorrektur
auszuschalten, Tabellen zu leeren, dafür zu sorgen, dass das
Eigenschaftenfenster nur in der Entwurfsansicht sichtbar ist und diverse
Dinge mehr, und zu guter Letzt die Datenbank zu komprimieren.

Post by Thomas Möller
Einen End-User werde ich in seinen Rechten an einer von mir entwickelten
Datenbank immer soweit beschränken, dass er nichts schlimmes anstellen
kann. Da gehört das Ausblenden der Standard-Menüleisten zum Basisprogramm.

Da sind wir grundsätzlich derselben Auffassung.

Mit freundlich-kollegialem Gruß,
Michel

[Mark Schneider]

Um noch etwas Licht in mein Vorhaben zu bringen:
Ich habe vor, ein Add-In bestehend aus mehreren Funktionen für unsere
Entwickler zu erstellen.

Es soll folgende Buttons als Symbolleiste in der VBE bieten:
- alle im VBE geöffneten Fenster auf einmal schliessen (da wäre der Weg über
das Add-Ins Menü in dem Accessanwendungsfenster sehr umständlich, erst
Fenster wechseln, dort ins AddInsmenü, um
Funktionalität aufzurufen, die dann in der VBE aktiv wird, muss man zwar
immer nur einmal machen, aber gerade das finde ich so enttäuschend. Es fehlt
nur ein ganz kleiner Schritt...)
- ein oder mehrere Module einrücken, mit Zeilennumern und unseren
Dokublöcken in Kommentaren versehen
- Module nach bestimmten Entwicklerkommentaren parsen
- Module zur Dokumentation nach Word exportieren
- Einen Report mit Entwicklungsstatistiken erstellen
- Buttons zum Einfügen von Codetemplates (sub/function mit Errorhandling,
Aufrufe unserer Codebibliothek)
- Button für entwicklungsinterne Notizen

Warum ich dafür gerne bei reinem VBA geblieben wäre:

1. VBA benutze ich täglich, in der Entwicklungsumgebung von VB bin ich nicht
so zuhause

2. Nicht alle unserer Entwickler haben/können VB, aber alle Access/VBA.
Einmal fertigestellt könnte jeder auch eigene Wünsche sehr einfach ergänzen.

3. Einheitlichkeit unseres Codes, Anpassbarkeit innerhalb von Access (gerade
für das Einfügen der Templates praktisch)

4. die gesamte gewünschte Funktionalität ist recht einfach in reinem VBA
erreichbar, speziell das Auswahlformular als Listenfeld, welches alle
vorhandenen Module zeigt und erlaubt, eine Mehrfachauswahl zu erstellen, um
mehrere Module auf einmal durchzuführen

5. bekomme ich den Report bekomme über VB überhaupt hin?

6. nur geringe Anpassungen wären nötig, die Logik, um alle
Module/Formulare/Reports zu durchlaufen etc. ist schon in unserer Anwendung
vorhanden

7. die MDA ist bequem einzubinden und auszutauschen, erfordert keine
Registrierung/Installation

8. Debugging/Testen wäre GANZ entspannt, einfach direkt in Access testen und
schliesslich 'ne mda draus machen

9. Erweiterungen/Änderungen sind schnell zu machen. MDA öffnen, anpassen, et
voilá.

Und der (vorsichtshalber: BISHER) einzige Grund, der wirklich dagegen
spricht:
- Das Add-In startet nicht automatisch und jedes Mal, wenn man die
Entwicklungsumgebung öffnet, muss man einmal das Add-In über das
Add-Ins-Menü im eigentlichen Accessfenster aufrufen, damit die Commandbar in
der VBE aufgebaut wird.

Die IDTExtensibility2 lässt sich in ein VBA Klassenmodul einfügen und das
debuggt auch durch, nur aufgerufen wird es für eine MDA wohl nie.

Mit Office Developer geht das wohl, aber die VSTO Tools zu kaufen, nur um zu
sehen, ob es dann geht?
http://msdn.microsoft.com/library/deu/default.asp?url=/library/DEU/modcore/html/dewlkWalkthroughCreatingCOMAdd-in.asp

Hätte so einfach sein könnnen... :)
Mark

[Sascha Trowitzsch]

Hi,

Abgesehen davon, dass du, um all diese Features zu realisieren, wahrscheinlich
mindestens gut und gerne 2 Monate wirst programmieren müssen, gibt's das fast
alles schon als Addin umsonst:
http://www.mztools.com/v3/features.aspx
(Must have!)
http://www.bmsltd.ie/Indenter/Default.htm

Wozu das Rad neu erfinden?

Ciao, Sascha

Post by Mark Schneider
Ich habe vor, ein Add-In bestehend aus mehreren Funktionen für unsere
Entwickler zu erstellen.
- alle im VBE geöffneten Fenster auf einmal schliessen (da wäre der Weg über
das Add-Ins Menü in dem Accessanwendungsfenster sehr umständlich, erst Fenster
wechseln, dort ins AddInsmenü, um
Funktionalität aufzurufen, die dann in der VBE aktiv wird, muss man zwar immer
nur einmal machen, aber gerade das finde ich so enttäuschend. Es fehlt nur ein
ganz kleiner Schritt...)
- ein oder mehrere Module einrücken, mit Zeilennumern und unseren Dokublöcken
in Kommentaren versehen
- Module nach bestimmten Entwicklerkommentaren parsen
- Module zur Dokumentation nach Word exportieren
- Einen Report mit Entwicklungsstatistiken erstellen
- Buttons zum Einfügen von Codetemplates (sub/function mit Errorhandling,
Aufrufe unserer Codebibliothek)
- Button für entwicklungsinterne Notizen
1. VBA benutze ich täglich, in der Entwicklungsumgebung von VB bin ich nicht
so zuhause
2. Nicht alle unserer Entwickler haben/können VB, aber alle Access/VBA. Einmal
fertigestellt könnte jeder auch eigene Wünsche sehr einfach ergänzen.
3. Einheitlichkeit unseres Codes, Anpassbarkeit innerhalb von Access (gerade
für das Einfügen der Templates praktisch)
4. die gesamte gewünschte Funktionalität ist recht einfach in reinem VBA
erreichbar, speziell das Auswahlformular als Listenfeld, welches alle
vorhandenen Module zeigt und erlaubt, eine Mehrfachauswahl zu erstellen, um
mehrere Module auf einmal durchzuführen
5. bekomme ich den Report bekomme über VB überhaupt hin?
6. nur geringe Anpassungen wären nötig, die Logik, um alle
Module/Formulare/Reports zu durchlaufen etc. ist schon in unserer Anwendung
vorhanden
7. die MDA ist bequem einzubinden und auszutauschen, erfordert keine
Registrierung/Installation
8. Debugging/Testen wäre GANZ entspannt, einfach direkt in Access testen und
schliesslich 'ne mda draus machen
9. Erweiterungen/Änderungen sind schnell zu machen. MDA öffnen, anpassen, et
voilá.
- Das Add-In startet nicht automatisch und jedes Mal, wenn man die
Entwicklungsumgebung öffnet, muss man einmal das Add-In über das Add-Ins-Menü
im eigentlichen Accessfenster aufrufen, damit die Commandbar in der VBE
aufgebaut wird.
Die IDTExtensibility2 lässt sich in ein VBA Klassenmodul einfügen und das
debuggt auch durch, nur aufgerufen wird es für eine MDA wohl nie.
Mit Office Developer geht das wohl, aber die VSTO Tools zu kaufen, nur um zu
sehen, ob es dann geht?
http://msdn.microsoft.com/library/deu/default.asp?url=/library/DEU/modcore/html/dewlkWalkthroughCreatingCOMAdd-in.asp
Hätte so einfach sein könnnen... :)
Mark

[Jens Schilling]

Hallo, Sascha

Post by Sascha Trowitzsch
Hi,
Abgesehen davon, dass du, um all diese Features zu realisieren,
wahrscheinlich mindestens gut und gerne 2 Monate wirst programmieren
http://www.mztools.com/v3/features.aspx
(Must have!)
http://www.bmsltd.ie/Indenter/Default.htm
Wozu das Rad neu erfinden?

Richtig, darum möchte ich speziell zum folgenden Punkt...

Post by Sascha Trowitzsch

Post by Mark Schneider
- Module zur Dokumentation nach Word exportieren

Deine Links noch um diesen ergänzen :

http://kulpa-online.com/downloads-access-addins-1003.html

Das Add-In liegt mit offenen Quelltext vor, und ist entsprechend einfach den
eigenen Bedürfnissen anpassbar.

[Mark Schneider]

Post by Jens Schilling

Post by Sascha Trowitzsch
Wozu das Rad neu erfinden?

Richtig, darum möchte ich speziell zum folgenden Punkt...

Post by Sascha Trowitzsch

Post by Mark Schneider
- Module zur Dokumentation nach Word exportieren

http://kulpa-online.com/downloads-access-addins-1003.html
Das Add-In liegt mit offenen Quelltext vor, und ist entsprechend einfach
den eigenen Bedürfnissen anpassbar.

Klasse, vielen Dank!
Mark

[Mark Schneider]

Post by Sascha Trowitzsch
Abgesehen davon, dass du, um all diese Features zu realisieren,
wahrscheinlich mindestens gut und gerne 2 Monate wirst programmieren
müssen,

Codeeinrückung, Nummerierung, Modulauswahl, Export des SourceCodes nach
Word: 3 Manntage.
Ist schon fast fertig, das ist ja mein Problem. Wir brauchen vieles der
Funktionalität sowieso artverwandt im VBA Code.

Post by Sascha Trowitzsch
http://www.mztools.com/v3/features.aspx
(Must have!)
http://www.bmsltd.ie/Indenter/Default.htm
Wozu das Rad neu erfinden?

Beides klasse Tools!

Für die Doku müsste ich dann noch einen Parser schreiben.

Fehlt nur noch eines bezüglich der automat. Nummerierung:
- der Indenter bietet keine Zeilennummerierung
- die MZTools können immer nur eine Prozedur am Stück nummerieren, weder das
ganze Modul noch das ganze Projekt
- die einzufügenden Errorhandler sind nicht anpassbar

Werde den Entwicklern mal schreiben
Mark

[Mark Doerbandt]

Hallo, Mark,

Post by Mark Schneider
3 Manntage.
Ist schon fast fertig

nach der 80-20-Regel bedeutet "fast": Du hast 80 Prozent fertig, das
sind 20 Prozent des Aufwandes. Da Dir noch 20 Prozent der Arbeit
bleiben, hast Du noch 12 Arbeitstage vor Dir. Da Du insgesamt mehr
willst, liegt Sascha mit seiner Aufwandsschaetzung voll richtig! ;-)

Gruss - Mark

[Jens Schilling]

Hallo, Mark

Post by Mark Schneider
- die MZTools können immer nur eine Prozedur am Stück nummerieren,
weder das ganze Modul noch das ganze Projekt

Wirf doch einmal einen Blick in den Download zu Henrys Whitepaper "Error
Handling in Access Anwendungen", dass Du hier finden kannst :

http://www.dbdev.org

In der darin enthalten DB gibt es das Modul "mdlLineNumbering" - vielleicht
findest Du darin Anregungen....

[Mark Schneider]

Post by Jens Schilling

Post by Mark Schneider
- die MZTools können immer nur eine Prozedur am Stück nummerieren,
weder das ganze Modul noch das ganze Projekt

Wirf doch einmal einen Blick in den Download zu Henrys Whitepaper "Error
http://www.dbdev.org
In der darin enthalten DB gibt es das Modul "mdlLineNumbering" -
vielleicht findest Du darin Anregungen....

Danke für den Tipp, gecodet habe ich das ja schon.

Übrigens:
wer lesen kann ist klar im Vorteil:
Ich habe übersehen, dass die MZTools sehr wohl ganze Module
oder das ganze Projekt nummerieren können. Dazu muss man nur auf das
Modul bzw. das Klassenmodul im Projektfenster rechtsklicken. Gibt es nur
keine Schaltfläche für.

Gruß
Mark

[Thomas Möller]

Hallo Michel,

Post by Michel Fouquet
2. Bei Assistenten bin ich geteilter Meinung. Hier kann ich mir
Szenarien vorstellen, wo ich den Usern eine gewisse Interaktivität
zubillige. So könnte ich z.B. in der Registry die standardmäßigen
Abfrage- oder Berichtsassistenten abknipsen und statt dessen nur
eigene anbieten. Oder eben per eigenem Menü oder per Schaltfläche den
standardmäßigen Diagramm- oder Etiketten-Assistenten zugänglich machen
(möglicherweise allerdings mit Scheunentoren zu eigentlich verbotenen
Bereichen).

Das mit den Scheunentoren sehe ich genau so wie Du. Deshalb bin ich auch
hier restriktiv mit dem, was ich den Usern an Standardoberfläche zur
Verfügung stelle. Der Nachteil meines Vorgehens ist sicher, dass ich im
Zweifel die gewünschte Funktionalität nachprogrammieren muss. Dafür kann
ich dann diese Funktionalität an die spezifischen Gegebenheiten der
Anwendung anpassen. Außerdem habe ich jederzeit die Kontrolle darüber,
was der User kann und was eben nicht.

Post by Michel Fouquet
3. Unser momentaner Diskussionszusammenhang sind aber die
Menü-Add-Ins. Und *gerade diese* halte ich nun *gerade für Enduser*
für besonders geeignet.
Nehmen wir als einfache Beispiele einen Datenimport-/ Datenexport-
Assistenten oder einen Backend-Switcher (also ein eigener
Tabellenverknüpfungs-Manager), einen Nachbau des
Etiketten-Assistenten, die Übernahme von DIN-gerecht aufbereiteten
Adressdaten in ein Word-Dokument, die schrittweise Abarbeitung einer
Projekt-ToDo-Liste, einen ordentlichen Such-Assistenten, einen
Assisten zum Data Drilldown, das SQL Scratchpad als Abfragegenerator
usw. usw. Also im Grunde alle wiederkehrenden automatisierbaren
Vorgänge, die
durch Standardwerte und/oder Benutzereingaben gesteuert werden
können/müssen. (Bzw. all die benötigten interaktiven Elemente, die in
der Runtime-Version wegfallen und nachprogrammiert werden müss(t)en.)

Ich bin auch dafür "wiederkehrende automatisierbare Vorgänge" zu
unterstützen. Dazu möchte ich aber keine allgemeingehaltenen Add-Ins
verwenden. Statt dessen werde ich Funktionen einsetzen, die speziell auf
die jeweilige Anwendung zugeschnitten sind.
Wenn es zum Beispiel um den Import von Daten geht, dann werde ich keinen
allgemeinen Assistenten bereitstellen, bei dem der User auch noch
auswählen kann, in welche Tabelle die Daten importiert werden können.
Statt dessen werde ich einen Importdialog implementieren. Bei diesem
kann der User die zu importierende Datei auswählen. Diese Datei wird vor
dem Import genau geprüft. Dabei wird untersucht, ob die Datei den
Anforderungen genügt und die notwendigen Spalten vorhanden sind.
Mein Vorgehen ist sicher wesentlich aufwendiger, als wenn ich allgemein
verfügbare Assistenten zulassen würde. Dafür habe ich aber die
Datenqualität einigermaßen im Griff. Und der User kommt hoffentlich nie
Objekte zu Gesicht, die ich nicht dafür vorgesehen habe.


CU

[Michel Fouquet]

Hallo Thomas,

Post by Thomas Möller
Ich bin auch dafür "wiederkehrende automatisierbare Vorgänge" zu
unterstützen. Dazu möchte ich aber keine allgemeingehaltenen Add-Ins
verwenden. Statt dessen werde ich Funktionen einsetzen, die speziell auf
die jeweilige Anwendung zugeschnitten sind.
Wenn es zum Beispiel um den Import von Daten geht, dann werde ich keinen
allgemeinen Assistenten bereitstellen, bei dem der User auch noch
auswählen kann, in welche Tabelle die Daten importiert werden können.
Statt dessen werde ich einen Importdialog implementieren. Bei diesem
kann der User die zu importierende Datei auswählen. Diese Datei wird vor
dem Import genau geprüft. Dabei wird untersucht, ob die Datei den
Anforderungen genügt und die notwendigen Spalten vorhanden sind.
Mein Vorgehen ist sicher wesentlich aufwendiger, als wenn ich allgemein
verfügbare Assistenten zulassen würde. Dafür habe ich aber die
Datenqualität einigermaßen im Griff. Und der User kommt hoffentlich nie
Objekte zu Gesicht, die ich nicht dafür vorgesehen habe.

wir sind natürlich gar nicht so weit auseinander. Denn ich meine
natürlich auch keine "allgemeingehaltenen Add-Ins", die sich an ein
unspezifisches Publikum richten.

Sondern (auch) ich beziehe mich auf die Bereitstellung von Funktionen
für eine spezifische Aufgabenstellung eines spezifischen Anwenderkreises
eines spezifischen Kunden.

Derlei stelle ich gerne in einem Add-In zur Verfügung. Ein solches kann
ich nach Wunsch "freischalten" oder auch nicht (generell oder nur für
eine bestimmte Benutzergruppe). Das kann ich, ggf. mit den notwendigen
spezifischen Anpassungen, im Sinne einer - ausgetesteten - Komponente
für einen anderen Kunden übernehmen.

Dass auch ein "allgemeingehaltenes" Add-In durch entsprechende
Parametrisierung zu einem "spezifischen" gemacht werden kann, ist sicher
einfach vorstellbar und realisierbar. Um deinen obigen Kritikpunkt
aufzunehmen: es ist ein Leichtes, in einer USysParam-Tabelle
festzuhalten, welche Daten in welche Tabelle zu importieren sind, ob
bestehende Datensätze zunächst gelöscht werden sollen oder überschrieben
werden dürfen oder nicht, welche Benutzergruppe überhaupt und in welcher
Weise mit dem Add-In arbeiten darf und, und, und...

Der Backend-Switcher griffe (natürlich?) auf eine Parameter-Tabelle
zurück, die u.a. die zulässigen Dateinamenserweiterungen verwaltet, auf
welche zugegriffen werden darf und die dann als Filter für den
Dateiauswahldialog benutzt werden (können).

Anders gesagt: ich implementiere gerne eine Grundfunktionalität in die
Anwendung, liefere dann aber Zusatzfunktionen ggf. über Add-Ins (ganz
beliebt: der nachgebaute Word-Serienbrief-Assistent), gerne auch mal als
(VB6-)DLL. Dazu muss das FrontEnd oft nicht mehr angefasst werden und
schon bei der Entwicklung muss ich nicht tausende Zeilen Code
propylaktisch rüberkopieren.

Ergo: schlankes FrontEnd, das schnell ausgeliefert werden kann. Und ggf.
muss für Wartungs- und Erweiterungszwecke nur das Add-In überarbeitet
und neu eingespielt werden.

Post by Thomas Möller
CU

Ob das noch mal was wird?

mfg,
Michel