Seite 1 von 2

.Net Control Container für Access

BeitragVerfasst: Fr 7. Feb 2014, 19:03
von 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

Re: .Net Control Container für Access

BeitragVerfasst: Mo 10. Feb 2014, 15:59
von Sten Schmidt
2014-02-10_NetComCtr.png
2014-02-10_NetComCtr.png (7.03 KiB) 34972-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.

Re: .Net Control Container für Access

BeitragVerfasst: Di 11. Feb 2014, 09:10
von 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

Re: .Net Control Container für Access

BeitragVerfasst: Di 11. Feb 2014, 09:49
von Josef Pötzl
Update: Namen geändert.
VB6-Control: ACLibControlContainer.ControlContainer
.net-COM-Control: ACLibDotNetControlContainer.ControlContainer

Re: .Net Control Container für Access

BeitragVerfasst: Di 11. Feb 2014, 19:53
von 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. :)

Re: .Net Control Container für Access

BeitragVerfasst: Mi 12. Feb 2014, 10:20
von 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

Re: .Net Control Container für Access

BeitragVerfasst: Mi 12. Feb 2014, 18:01
von 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

Re: .Net Control Container für Access

BeitragVerfasst: Do 13. Feb 2014, 14:41
von Sten Schmidt
Hallo Josef,

Josef Pötzl hat geschrieben: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 :)

Re: .Net Control Container für Access

BeitragVerfasst: Fr 14. Feb 2014, 09:13
von 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

Re: .Net Control Container für Access

BeitragVerfasst: Do 20. Feb 2014, 11:56
von Sten Schmidt
Hallo Josef,

Josef Pötzl hat geschrieben: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.