Je voudrais faire une libraire dont un de mes contrôles contient un truc
du genre :
ON_COMMAND(ID_BLABLA,Onblabla)
Le problème, c'est que ID_BLABLA est défini dans les ressources de
l'application qui utilisera cette librairie.
Si je mets un UINT, ça compile pas.
Donc lorsqu'on veut utiliser, dans une librairie, des ressources
(principalement les constantes qui les définissent) qui seront définies
ultérieurement, comment fait-on?
Faire un premier fichier "libresource.h" contenant les ID de la librairie. Puis l'inclure dans l'application principale.
Mais est-ce que cela évite les conflits d'ID?
Merci
Vincent Burel
"JM" wrote in message news:44ad13b4$0$865$
Bonjour
Je voudrais faire une libraire dont un de mes contrôles contient un truc du genre :
ON_COMMAND(ID_BLABLA,Onblabla)
Le problème, c'est que ID_BLABLA est défini dans les ressources de l'application qui utilisera cette librairie. Si je mets un UINT, ça compile pas.
Généralement ID_BLABLA n'est pas une constante mais un #define qui peut être utilisé par votre application aussi bien que par vos diverses librairies (suffit d'include le header contenant ces #define).
Sinon généralement on exporte pas les constantes ou des variables (dans une lib comme dans un DLL), on préfèrera user d'une fonctions pour se communiquer, d'un module à l'autre (lib, dll, mais même d'un module 'c' à un autre), les valeurs, les structures et pointeurs dont on a besoin...
VB
"JM" <nospamjm@yahoo.com> wrote in message
news:44ad13b4$0$865$ba4acef3@news.orange.fr...
Bonjour
Je voudrais faire une libraire dont un de mes contrôles contient un truc
du genre :
ON_COMMAND(ID_BLABLA,Onblabla)
Le problème, c'est que ID_BLABLA est défini dans les ressources de
l'application qui utilisera cette librairie.
Si je mets un UINT, ça compile pas.
Généralement ID_BLABLA n'est pas une constante mais un #define qui peut être
utilisé par votre application aussi bien que par vos diverses librairies
(suffit d'include le header contenant ces #define).
Sinon généralement on exporte pas les constantes ou des variables (dans une
lib comme dans un DLL), on préfèrera user d'une fonctions pour se
communiquer, d'un module à l'autre (lib, dll, mais même d'un module 'c' à un
autre), les valeurs, les structures et pointeurs dont on a besoin...
Je voudrais faire une libraire dont un de mes contrôles contient un truc du genre :
ON_COMMAND(ID_BLABLA,Onblabla)
Le problème, c'est que ID_BLABLA est défini dans les ressources de l'application qui utilisera cette librairie. Si je mets un UINT, ça compile pas.
Généralement ID_BLABLA n'est pas une constante mais un #define qui peut être utilisé par votre application aussi bien que par vos diverses librairies (suffit d'include le header contenant ces #define).
Sinon généralement on exporte pas les constantes ou des variables (dans une lib comme dans un DLL), on préfèrera user d'une fonctions pour se communiquer, d'un module à l'autre (lib, dll, mais même d'un module 'c' à un autre), les valeurs, les structures et pointeurs dont on a besoin...
VB
JM
Vincent Burel a écrit :
Généralement ID_BLABLA n'est pas une constante mais un #define qui peut être utilisé par votre application aussi bien que par vos diverses librairies (suffit d'include le header contenant ces #define).
Quand je parlais de "constante", je pensais effictivement #define. Le problème qui se pose, c'est l'incompatibilité entre divers ID dans les ressources
Vincent Burel a écrit :
Généralement ID_BLABLA n'est pas une constante mais un #define qui peut être
utilisé par votre application aussi bien que par vos diverses librairies
(suffit d'include le header contenant ces #define).
Quand je parlais de "constante", je pensais effictivement #define.
Le problème qui se pose, c'est l'incompatibilité entre divers ID dans
les ressources
Généralement ID_BLABLA n'est pas une constante mais un #define qui peut être utilisé par votre application aussi bien que par vos diverses librairies (suffit d'include le header contenant ces #define).
Quand je parlais de "constante", je pensais effictivement #define. Le problème qui se pose, c'est l'incompatibilité entre divers ID dans les ressources
Vincent Burel
"JM" wrote in message news:44ad2b58$0$826$
Vincent Burel a écrit :
> Généralement ID_BLABLA n'est pas une constante mais un #define qui peut
être
> utilisé par votre application aussi bien que par vos diverses librairies > (suffit d'include le header contenant ces #define).
Quand je parlais de "constante", je pensais effictivement #define. Le problème qui se pose, c'est l'incompatibilité entre divers ID dans les ressources
il faut s'organiser et faire attention que les resources d'une DLL sont indépendantes de celle de l'appli qui l'utilise (les HMODULE-dll sont différent du HINSTANCE-app) à moins qu'il y ait moyen de gérer les resources des uns et des autres en se comuniquant les bon hinst... beueuerk :-)
Si une DLL doit utiliser les mêmes ressources qu'une appli, c'est généralement plus simple de communiquer directement à la DLL (via une fonction) un ou plusieurs handle sur du BITMAP, FONT, ICON etc... plutot que d'imaginer un tron commun qui va limiter la portabilité de cette librairie et surement poser des problème de compatibilité un jour ...
VB
"JM" <nospamjm@yahoo.com> wrote in message
news:44ad2b58$0$826$ba4acef3@news.orange.fr...
Vincent Burel a écrit :
> Généralement ID_BLABLA n'est pas une constante mais un #define qui peut
être
> utilisé par votre application aussi bien que par vos diverses librairies
> (suffit d'include le header contenant ces #define).
Quand je parlais de "constante", je pensais effictivement #define.
Le problème qui se pose, c'est l'incompatibilité entre divers ID dans
les ressources
il faut s'organiser et faire attention que les resources d'une DLL sont
indépendantes de celle de l'appli qui l'utilise (les HMODULE-dll sont
différent du HINSTANCE-app) à moins qu'il y ait moyen de gérer les resources
des uns et des autres en se comuniquant les bon hinst... beueuerk :-)
Si une DLL doit utiliser les mêmes ressources qu'une appli, c'est
généralement plus simple de communiquer directement à la DLL (via une
fonction) un ou plusieurs handle sur du BITMAP, FONT, ICON etc... plutot que
d'imaginer un tron commun qui va limiter la portabilité de cette librairie
et surement poser des problème de compatibilité un jour ...
> Généralement ID_BLABLA n'est pas une constante mais un #define qui peut
être
> utilisé par votre application aussi bien que par vos diverses librairies > (suffit d'include le header contenant ces #define).
Quand je parlais de "constante", je pensais effictivement #define. Le problème qui se pose, c'est l'incompatibilité entre divers ID dans les ressources
il faut s'organiser et faire attention que les resources d'une DLL sont indépendantes de celle de l'appli qui l'utilise (les HMODULE-dll sont différent du HINSTANCE-app) à moins qu'il y ait moyen de gérer les resources des uns et des autres en se comuniquant les bon hinst... beueuerk :-)
Si une DLL doit utiliser les mêmes ressources qu'une appli, c'est généralement plus simple de communiquer directement à la DLL (via une fonction) un ou plusieurs handle sur du BITMAP, FONT, ICON etc... plutot que d'imaginer un tron commun qui va limiter la portabilité de cette librairie et surement poser des problème de compatibilité un jour ...
