only the developers can say for sure, but one of the new 'features' listed for alpha 5 was support of unicode.


findit was having a unicode conversion problem if one box was left blank (no 1-15 value inserted) once any number was stuck in the box crashes stopped.


SO, maybe somewhere stuck in old code is something about dashs that isn't now handled properly via the unicode. would assume as well as they test it isn't the case, but it could be a 1 in million oddball problem yes.

 

-----signature-----

No, Gouru's problem was all in his own code. He was passing a null _bstr_t (a wrapped BSTR) to a conversion routine, which was causing an access violation exception. As the _bstr_t wrapper class automatically handled a wchar_t* to char* to conversion, his code worked when the textbox was filled in and atol didn't choke, though wcstol is a better choice as it does not require an conversion. The Decal internal conversion towards Unicode had absolutely nothing to do with it; as Decal is a COM/OLE Automation based API, all strings are passed as BSTRs -- and all string BSTRs are wide characters. The external API did not change one bit.


The distinction between wide characters (int16/c++ type "short" and Unicode is slim at best, but in any case, it had absolutely nothing to do with this bug.


Thanks for playing, and try again sometime.

 

-----signature-----