originally posted by Stephen Robertson
We never used the lock system, so I don't believe it's been fully tested.
Thanks: I'll try to stay away from it in future.
Just remembered another nugget of peculiarity that may as well go on the list:
The Stream package doesn't work with sound resource files inside zip archives. To use Stream.Play() for audio playback, you need to unzip the sound files directly into the ./resource tree. This applies to the sounds in resource.zip, as well as any you're adding.
[edit]
Found some new GUI voodoo: not sure how generally useful this is, but it's taken me forever to come up with, so it might save someone some time.
You can persuade multiple windows to operate as a single window for focus purposes by making them all children of a single GUI.CreateWindow() that's set to accept focus, and setting the children not to accept focus -- this is pretty obvious. The drawback is that GUI.CreateWindow() objects don't (?) accept input override functions, so you can't assign an on-click event to the resulting composite window. You can't make the grouper window a GUI.CreateButton() because, as far as I can tell, buttons won't accept children. You can overcome this by making the grouper window a lone entry in an invisible list box with all its normal listbox-y features disabled, then using the list box's on-select event as your on-click function:
Code:
// Holder for composite window
grouper = GUI.CreateWindow(x, y, w, h, none);
// First detail sub-window
detail1 = GUI.CreateStaticWindow(x, y, w, h, grouper);
// (...text/texture options for detail1...)
// Second detail sub-window
detail2 = GUI.CreateStaticWindow(x, y, w, h, grouper);
// (...text/texture options for detail2...)
// (...additional detail windows...)
// Listbox to provide on-click event for grouper window
box = GUI.CreateListBox(x, y, w, h, parent, false, false);
GUI.DisableHighlight(box);
GUI.SetListBoxSelectFunction(box, "package.OnCompositeClick");
GUI.AddListBoxEntry(box, grouper);
That's an awful lot of windows to do not much, but it works; if anyone can see a cleaner approach, I'd love to know about it.
[/edit]
[edit]
Another Sunday, another strange and unnatural pog behaviour identified.
I haven't tested to establish that this is always the case, but I've just traced some extremely odd behaviour to the fact a deleted window doesn't seem to behave as a normal bad handle (although Debug.PrintHandle() still claims it is one).
On a window that'd been destroyed by GUI.DeleteWindow() on an ancestor, 'window == none', '!window', and 'window == GUI.Cast(none)' all returned
false. Simplest workaround I could see in this particular case was to test 'GUI.WindowCanvasWidth(window) == 0' instead, which should work as long as you know it can't be true while the window remains current.
[/edit]
[edit]
<sigh> And another one. It appears that INIFile block names can't contain spaces. That probably should have been obvious, but it really wasn't until I realised what was breaking my stuff.
[/edit]
