Créez des formulaires sans table avec le Data Shaping ADO [Tutoriel]

[Lou Pitchoun]

Bonjour à tous,

Vous pouvez sur cette discussion commenter l'article suivant :
Créez des formulaires sans table avec le Data Shaping ADO

L'avez vous lu?
Le trouvez vous intéressant?
Commentaires, critiques, remerciement, ... Tout est bienvenue si c'est constructif.

Pensez également à ajouter une note. ("Noter la discussion" en haut à droite)
Votre avis nous intéresse.

[vodiem]

salut Lou Pitchoun,

j'ai pas tout lu, seulement l'essentiel et j'ai regardé sur msdn les possibilités, c'est vrai que cela à l'air vraiment sympas.
surement parce que c'est vraiment simple à mettre en place.

il y a juste un truc qui me chiffonne, comme spécifié: on ne peut pas éditer dans le formulaire directement les contrôles associés aux champs.

juste une question donc: et si je veux pouvoir éditer à partir du formulaire, quel serait la méthode la plus simple à adopter?

merci,

[Arkham46]

juste une question donc: et si je veux pouvoir éditer à partir du formulaire, quel serait la méthode la plus simple à adopter?

salut vodiem

On est un peu bloqué sur ce coup là.

On peut quand même agir sur l'objet recordset, donc on peut utiliser un petit formulaire de modification, à ouvrir sur double-click ou click sur un bouton.
Mais pour la modif directement sur le formulaire, je n'ai pas trouvé grand chose d'efficace (on peut agir sur l'événement "touche appuyée" pour modifier la valeur en fonction de la touche mais ça fait bidouille)

[vodiem]

salut Arkham46,

merci pour ta réponse,

j'ai regardé plutôt du coté "sur touche activée" qui donne le code ascii et facilite donc le traitement.
globalement cela me satisfait, cela reste plus simple que les pistes que j'entrevoyais.

j'aimerais savoir: serait-il possible de mettre à jour l'affichage lorsqu'on est en mode "edit" sans avoir à repasser par la maj du champ?
ceci me permettrais de faire un update "sur activation" (et ainsi pourvoir avoir la possibilité d'annuler l'"édit") sans avoir à coder ce comportement.

y a t-il une explication qui justifie l'impossibilité du passage à l'"édit"?
sous entendu: n'y aurait-il pas une autre façon de connecter le recordset pour pouvoir l'autoriser? faire reconnaitre au formulaire que le recordset est éditable ou le forcer à le reconnaitre ?

merci,

[LedZeppII]

Bonjour,

Extrait de l'aide en ligne d'Access 2000 à propos de la propriété Recordset de l'objet Form:

Quand un objet Recordset est demandé dans une base de données Microsoft Access (.mdb), un objet DAO Recordset est renvoyé tandis que dans un projet Microsoft Access (.adp), c'est un objet ADO Recordset qui est renvoyé.

Le comportement en lecture/écriture d'un formulaire dont la propriété JeuEnregistrements (Recordset) a été définie en Visual Basic est déterminé par le type d'objet Recordset (ADO ou DAO) ainsi que le type de données (Jet ou SQL) contenues dans l'objet Recordset identifié par la propriété.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Type d'objet     Basé sur des           Basé sur des
 Recordset       données SQL            données Jet 
------------   ---------------------  -------------------
ADO            Lecture/écriture (1)     Lecture seule 
DAO                  N/A               Lecture/écriture

(1) Remarque La propriété ADO Recordset.CursorLocation doit avoir la valeur adUseClient.

Le problème (ou la limitation) semble venir de là.
Ça serait intéressant de faire l'essai dans un formulaire d'un projet ADP.
A moins qu'il ne faille impérativement que le recordset ADO soit basé sur des données SQL Server.

A+

[vodiem]

merci LedZeppII pour tes recherches et explications.
je m'en doutais un peu et j'avais fait qq naïves essaies en DAO sans succès.
voilà le code que j'ai rajouté en fin de module qui permettrait de faire l'édition d'un contrôle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Private Function editControl(KeyAscii As Integer, Optional Suppr As Boolean = False)
Dim s As Long       'sauvegarde de la position du curseur
Dim c As String     'caractère à insérer
Dim txt As String   'texte résultat
 
With ActiveControl
    If Suppr Then
        'supprime
        If (.SelStart = Len(ActiveControl)) And (.SelLength = 0) Then Exit Function
        s = .SelStart
        If .SelLength = 0 Then .SelLength = 1
    Else
        Select Case KeyAscii
            Case 8
                'delete
                If (.SelStart = 0) And (.SelLength = 0) Then Exit Function
                If (.SelStart > 0) And (.SelLength = 0) Then
                    .SelStart = .SelStart - 1
                    .SelLength = 1
                End If
                s = .SelStart
                If .SelLength = 0 Then .SelLength = 1
            Case 32 To 126, 160 To 255
                'caractères supportés par windows
                s = .SelStart + 1
                c = Chr(KeyAscii)
        Case Else
            Exit Function
        End Select
    End If
    txt = Left(ActiveControl, .SelStart) & c & Right(ActiveControl, Len(txtvaleur) - (.SelStart + .SelLength))
    Application.Echo False
    oRs.Fields(.ControlSource) = txt
    oRs.Update
    .SelStart = s
    Application.Echo True
End With
End Function
 
Private Sub txtvaleur_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = 46 Then editControl 0, True    'supprime
End Sub
 
Private Sub txtvaleur_KeyPress(KeyAscii As Integer)
editControl KeyAscii
End Sub

il faut malheureusement intercepter la touche de suppression dans "touche appuyée".

c'est un peu simpliste puisque cela ne gère pas l'annulation du champ ou de l'enregistrement et peut être d'autre comportement.

en attendant qui sait que l'on puisse éditer...