játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5471
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2525

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2194
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] > 90 < [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [142]
AmidaBucu - Tag | 281 hsz       Online status #83037   2008.03.11 08:53 GMT+1 óra  
OKok. Most meg hiába inkludolom csak a h-kat, ugy csinál mintha nem léteznének cpp, és mikor egy osztály tagvügvényét használnám akkor bedob linker hibát
Ami tönkremehet, az tönkre is megy!!!
   
Kristf - Törzstag | 125 hsz       Online status #83032   2008.03.11 07:31 GMT+1 óra  
Idézet
AmidaBucu :
Hi! Nem tudjátok, mit kell átállítani, ahoz hogy ne kössön belém a fordító, ha
Kód:
/////1.h
#include"2.h"
#include"3.cpp"

/////2.h

class akarmi;

/////2.cpp
#include"2.h"
[akarmi fügvényeinek definiálása]

/////3.cpp
akarmi bigyo;
bigyo.fugveny();///ittt


A lényeg az hogy 3.cppben nem használja a fordító a 2.cpp cuccait és linker hibát dob;
Ha a 3.cppben inkludolom a 2.h,akkar, redefinition ba köt bele;



Ebben több hiba i van: először is nem szabad cpp-t include-olni. A másik, hogy érdemes a header fileokban az elejére beírni hogy
#ifndef VALAMI
#define VALAMI
//változók, fv-ek..
#endif
így max 1-szer tudod beilleszteni.

Ha változót több modulban szeretnéd használi, akkor headerben extern tipus valtozonev; -el adod meg, utána egy modulba beírod a definiciót is, hogy tipus valtozonev.

   
AmidaBucu - Tag | 281 hsz       Online status #83028   2008.03.11 06:49 GMT+1 óra  
Hi! Nem tudjátok, mit kell átállítani, ahoz hogy ne kössön belém a fordító, ha
Kód:
/////1.h
#include"2.h"
#include"3.cpp"

/////2.h

class akarmi;

/////2.cpp
#include"2.h"
[akarmi fügvényeinek definiálása]

/////3.cpp
akarmi bigyo;
bigyo.fugveny();///ittt


A lényeg az hogy 3.cppben nem használja a fordító a 2.cpp cuccait és linker hibát dob;
Ha a 3.cppben inkludolom a 2.h,akkar, redefinition ba köt bele;
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82794   2008.03.06 11:27 GMT+1 óra  
THX
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5471 hsz       Online status #82792   2008.03.06 10:15 GMT+1 óra  
ha egy almám van és három körtét megeszek akkor hány barackom van?

Kód:
LRESULT WINAPI WndProc(HWND hWnd, unsigned int msg, WPARAM wParam, LPARAM lParam);

typedef LRESULT (WINAPI *WindProc)(HWND hWnd, unsigned int msg, WPARAM wParam, LPARAM lParam);

WindProc wndproc = &WndProc;

Ezt a hozzászólást Asylum módosította (2008.03.06 10:23 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82791   2008.03.06 10:10 GMT+1 óra  
okok.
Jah, hadd kérdezzeg még vmit.
Kód:
HRESULT WindowProc (HWND IN_hwnd, UINT IN_msg, WPARAM IN_wparam, LPARAM IN_lparam)
fügvényre mutató pointer a
Kód:
HRESULT ( *WindowProc )(HWND IN_hwnd, UINT IN_msg, WPARAM IN_wparam, LPARAM IN_lparam)

akkor a
Kód:
HRESULT CALLBACK WindowProc (HWND IN_hwnd, UINT IN_msg, WPARAM IN_wparam, LPARAM IN_lparam)
fügvényre mutató pointer hogyan néz ki?
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5471 hsz       Online status #82789   2008.03.06 09:39 GMT+1 óra  
öö ezt igy lehet ? arra gondolok, hogy tömböt meg lehet indexelni...erröl még nem tudtam...
probáld ki egy teszt ben hogy mivan akkor ha a tömböket adod át egyben SetVectorArray() -al meg stb vel.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82787   2008.03.06 07:54 GMT+1 óra  
Nem azt mondtam hogy az a fügvény rossz csak rossz pointert ad: Nem ugy értettem hogy alapból hanem, hogy aktuálisan. Jah azt is ésszerünek tartottam, hogy vmit én rontottam el. Azthittem ez kiveheteő.

Ezt a hozzászólást AmidaBucu módosította (2008.03.06 08:12 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
Orphy - Törzstag | 1893 hsz       Online status #82784   2008.03.06 07:32 GMT+1 óra  
Idézet
AmidaBucu :
Debugmodban is ránéztem, és arra jutottam hoghy ez a fügvény vmiért rosz pointer címet add.
(magyarul nem jutottam semmire )



Ebben azért nem lennék ennyire biztos a helyedben...
Bocs, de valószínűbb, hogy valamit valahol rosszul csinálsz. Elég sokan használják a DX-nek ezt a részét ahhoz, hogy feltűnjön, és kijavítsák, ha nem jó. Továbbá az ezt bemutató SDK-s sample is működik.

Én a helyedben ránéznék a többi pointerre is. (Bár nem tudom, pontosan mit értettél pointer hiba alatt)
Azt is érdemes lehet megnézni, hogy pontosan mikor lehet használni ezeket a függvényeket (pl effekt.begin(), effekt.end() között kell lennie, stb)
   
AmidaBucu - Tag | 281 hsz       Online status #82783   2008.03.06 07:20 GMT+1 óra  
Kód:
Effects[0].EEffect->BeginParameterBlock();
for(int i = 0; i < min(MPPL, Lights.size()); i++)
{
itoa(i, t,10);
Effects[0].EEffect->SetValue(SMerge(SMerge("LightDistance[", t),"]"),&distance[i], num);

Effects[0].EEffect->SetValue(SMerge(SMerge("LightPower[", t),"]"),&Lights[i].Power, num);

Effects[0].EEffect->SetValue(SMerge(SMerge("LightSpecular[", t),"]"),&Lights[i].Specular, num);

Effects[0].EEffect->SetValue(SMerge(SMerge("LightPos[", t),"]"),&Lights[i].xyz, num);

Effects[0].EEffect->SetValue(SMerge(SMerge("LightDiffuse[", t),"]"),&Lights[i].Diffuse, num);
}
D3DXHANDLE temphandle = Effects[0].EEffect->EndParameterBlock();

Debugmodban is ránéztem, és arra jutottam hoghy ez a fügvény vmiért rosz pointer címet add.
(magyarul nem jutottam semmire )
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82781   2008.03.06 07:17 GMT+1 óra  
Jajajaja, én is igy csináltam
Ami tönkremehet, az tönkre is megy!!!
   
Orphy - Törzstag | 1893 hsz       Online status #82753   2008.03.05 14:07 GMT+1 óra  
Next, the sample creates a parameter block that contains the effect parameters. This is done by first calling BeginParameterBlock. This call indicates to the effect object that it should record all subsequent set calls, until EndParameterBlock is called. When EndParameterBlock is called, the effect returns a D3DXHANDLE for the parameter block. From this point on, when the parameter block is applied (with ApplyParameterBlock), the effect looks at the parameters inside the block, and sets the values for each of the parameters. The result is as if the application called this series of set methods. For instance, if an effect has two float4 parameters called Diffuse and Specular, a parameter block can be created to include these two parameters like this:

Kód:
D3DXVECTOR4 vDiffuse;
D3DXVECTOR4
    vSpecular;
D3DXHANDLE  hBlock;

// Initialize vDiffuse and
    vSpecular

pEffect->BeginParameterBlock();
pEffect->SetVector(
    "Diffuse", &vDiffuse );
pEffect->SetVector( "Specular",
    &vSpecular );
hBlock = pEffect->EndParameterBlock();

After this code is run, hBlock contains two parameters, Diffuse and Specular, and the recorded value of vDiffuse and vSpecular. Now, whenever the application does this:

// Apply the parameter
    block

pEffect->ApplyParameterBlock(hBlock);


The result is equivalent to the following, assuming vDiffuse and vSpecular still have the correct values:

Kód:
pEffect->SetVector( "Diffuse", &vDiffuse
    );
pEffect->SetVector( "Specular", &vSpecular );


http://www.paradoxalpress.info/Docs/dx9_out/EffectParam_Sample.htm
   
Asylum - Törzstag | 5471 hsz       Online status #82745   2008.03.05 11:53 GMT+1 óra  
hát ugye ez most egy karaktertömbre mutató pointert ad vissza, kérdés, hogy ezt hogyan probálod feldolgozni...nekem spec. nem világos, hogy mi mert msdn azt irja hogy a paraméterek állapotaira mutató pointert ad vissza

Returns a handle to the parameter state block.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82735   2008.03.05 09:02 GMT+1 óra  
Nah próbáltam ugy ahogy mondtátok:
Kód:
D3DXHANDLE handle;

[...]

handle = Effects[0].EEffect->EndParameterBlock();

de ahogy ez a sor lefut Rosz pointer lesz a handle. Talán az endparameterblock és a beginparameterblock között valamit csunyán csináltam?

Ezt a hozzászólást AmidaBucu módosította (2008.03.05 10:54 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82734   2008.03.05 08:59 GMT+1 óra  
Mondom hogy bocsi! Csak sulivolt, azé vok ilyen.
Ami tönkremehet, az tönkre is megy!!!
   
beast - Törzstag | 1241 hsz       Online status #82733   2008.03.05 08:24 GMT+1 óra  
Azt hiszem, ezek után innen ne várj segitséget...

   
AmidaBucu - Tag | 281 hsz       Online status #82732   2008.03.05 08:14 GMT+1 óra  
BOCSIIIIIIi hoszzu napom volt, hülye suli után már mindenen megsértődők, minden negatív megjegyzést komolyan veszek ( mondjuk lehet hoghy komoly is volt )
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #82728   2008.03.05 07:58 GMT+1 óra  
[bunkó megjegyzés]

Tisztelet a kivételért. Bocsánat az offért. Köszönet a válaszokért.

Ezt a hozzászólást AmidaBucu módosította (2008.03.05 09:00 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5471 hsz       Online status #82723   2008.03.05 07:08 GMT+1 óra  
van értelme, 4 karakternek
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82722   2008.03.05 06:58 GMT+1 óra  
Idézet
AmidaBucu :
Hi!
Pointer problémám lenne.
Van egy
Kód:
D3DXHANDLE* handle;
handle = (D3DXHANDLE*)malloc(sizeof(LPCSTR));

pointerem;
Megvan cimezve rendesen, de amikor itt tarta program:
Kód:
[...]
handle[0] = Effects[0].EEffect->EndParameterBlock();

Tönkre megy a pointer. Próbálkoztam mindennel de nem tom megcsinálni.
Vmi ötlet hogy lehet?



Az EndParameterBlock() függvény definíciója így néz ki:
D3DXHANDLE EndParameterBlock();

Úgy látom, csinálsz egy handle-t, aminek aztán LPCSTR méretű memóriát foglalsz (LPCSTR = const char*, ergó pointer típus).
Aztán ebbe D3DXHANDLE-t próbálsz beleerőltetni. Értelme semmi.
Csináld így:

Kód:
D3DXHANDLE handle;

[...]

handle = Effects[0].EEffect->EndParameterBlock();
   
Asylum - Törzstag | 5471 hsz       Online status #82721   2008.03.05 06:56 GMT+1 óra  
na vajon mért

#define LPCSTR const char*

ami 4 bájt és pointer típus..

wtoma válasza sem jó mert az ugyanazt csinálja
helyesen:

D3DXHANDLE* alma = (D3DXHANDLE*)malloc(valami * sizeof(char));
ahol valami a szöveg hossza + 1 (stringvége karakter)

amugy biztos vagy te ebben a dx ben?

Ezt a hozzászólást Asylum módosította (2008.03.05 07:07 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82720   2008.03.05 06:30 GMT+1 óra  
Nah, valaki tudna segíteni az előző kérdésemmel kapcsolatban? A pointer problémában?
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5471 hsz       Online status #82589   2008.03.02 09:30 GMT+1 óra  
Idézet
Orphy :
Megvan a megoldás, elég tanulságos lehet azoknak, akik hozzám hasonlóan C# alól érkeztek:

Ha egy C++ progit dll-be, vagy static library-be fordítunk, akkor a kötelezően mellékelt header file-nak tartalmaznia kell a private részeket is...



ezért szoktak inkább interfaceket csinálni és igy csak azok a headerek, minden más számraztatással történik
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #82584   2008.03.02 07:19 GMT+1 óra  
Idézet
Nem vagyok benne a DX-ben, de nekem logikusnak tűnne D3DXHANDLE típusú ptr-nek D3DXHANDLE méretet foglalni


Mindegy mer D3DXHANDLE végüis LPCSTR típus csak más néven. Any Idea?
Ami tönkremehet, az tönkre is megy!!!
   
Orphy - Törzstag | 1893 hsz       Online status #82583   2008.03.02 06:58 GMT+1 óra  
Megvan a megoldás, elég tanulságos lehet azoknak, akik hozzám hasonlóan C# alól érkeztek:

Ha egy C++ progit dll-be, vagy static library-be fordítunk, akkor a kötelezően mellékelt header file-nak tartalmaznia kell a private részeket is...
   
Orphy - Törzstag | 1893 hsz       Online status #82577   2008.03.02 05:00 GMT+1 óra  
hmm, megpróbáltam sima static library-ként is, de ugyanaz a hiba:
úgy tűnik, mintha a tömböket, és std-s osztályokat valamiért teljesen rosszul kezelné lib-ből...
   
Orphy - Törzstag | 1893 hsz       Online status #82570   2008.03.02 02:48 GMT+1 óra  
Van egy eléggé idegesítő problémám:

A framework-ömet szeretném dll-esíteni.
A megfelelő osztályokhoz betettem a __declspec(dllexport) sorokat, átállítottam a projektet dll-re, le is fordult hiba nélkül, megkaptam a dll-t, és a lib-et.

A probléma akkor van, ha használni is szeretném:
megcsináltam az import interfészt, a megfelelő osztályok .h-ja van benne namespace-estől, de csak a függvénydefiníciókkal, és __declspec(dllimport)-tal az osztálydefiníció előtt.

Eddig is ok.
A main.cpp-ben is ok a kód, szépen le is fordul.
Aztán amikor tesztelném, akkor kapok egy access violation writing location error-t az arcomba, ha pl egy olyan osztályt példányosítok, ami konstruktorban default értékekkel tölti fel magát.
Ha pl static függvényt hívok egy osztályból, ami nem nyúlkál ilyenekhez, az megy.

Az osztályok nem hibásak, működnek, a hiba biztosan a dll-esítéssel függ össze!
Találkozott már valaki ilyennel?
   
WToma - Szerkesztő | 635 hsz       Online status #82567   2008.03.02 01:35 GMT+1 óra  
Nem vagyok benne a DX-ben, de nekem logikusnak tűnne D3DXHANDLE típusú ptr-nek D3DXHANDLE méretet foglalni
Kód:
D3DXHANDLE* handle;
handle = (D3DXHANDLE*)malloc(sizeof(D3DXHANDLE));


(az LPCSTR egy pointer típus, ha jól értem a google találatokat...)
Ez nem bug, hanem feature!
http://sohivatal.uw.hu
   
AmidaBucu - Tag | 281 hsz       Online status #82566   2008.03.02 01:01 GMT+1 óra  
Hi!
Pointer problémám lenne.
Van egy
Kód:
D3DXHANDLE* handle;
handle = (D3DXHANDLE*)malloc(sizeof(LPCSTR));

pointerem;
Megvan cimezve rendesen, de amikor itt tarta program:
Kód:
[...]
handle[0] = Effects[0].EEffect->EndParameterBlock();

Tönkre megy a pointer. Próbálkoztam mindennel de nem tom megcsinálni.
Vmi ötlet hogy lehet?
Ami tönkremehet, az tönkre is megy!!!
   
WToma - Szerkesztő | 635 hsz       Online status #82457   2008.02.28 09:08 GMT+1 óra  
Ellenben ha érvényes objektumra mutat, akkor a (2005-össel kezdődően már biztosan) a VS debugger meg tudja mutatni, hogy mi is van az objektumban. Hasznos még az expression kiértékelés, azzal is lehet ellenőrizni dolgokat.
Ez nem bug, hanem feature!
http://sohivatal.uw.hu
   
fpeti - Törzstag | 1295 hsz       Online status #82414   2008.02.27 12:33 GMT+1 óra  
Megpróbálhatod, hogy nyomsz egy F5-t (elindul a debug), fontos, hogy ne legyen fullscreen a cucc, majd megmutatja azt a sort, ahol kifagy. Ha ott van vmi pointerkedés, akkor megnézheteted akár csak egérrámutatással, hogy hátha vmelyik 0-ra mutat (vagy a 0xCCCCCC...érték is lehet hiba - not iniced kb.).
Ha itt nincs, és ez mondjuk egy class vmelyik függvényében van, akkor valszeg valahol van egy pointer aminek a típusa ez az osztály, de rossz címre mutat. Nekem sokszor így van.

(bocs a fogalmazásért, épp most ettem )
   
Orphy - Törzstag | 1893 hsz       Online status #82406   2008.02.27 11:34 GMT+1 óra  
Ha access violation, akkor az egyik pointered nem ok.

Elképzelhető, hogy létrehozáskor, vagy törlés után nem incializáltad NULL-ra (és ilyenkor az if(pointer) ellenőrzések sem segítenek), esetleg egy függvény valami hiba miatt NULL pointert ad vissza, és ezt nem vizsgáltad meg...

Debugolj ezerrel, ilyenkor az segít a legtöbbet!
   
ibax - Tag | 154 hsz       Online status #82404   2008.02.27 10:46 GMT+1 óra  
közelebbit sajna nem, access violation error hiba, de sajna nemtok rájönni...
   
Asylum - Törzstag | 5471 hsz       Online status #82387   2008.02.27 06:56 GMT+1 óra  
ja arra ondoltm nálam mindkettő fagyásnak számit
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82377   2008.02.27 04:36 GMT+1 óra  
Igaz, pointerek is okozhatják.

Mondjuk nálam pointer miatt még soha nem fagyott ki semmi, maximum kaptam egy access violation error-t, és szétszállt a progi. A kifagyásra szerintem általánosságban a végtelen ciklus valószínűbb.

Ibax, esetleg valami közelebbit tudsz mondani?
   
Asylum - Törzstag | 5471 hsz       Online status #82362   2008.02.27 02:53 GMT+1 óra  
általában pointerek okozzák
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Orphy - Törzstag | 1893 hsz       Online status #82353   2008.02.27 01:15 GMT+1 óra  
Az hogy a build successfull, az azt jelenti, hogy nincs a kódban olyan syntax hiba, illetve nem implementált fügvény, ami miatt nem lehetne a progit lefordítani.
Ez viszont nem jelenti azt, hogy a program jól is fog működni.

A debugolás úgy működik, hogy a program egy sora elé beteszed a piros pöttyöt - ekkor ha odaér a vezérlés, akkor a progid megáll, és az F10, F11 billekkel soronként tudod a kódot végrehajtani, vagy az F5-tel folytatni. Közben meg tudod nézegetni a változóidat.

Ennek előfeltétele, hogy a debughoz szükséges map file-t a Studio elkészítse, hogy debug módban fordíts, meg hasonlók. Szvsz a progid első sorára nézd meg, működik-e a debug, ha nem, akkor még be kell állítani valamit. Ha megy, akkor debugolhatsz.

A lefagyást általában végtelen ciklus okozza, érdemes megnézegetni a while és for ciklusokat.
   
ibax - Tag | 154 hsz       Online status #82352   2008.02.27 01:06 GMT+1 óra  
a debug-olásban tudna segíteni valaki (visual studio 2005).
c++ -os projektem van, és tudom, hogy a sor elejére egy KATT lerak egy piros pontot, ami azt jelzi (gondolom), hogy addig a pontig fusson a progi, és utána várjon felhasználói beavatkozásra a továbbfutáshoz (?).
sajnos elakadtam egy proginál, mert a build successfull, de a progi kifagy egy idő után, és így nehéz rájönnöm a hiba tényleges okára...
   
Asylum - Törzstag | 5471 hsz       Online status #82328   2008.02.26 12:59 GMT+1 óra  
vagy felveszed attribútumnak
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
WToma - Szerkesztő | 635 hsz       Online status #82312   2008.02.26 10:33 GMT+1 óra  
1) adogasd át szépen minden függvénynek. Ha nagy adatról van szó, akkor persze csak a címet
2) rakd be egy osztályba statikus változónak. Ekkor gyakorlatilag globálisként viselkedik, de legalább van egy hely, ahova logikailag tartozik (valamint elkerülhető a névütközés.)
Ez nem bug, hanem feature!
http://sohivatal.uw.hu
   
ibax - Tag | 154 hsz       Online status #82311   2008.02.26 10:30 GMT+1 óra  
és miért baj globális változókat használni? ha szükségem van olyan változókra, amiket több függvényben is használni fogok, felhasználok, akkor azt hogy oldjam meg globális változók nélkül?
   
Asylum - Törzstag | 5471 hsz       Online status #82274   2008.02.26 02:48 GMT+1 óra  
hát ha már nekiálltál az oop-nek akkor nemkéne globális változókat használi egyrészt...másrészt figyelni kell arra, hogy mi minek adsz értékül mert pointerek esetén a legeldugottabb hibától is az egész program hülyeséget csinál.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ibax - Tag | 154 hsz       Online status #82273   2008.02.26 02:32 GMT+1 óra  
hmm, ma megoldottam a problémát, egy kicsit másképp. ami mindenképp hiányzott, az a while ciklus if -jének else ágából a
Kód:
temp.nextRow();
sor, vagyis amikor a feltétel nem teljesült, és belementem az else ágba, attól kezdve végtelen ciklusra futottam. valamint kivettem a fgv negyedik paraméterét, és egy másik fgv-t írtam, ami egyszerüen átadja a globális patientID mutatónak a kapott char* mutatót.

aztán szépen lassan óvatosan a
Kód:
cout << patientID;
-t lecseréltem
Kód:
cout << patientID[0];
-ra, majd töröltem a sort, és most müxik

igazából máig se értem, mi lehetett a gond...
   
ibax - Tag | 154 hsz       Online status #82263   2008.02.25 15:21 GMT+1 óra  
a függvényen belül a negyedik paraméterként kapott mutató értékét átadom egy újonnan deklarált mutatónak, és annak segítségével vizsgálok a feltételben. mivel mindez egy fgv-en belül van, ezért ennek így müködnie kéne, nem?
függetlenül attól, hogy hol deklaráltam (vagy rosszul tudom?)

egyébként a header file-ok után deklaráltam, mielőtt elkezdtem volna kidolgozni az egyes függvényeket (az admin osztályom függvényeit; void admin::mainMenuDatas(), stb)
   
Asylum - Törzstag | 5471 hsz       Online status #82259   2008.02.25 13:50 GMT+1 óra  
hát de ebben amit beirtál én nem látok deklarációt
ugyérted, hogy ez egy member változó? ha igen mi képes megváltoztatni
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ibax - Tag | 154 hsz       Online status #82249   2008.02.25 10:32 GMT+1 óra  
és így hívom meg a main-ból a fgv-t:

Kód:
admin.mainMenuDatas(env,driver,device,tempbuf);


ahol tempbuf-nak lefoglaltam memterületet. így a tempbuf által lefoglalt területre mutat az előbb említett pid mutató is (ugye?)
   
ibax - Tag | 154 hsz       Online status #82248   2008.02.25 10:30 GMT+1 óra  
patientID-t még az összes fgv elején deklaráltam, hogy minden fgv használni tudja. igazából ebben tárolom az aktuálisan kijelölt ID-t, amit a pid-ben kapok meg (hogy esetleg más fgv is tudja, miről van szó). mivel mutatókról van szó, elég úgy, ahogy írtam. vagy nem???

bár tudom, ebben a fgv-ben máshol nem is használom
   
Asylum - Törzstag | 5471 hsz       Online status #82247   2008.02.25 10:21 GMT+1 óra  
Kód:
patientID = pid;


ez hol van deklarálva és mit müvel
mit is tanultunk ovodában a pointerekröl?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ibax - Tag | 154 hsz       Online status #82246   2008.02.25 10:19 GMT+1 óra  
a patientID = pid kell, mert máshol is felhasználom, más fgv-ekben...

az első cout kikommentezése után végtelen ciklust kapok, a második cout (while-ban) kikommentezése után kifagy a progi...

de ebben a formában müxik
   
ibax - Tag | 154 hsz       Online status #82244   2008.02.25 10:17 GMT+1 óra  
azt kihagytam, mert ennek így is teljesen müködnie kéne...

de ez a müködő verzió:
Kód:
void Admin::mainMenuDatas(IGUIEnvironment* env, IVideoDriver* driver, IrrlichtDevice* dev,char* pid)
{
cout << pid;
patientID = pid;
int i;

b1 = env->addButton(rect<s32>(275, 200, 403, 264),0,6003); // gomb
b1->setImage(driver->getTexture("buttons/bUsePatient.jpg"),rect<s32>(0, 0, 128, 64));
b1->setToolTipText(L"Use selected patient");

b2 = env->addButton(rect<s32>(510, 200, 638, 264),0,6003); // gomb
b2->setImage(driver->getTexture("buttons/bDetails.jpg"),rect<s32>(0, 0, 128, 64));
b2->setToolTipText(L"View patient's details");

name = env->addStaticText(L"Name:",rect<s32>(270,70,420,92),0,0,0,-1);
date = env->addStaticText(L"Date of birth:",rect<s32>(270,110,420,132),0,0,0,-1);
id = env->addStaticText(L"ID:",rect<s32>(270,150,420,172),0,0,0,-1);

namebox = env->addEditBox(L"",rect<s32>(460,68,688,94),1,0,-1);
datebox = env->addEditBox(L"",rect<s32>(460,108,688,134),1,0,-1);
idbox = env->addEditBox(L"",rect<s32>(460,148,688,174),1,0,-1);

db.open(dbFile);

CppSQLiteQuery temp = db.execQuery("SELECT * FROM patients;");

const char* buf;
wchar_t* wbuf;

char* var = new char[20];
sprintf(var,pid);

while(!temp.eof())
{
cout << "pid " << pid;
if (strcmp(var,temp.fieldValue("personalID"))  &&  !temp.eof())
{
temp.nextRow();
}
else
{
buf = getSelectedListItem();
mbstowcs(wbuf,buf,52);
namebox->setText(wbuf);


buf = temp.fieldValue("year");
mbstowcs(wbuf,buf,5);
datebox->setText(wbuf);

buf = temp.fieldValue("personalID");
mbstowcs(wbuf,buf,20);
idbox->setText(wbuf);
}
}
temp.finalize();
db.close();
}


csak akkor müxik az egész, ha az elején,és a while ciklusban is kiíratom a "pid" értékét, valamint a if feltételébe nem konrkétan a pid-et ellenőrzöm, hanem egy olyan változót, amibe beleírtam előtte a "pid"-et (var változó)

nagyon kókány és beteges megoldás, de csak így müxik a progi...
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [85] > 90 < [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [142]