.Net Control Container für Access

[Josef Pötzl]

Hallo!

Heute probiert: .net-UserControl mit COM-Interface als Container für .net-Controls zu verwenden.

Einen Umweg musst ich allerdings einfügen: In Access verwende ich nicht direkt das .net-COM-Usercontrol sondern ein VB6-Control, in das das .net-Control eingearbeitet ist.
Grund: Damit funktioniert in Access die Größenänderung durch die Anker-Einstellung.

Falls es jemand ausprobieren will:
https://svn.access-codelib.net/svn/DotN ... ainer/Lib/

LG
Josef

[Sten Schmidt]

2014-02-10_NetComCtr.png (7.03 KiB) 40983-mal betrachtet

Hallo Josef,

kurzes Feedback:

ich habe die RegisterTLBs.cmd ausgeführt und in Access über ActiveX Steuerelement hinzufügen das Control verwendet.

Dem Control selbst gab ich jeweils "Beide" als Anker.

So ganz scheint das noch nicht zu funktionieren, die Breite und Höhe des Controls vergrößert sich immer über den sichtbaren Bereich hinaus.

Damit das besser sichtbar ist, habe ich dem Control mal einen roten Rahmen als Eigenschaft mitgegeben.

[Josef Pötzl]

Hallo Sten!

Du hast aber schon das VB6-Control (DotNetControlContainer.NetContainer) in Access ausgewählt?
Das .net-COM-Control (ACLibDotNetControlContainer.NetContainer) verhält sich bei mir auch so wie von dir beschrieben.

Anm.: Die schlechte Namensunterscheidung werde ich noch korrigieren - bzw. versuche ich das .net-COM-Control mit einem Manifest in VB6 eizubinden. Dann sollte es nicht registriert werden müssen und steht in Access gar nicht zur Auswahl.

mfg
Josef

[Josef Pötzl]

Update: Namen geändert.
VB6-Control: ACLibControlContainer.ControlContainer
.net-COM-Control: ACLibDotNetControlContainer.ControlContainer

[Sten Schmidt]

Hallo Josef,

ja du hast recht, ich hatte die .NET Variante erwischt. Jetzt funktioniert es!

Die neue Benennung finde ich gut, da sieht man den Unterschied gleich auf den ersten Blick.

[Sten Schmidt]

Hallo Josef,

wie hast die Verwendung von VBA heraus prinzipiell vorgesehen?

Das VB6-Control wird eingefügt, kann kann beispielsweise von VBA aus per

Code: Alles auswählen


        Me.VB6Control ...
 

angesprochen werden. Lt. Code des VB6-Controls

Code: Alles auswählen


'VB6 Control
Public Property Get Control() As Object
   Set Control = NetControlContainer.Control
End Property
 

sollte man hier doch per

Code: Alles auswählen


        Me.VB6Control.Control ...
 

eine Referenz auf das geladene .Net-Control bekommen, dies scheint aber nicht zu funktionieren.
Ist "Control" ggf. Reserviert und nicht verwendbar?

Oder sollte man lieber

Code: Alles auswählen


'VB6 Control
Public Sub LoadControl(ByVal ControlRef As Object)
   NetControlContainer.LoadControl ControlRef
End Sub
 

verwenden, so dass man seine eigene Instanz(ControlRef) bereits in VBA zur weiteren "Steuerung" vorliegen hat?

Gruß Sten

[Josef Pötzl]

Hallo Sten!

Grundsätzlich stelle ich mir den Weg über LoadControl vor.
Die aktuell per .net-ControlContainer ladbaren Controls sind eigentlich nur zum Ausprobieren, ob es grundsätzlich funktioniert.

Trotzdem sollte die Rückgabe der Referenz über Control funktionieren.

Eventuell muss du in VBA

Code: Alles auswählen

Me.Steuerelement.Object.Control

verwenden.

mfg
Josef

[Sten Schmidt]

Hallo Josef,

Trotzdem sollte die Rückgabe der Referenz über Control funktionieren.

ja, Referenz in VBA erzeugen und an LoadControl übergeben funktioniert. Fernsteuern erfolgt dann über die Referenz.

PS:
Das wird dann noch lustig... erste Tests mit dem DataGridView ergaben, dass die Zurücktaste und die Entf-Taste beim Editieren einer GridViewZelle nicht funktioniert... ich konnte einmal eingegebene Werte nicht mehr löschen, sondern nur von vorne nach hinten überschreiben. Hinzufügen und Löschen ganzer Rows hingegen funktioniert.

Das ist wohl nur ein kleiner Vorgeschmack auf die Probleme die da noch entstehen werden

[Josef Pötzl]

Die Variante Me.Steuerelement.Object.Control liefert das geladene .net-Control.

Wäre es sinnvoll, ein paar Standard-Controls direkt über den ControlContainer erzeugen zu können?
Ursprünglich dachte ich, ich erstelle nur die dll mit dem ControlContainer. Die gewünschten Controls muss man über andere COM-dlls erstellen und mit LoadControl im ControlContainer anzeigen lassen.

Ich könnte mir aber auch vorstellen, dass man die .net-ControlContainer-dll so ausbaut, dass man gängige Controls direkt laden kann. Das hätte dann den Vorteil, dass man in der Access-Anwendung zur Laufzeit keine weitere dll benötigen würde.
Nachteil: ControlContainer-dll wird komplexer => Fehleranfälliger / mehr Updates usw.

erste Tests mit dem DataGridView ergaben, dass die Zurücktaste und die Entf-Taste beim Editieren einer GridViewZelle nicht funktioniert.

Wenn ich das mit meinem Mini-Beispiel (das im ControlContainer enthalten ist) ausprobiere, kann ich die Entf- oder auch die Zurücktaste verwenden. Ich muss nur zuvor per Doppelklick oder {F2} in den "Edit-Modus" wechseln.

mfg
Josef

[Sten Schmidt]

Hallo Josef,

Wäre es sinnvoll, ein paar Standard-Controls direkt über den ControlContainer erzeugen zu können?
Ursprünglich dachte ich, ich erstelle nur die dll mit dem ControlContainer. Die gewünschten Controls muss man über andere COM-dlls erstellen und mit LoadControl im ControlContainer anzeigen lassen.

Ich könnte mir aber auch vorstellen, dass man die .net-ControlContainer-dll so ausbaut, dass man gängige Controls direkt laden kann. Das hätte dann den Vorteil, dass man in der Access-Anwendung zur Laufzeit keine weitere dll benötigen würde.
Nachteil: ControlContainer-dll wird komplexer => Fehleranfälliger / mehr Updates usw.

Ich denke der Container sollte ein Container bleiben. Einmal mit Admin-Rechten Deployen und dann nach Möglichkeit für eine lange Zeit nicht wieder anfassen.

Es spricht ja nix dagegen z.B. ein davon getrenntes "AccessNetLibDataGridView" oder "AccessNetLibCommonControls"-Projektchen zu machen, von dem es dann ein paar Updates gibt.