Bug in actor editor under Linux

[myconid]

zoot seems to have exposed a bug in the actor editor: when trying to choose the "anim name" in the animations dialog box, the combo box fails to store the value chosen. He found this while testing under Linux, and I have reproduced it under Linux. I'm assuming this does not occur under Windows.

The issue is in the file source/tools/atlas/AtlasUI/CustomControls/EditableListCtrl/QuickComboBox.cpp, in this method:

void QuickComboBox::OnKillFocus(wxFocusEvent& event)
{
	// We need to test whether there's actually a window receiving focus;
	// otherwise it tries to destroy the control while wx is focusing
	// on the text-input box, and everything crashes.
	if (event.GetWindow())
	{
		GetValidator()->TransferFromWindow();
		Destroy();
	}
}

It appears that under Linux, event.GetWindow() returns NULL so the control can't lose focus and as a result the validator never gets triggered and the value isn't stored. If I leave the if statement out, I don't get a crash like it's suggested in the comment, though that may not be the case on other platforms.

Isn't it better and safer if we just force the focus to the parent window instead? i.e.:

void QuickComboBox::OnKillFocus(wxFocusEvent& event)
{
	GetValidator()->TransferFromWindow();
	GetParent()->SetFocus();
	Destroy();
}

This solves zoot's bug, but does it work around the crashing issue?

Edit: This solution seems to mess it up in other ways. Sigh.

Edited June 29, 2012 by myconid

[zoot]

I guess I should try fixing this upstream, though I suppose the Windows functionality should suffice for now.

[historic_bruno]

Which version of wxWidgets?

[zoot]

Which version of wxWidgets?

I'm running 2.8.12.1-6ubuntu2.

[historic_bruno]

Don't suppose you could test how it goes with a newer (2.9.x) version of wxWidgets?

[zoot]

Sure!

[zoot]

Don't suppose you could test how it goes with a newer (2.9.x) version of wxWidgets?

That fixed it

[historic_bruno]

Wow, I really didn't expect it would and thought we might have to redesign the logic We still might, if lots of people are using wxGTK 2.8, but at least there's a workaround.

[zoot]

Well, it started segfaulting later, but yes, it's good to know that a fix at least exists in some abstract sense.

[historic_bruno]

Was it the same error you posted in the hdr/bloom/ao topic?

[zoot]

Yes.

[historic_bruno]

ERROR: DllLoader: dlopen(libAtlasUI.so) failed: libwx_gtk2u_gl-2.9.so.3: cannot open shared object file: No such file or directory; dlopen(libAtlasUI_dbg.so) failed: libAtlasUI_dbg.so: cannot open shared object file: No such file or directory;
TIMER| LoadDLL: 109.79 ms
Atlas.cpp(46): The Atlas UI was not successfully loaded and therefore cannot be started as requested.
The Atlas UI was not successfully loaded and therefore cannot be started as requested.
Location: Atlas.cpp:46 (ATLAS_Run)

Call stack:

(0x805fda) ./pyrogenesis() [0x805fda]
(0x7abd71) ./pyrogenesis() [0x7abd71]
(0x7aca4e) ./pyrogenesis() [0x7aca4e]
(0x58e0c1) ./pyrogenesis() [0x58e0c1]
(0x58e198) ./pyrogenesis() [0x58e198]
(0x41c977) ./pyrogenesis() [0x41c977]
(0x4135d7) ./pyrogenesis() [0x4135d7]
(0x7f158bef276d) /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f158bef276d]
(0x41c105) ./pyrogenesis() [0x41c105]

errno = 0 (No such file or directory)
OS error = ?


Aborted (core dumped)

At first glance that doesn't appear to be a wxGTK 2.9 problem. Did you have both 2.8 and 2.9 installed? Did you do a clean-workspaces.sh and clean build after upgrading?

ldd might be useful to see where libAtlasUI.so is expecting to find wxWidgets. The correct path should be injected by wx-config when Premake is run (update-workspaces.sh).

[zoot]

I did crudely do configure;make;make install on top of the previous installation. I don't know if that messes it up?

$ ldd libAtlasUI.so | grep libwx_gtk2u_gl-2.9.so.3
libwx_gtk2u_gl-2.9.so.3 => /usr/local/lib/libwx_gtk2u_gl-2.9.so.3 (0x00007f561d59d000)

Oddly, the file at that path does exist.

Edited July 1, 2012 by zoot

[historic_bruno]

/usr/local/lib seems like one of the standard search paths, it might end up there by default. The actual path of the wxGTK 2.9 libs should come from "wx-config --libs". But note that the absolute path typically gets built into wx-config (same as e.g. sdl-config), so if you move the libs after building, it will reference the old paths. I don't know if that happened, but just throwing it out there

[zoot]

$ wx-config --libs
-L/usr/local/lib -pthread   -lwx_gtk2u_xrc-2.9 -lwx_gtk2u_html-2.9 -lwx_gtk2u_qa-2.9 -lwx_gtk2u_adv-2.9 -lwx_gtk2u_core-2.9 -lwx_baseu_xml-2.9 -lwx_baseu_net-2.9 -lwx_baseu-2.9

libwx_gtk2u_gl-2.9 seems conspicously absent from that list?

(Note that I've 'reinstalled' 2.8 on top of 2.9)

Edited July 1, 2012 by zoot

[historic_bruno]

Oh, that could explain what happened You might not have built wxWidgets with the GL libs, I believe it's optional (--with-opengl to ./configure?). Actor Editor doesn't use the GL canvas so it would work, but Atlas needs the canvas to display the game view. I didn't think of that possibility. FWIW, the full command we use in extern4_libs.lua is "wx-config --unicode=yes --libs std,gl", so if you leave off the "gl" it won't list it either.

[zoot]

I see. I'll try building again with that flag on.

[zoot]

I see. I'll try building again with that flag on.

Okay, now I don't get any errors in Atlas, but the original issue has reappeared Not sure what happened, since it is not likely to have anything to do with GL being enabled. Maybe I misinterpreted the result of my first test of 2.9 and the issue was never fixed in the first place.

[historic_bruno]

I'm ready to consider the original bug something we need to fix in actor editor, if you can't confirm it's fixed with wxGTK 2.9 (it seems like yucky logic and misuse of wxWidgets events anyway)