yang686526

dd2.1.0 can't support wchar filename,it leads to a crash
dd2.1.0 can't support wchar filename,it leads to a crash
i rebuilded my old progam at dd2.1.0 and run it. i found the files with chinese name could't be open, and the program crashed in a sentence in "\dd_nonlibs\extensions\exservices\odfilebuf.c pp" :
{
m_sfilename = sfilename;
}
m_sfilename and sfilename are odstring objects.
if it was be build at dd1.13 will be ok.
what is sfilename?, what is the current locale? is your program unicode or not?
vladimir
dd2.1.0 can't support wchar filename,it leads to a crash
hi wvk,
the part code is that:
code:
#ifdef dd_unicode
odstring sfilename = wszfilename;
#else
odstring sfilename = odwidechartostring((lpcwstr)wszfilename);
#endif //dd_unicode
m_hfile = ::createfilew(wszfilename, dwaccess, dwshare, null, dwdisposition, dwattr, null);
if( m_hfile == invalid_handle_value )
{
oda_trace1(dd_t("open() can't open file, getlasterror = %x"), ::getlasterror());
throw oderror_fileexception(ecantopenfile, sfilename);
}
else
{
m_sfilename = sfilename;
m_ifileshare = nsharemode;
}
sorry i made a mistake, the crash happened on "throw oderror_fileexception(ecantopenfile, sfilename);",not on the lines under it.-_-|
wszfilename is also a odstring variable, it's a function param transformed from "lpszpathname" of cdocument:nopendocument(lpctstr lpszpathname). my program isn't unicode, and thanks for your remind, i found a "dd_unicode" defined in odadefs.h in dd2.1.0 but not in dd1.13.
don't you think it's new vision's bug? because the program worked good with the old version.
step through the code, see how the string is converted. dump unicode string passed to createfilew.
try to build odamfcappdll "debug - non unicode" configuration, see if it works.
vladimir
i built odamfcappdll but it couldn't run. there was a error report that says can't find program entry reverseparam.... on dd_ge.dll. so i built odamfcapp "debug - non unicode" instead. it ran but when i open "e:\文字.dwg", it report:can't open file "e:\". step in and found the value in odstring's unitcodebuffer is just "e:\". it looks like the odstring's converting process is not right.
possible it is bug with conversion to unicode with undefined codepage.
try to initialize odstring like
odstring filename ( "e:\\文字.dwg", cp_ansi_936 ); // string must be in mbcs coding
filename.getlenght(); // force conversion to unicode
and see unicodebuffer of odstring.
best regards,
sergey z.
thanks, after forcing conversion, the program can open files with chinese name now. hope the bug can be resolved in next dd version.
last edited by willasw; 22nd november 2006 at 09:16 pmfff">.