listresources related issues about gemrb HOT 12 CLOSED

ah, the gist of the issue is the commented out line: selectOptions->AppendContent(selOption)
this needs to be changed to something like: selectOptions->AddSubviewInFrontOfView(selOption);
also the frame for it is wrong. it is set to the bottom of the text view, so you will never see it.

This is something I'm actually working on now related to aafce26

from gemrb.

much of this should be fixed now.

possibly some GUIScript tweaks left, but the actual ability for the TA to list and select options has been restored.

from gemrb.

Did you manage to test this? Voice selection in cg crashes here and the script customisation has several additional problems: removed spacing between items, wrong association between names and descriptions, unresolved names and wrong selection color (green vs orange). Some of this is a guiscript regression, but not all.

from gemrb.

I'll have to checkout master and compare. this is from an old stash so i just went with what was in it.

from gemrb.

The last comparison was with the original, so I don't remember what color was used in master, if at all. The rest worked fine.
This one's from EE, but the basic format is the same:
https://us.v-cdn.net/5019558/uploads/FileUpload/18/ff7b9966ba28f17a54f00e4545562d.jpg

from gemrb.

the crash is via GemRB_Control_SetAction calling TextArea::QueryText, while contents is null. And no, I'm using the English version.

from gemrb.

TextArea::QueryText? I don't see how TA could crash there, it checks for NULL.

I mistakenly assumed that the listing was just the name I guess. easy to fix of course.

from gemrb.

but it doesn't check if Selection() is, though the final frame really was on a bad contents var, I just forgot where.

from gemrb.

#0 std::__cxx11::list<GemRB::Content*, std::allocator<GemRB::Content*> >::begin() at /usr/include/c++/6/bits/stl_list.h:850
#1 GemRB::TextContainer::Text[abi:cxx11]() const() at /home/kajak/games/gemrb/gemrb/core/GUI/TextSystem/TextContainer.cpp:565
#2 GemRB::TextArea::QueryText[abi:cxx11]() const() at /home/kajak/games/gemrb/gemrb/core/GUI/TextArea.cpp:474
#3 GemRB_Control_QueryText() at /home/kajak/games/gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:1319
#4 PyEval_EvalFrameEx() at /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#5 PyEval_EvalCodeEx() at /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#6 PyEval_EvalFrameEx() at /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#7 PyEval_EvalCodeEx() at /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#8 ??() at /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#9 PyObject_Call() at /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#10 PyEval_CallObjectWithKeywords() at /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#11 GemRB::CallPython<int, &GemRB::noop<int> >() at /home/kajak/games/gemrb/gemrb/plugins/GUIScript/PythonCallbacks.h:47
#12 GemRB::CallPython() at /home/kajak/games/gemrb/gemrb/plugins/GUIScript/PythonCallbacks.h:67
#13 GemRB::PythonComplexCallback<GemRB::Control*, void>::operator()() at /home/kajak/games/gemrb/gemrb/plugins/GUIScript/PythonCallbacks.h:130
#14 GemRB::ControlEventHandler::operator()() at /home/kajak/games/gemrb/gemrb/core/GUI/Control.h:74
#15 GemRB::Control::PerformAction() at /home/kajak/games/gemrb/gemrb/core/GUI/Control.cpp:140
#16 GemRB::Control::OnMouseUp() at /home/kajak/games/gemrb/gemrb/core/GUI/Control.cpp:226
#17 GemRB::Button::OnMouseUp() at /home/kajak/games/gemrb/gemrb/core/GUI/Button.cpp:538
#18 GemRB::Window::DispatchMouseUp() at /home/kajak/games/gemrb/gemrb/core/GUI/Window.cpp:263
#19 GemRB::Window::DispatchEvent() at /home/kajak/games/gemrb/gemrb/core/GUI/Window.cpp:352
#20 GemRB::WindowManager::DispatchEvent() at /home/kajak/games/gemrb/gemrb/core/GUI/WindowManager.cpp:358

an easier way to trigger it is to press the Play button in sound customisation of guirec. No content there, nothing selected either, so boom.

from gemrb.

yeah, if you are talking about selections then that makes sense. Assuming NULL selections are a valid state then we can just check that there is one. I assume no selection would just return an empty string.

Now that ListResources returns the list of options it might be nice to handle these cases on the GUIScirpt side. Otherwise its impossible to get the actual text from a TA if it has options (apparently we have no current use for this).

Its easy to just add the value param to the TA selection callback and use it as an index to the list that was returned by ListResources rather then using QueryText() at all.

from gemrb.

Unless you use the same codepath for dialog, no selection shouldn't be a valid state. Except maybe if there are no options. For ambiguous things we could default to the first entry, if there's any such case at all.

from gemrb.

I'm closing this. the only remaining issue I know of is related to some general control value stuff and not specific to resource listings.

from gemrb.