DirectInput og Dev-C++

Hvis du skriver #include <din.h>
så prøv istedet at skrive
#include \"dinput.h\"

ellers prøv at kigge de steder der er fejl.
linie
645
657
osv
måske kan du hitte ud af det ved at kigge der

Jeg skriver #include <dinput.h>, og er allerede ved at kigge på de linier...

Fejlene er begrænset til een, da alle linierne er ens - nemligt:
UINT_PTR    uAppData;
Det hjælper ikke mig meget, men jeg håber, at der er nogle kloge hoveder, der er klar over hvad der er tale om...

E)mil

Hvor er denne variabel defineret

UINT_PTR    uAppData;

prøv at ligge h filen sammen med cpp filen. Altså koden lægges i samme fil så man ikke behøver at include h filen. Hvis det virker så ved man at det er noget galt med include\'eringen hvis det ikke virker alligevel så ved man at det er ??? :-)

Det er 1000 linier!
Desuden kom filen jo med DirectX sdk\'en, så waffor skulle det system lige precist ikke virke med mig?!
Det giver altså ingen mening...

Nej det gør det mange gange ikke :-) men man må bare prøve mange mærkelige ting før at den lige pludselig er der..svært at sidde her på afstand og lige nøjagtig sige hva der er galt, sorry

UINT_PTR er af integer typen og er en 32/64 bits stor pointer.
UINT_PTR er garanteret til at være så stor som en pointer er (32/64)som i de fleste compilere.
Ligeledes er  UINT_pointeren unsigned, som indikere at den højest signifikante bit af en integer variable, presentere en data bit og ikke en fortegns bit. Ja, hvor vil jeg så hen med dette. Det kunne tænkes at de funktionaliteter fra directDraw.h er af ældre dato og kun repræsentere 16bit pointere?? Eller at de konventioner de har ikke taler indbyrdes..
Et skyd fra hoften, men prøv at kigge på dine pointer erklæringer, især den erklæret integer pointer uAppData....
(perfi:

hvor faen ved du det fra :)
(skal se godfather kl2200 på tvdk)

>>Perfi

Mig kun almindelig dødelig 2.g\'er - du sige hvad? *lol*

Det ville da være under ligt hvis ddraw.h og dinput.h ikke kan arbejde sammen, da de jo begge er fra samme sdk (8.0a), som jeg lige downloadede i forgårs fra ms\' hjemmeside...

Kunne det tænke sig, at der er problemer med compileren, der bruges af Dev-C++?
I så fald - how on earth får jeg det på ret køl?

E-)mil
http://eej.dk

emileej.
Ja, det er jo ikke godt at vide, men ifølge tilsvarende i Builderen, så referere pointeren til en funktion/erklæring som ligger i en DLL.(class) \"basetsd\". Selvom de begge kommer fra samme sdk, så skal man huske at _export alle DLL, h. filerne da man må formode at DLL\'erne er dynamisk bundet til funktionerne..Det er UINT_PTR funktionen de gør at du kan benytte forskellige pointer størrelser...Og den i sig selv er ikke part af dinput.h eller ddraw.h, men part af compileren.

perfi:

Aha! Det er nok der den ligger...
Sagen er nemligt den, at dll\'erne IKKE kunne anvendes med Dev-C++, der i stedet har sine egne erstatninger (libddraw.a og libdinput.a)...
Hvad kan jeg gøre ved det?

E-)mil

Det er jo det der er det godt ved DLL filer. Funktionerne i DLL\'erne, hvis de er skrvet rigtigt, kan benyttes af de fleste applikationer, med forbehold selvfølgelig.
Når man kalder en funktion fra en DLL fil, så skal man først funktionserklæring for funktionen, og derefter kan man kalde funktionen, ligesom man kalder en hvilken som helst funktion..
allá:
erklæringen: extern \"C\" import void uAppData(HWND);
Funktionskald: uAppData(Apllication->Handle);
Man skal også huske at inkludere DDL\'en, som man inkludere headere.
Det var en måde, måske....
Eller kan du finde ud af hvad den (uAppData;) funktion gør i programmet, og se om der ikke er en tilsvarende i libddraw.a ell. libdinput.a, eller om det er nødvændigt at access den ved direkte adresse erklæring (pointeren)...
I sidste instans, skrive en funktion selv..men det er for de langhåret..
Perfi:

Sorry - nu vrøvler jeg - det er .lib filerne, der ikke funker, så jeg i stedet må bruge .a filerne...

OK, min vurdering er at du benytter den funktioner der ligger i .a filerne, nu når det virker, så må du se bort fra DLL\'erne. Hvis DLL\'erne er skrevet som statisk, ja så kan du \"NÆSTE\" ligeså godt benytte a.filerne istedet uden at tabet alt formeget i accesstider og memoryen, da inkluderet statiske DLL filer bliver compiled ved starten af applikationen, \"lidt\" ligesom inkluderet klasser og funktioner.
Jeg kan ikke løse dit problem med en kodestupm ud over det jeg har lagt op til, ....så good luck maté
Perfi:

Jeg har fået fat i et par gutter på GameDev.net, der (no offence) ved hvad de taler om :)
Tak for forslagene :)

- lukker og slukker -

E-)mil
http://eej.dk

OK emileej
No problemos.........

Perfi: