Convertir une chaîne de caractère en datetime

Je vais tenter ça.
Il existe déjà une seconde fonction dans l'appli :

Code:

---

CLdap::Put_INT_Attribut(IADs & pADs,BSTR sNomAttribut, int iValeurAttribut)

---

Je vais en ajouter une troisième pour gérer un paramètre LARGE INTEGER

Mais il me reste malgré tout à convertir mon FILETIME en LARGE_INTEGER de manière correct.
Je vais reprendre toutes mes notes pour repartir sur cette piste.

Merci encore une fois (de plus) pour votre aide ;)

Code:

---

CLdap::Put_INT_Attribut(IADs & pADs,BSTR sNomAttribut, int iValeurAttribut)

---

C'est tout aussi ridicule comme signature, surtout avec du 32 bits et du 64 bits qui se balade.
Ce 'int" on c'est même pas combien il a d'octet.

Citation:

---

Mais il me reste malgré tout à convertir mon FILETIME en LARGE_INTEGER de manière correct.

---

Si vous avez comme valeur un FILETIME, mettez un FILETIME comme paramètre de cette fonction.
Si les primitives LDAP ne veulent que du LARGE_INTEGER, faites la conversion à l'intérieur de la fonction.
Comme ça, vous aurez plus de libertés sur le choix des méthodes que publie l'interface "IADs".

En effet, tant qu'à créer une nouvelle fonction, autant m'éviter cette étape de conversion.

La fonction de iADS appelée par mon code est la fonction Put suivante :

Code:

---

1 2 3

virtual /* [id] */ HRESULT STDMETHODCALLTYPE Put( /* [in] */ BSTR bstrName, /* [in] */ VARIANT vProp) = 0;

---

Quel que soit le format de ma variable en entrée de ma fonction, il faut donc que je la convertisse en VARIANT

Je vais tenter le coup avec la fonction InitVariantFromFileTime.
A priori ça devrait en effet pouvoir se faire plus facilement.

Citation:

---

Envoyé par bacelar

Le plus simple, c'est de faire une autre méthode qui prend un LARGE_INTEGER en troisième paramètre et pas cet horrible CString.

Vous faites un code bien plus propre et bien plus simple en utilisant des COleVariant, comme l'indique @Médinoc.

Je pense que c'est une fonction qui ne devrait pas faire plus de 5 lignes. (Je n'ai pas de MFC ni d'AD sous la main, désolé).

---

Attention, il n'y a pas de type de variant pour LARGE_INTEGER... mais VT_I8 devrait probablement convenir.

Sinon, il faudra utiliser VT_DATE, après avoir converti le FILETIME en COleDateTime.

En fait j'ai créé une fonction CLdap:: Put_FT_Attribut à laquelle je fournis mon FILETIME en paramètre au lieu d'un CString.
Maintenant dans cette fonction, il faut que je convertisse ce FILETIME en VARIANT, pour pouvoir utiliser la fonction IADs:: Put qui attend ce format en entrée. Et a priori la fonction InitVariantFromFileTime va me permettre de le faire.

L'idéal aurait été de pouvoir faire comme un int, en utilisant var.intVal, mais il n'y a pas de var.ftVal ou équivalent.:(

Apparemment, InitVariantFromFileTime() fait le travail de convertir le FILETIME en VT_DATE, exactement ce qu'il fallait, je parie.

Mais j'ai une erreur sur cette fonction :

Error: identificateur "InitVariantFromFileTime" non défini :'(

Pourtant cette fonction semble être une fonction de VARIANT, objet que je défini sans souci dans mon code. Donc il ne doit pas me manquer d'include...

RTFM:

Citation:

---

Envoyé par MSDN

Header

PropVarUtil.h

---

:weird::weird:

Alors que Visual Studio ne m'affiche plus d'erreur après avoir ajouté l'include de la classe PropVarUtil.h, à la compile j'ai une erreur malgré tout.

Code:

---

error LNK2019: symbole externe non résolu __imp__InitVariantFromFileTime@8 référencé dans la fonction "public: long __thiscall CLdap::Put_FT_Attribut(struct IADs &,wchar_t *,struct _FILETIME)" (?Put_FT_Attribut@CLdap@@QAEJAAUIADs@@PA_WU_FILETIME@@@Z)

---

J'ai écrit ma fonction comme suit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

HRESULT CLdap::Put_FT_Attribut(IADs & pADs,BSTR sNomAttribut, FILETIME fValeurAttribut) {   VARIANT var;   VariantInit(&var); var.vt=VT_DATE;   HRESULT hr = InitVariantFromFileTime(&fValeurAttribut, &var);   return(pADs.Put(sNomAttribut,var));   }

---

Et a priori la fonction InitVariantFromFileTime ne veut pas fonctionner.

Etant donné qu'il s'agit d'une fonction d'initialisation d'un VARIANT, j'ai tenté en supprimant les deux lignes d'initialisation au dessus, pensant que ça entrait en conflit, mais non. Pas mieux... :'(
J'ai aussi tenté le coup en modifiant ma ligne de code :

Code:

---

var.vt=VT_FILETIME;

---

Mais pas mieux encore...

Il s'agit d'une erreur de link, il doit te manquer une lib à lier à ton exécutable pendant l'édition de liens.
Comme le montre la doc https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx tu as ajouté l'include c'est bien, faut aussi lier Propsys.lib

En d'autres termes, RTFM encore.

J'avais bien cru comprendre qu'il me manquait une DLL nommée propsys.dll, mais je l'ai téléchargée et déposée dans le répertoire d'exécution de mon appli, avec les autres dll qu'elle utilisait déjà jusque là, mais ça ne suffit pas.

RTFM, certes
Mais je ne vois pas sur la page de la fonction InitVariantFromFileTime quoi que ce soit faisant référence à cette lib, et encore moins comment la "lier" à mon application...

Normalement la DLL est déjà là, supprime ce que tu as DL et ajoute la lib statique d'importation PropSys.lib aux options d'édition de liens du projet.

Parles-tu d'un simple
#include <Propsys.h>
?

Car même avec ça, j'ai toujours le même message d'erreur.:aie:
Je n'en peux plus du langage objet...

C'est bon, j'ai trouvé ça sur le site.

Mais la conversion n'est pas bonne...
La création du compte se fait dans l'AD, mais le champ accountExpires n'est pas valorisé correctement.

Le sujet peut être clos, j'ai solutionné mon problème.
Vu l'aide que vous m'avez apporté, la moindre des choses était de vous en faire part :D

En fait il restait une erreur toute conne.
A la création de mon systemetime, je valorisais st.wYear, st.wMonth et st.wDay, mais il faut impérativement valoriser wMillesecond, wSecond etc... même si on veut les mettre à 0.
Ma création de FILETIME était donc mauvaise.

C'est corrigé, et ça marche.

C'est pour ça qu'il vaut mieux initialiser toute la structure à zéro:

Code:

---

SYSTEMTIME st = {0};

---

Et il y a probablement des façon plus "C++" de déclarer cela.