Messages

Thanks, I got something that works well.

I ended up doing:
leftMousePressed override to toggle into a "moving" mode.
leftMouseReleased override to turn off moving mode.
and mouseMoved overloaded to update the position.

Roughly what I am trying to do:
I have a class which inherits from panel, it is just a big grid.
Inside are child widgets, they are boxes with text etc contained in them.  (They also inherit from panel).

What I want to happen:
When I click on a "box" (child panel) I want to set it as selected.
When I click an already selected box, I want to be able to hold the LMB and move it.
When I click elsewhere on the grid I want to deselect any boxes that are selected.

What I tried so far:
#1.  override leftMousePressed on both the grid, and the box.  In this case the parent "grid" responds and appears to "eat" the event.  The child's method never triggers even if it was under the cursor.

#2.  Do not override.  Both grid and box use "onClick" to call their own methods.  In this case, first the parent and then the child respond to the "onClick". 

So my actual question then, is what is the difference between overriding and signals?  I assume signals are preferred when using stock tgui::widgets, and the override is needed when doing custom functionality.  If I override, then I need to handle passing the event to the child widgets even if I inherited from a widget which normally has sub-widgets?

Unlike with the SubwidgetContainer which forwards all events to the correct subwidget, if you inherit from Widget directly then you will likely have to handle some events yourself.

So I see "panel" is a "container" but not a "SubWidgetContainer", so I guess it also "does not forward"?

I like simple answers.

Thanks.

I'm confused on loading from file.  I know the form builder is/was under major overhaul, but I'm not sure of the current status of what is and is not working.

If I have a text form that looks like:

Code Select Expand

Window: "Form Window"
{
Button: "Button1"
{
ConfigFile = "widgets/White.conf"
Left = 180
Top = 100
Width = 121
Height = 30
Visible = true
Enabled = true
Transparency = 255
CallbackId = 0
Text = "MegaButton"
TextColor = (0,0,0,255)
TextSize = 17
}
}

If I load into the "main gui container"

Code Select Expand


tgui::Gui gui;
gui.loadWidgetsFromFile("form.txt");

I get a button in the middle of my main program window.  What does "Window: Form Window" refer to in the form?  Isnt the gui object already the "window" in this case, with the button being a child in it?  The "form.txt" implies the button lives inside a container called "Form Window".  The C program implies that the button lives inside the container "gui".

If I do...

Code Select Expand


tgui::ChildWindow::Ptr aChildWindow(gui);
aChildWindow->setTitle("Hard Coded Child Window");
aChildWindow->loadWidgetsFromFile("form.txt");


Now the button rides along inside the child window, which lives inside the "gui" container.  What does the "Window: Form Window" refer to?  It seems like a wasted identifier, since the button is living inside "Hard Coded Child Window", but the button doesn't work at all if I strip out the "Window { }" from the text file.

My first try was to hard code containers, and have each one load his widgets from a form file.  This *kind of* works, but I am confused over the nested syntax of the form text files.  (The Window {} part seems redundant and contradictory).

It appears forms do not yet support containers directly.  IE:

Code Select Expand


ChildWindow:
{
       Button: "Yay Im a Button"
       {
        // button stuff
        }
}


If/when they do, I suspect it will help because larger chunks of GUI could be "soft coded" in text files.

Code Select Expand


class Widget
{
public:
    Widget(dp::Gui &gui, const std::string &name);

protected:
    std::string name;
    tgui::Picture::Ptr icon;
    tgui::ChildWindow::Ptr popupWindow;
};

// and in an inherited class...
ConnectionBlock::ConnectionBlock(dp::Gui &gui, const std::string &name) : Widget(gui, name)
{
      popupWindow->loadWidgetsFromFile("Forms/ConnectionBlockPopup.txt");
      icon->load("Images/Icons/db9.png");
      icon->bindCallback(&tgui::Widget::show, popupWindow, tgui::Button::LeftMouseClicked);
}


I can't get the last line to work.  I get a variety of "no matching function for call..." errors.
Should the instance of the object get a &?  I think not, because it is already a ChildWindow::Ptr (it is already an address).
Does it matter that popupWindow is a ChildWindow, and i am binding a function from Widget?  (ChildWindow IS a Widget). 

I suspect I am doing something elementary incorrectly with function binding.

Thanks.

Any function declared on tgui::Widget can be called no matter the real type of the widget. You only need to upcast when you need specific functions like setText.

That's what I was trying to do.  To use .additem from comboBox.

This didn't compile:

Code Select Expand

tgui::Combobox::Ptr comboPtr = dynamic_cast<tgui::Combobox::Ptr>(gui.get("A Combo Box"));
Where are the "Ptr" types declared?  Are they just typedefs for pointers of each widget type?

I also see now that I should check the type of widget before casting. 

I am still learning this C++ stuff and your answers have been helpful thus far.  Thank you.

Your coded solution should work well enough.  I was struggling with casting the returned Widget::Ptr into specific types.  Didn't know to use "auto" like that.

As you said, I don't think adding function binding to the object files is practical.  Binding of the built in "callback triggers" would be a welcome future addition, though.

Me again...

Is there a way to bind callbacks in the object file?
like:
bindCallback(tgui::Button::LeftMouseClicked)

You can set a callback ID in the object file, but it doesn't do anything without loading each UI object with a trigger like above in the C++ code.

Thanks.  I realized I could just call "loadWidgetsFromFile" from the container I want to populate, instead of from the instance of GUI.  Then I can just make a panelName.txt file for each menu.

As an aside: is "ContainerWidget" gone?  Merged with "Container"?  It still appears in the 0.6 documentation.

Can I use the form builder and gui.loadWidgetsFromFile() to create child windows or populate panels?
If so, what is the syntax?  Is there any documentation for formbuilder?

Currently everything created and loaded this way is enabled and drawn by default. 
I am not sure how to create sub menus, option screens, etc.

Is my only option to load the objects, and then retrieve each by name (gui.getWidgets, etc) remove them from the GUI container, and add them to the proper panel/child window container?