We have received at least 5 bugs for WorldEditor that seem to have similar characteristics
- Inexplicable crash to desktop with no error message
- Happening on Windows 10, not reproduceable on Windows 7, Linux, or WINE
- Happens shortly after using the Truck Destination tool
Windows Tool Tips and You
Tool tips are those little pop ups that appear when you hover your mouse over UI elements. Sometimes their text includes helpful tips, sometimes they include data; it is whatever we program them to have.
The code to do that is located in xptools\src\GUI\GUI_Window.cpp:1252-1272. Windows passes a message to WED saying the user has hovered over some UI element, we hand over some text to a data structure (NMTTDISPINFO), Windows uses the data to display the tool tip.
Look at line 1272. This is the line that does the copying our tip string into the szText for Windows to display.
//wcs = wide-char-string = Unicode string, cpy means copy, _s means "more secure" version of the function wcscpy_s( di->szText, //The data in here will show up in 80, //Our stupid magical number convert_str_to_utf16(tip).c_str() //convert our UTF-8 string to UTF-16 to please Bill Gates );
This line was the source of the crashes.
What’s so special about the number 80 and “_s”?
Window’s gives you a free “no-work” string, szText, for your tool tip text that is 80 characters long. If you want a longer tool tip, you’ll have to do a bunch of (not well documented) work.
What makes this a “secure” string function is it immediately ends the program if you attempt to copy more than the specified 80 characters into the new string. This information is overwhelmingly under-documented. In addition, the crash doesn’t included any information about the cause, even in debug mode!
How did this go on for so long without getting caught?
Amazingly, we’ve never really had this be a problem, or previous versions of Windows have had this function not crash. One reason why this is now getting reported is due to the Truck Destination tool’s Truck Types property. When you add up enough of those strings and hover your mouse over them, it quickly ends up being much longer than 80 characters.
"Baggage Loader" + "Baggage Train" + "Fuel Truck (Jets)" + ""Fuel Truck (Liners)" + "Fuel Truck (Props)" = 81 characters in total.
- It is also possible we’ve just been getting lucky with our memory, always having strings getting corrupted exactly just right.
- It is also possible that all our data is short, with abbreviations being so common in aviation, its normally hard to reach more than 80 characters.
- Maybe no one reported a bug (please report your problems so we can fix them!)
Please comment if you have some ideas of why this doesn’t seem to happen on Windows 7, but does on Windows 10. Maybe this “secure” function isn’t as secure as we all think it is.
The solution: truncation!
Our easy fix for this is to chop a string off at 77 characters and append a “…” at the end. Hopefully no-one will mind this.
This new fix will soon make it into a beta and a release. Until then we have this nightly build available.
Thanks to a video sent in by a user, this was a pretty easy WED bug to find and solve. The hard part was weeding through all the bug reports that seemed shrouded in unrelated but related mystery. No one was realizing their most trusted friend, the mouse and common tool-tip, were causing the problem.
Thank you for your patience as always as we try our best to make WED the best we can, and thank you to the people who report their problems instead of suffering through it, making a work around, or assuming their simply doing it wrong: You make the product better for everyone, including the developers!