fix for scrollbar segfaults #251
Reference in New Issue
Block a user
No description provided.
Delete Branch "fix_scrollbar_segfaults"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On the whole this looks fine. I'll probably merge it in for testing purposes "soon" and see how well it runs. If I notice anything wrong I'll mention it then. Until then, here's all my comments from just reading through the diff.
General style points, not high priority as I can change them myself after merge, but if you want to take the time to change them yourself, feel free:
if,while,switch,for, function names, etc<in template parameters (both in defining the template and in instantiating it), nor after the closing>(when calling a template function or using a C++ cast keyword)const someType&instead ofsomeType const &public:,protected:, andprivate:should be indented to the same level as the class header, ie one level less than you're doing.@@ -62,6 +62,10 @@ void cScrollbar::setStyle(eScrollStyle newStyle) {style = newStyle;This name is too long... can we call it something like
set_controlled_rectorset_pane_rect(after the cScrollPane class)?@@ -86,6 +90,190 @@ eScrollStyle cScrollbar::getStyle() {return style;I think this should check both the "catching" / "controlled" rect and the rect of the scrollbar itself. Obviously the former rect can generally be arranged to encompass the latter rect, but in case for some reason it isn't (maybe it's being used as a slider instead of a scrollbar), using the wheel while hovering the bar should probably still work.
This isn't an issue per se but I kinda prefer trailing return types here as it eliminates the need to qualify the nested type:
auto cScrollbar::location_to_part(...) const -> eScrollbarPart(I think this type should basically never be qualified anyway, unless used from outside the class. Well, if it was called ePart instead of eScrollbarPart, I might not mind it always being qualified...)
@@ -45,7 +47,20 @@ class cScrollbar : public cControl {bool vert = true;As with the function to set it, this name is too long. (I think explicitly initializing it also isn't necessary, but it can't hurt either, I guess.)
Also as I mentioned elsewhere, there's not really any need to force it to cover the scrollbar itself.
@@ -2114,29 +2113,19 @@ bool handle_keystroke(const sf::Event& event){}Can you please write TODO comments as
// TODO: ...? Note the colon. (C-style TODO comments are fine too, for the record.)@@ -2123,3 +2121,4 @@location pos(event.mouseWheel.x, event.mouseWheel.y);pos = mainPtr.mapPixelToCoords(pos, mainView);int amount = event.mouseWheel.delta;It's not immediately clear why these were removed, but... I guess they're now set as the control rect of the two scrollbars?
@@ -164,2 +162,4 @@const int UI_LAYER_DEFAULT = 1000;const int UI_LAYER_MENUBAR = 1200;#endifWhy were the other two constants removed here?
@@ -2,9 +2,10 @@#include "boe.global.hpp"This relates to my Mac (Xcode 4) build, but given that it specifically references Boost.Thread which we're no longer using, it's probably safe to remove it.
@@ -41,9 +45,10 @@ bool first_sound_played = false,spell_forced = false;bool party_in_memory = false;std::shared_ptr<cScrollbar> text_sbar, item_sbar, shop_sbar;std::shared_ptr<cButton> done_btn, help_btn;Please use either
TODO:orFIXME:for todo-comments, instead ofXXX.@@ -91,6 +99,10 @@ effect_pat_type current_pat;short missile_firer,current_monst_tactic;short store_current_pc = 0;Again,
TODO:orFIXME:prefix instead of aXXXsuffix.@@ -135,21 +147,65 @@ int main(int argc, char* argv[]) {}}I realize this is a silly little thing, but can we perhaps call this
"transcript-scrollbar"?@@ -167,3 +220,1 @@init_sbar(shop_sbar, shop_sbar_rect, 16, 8);init_btn(done_btn, BTN_DONE);init_btn(help_btn, BTN_HELP);init_ui();Oh, "events_rect" is nice, maybe that can be used as its name within the cScrollbar class. Or something more similar to it.
In fact, at some point probably the entire
init_uicould be moved there...@@ -264,6 +317,7 @@ void handle_one_event(const sf::Event& event) {change_cursor({event.mouseMove.x, event.mouseMove.y});return;Another improperly-formatted TODO note.
I'm probably building with a rather older SFML, too, so this is far from a priority.
@@ -21,2 +21,4 @@virtual bool handle_event(const sf::Event&) override;virtual void draw() override;void update_for_game_state(eGameMode overall_mode, bool party_in_memory);void update_spell_menus();You don't actually need the virtual keyword here as the virtual property is inherited... not that it hurts or anything.
@@ -19,6 +19,9 @@ const int RIGHT_AREA_HEIGHT = 400;const int TER_RECT_UL_X = 6;const int TER_RECT_UL_Y = 19;const int UI_LAYER_DEFAULT = 1000;Seeing this constants duplicated in two places makes me wonder if they should be in the interface header instead...
@@ -66,6 +67,10 @@ extern rectangle terrain_buttons_rect;extern void set_up_apple_events(int argc, char* argv[]);More wrongly-formatted TODO comments.
Feels like there's no reason for the
Mouse_Pressedfunction to even exist anymore...@@ -2123,3 +2121,4 @@location pos(event.mouseWheel.x, event.mouseWheel.y);pos = mainPtr.mapPixelToCoords(pos, mainView);int amount = event.mouseWheel.delta;Yes. And these magic numbers were not even used as-is, they were "adjusted" using .offset before being used.
And this calculation was performed per every mousewheel event processed.
So I removed this and instead use the "already adjusted" values as event catching rects.
@@ -164,2 +162,4 @@const int UI_LAYER_DEFAULT = 1000;const int UI_LAYER_MENUBAR = 1200;#endifThey were introduced during linux menubar implementation, but never actually used. I forgot to remove them then.
@@ -135,21 +147,65 @@ int main(int argc, char* argv[]) {}}done
@@ -91,6 +99,10 @@ effect_pat_type current_pat;short missile_firer,current_monst_tactic;short store_current_pc = 0;done
@@ -41,9 +45,10 @@ bool first_sound_played = false,spell_forced = false;bool party_in_memory = false;std::shared_ptr<cScrollbar> text_sbar, item_sbar, shop_sbar;std::shared_ptr<cButton> done_btn, help_btn;done
@@ -2,9 +2,10 @@#include "boe.global.hpp"done
@@ -45,7 +47,20 @@ class cScrollbar : public cControl {bool vert = true;done
@@ -86,6 +90,190 @@ eScrollStyle cScrollbar::getStyle() {return style;done
@@ -86,6 +90,190 @@ eScrollStyle cScrollbar::getStyle() {return style;done
@@ -62,6 +62,10 @@ void cScrollbar::setStyle(eScrollStyle newStyle) {style = newStyle;done
@@ -264,6 +317,7 @@ void handle_one_event(const sf::Event& event) {change_cursor({event.mouseMove.x, event.mouseMove.y});return;done
@@ -19,6 +19,9 @@ const int RIGHT_AREA_HEIGHT = 400;const int TER_RECT_UL_X = 6;const int TER_RECT_UL_Y = 19;const int UI_LAYER_DEFAULT = 1000;Layer ids are per application values. And since game and editors are different applications I think this is fine.
@@ -66,6 +67,10 @@ extern rectangle terrain_buttons_rect;extern void set_up_apple_events(int argc, char* argv[]);done
@@ -2114,29 +2113,19 @@ bool handle_keystroke(const sf::Event& event){}done
Added note.
@@ -21,2 +21,4 @@virtual bool handle_event(const sf::Event&) override;virtual void draw() override;void update_for_game_state(eGameMode overall_mode, bool party_in_memory);void update_spell_menus();I will leave this as is.
Coordinate translation is a long statement, I do not like having them inline, so I'll leave this as is.
I have adjusted some whitespace as requested.
Please note however that I do not intend, under any circumstances, to use "const before" notation.
Pull request closed