0 Members and 1 Guest are viewing this topic.
#define STRICT // remis ici#define ORBITER_MODULE //déplacé ici#include "MaClasseAddon.h"//déclaration de hDLL dans ce cpp//HINSTANCE hDLL;// je vais la nommer bibiHINSTANCE BIBI_DLL; //créé icibool MonAddon::clbkLoadPanel (int id){ static MFDSPEC mfds_left = {{ 66, 84, 326, 344}, 6, 6, 31, 38}; static MFDSPEC mfds_right = {{828, 84, 1088, 344}, 6, 6, 31, 38}; HBITMAP hBmp = LoadBitmap (BIBI_DLL, MAKEINTRESOURCE(IDB_PANEL1)); oapiRegisterPanelBackground (hBmp, PANEL_ATTACH_BOTTOM|PANEL_MOVEOUT_BOTTOM, 0xffffff); oapiRegisterMFD (MFD_LEFT, mfds_left); oapiRegisterMFD (MFD_RIGHT, mfds_right); return TRUE;}//////////////////////////////////////////////////////////////////// Rien.cpp// ---------------------------------------------------------------// Rien à toucher ici, Orbiter ce sert de ceci pour creer des // instances de votre classe, oubliez ce source la.////////////////////////////////////////////////////////////////// // --------------------------------------------------------------// Vessel initialisation// --------------------------------------------------------------DLLCLBK VESSEL *ovcInit (OBJHANDLE hvessel, int flightmodel){ return new MonAddon (hvessel, flightmodel);}// --------------------------------------------------------------// Vessel cleanup// --------------------------------------------------------------DLLCLBK void ovcExit (VESSEL *vessel){ if (vessel) delete (MonAddon*)vessel;}DLLCLBK void InitModule (HINSTANCE hModule){ BIBI_DLL = hModule;}DLLCLBK void ExitModule (HINSTANCE hModule){}
.\MonAddon.rc(17) : error RC2135 : file not found: ..\DeltaGlider\Bitmaps\Panel1.bmp
C:\Documents and Settings\Émile\Mes documents\Orbiter2006/ShuttlePB.dll
Mais chez toi ... essaye !autre genre d'obstacle à la compilation ...Dans MonAddon->Propriétés->Linker->Outpout
------ Début de la génération : Projet : Sentinel, Configuration : Debug Win32 ------Édition des liens en cours...clbkConsumeBufferedKey.obj : warning LNK4075: ' /EDITANDCONTINUE' ignoré à cause de la spécification '/INCREMENTAL:NO' Création de la bibliothèque .\Debug/ShuttlePB.lib et de l'objet .\Debug/ShuttlePB.expIncorporation du manifeste en cours...Le journal de génération a été enregistré à l'emplacement "file://c:\Documents and Settings\Émile\ [...]"Sentinel - 0 erreur(s), 1 avertissement(s)========== Génération : 1 a réussi, 0 a échoué, 0 mis à jour, 0 a été ignoré ==========
/INCREMENTAL[:NO]NotesL'option /INCREMENTAL contrôle la façon dont l'éditeur de liens gère les liaisons incrémentielles.Par défaut, l'éditeur de liens s'exécute en mode incrémentiel. Pour substituer un lien incrémentiel par défaut, spécifiez /INCREMENTAL:NO.Un programme lié de façon incrémentielle équivaut, en termes de fonctionnalités, à un programme lié de façon non incrémentielle. Toutefois, comme ils sont préparés pour des liens incrémentiels à venir, les fichiers exécutables liés de façon incrémentielle (.exe) ou les bibliothèques de liens dynamiques (DLL) présentent les caractéristiques suivantes :Ils sont plus volumineux qu'un programme lié de façon non incrémentielle du fait du remplissage du code et des données. (Le remplissage permet à l'éditeur de liens d'augmenter la taille des fonctions et des données sans recréer le fichier .exe.)Ils peuvent contenir des thunks de branchement gérant le réadressage des fonctions vers les nouvelles adresses.RemarquePour s'assurer que la génération de la version release ne contient pas de remplissages ou de thunks, liez votre programme de façon non incrémentielle.Pour lier par incrément indépendamment de la valeur par défaut, spécifiez /INCREMENTAL. Lorsque cette option est sélectionnée, l'éditeur de liens émet un avertissement s'il ne peut pas lier par incrément, puis lie le programme de façon non incrémentielle. Certaines options et situations substituent l'option /INCREMENTAL.La plupart des programmes peuvent être liés par incrément. Toutefois, certaines modifications étant trop importantes, quelques options sont incompatibles avec les liaisons incrémentielles. LINK effectue un lien complet si l'une des options suivantes est spécifiée :L'option Lier par incrément n'est pas sélectionnée (/INCREMENTAL:NO)./OPT:REF est sélectionné./OPT:ICF est sélectionné./ORDER est sélectionné./INCREMENTAL est implicite lorsque /DEBUG est spécifié.De plus, LINK effectue un lien complet si l'une des situations suivantes se produit :L'état incrémentiel du fichier (.ilk) est manquant (LINK crée un nouveau fichier .ilk en prévision des liaisons incrémentielles à venir).Le fichier .ilk ne possède pas d'autorisation en écriture. (LINK ignore le fichier .ilk et fait des liens non incrémentiels.)Le fichier de sortie .exe ou .dll est manquant.L'horodatage du fichier .ilk, .exe ou .dll est modifié.Une option LINK est modifiée. La plupart des options LINK, lorsqu'elles sont modifiées entre les générations, provoquent un lien complet.Un fichier objet (.obj) est ajouté ou omis.Un objet qui a été compilé avec l'option /Yu /Z7 est modifié.
Je ne sais pas ,le format de EDITANDCONTINUE ressemble à un "flag" défini dans un fichier comme suit :#define EDITANDCONTINUE 202 //par exemple ...C'est une astuce de programmeur qui permet de changer le comportement du programme au besoin .Du genre : switch ( EDITMODE){case EDITANDCONTINUE : bla blabla ...;break;case EDITANDSTOP : bla blabla ...;break;
Sinon , quel était le fichier qui faisait doublon avec ta dll ? Renommer le fichier devrait suffire à corriger le problèmesans toucher aux Options de compil ?
De plus, LINK effectue un lien complet si l'une des situations suivantes se produit :L'état incrémentiel du fichier (.ilk) est manquant (LINK crée un nouveau fichier .ilk en prévision des liaisons incrémentielles à venir).
#ifndef __MonAddon_H#define __MonAddon_H[Blablabla de code mais on s'en fou car c'est pas ça l'important]#endif
Conclusion : DANSTEPH est un fin Stratège !!
Pour l'histoire des .h incluent plusieurs fois par mauvaise structure, je suis sauver car j'utilise la technique de protection. Avec ça, le compilateur ne chargera jamais 2 deux le même .h dans un fichier. Voilà le code de mes .h :#ifndef __MonAddon_H#define __MonAddon_H[Blablabla de code mais on s'en fou car c'est pas ça l'important]#endif
Et le #define EDITANDCONTINUE n'est pas de moi. Ça doit être dans les .h d'Orbiter ou d'OrbiterSound35.
L'état incrémentiel du fichier (.ilk) est manquant (LINK crée un nouveau fichier .ilk en prévision des liaisons incrémentielles à venir).
MrSpock a écrit:QuoteEt le #define EDITANDCONTINUE n'est pas de moi. Ça doit être dans les .h d'Orbiter ou d'OrbiterSound35.C'est ce que je sous-entendais ...Je rejoins cet avis .QuoteL'état incrémentiel du fichier (.ilk) est manquant (LINK crée un nouveau fichier .ilk en prévision des liaisons incrémentielles à venir).Le coup de la version .ilk.8.0 générée par un .ilk.5.0 manquant ? j'en reviens pas !Politique Microsoft ... Tu as une trace de VC++ 2008 dans ta base de registre peut-être ?Etonnant ... De prévoir les fichiers de Link de la version suivante !Spock .
private: void DefineAnimations (); bool ToggleGrapple (int grapple); double payload_mass; void ComputePayloadMass(); ATTACHMENTHANDLE payload_attachment[6];.......
est-ce que c'est vraiment avantageux ?
double payload_mass;
Les fontions/variables déclarées à l'extérieur de la classe sont globalesQuoteOui ! et ne sont initialisées qu'une fois par session, peut importe combien il y a de vaisseaux.
Oui !
Les méthodes/attributs déclarés à l'intérieur d'une classe sous l'étiquette public: sont créés pour chaques vaisseaux. Ils seront disponibles à Orbiter. Donc, Orbiter pourra voir et modifier ces méthodes/attributs.
-Les méthodes/attributs déclarés à l'intérieur d'une classe sous l'étiquette private: sont créés pour chaques vaisseaux.
Ils seront indisponibles à Orbiter.
Donc, Orbiter ne les verras pas et ne pourra pas les modifier.
Par contre, les méthodes/attributs à l'intérieur de la classe pourront les voir et les modifier.
L'encapsulation permet de faire abstraction du fonctionnement interne (c'est-à-dire, la mise en œuvre) d'une classe et ainsi de ne se préoccuper que des services rendus par celle-ci. C++ met en œuvre l'encapsulation en permettant de déclarer les membres d'une classe avec le mot réservé public, private ou protected. Ainsi, lorsqu'un membre est déclaré :public, il sera accessible depuis n'importe quelle fonction.private, il sera uniquement accessible d'une part, depuis les fonctions qui sont membres de la classe et, d'autre part, depuis les fonctions autorisées explicitement par la classe (par l'intermédiaire du mot réservé friend).protected, il aura les mêmes restrictions que s'il était déclaré private, mais il sera en revanche accessible par les classes filles.C++ n'impose pas l'encapsulation des membres dans leurs classes. On pourrait donc déclarer tous les membres publics, mais en perdant une partie des bénéfices apportés par la programmation orientée objet.
Il est de bon usage de déclarer toutes les données privées, ou au moins protégées, et de rendre publiques les méthodes agissant sur ces données. Ceci permet de cacher les détails de la mise en œuvre de la classe[/b].
Je veux créer un trottle (manette des gaz) dont les extrémités sont rondes plutôt d'être carré
Comme je sais qu'on peut définier une couleur d'invisibilitée dans Orbiter, j'ai choisi le blanc pûr (comme les exemples de Martin)
/// \defgroup bltflag Bit flags for blitting operations/// @{#define BLT_SRCCOLORKEY 0x1 ///< Use source surface colour key for transparency#define BLT_TGTCOLORKEY 0x2 ///< Use target surface colour key for transparency/// @}
/** * \brief Set transparency colour key for a surface. * \param surf surface handle * \param ckey transparency colour key value * \default None, returns false. * \note Derived classes should overload this method if the renderer * supports colour key transparency for surfaces. */ virtual bool clbkSetSurfaceColourKey (SURFHANDLE surf, DWORD ckey) { return false; }
/** * \brief Create an offscreen surface from a bitmap * \param hBmp bitmap handle * \return surface handle, or NULL to indicate failure * \default Creates a surface of the same size as the bitmap, and * uses clbkCopyBitmap to copy the bitmap over. * \note The reference counter for the new surface is set to 1. * \sa clbkIncrSurfaceRef, clbkReleaseSurface */ virtual SURFHANDLE clbkCreateSurface (HBITMAP hBmp);
Author
Topic: Mes questions sur VC++ 2005 (Read 23810 times)
Search
Login
Register