Hozzászólások
-
Bejegyzés
-
Ha nem babraltal bele semmit, nincs csok ertelme, hogy ujratedd, mert nem fog valtozni a helyzet. Ha ennyire kiakad az X inditasanal, inditsd eloszor konzolos modban, es nezd meg a logokban, hogy mi tortent.
Velem is megesett hasonlo mepis 3.3 alatt, akkor az tortent, hogy a konzolos felbontas 80×25 volt, de az mc ennel tobbnek hitte a szelesseget, es emiatt elkezdett szemetelni a kepernyore (ha egyik oszlopban setaltagattam a fajlok kozott, felulirta a kozepso vonalat, aztan ha a masikban, akkor beleirt az elotte odarajzolt kozepso vonalba). Megoldast nem talaltam, ezert engem is erdekel a dolog.
Nekem ezt ujra kellett forgatnom, mert nem volt libstdc++.so.6-om a rendszerben 🙁 (uhu 1.2). Hu, azert nagy lett ez a program. Delphi-ben lehet ilyet ~60k-s forrasmerettel elerni. A piros gomb ki-be kacsolgatasa nem egy bug, hanem egy feature 🙂 😛
Kiprobaltam, hogy mire helyettesitodik be ez a makro. Gyakorlatilag
Code:_T(„valami”)helyett
Code:L”valami”jelenik meg a forrasban (ez ugy probaltam ki, hogy csak a preprocesszort engedtem ra a forrasra 😉
Igy van ertelmezve:
Code:// —————————————————————————-
// define _T() and related macros
// —————————————————————————-// BSD systems define _T() to be something different in ctype.h, override it
#if defined(__FreeBSD__) || defined(__DARWIN__)
#include
#undef _T
#endif// could already be defined by tchar.h (it’s quasi standard)
#ifndef _T
#if !wxUSE_UNICODE
#define _T(x) x
#else // Unicode
#define _T(x) L ## x
#endif // ASCII/Unicode
#endif // !defined(_T)// although global macros with such names are normally bad, we want to have
// another name for _T() which should be used to avoid confusion between _T()
// and _() in wxWindows sources
#define wxT(x) _T(x)Megyek meg dokumentaciot olvasni, mert leszedtem egy masik peldaprogramot, ami mar mukodott. Ebbol kilestem, hogy hogyan kell a karakterlancokat helyesen hasznalni wxWidgetsel. Tehat a sima
Code:„karakterlanc”helyett mindenutt
Code:_T(„karakterlanc”)-ot kell hasznalni. Hogy miert, pontosan nem tudom, de ugy mukodik
Ezzel mind egyetertek. A nagyon nagy gondom az, hogy ezt a programot egy az egyben egy wxwidgetes oldalrol szerdem le, mint a „Hello world” program wxwidgetben. Es mint irtam, uhu 1.2 alatt siman lefordul, uhu 2.0 alatt mar nem (hanem azt a fura hibat produkalja). Ezert vagyok egy kicsit megakadva rajta, hogy nem megy. (Ha en irtam volna, akkor magamban keresnem a hibat — habar nem kizart, hogy most is tennem van)
Ugy tunik, a problema nem ilyen egyszeru. Vagyis probaltam mar minenfele cast-operatorral, de nem jutottam sokra. Ha sima wxChar-ra castolotm a karakterlancokat (tudom, nem mukodokepes), DE akkor lefordul a program, viszont a karakterlancok helyen egy rakas kerdojel jelenik meg. Erdekes modon nem segfaultol el.
Kozben utananeztem, hogy mi is van a megadott helyeken a string.h-ban. A kovetkezo constructorok kozott nem tud valasztani a fordito:633:
// these methods are not implemented – there is _no_ conversion from int to
// string, you’re doing something wrong if the compiler wants to call it!
//
// try `s << i' or `s.Printf("%d", i)' instead
wxString(int);644:
// string containing nRepeat copies of ch
wxString(wxChar ch, size_t nRepeat = 1)
: wxStringBase(nRepeat, ch) { }Elolvasva a megjegyzest az elsohoz, a problema egyre furcsabbnak tunik. ???
Nezd meg a kepek URL-jet, peldaul: http://web.t-online.hu/bepe1979/Bepe-GTR2-2006-09-22-00-12-21-51.jpg
Na, onnan tuntek el a kepeid. :-csatolok egy igen konkret kimenetet. (lehet, hogy a sorok szama az elozo csatolt allomannyal nem fog pontosan egyezni)
legutóbbi hsz