Not sure, whether some of you have run into this, but the MS-ADODC-Control does not support Unicode when linked to Control-Bindings.
So the 3 Binding-Controls in this Demo can be seen as an Unicode-aware Replacement:
- not only for the ADODC-Control (represented by ucBindingNav)
- but also for a Scrollable-DetailView-Container (which hosts Bound-Control-entries "PropertyGrid-like")
Perhaps a ScreenShot explains better, what the Main-Control (ucBindingCont) does:
![]()
In this example, the ucBindingCont(ainer) fills the Form in its entirety,
and is the only Control one has to create on the given Form.
The ADODC-like Navigation-Bar at the Bottom of the Screenshot (ucBindingNav) is internally part of that ucBindingCont.ctl.
The approach needs a Unicode-library (for the Controls which are bound to ADO-Rs later),
and it should work with any decent Unicode-Control-lib, like e.g. the OCXes which are available from:
- CyberActiveX
- CodeJock
- or Krools OCX-version
Note, that neither Control-Lib has to offer special DataSource/DataField Props on their Controls -
the Binding-implementation here will not require these (they will be ignored, even if they do exist).
In this Demo I was making use of Krools latest OCX-Version (VBCCR17), which is therefore a prerequisite -
(which one has to download and register, before running this Demo-Project makes any sense).
Note, that the Conrols of the Unicode-lib one wants to use - are instantiated (and later accessed) in a LateBound fashion,
for that to work - only their ProgIDs have to be defined (for each of the Control-Types which make sense) - here's the ones for Krools lib:
With these Constants in place, the Definition which creates the Binding-View (as seen in the ScreenShot) is this:
The magenta-colored Comment above describes, what is needed for an automatic "ForeignKey-Combo-DropDown-Binding".
So, a Binding-Def-CodeLine requires the following Parameters:
- the Rs-FieldName in the first Parameter (when no explicit Caption is set, these FieldNames will provide also the Labeling in the View)
- the ProgID (for Control-Creation... above marked in blue, as defined in our Consts)
- the Name of the Control-Event, which tells us about a Value-change in the Control (often "Change", but sometimes "Click" or whatever)
- the Name of the Value-Property of the Control, we will bind the Rs-Value to later on
- and finally an optional ToolTip-Text, followed by an optional FormatString argument
That's it (basically) to create a nice looking Data-Entry-Form (or -View)...
For full CRUD-operation-support (Create, Read, Update Delete) via the Bottom-NavBar, only one EventHandler has to be implemented:
For usage in your own Projects, only the 3 UserControls (ucBindingCont, ucBindingNav and ucBindingEntry)
have to be included (directly as Private UserControls - they are small enough - and use no SubClassing or some such).
Other than the ADO-reference (which is obvious when we use ADO-Bindings) no other dependency is needed.
Well, I hope the above explanations were clear enough to get you started, here is the Demo-Zip:
BindingDemo.zip
Have fun,
Olaf
So the 3 Binding-Controls in this Demo can be seen as an Unicode-aware Replacement:
- not only for the ADODC-Control (represented by ucBindingNav)
- but also for a Scrollable-DetailView-Container (which hosts Bound-Control-entries "PropertyGrid-like")
Perhaps a ScreenShot explains better, what the Main-Control (ucBindingCont) does:
In this example, the ucBindingCont(ainer) fills the Form in its entirety,
and is the only Control one has to create on the given Form.
The ADODC-like Navigation-Bar at the Bottom of the Screenshot (ucBindingNav) is internally part of that ucBindingCont.ctl.
The approach needs a Unicode-library (for the Controls which are bound to ADO-Rs later),
and it should work with any decent Unicode-Control-lib, like e.g. the OCXes which are available from:
- CyberActiveX
- CodeJock
- or Krools OCX-version
Note, that neither Control-Lib has to offer special DataSource/DataField Props on their Controls -
the Binding-implementation here will not require these (they will be ignored, even if they do exist).
In this Demo I was making use of Krools latest OCX-Version (VBCCR17), which is therefore a prerequisite -
(which one has to download and register, before running this Demo-Project makes any sense).
Note, that the Conrols of the Unicode-lib one wants to use - are instantiated (and later accessed) in a LateBound fashion,
for that to work - only their ProgIDs have to be defined (for each of the Control-Types which make sense) - here's the ones for Krools lib:
Code:
Const TxtCtlProgID = "VBCCR17.TextBoxW"
Const CmbCtlProgID = "VBCCR17.ComboBoxW"
Const DatCtlProgID = "VBCCR17.DTPicker"
Const ChkCtlProgID = "VBCCR17.CheckBoxW"Code:
Private Sub CreateBoundControlsView(RsUnicode As ADODB.Recordset, RsLanguages As ADODB.Recordset)
With ucBindingCont1 'the dynamic adding + binding of Controls (all LateBound, using the above ProgID-Consts)
.Visible = False 'we hide the Binding-Container here, to avoid Flickering during Control-(Re-)Adds
.SetTitle "ADO.Rs-Binding to UniCode-Controls"
.AddBoundCtlFor "Welcome", TxtCtlProgID, "Change", "Text", "a longer Unicode-Welcome-ToolTip with chinese Chars: " & ChrW(&H6B22) & ChrW(&H8FCE)
.AddBoundCtlFor "Country", TxtCtlProgID, "Change", "Text", "ToolTip for the Country-Field"
.AddBoundCtlFor "Capital", TxtCtlProgID, "Change", "Text", "ToolTip for the Capital-Field"
.AddBoundCtlFor "Checked", ChkCtlProgID, "Click", "Value", "ToolTip for the Checked-Field"
.AddBoundCtlFor "SomeDate", DatCtlProgID, "Change", "Value"
.AddBoundCtlFor "Language", CmbCtlProgID, "Click", RsLanguages '<- instead of a ValuePropName, we pass an FK-Rs to our ComboCtl
Set .DataSource = RsUnicode 'finally we set the DataSource to our Main-Rs, to bring the Bindings to life
.Visible = True 'reset the hidden-state of the Container
End With
End SubSo, a Binding-Def-CodeLine requires the following Parameters:
- the Rs-FieldName in the first Parameter (when no explicit Caption is set, these FieldNames will provide also the Labeling in the View)
- the ProgID (for Control-Creation... above marked in blue, as defined in our Consts)
- the Name of the Control-Event, which tells us about a Value-change in the Control (often "Change", but sometimes "Click" or whatever)
- the Name of the Value-Property of the Control, we will bind the Rs-Value to later on
- and finally an optional ToolTip-Text, followed by an optional FormatString argument
That's it (basically) to create a nice looking Data-Entry-Form (or -View)...
For full CRUD-operation-support (Create, Read, Update Delete) via the Bottom-NavBar, only one EventHandler has to be implemented:
Code:
Private Sub ucBindingCont1_NavButtonClick(ByVal BtnType As eNavButtonType, CancelClickEvent As Boolean)
On Error Resume Next
With ucBindingCont1.DataSource 'we just call the matching Methods of our DataSource (of type ADODB.Recordset)
Select Case BtnType 'in a real App one might want to throw some MessageBoxes like "Do you really want to save" at the User
Case navBtnRequery: .Requery
Case navBtnDelete: .Delete
Case navBtnAddNew: .AddNew
Case navBtnSave: .UpdateBatch
End Select
End With
If Err Then MsgBox Err.Description: Err.Clear
End Subhave to be included (directly as Private UserControls - they are small enough - and use no SubClassing or some such).
Other than the ADO-reference (which is obvious when we use ADO-Bindings) no other dependency is needed.
Well, I hope the above explanations were clear enough to get you started, here is the Demo-Zip:
BindingDemo.zip
Have fun,
Olaf