Messages

I obviously cannot know some of the deeper Signals implications as well as you; however, from my perspective as a user, either '4' or '5' seem preferable.
I could even like '2' if the first argument was a strongly-typed enum instead of a 'constexpr char *'. (Efficiency aside, the strings in '1' & '2' just don't feel very C++ & that bugs me. Granted, I don't load any parameters from text files.)

If I had to choose between '4' & '5', I suppose I would have a very minor preference for '5', only because it reads well as english in your example.
And, while you're breaking interfaces and I'm being OCD, would you consider changing 'connect()' to 'assign()'? 

Code Select Expand

5. button->signalPressed.assign(myCallbackFunc);
Or better yet, for '4', you could use an 'operator()(..)' overload in your 'Signal[String?]' struct to make it even more succinct by skipping 'connect()' altogether:

Code Select Expand

4'. button->onPress(myCallbackFunc);
Ooo; yeah, baby.

Thanks for humoring me.

I will add the callback to TextBox

Awesome, thanks! 
This, coupled with 'Signal::setEnabled()', should be able to cover any scenarios I can imagine.

Keeping the lambda, is there a way I can programmatically trigger that callback after calling 'setText()'?
[edit]: This code below works, but surely there's a better way...
  box->setText("hi");
  box->onTextChange.emit(box.get(), box->getText()); // yikes!

Comment:
I agree that consistency is king.
From the standpoint of a user of your library,  I would prefer that widget setters (such as 'setText()') do indeed signal their respective callbacks (if I change the text, programmatically or otherwise, it makes sense 'TextChanged' would be triggered).
I certainly understand your example where calling the callback from within the setter might be less than desirable; however wouldn't you prefer to leave that decision to the user? Perhaps a skip-any-callbacks bool argument for each setter, defaulted (to false?) to preserve the existing interface?
Just my thoughts, though. Thank you for creating & maintaining this helpful library. And thanks for your very prompt replies!

Hi, again.
I've recently switched one widget from an 'EditBox' to a 'TextBox' but it did not behave as I would have thought:

Code Select Expand



//// This responded they way I wanted: to both 'setText()' and to keyboard entry
//auto box{ tgui::EditBox::create() };
//box->connect(tgui::Signals::EditBox::TextChanged, []() { /* worked as expected */ });

// This does *not* respond when 'setText()' is called, but does respond to keyboard entry
auto box{ tgui::TextBox::create() };
box->connect(tgui::Signals::TextBox::TextChanged, []() { /* deaf to 'setText()' */ });

// This only seems to send the "TextChanged" signal when 'box' is an EditBox (not a TextBox)
box->setText("hi");



It appears I could be missing something obvious; might someone be able to point me down the proper path?

[ver 0.8]

Does 'CheckBoxRenderer' exist in ver 0.8? (I notice it once existed in ver 0.7.)

I am attempting:

Code (cpp) Select Expand


#include "header.h"

#include <TGUI/Loading/Theme.hpp>
#include <TGUI/Renderers/CheckBoxRenderer.hpp> // <-- This doesn't exist
//#include <TGUI/Renderers/RadioButtonRenderer.hpp> // <-- This doesn't help

void Implementation()
{
  auto theme{ tgui::Theme::getDefault() };
  tgui::CheckBoxRenderer widgetRenderer{ theme->getRenderer("CheckBox") }; // <-- No such thing as 'CheckBoxRenderer'
  //tgui::RadioButtonRenderer widgetRenderer{ theme->getRenderer("RadioButton") }; // <-- Doesn't affect check boxes
  widgetRenderer.setTextColor(..); // <-- I want to accomplish this
}


I thought perhaps it had been rolled into 'RadioButtonRenderer' but that does not appear to work.
Any help would be appreciated; thanks!