Discussions au sujet de NI LabVIEW
Intégrer un toolkit Report Generation customisé au versioning Git
Résolu !
salut à vous,
je me permets quelques remarques .
- La vi.lib est réservée à du code de National Instruments.
- La user.lib est destinée à du code personnalisé.
La conséquence est que sur un changement de version de LabVIEW ou de réinstallation d'un toolkit ou driver ou autres, le code de la vi.lib va être écrasé ou modifié ou perdu. Le dossier vi.lib est sous le contrôle de NI.
Donc (pour moi) un code de National Instruments peut être modifié (évidement) mais il faut lui changer de nom et le mettre dans la user.lib ou dans le projet.
Dans l'exemple du report generation toolkit, j'ai déjà modifier certaines fonctions (de NI et donc dans la user.lib). Pour faire cela :
- je lui donne un nouveau nom
- je le sauvegarde dans mon projet (il est donc sous le contrôle du Source Code Control)
Pour l'histoire c'est la raison du VI "Excel Get ActiveX References" : Le report generation étant une classe, seulement les membres de la classe peuvent manipuler un objet de la classe. La conséquence est qu'un VI qui n'est pas dans la classe ne peut pas manipuler une référence au "report" du toolkit report generation. National Instrument a donc insérer dans la classe, un vi qui permet à un vi extérieur dans la classe d'avoir accès aux références. Donc un VI du projet peut accéder aux références.
Donc ma réponse est : ton code est dans le dossier de ton projet, et donc gérer par le contrôle de code source.
non?
a écrit :
salut à vous,
je me permets quelques remarques .
- La vi.lib est réservée à du code de National Instruments.
- La user.lib est destinée à du code personnalisé.
La conséquence est que sur un changement de version de LabVIEW ou de réinstallation d'un toolkit ou driver ou autres, le code de la vi.lib va être écrasé ou modifié ou perdu. Le dossier vi.lib est sous le contrôle de NI.
Donc (pour moi) un code de National Instruments peut être modifié (évidement) mais il faut lui changer de nom et le mettre dans la user.lib ou dans le projet.
Dans l'exemple du report generation toolkit, j'ai déjà modifier certaines fonctions (de NI et donc dans la user.lib). Pour faire cela :
- je lui donne un nouveau nom
- je le sauvegarde dans mon projet (il est donc sous le contrôle du Source Code Control)
Pour l'histoire c'est la raison du VI "Excel Get ActiveX References" : Le report generation étant une classe, seulement les membres de la classe peuvent manipuler un objet de la classe. La conséquence est qu'un VI qui n'est pas dans la classe ne peut pas manipuler une référence au "report" du toolkit report generation. National Instrument a donc insérer dans la classe, un vi qui permet à un vi extérieur dans la classe d'avoir accès aux références. Donc un VI du projet peut accéder aux références.
Donc ma réponse est : ton code est dans le dossier de ton projet, et donc gérer par le contrôle de code source.
non?
Merci pour ta réponse Luc. Du coup je pense effectivement que je vais procéder de la même manière:
sauver ma version du NI_ReportGenerationToolkit.lvlib dans mon dossier projet, comme ça je profite du versioning. Mais par contre je tire un trait sur une possible mise à jour (facile) de ce toolkit customisé.
Ah, petite question subsidiaire, du coup pour distribuer les sources tu procèdes de la même façon pour les drivers d'instrumentation (copie des lvlib dans ton dossier projet) ou tu crées plutôt des packages avec VIPM, ou autre?
Salut, pour préciser, de mon côté j'ai :
- le code standard "LabVIEW" : Program Files\National Instruments\LabVIEW : la distribution standard de LabVIEW. Donc dans la vi.lib j'ai le report generation toolkit avec NI_ReportGenerationToolkit.lvlib. Le dossier Program Files\National Instruments\LabVIEW est sous le contrôle des installeurs de National Instruments. Il est standard entre les PC.
- le code "projet" : /monprojet/source/ qui mon dossier projet. Il contient l'ensemble de mon code "source", et il est sous le contrôle de mon SCC (j'utilise SVN)
- A la fin du projet, je distribue le code de ma user.lib (utilisé dans le projet) dans le dossier Windows du projet : /monprojet/source/common/user. Donc à la fin sous le contrôle de mon SCC. Il n'y a pas toute ma user.lib, mais uniquement le code utilisé.
Par exemple,
- un vi "spécifique" à notre projet, qui utilise la classe du report generation, va être sauvegardé sous /monprojet/source/common/user/lib/Excel
- le code de NI est "standard" et il est dans la vi.lib : NI_ReportGenerationToolkit.lvlib car il est
je suis plus claire? A+
salut
non
Par contre si quelqu'un récupère ton code via SVN, il va devoir copier manuellement le contenu de /monprojet/source/common/ dans les dossiers correspondants?
car : /monprojet/source/ qui mon dossier projet, et qui contient l'ensemble de mon code "source", est sous le contrôle de mon SCC. Donc il va exporter le dépôt SVN, et il aura le code dans le dossier et les sous-dossiers (donc common et autres)
plus claire?
