Messages

I'm sorry for not answering, I missed this topic because I didn't get a mail for it. The forum apparently doesn't send multiple mails when multiple topics are created in the same category (so I only saw the other topic that was posted that night), and since the topic was still unread it didn't send a mail on your second post either. (edit: there is an account setting for this apparently, I've changed it so this won't happen again to me)

There is no option to auto-scroll currently, but it can be done manually. Every time you add a line you can call "listBox->setSelectedItemByIndex(listBox->getItemCount() - 1)" then the scrollbar should move to the end. If the line shouldn't be selected then you could call listBox->deselectItem() right after it.

But I'll add a setAutoScroll function in v0.7-alpha2, I'll probably even make it scroll by default so that you don't even have to call anything.

It is/was a documented problem:

Note that this will only change the transparency of the images. The parts of the widgets that use a color will not be changed. You must change them yourself by setting the alpha channel of the color.

But three days ago I finally rewrote all the transparency stuff and the setTransparency function was replaced with a setOpacity function that takes a float from 0 to 1 as parameter which will work for the entire widget.
But since this was done after the alpha1 release you would have to download TGUI 0.7-dev and build the library yourself with CMake.

Are u using TGUI 0.6 or 0.7-alpha1?

Yeah, text size is currently 0.8 * item height.
But a setTextSize function will be added during the internal text rewrite that I have planned for 0.7-alpha2, so you will be able to set a different value in the future. I'm actually starting that rewrite today, hopefully I get it done by next week, otherwise it may have to be delayed several months.

FYI, the registration CAPTCHA on this forum does not work in Firefox.

I'm using Firefox 40 on linux and it works fine here. But I'll keep it in mind, if someone else reports this then I'll change it.

Am I too cutting edge for my own good, or is anyone using similar setup successfuly?

I'm waiting for official VS2015 libraries from SFML before I test TGUI with it.
But I don't see a reason why it wouldn't work, if SFML works then TGUI should work too.

Access violation
The exception happens in tgui::Gui::draw() function

The access violation in the draw functions sounds familiar though, it usually happens when the libraries are incompatible (e.g. mixing release and debug versions or mixing static and dynamic linking).

All optimizations in VS2015 are turned

What do you mean with this exactly? SFML, TGUI and your project should all match the same settings so you might want to try and just compile everything without setting special settings in your project.

Pictures (or any other widget) are now supported as tool tips in TGUI 0.7-dev.

Normal tool tip:

Code (cpp) Select Expand

tgui::Label::Ptr toolTip = theme->load("ToolTip");
toolTip->setText("Don't read this!");
button->setToolTip(toolTip);

Setting a picture as tool tip:

Code (cpp) Select Expand

tgui::Picture::Ptr pic = std::make_shared<tgui::Picture>("Image.png");
pic->setSize(100, 100);
button->setToolTip(pic);

Changing the time to display and the distance between the mouse and the tool tip can be changed through the static functions from the ToolTip class:

Code (cpp) Select Expand

tgui::ToolTip::setTimeToDisplay(sf::milliseconds(400));
tgui::ToolTip::setDistanceToMouse({10, 10});

Obviously Part is mandatory now then.

Yep. The new themes files were not meant to be compatible with the previous ones, I never even thought about just using a Part-rect when there is no "Middle" or "Part" in front of it to make porting v0.6 files to v0.7 easier.

sorry for all of the questions

I don't mind. If I get questions it means that people are using tgui which makes me happy.

I no longer have the pdb files from the alpha build unfortunately, they get erased every time I build a new version and they got overwritten while testing a new build script.

So you would have to replace your tgui libraries (and to be sure the header files too) with the one included in the zip file to use the included pdb file.

https://www.dropbox.com/s/mkfie2n21mbdtak/TGUI-122-ffe014140c5623e46b5eb4d20ced2f57f5f24dd6.zip?dl=1

The pdb files are created when you compile tgui yourself. If you downloaded the precompiled libraries from my site then you should tell me which one and I'll upload the pdb files that were created on my pc. (you probably already told me which version you have but I can't remember who is using what)

Edit: btw, what happens if you put the stuff from "Button.CustomButtonRomeHI" into the normal "Button" section and load that one?

I is supposed to be:

Code (cpp) Select Expand

tgui::Button::Ptr button = theme->load("CustomButtonRomeHI");

without the "Button." in front of it. But I still don't get how you could get an exception WidgetConverer. That object is only created once the button was fully loaded.

Something is clearly wrong but I don't know what it could be. If I have a section called CustomButtonRomeAR then I get the exception "Failed to load widget of type 'custombuttonromear'. No constructor function was set for that type." which is the error that you were supposed to have to begin with.

When I rename the section to "Button.CustomButtonRomeAR" as it is supposed to be and I put the contents from the button in Black.conf there (because it otherwise fails to load your images which I don't have) then it works fine.

The only way to get the exception from WidgetConverter is when you have something like "tgui::EditBox::Ptr editBox = theme->load("ButtonSection")" but the code in WidgetConverter can only be executed after it has loaded it, so it can't happen when the section isn't found.

Perhaps you can narrow it down a little more? (e.g. check if it also occurs when you just have a main function with just creating a button with that that section)

This reminds me that I still have to write a tutorial on the new theme files

The new syntax is:

Code Select Expand

Button.CustomButtonRomeAR { ... }

This is done so that the theme knows what type of widget it should create.

If you just write "Button" it is actually the same as writing "Button.Button".

I'm going to take a closer look at that exception though, because the code was supposed to detect this earlier and throw before the WidgetConverter is even created.

Panels as tooltips is something that will happen, but recursive tooltips are out of the question. In order to have them I would have to keep the tool tip visible even after the mouse moves until it move off the tooltip (which is not that easy to detect since the mouse starts outside of it or on the top left corner, it would easily disappear when trying to move the mouse on it). And I don't like it when tooltips act that way.

So if you want such behavior you will indeed have to implement it in your own code.

Making the tooltip something different than a Label has been requested before.
The problem is currently the design of such functionality, the tooltip should be allowed to be a panel but it should still be as simple as it is now so that you can just set a string without hassle.

If the tooltip can be a panel then recursive tooltips are immediately supported as well.

Maybe I can make two functions: setToolTipText which works like the current one and setToolTip which takes a widget as parameter, any widget whether it is a picture or a panel.

Edit: I have been thinking about a few different ways of implementing it but all of them make using a tooltip more complex. I also realized that the recursive tooltips won't work because the tooltip goes away when you move the mouse.

The code worked for me (although I don't have the exact code since you didn't include the main function, I just created a Test instance and called drawMainMenu on it).

But if I google the error then it seems like a linking problem that causes it to crash on runtime. So based on what I have read it should have something to do with one of those things:
In Visual Studio, did you change any settings about Runtime Library (stuff like /MD, /MT, /MDd or /MTd)? Don't touch these options unless you recompile sfml and tgui for the non-default setting.
If you compiled TGUI, did you keep TGUI_USE_STATIC_STD_LIBS unchecked? Because it should only be checked when you fully understand what it does.
Did you download the v0.7-alpha version for VS2013? If so, are you using the official SFML 2.3.1 VS2013 libraries as well?
You are sure that you are not accidentally linking release libraries in debug mode?

gui.get("mainPanel") will indeed return a Widget::Ptr which is just a typedef for std::shared_ptr<tgui::Widget> which you could cast yourself with std::static_pointer_cast<tgui::Container>. But there is a templated get function that already does exactly that for you:

Code (cpp) Select Expand

gui.get<tgui::Container>("mainPanel")

Obviously this will lead to undefined behavior if "mainPanel" is not of type tgui::Container, you could use std::dynamic_pointer_cast to test that but that probably won't be necessary here.

I removed the background image in panel because there were other ways to achieve the same thing.

If the background is a normal image then you can use a tgui::Picture:

Code (cpp) Select Expand

panel->add(std::make_shared<tgui::Picture>("image.png"));

Since the Picture class can apparently also be created from a sf::Texture you can do this in your code too:
(I almost recommended a 10 line long code using tgui::Canvas before I realized that this could also be achieved with Picture )

Code (cpp) Select Expand

panel->add(std::make_shared<tgui::Picture>(texture));

One question, what is difference between the button pressed and the clickableWidget clicked signal?

The "clicked" trigger is available for a lot of widgets, "pressed" is specific for button. There are two differences, I already mentioned the first one about the pressed signal being triggered when the button is focused and you press space. The second one is about the information you get in your callback: "clicked" gives you the position where you clicked while "pressed" gives you the text of the button. But if you just connect a function without parameters then you won't notice this difference.

Edit: but don't try to focus your button to test this difference, the focus function won't work with any of the themes that tgui ships with.

how does the button widget know that this function gets triggered when the left mouse button is clicked. what if I wanted to do something if the right mouse button is clicked or if the middle button etc ?

Middle or right mouse buttons were never supported (tgui doesn't even process these events at the moment). I basically just renamed LeftMouseClicked to Pressed. There is a small difference between the two because LeftMouseClicked only activated on click while Pressed is also triggered when the button is focused and you press space or return, but since focusing widgets is something that never really functioned well in tgui I guess you could say that it is just a renaming.

You should try to recompile tgui with VS2015.

There is something strange with the dll, the bindCallbackEx uses std::tr1::function instead of std::function while your program tries to load the one with std::function which I can see exist in my VS2013 version. I don't have the VS2015 compiler here so I can't compare it with that.

Edit: I just installed VS2015. If you recompile it and you have the same error then you should send me your SFML libraries, then I can try to build it here with the same libraries and see if I can reproduce it.

This is the only linking error you get, right? No other ones? That's weird so I'm going to need a bit more information.

Did anything else change other than the update to windows 10? A different compiler, different project, different project settings, ...?

Did you download the tgui library or did you build it yourself? What version are you using exactly?
Could you send me the tgui dll so that I can check if it contains the function?

Could you also show me the line in your code where this happens (some bindCallbackEx function call inside your GuiOptions::loadWidgets function) and the declaration of the function that you are trying to bind?

You have to do such things in the constructor initializer list:

Code (cpp) Select Expand

Test::Test() :
    chatbox(gui)
{
}

Of course that means that the window and gui would also have to be put in the initializer list because otherwise the gui may not yet be fully initialized when creating the chatbox.

But alternatively you can just not initialize it in which case it will just be a nullptr and then in your constructor you just add:

Code (cpp) Select Expand

chatbox = tgui::ChatBox::Ptr(gui);

I though mixing debug and release libraries would lead to a crash, I guess it just leads to undefined behavior.
At least next time someone reports that nothing is being displayed I know what he should check first.

There is no way to mark a topic as solved in this forum, although you could edit the subject of the first post and add "[Solved]" to it. But marking it as solved isn't really needed.
I have added a "Topic Solved" button and marked this topic as solved. I guess it can be useful in the future to keep track of which topics are still active.

Can I use part of these images on my site to show as an example of how you can make the gui look? All other screenshots I have are years old or use the default black theme.

The changes (including the one you just asked to add) have been added to tgui.

The changes wouldn't be made at all if you didn't start them, and the code that I improved was always still based on what you wrote, so I think you do deserve the credit.